You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One potential issue with all of these is that they crash when the focus is undefined (or null). They can also be relatively verbose with more interesting conditionals or path to the data used in the conditional (the examples are really the simplest case). There are several potential approaches to improving these.
One possibility is to introduce Of variants of conditional combinators, such as in the #156 PR. This would allow one to write e.g.:
L.whenOf('type',R.identical('something'))// Using faster `R.identical` operation
The downside of this approach is that multiple new combinators would be needed (don't forget L.all, L.any, L.find, ...).
Another possibility would be to make it so that places where a predicate is now allowed would also allow a lens such as in the #157 PR. This would allow one to use ordinary predicates as before and also allow one to use optics and write e.g.:
L.when(['type',R.equals('something')])// can compose arbitrary predicate as a functionL.when(['type',L.is('something')])// `L.is` can also be used for acyclic structural equality
One downside of this approach is that it might look weird. It also needs to be optimized internally to perform as well as the predicate only approach.
Another version of the previous idea is to allow a traversal in places where a predicate is now allowed and interpret the traversal as a logical or as in the #159 PR. This would allow one to use ordinary predicates and lenses and also allow one to use traversal such as
L.when(['types',L.elems,L.is('something')])
which would pass in case the types field is an array containing 'something'.
Currently I'm somewhat leaning towards supporting the use of optics in conditions, either lenses as in the #157 PR or traversals as in the #159 PR. However, the benefit doesn't seem major.
Note that currently one can, of course, explicitly use L.get and L.or to get (almost) the above behaviour:
One very common pattern I see in code using traversals is uses of
L.when
to filter elements based on some field:The condition also often uses Ramda:
One potential issue with all of these is that they crash when the focus is
undefined
(ornull
). They can also be relatively verbose with more interesting conditionals or path to the data used in the conditional (the examples are really the simplest case). There are several potential approaches to improving these.One possibility is to introduce
Of
variants of conditional combinators, such as in the #156 PR. This would allow one to write e.g.:The downside of this approach is that multiple new combinators would be needed (don't forget
L.all
,L.any
,L.find
, ...).Another possibility would be to make it so that places where a predicate is now allowed would also allow a lens such as in the #157 PR. This would allow one to use ordinary predicates as before and also allow one to use optics and write e.g.:
One downside of this approach is that it might look weird. It also needs to be optimized internally to perform as well as the predicate only approach.
Another version of the previous idea is to allow a traversal in places where a predicate is now allowed and interpret the traversal as a logical
or
as in the #159 PR. This would allow one to use ordinary predicates and lenses and also allow one to use traversal such aswhich would pass in case the
types
field is an array containing'something'
.Currently I'm somewhat leaning towards supporting the use of optics in conditions, either lenses as in the #157 PR or traversals as in the #159 PR. However, the benefit doesn't seem major.
Note that currently one can, of course, explicitly use
L.get
andL.or
to get (almost) the above behaviour:The text was updated successfully, but these errors were encountered: