I would like to start by saying really enjoy this library for it's simplicity and well written type signatures. Many of the other options that try to introduce fp optics include way too much overhead and stop feeling like typescript.
One issue I am running into is that my lenses often lookup data that may very well be undefined and that is not a failure in the prism sense but a perfectly valid value. Can we use a sentinel value (like Prism.FAIL) or similar to require get to explicitly state the intent to fail? This way Lens can still share all of the Prism constructors/composition/etc while still allowing undefined as a valid value. I am a huge fan of the type union approach over wrapping the result in optional or similar in Prism's get and so I think this must stay.
Mainly this breaks during composition but I've been putting together some utilities as well (like filter) that also run into this problem as they use Prismish so we lose the | undefined from the actual projection type.
I would be happy to submit a PR for this if you agree it is a worth-while breaking API change, as I do :)
I would like to start by saying really enjoy this library for it's simplicity and well written type signatures. Many of the other options that try to introduce fp optics include way too much overhead and stop feeling like typescript.
One issue I am running into is that my lenses often lookup data that may very well be undefined and that is not a failure in the prism sense but a perfectly valid value. Can we use a sentinel value (like
Prism.FAIL) or similar to requiregetto explicitly state the intent to fail? This wayLenscan still share all of thePrismconstructors/composition/etc while still allowingundefinedas a valid value. I am a huge fan of the type union approach over wrapping the result in optional or similar in Prism'sgetand so I think this must stay.Mainly this breaks during composition but I've been putting together some utilities as well (like
filter) that also run into this problem as they usePrismishso we lose the| undefinedfrom the actual projection type.I would be happy to submit a PR for this if you agree it is a worth-while breaking API change, as I do :)