Genuinely asking as I've had to tackle modification of large deeply nested immutable objects in JS. Because of the large and varied object, I used a generic approach of set/get functions that could take paths using https://github.com/mariocasciaro/object-path-immutable
Use of this lens pattern as given in the article seems to lead to a lot more boilerplate with lenses that have knowledge of object structure, which doesn't seem optimal. So I must be missing what this specific+compositional approach gives over using something like object-path-immutable. Perhaps they are two approaches for two different situations?
Lenses are type-safe, so if you care about type-safety then object/json paths are not really a feasible option. Regarding the boilerplate in this post, that is mainly a side-effect of demonstrating how lenses work. If you use a library like monocle-ts the boilerplate is reduced drastically (see: https://github.com/gcanti/monocle-ts).
Use of this lens pattern as given in the article seems to lead to a lot more boilerplate with lenses that have knowledge of object structure, which doesn't seem optimal. So I must be missing what this specific+compositional approach gives over using something like object-path-immutable. Perhaps they are two approaches for two different situations?