Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
FEATURE: Make fizzle filter operations capable of dealing with arrays #1082
This commit amends the implementation for the
If the given property is not an array the filter operations behave the same way as before.
Sep 22, 2017
changed the title
WIP: FEATURE: Make fizzle filter operations capable of dealing with arrays
Oct 3, 2017
Hey @p-weisk, thanks for your contribution. I can see the use case for this behavior, although doubt it's a very common one. However the behavior is not intuitive if you ask me and there's nothing similar in jQuery as it DOM doesn't have array properties, hence I'm a bit reluctant about adding it.
Another way to achieve what you're doing is to do s.th. like
Would that work for you or does it need to be an EEL filter?
I'm with @aertmann here, mixed feeling ... not sure if we want this in the core ... Array.first/last can be use and the synthax is clean an easy to read.
But there are cases where more advanced operator can make a lots sense, like in postgres your have the
This kind of operator can make sense. I think we don't need to be too dogmatic about "it does not exist in DOM query" ... because we don't query the DOM here, but we can deal a lots with JSON style structure. So maybe taking some inspiration from Psql can be good, like:
I have to say, I like the transport of the known operators "contains" (
Still not a fan of the proposal I must say. The syntax just doesn't feel natural to me and it can be achieved in other ways as I explained. The point is not that we're not working with the DOM here, but that jQuery struck a good balance between functionality and API surface area. If this is a very common use case that would be difficult to solve in different ways, then the proposal makes sense. I just don't see that being the case here.
Food of thought, this change doesn't include any documentation. I don't think we can really make a decision without seeing how well this proposal fits with the overall documentation/concepts.
Sorry for being the devils advocate here, but we should always be conservative when deciding on a end user API.
Sep 7, 2018