For the same purpouse I ofter use this https://github.com/calmm-js/partial.lenses
[deleted]
Show HN: JAQT – JavaScript Queries and Transformations
21–30 of 40 posts
Re: Show HN: JAQT – JavaScript Queries and Transformations
#22There 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 )
[deleted]
Re: Show HN: JAQT – JavaScript Queries and Transformations
#23Earlier quoted context omitted.
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.
[flagged]
Re: Show HN: JAQT – JavaScript Queries and Transformations
#24Earlier quoted context omitted.
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.
[flagged]
This is a discussion forum, you know? Different people, different opinions. You can go ahead and use JAQT which I found fine but I prefer to avoid adding external dependencies. I hope it doesn't hurt your feelings too much but the good thing is that you can continuing using JS the way you like.
Re: Show HN: JAQT – JavaScript Queries and Transformations
#25Earlier quoted context omitted.
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.
[flagged]
This is such a weirdly contrarian take. You’re basically saying that everything in context is terrible, and somehow at the same time, on the same basis, that it’s wrong to critique anything because everything is terrible.
That’s certainly a logically consistent position, but it isn’t one that allows much room for anything to improve… or even become a productive discussion.
Re: Show HN: JAQT – JavaScript Queries and Transformations
#26Earlier quoted context omitted.
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.
[flagged]
jQuery provided a DOM manipulation API that was the same in all browsers when there were lots of differences between browser implementations. While you could do everything using standard web APIs, that would be incredibly error prone and tedious at a time when `querySelector` was not a thing yet.
Lodash does way more than some basic functional wrappers. I've seen too many buggy re-implementations of debounce, throttle and groupBy at this point, it's not even funny.
Re: Show HN: JAQT – JavaScript Queries and Transformations
#27Earlier quoted context omitted.
[flagged]
This is such a weirdly contrarian take. You’re basically saying that everything in context is terrible, and somehow at the same time, on the same basis, that it’s wrong to critique anything because everything is terrible. That’s certainly a logically consistent position, but it isn’t one that allows much room for anything to improve… or even become a productive discussion.
No, I am saying don't complain about something only because its an abstraction when likely the person making that comment cannot program without vanity abstractions. Clearly, this is about bias and preference. At the very least people could be consistent in their reasoning.
Re: Show HN: JAQT – JavaScript Queries and Transformations
#28Wouldn'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.
This is actually a pretty decent use case for something like this. You could technically convert a user provided filter function to a string to serialize it, then recreate it using the Function() constructor, but that requires adding 'unsafe-eval' to your content security policy [1][2].
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Re: Show HN: JAQT – JavaScript Queries and Transformations
#29[flagged]
This is an amazing use-case for TypeScript's conditional types: https://www.typescriptlang.org/docs/handbook/2/conditional-t...
Re: Show HN: JAQT – JavaScript Queries and Transformations
#30Earlier quoted context omitted.
This is such a weirdly contrarian take. You’re basically saying that everything in context is terrible, and somehow at the same time, on the same basis, that it’s wrong to critique anything because everything is terrible. That’s certainly a logically consistent position, but it isn’t one that allows much room for anything to improve… or even become a productive discussion.
No, I am saying don't complain about something only because its an abstraction when likely the person making that comment cannot program without vanity abstractions. Clearly, this is about bias and preference. At the very least people could be consistent in their reasoning.
You’re right but arguing with the “add another dependency” people is a waste of time. This just isn’t really a software engineering community.