For the same purpouse I ofter use this https://github.com/calmm-js/partial.lenses
Show HN: JAQT – JavaScript Queries and Transformations
11–20 of 40 posts
Re: Show HN: JAQT – JavaScript Queries and Transformations
#12Wouldn't the query for your example just be data.filter(d => d.friends.includes("John")).map(d => ({name: d.name+" "+d.lastName})) Maybe I'm missing the bigger picture, but that doesn't seem so bad
one of the cases something like this is useful for is when you have user configured saved 'filters' - you can simply pass the stored object into the where clause. I agree if you're doing hard-coded queries on arrays of objects, this may not add a lot. That said, a consistent syntax for doing searches and mapping is useful - projects like lodash have that as part of their api too.
Re: Show HN: JAQT – JavaScript Queries and Transformations
#13can a query like that be observable? so updating the array/object would cause the results to update?
I don't know if RxJS has run out of fashion, but that would give you observable js using map/filter/reduce etc.
Re: Show HN: JAQT – JavaScript Queries and Transformations
#14There is another excellent write-up exploring the theory / use-cases for such libraries https://www.inkandswitch.com/cambria/ (and a corresponding library at https://github.com/inkandswitch/cambria-project)
Re: Show HN: JAQT – JavaScript Queries and Transformations
#15Thanks. Looks really useful.
Re: Show HN: JAQT – JavaScript Queries and Transformations
#16[deleted]
Re: Show HN: JAQT – JavaScript Queries and Transformations
#17[flagged]
Re: Show HN: JAQT – JavaScript Queries and Transformations
#18Wouldn't the query for your example just be data.filter(d => d.friends.includes("John")).map(d => ({name: d.name+" "+d.lastName})) Maybe I'm missing the bigger picture, but that doesn't seem so bad
I liked JAQT API but it is not really good to create a layer on top of already simple functional constructors.
Why is that not good? JavaScript is full of layers of unnecessary abstraction often for completely superficial reasons and sometimes even irrationally applied at great cost in defiance of evidence and simplicity. So, what makes this specific example less good than all the other countless examples of abstractions most JavaScript developers would happily die to defend?
Re: Show HN: JAQT – JavaScript Queries and Transformations
#19Earlier quoted context omitted.
I liked JAQT API but it is not really good to create a layer on top of already simple functional constructors.
Why is that not good? JavaScript is full of layers of unnecessary abstraction often for completely superficial reasons and sometimes even irrationally applied at great cost in defiance of evidence and simplicity. So, what makes this specific example less good than all the other countless examples of abstractions most JavaScript developers would happily die to defend?
because in the past it didn't have those functional constructors so things like underscore or lodash would be needed but adding a layer as you mentioned. It is not good, for me, to add a dependency for this again. But in the end I have in my utils file a few functions that basically do what JAQT does and I might copy a few more.
Re: Show HN: JAQT – JavaScript Queries and Transformations
#20In a similar vein is https://pbeshai.github.io/tidy/ which I've used for 3+ years. It's a really nice lightweight transformer. I've also used https://github.com/uwdata/arquero once (better performance for large datasets).
[deleted]