This comes so timely
On thing I wonder, though.
I tested using (having imported
[:notes, filter(&(&1.id == 1)), :sections, filter(&(&1.id == 2))]
[:notes, filter(&(&1.id == 1)), key(:sections), filter(&(&1.id == 2))]
But that’s not working as expected. So the regular (non-function) key path elements don’t seem to combine with
:get_and_update style functions. Is that true? You know why that is?
Is it the
unzip part that’s missing there?
The gist of the usage is:
- A lens “focuses” desired elements (e.g.
Lens.filter(&(&1.id == 123))).
- Lenses are composable (e.g.
Lens.key(:notes) |> Lens.filter(&(&1.id == 1)) |> Lens.key(:sections) |> Lens.filter(&(&1.id == 2)))
- Lenses can work with
update_in(my_data, Lens.key(:notes) |> ..., &(&1 |> ...))
- No special macro magic required (i.e. no
import). Stock lenses in the
Lensmodule are functions, and you can build your own lenses as function which chain them. There is a
deflensmacro which is a fairly simple convenience helper, but in many cases you don’t need to use that macro at all.
We’ve been using
lens for more than a year to transform and work on a deeply nested structure of polymorphic elements, and it’s been working well for us. If you plan on using it on a larger dataset, I advise to check the performance, because I’m not sure that a lot of effort has been invested in that area.
:notes navigation reaches into a standard Map which does implement the Access behaviour - so the necessary functionality already exists in the
OK, now the picture emerges for me. Thanks so much!
That looks very interesting. Truly powerful.
Once the internal functions start looking lacking for a use-case, this seems a good small toolkit to take on as a dependency. Thanks so much.