3 ms·
This could use a touch more intelligence to cut down on a lot of the noise. You could eliminate `$equal` and `$match` by looking for regex types and strings.
by tcdent 11y ago
This could use a touch more intelligence to cut down on a lot of the noise.
You could eliminate `$equal` and `$match` by looking for regex types and strings.
You could also take hints from Django and add operations to the keys to eliminate instantiating a new object for `$not`, `$gt` and `$lt`.
So, instead of:
queryl.match({
$or: {
$equal: {
foo: 'bar'
},
$and: {
$not: {
$match: {
foo: /^baz/
}
},
$gt: {
bar: 3
}
}
}, ...
...it would look like:
queryl.match({
$or: {
foo: 'bar',
$and: {
foo__not: /^baz/,
bar__gt: 3
}
}, ...
Seems like this syntax is popular; is there something about this that doesn't work when serializing, or other uses that need the pure-object approach?
- deleted 11y ago[deleted]
- jviotti 11y agoHey there! Your second example was the original idea when building Queryl, however that required me to always inspect the properties of an object, and based on the key, check if it is a Queryl operation (e.g: starts with $ and it's recognised), or a simple property to match for equality. Also, it had the edge case in which a user's object properties could collide with the operations defined by Queryl, which (I believe, didn't write tests for it) doesn't happen with the current approach.