Comments (5)
I agree this would be great. I imagine the API would look something like this:
import { Controller } from 'lux-framework'
class UsersController extends Controller {
filter = {
/**
* @param query Query - The instance of the query builder dsl
* @param value string - The deserialized value from the param in the url
*/
fullName: (query, value) => {
const [firstName, lastName] = value.split(' ')
return query.where({
firstName,
lastName,
})
},
}
}
Ideally this would be backwards compatible with the current filter
property in the Controller
API which is just an array of strings used to whitelist property names. We could expand values using the old API upon application boot. The "de-sugared" implementation could look something like the following example:
import { Controller } from 'lux-framework'
/**
* A naive implementation of how Lux could internally transform
* strings in a filter array into functions that use the new API.
*/
const eq = (key) => (query, value) => query.where({
[key]: value,
})
/**
* Before Expansion
*/
class UsersController extends Controller {
filter = [
'isAdmin',
'firstName',
'lastName',
]
}
/**
* After Expansion
*/
class UsersController extends Controller {
filter = {
isAdmin: eq('isAdmin'),
firstName: eq('firstName'),
lastName: eq('isAdmin'),
}
}
This still needs a bit of thought regarding whether or not the default filters are implicitly added to the filter object amongst other things like exposing utility functions to help with composing custom filters.
Any thoughts on how the public API would look for this feature? My examples above are really just brainstorming.
cc @aortbals @nickschot @jamemackson
from lux.
I tend to agree that filtering by relationship ids/comparative operators should come out of the box.
As for using filters on the related resource, that's a great idea. So /articles?filter[tags][name]=foo
would hit the ArticlesController
, see we're wanting to filter by related tags
and then use the name
filter in the TagsController
. Alternatively, the following in the ArticlesController
could override the filter:
filter = {
tags: {
name(query, value) {
return ...;
}
}
}
Btw, Ember JSONAPISerializer serializes nested filters as filter[tags][name]=foo
, so perhaps we stick to that syntax?
Also, if we're enabling related record filtering, do you think there's value in offering a nice way of sorting on related record values?
from lux.
Also, this is related to #699.
@willviles do you have any thoughts regarding this feature?
from lux.
@zacharygolba @matthewdias - I really like the idea of custom filter params. The suggested API looks great.
With regard to #699, I suppose that's down to whether we think filtering by relationship values should work out-of-the-box, or require a level of explicit configuration.
Consider the example I give in #699, finding users by their permission id: /users?filter[permission]=2,4
. Pretty simple right?
import { Controller } from 'lux-framework'
class UsersController extends Controller {
filter = {
permission: (query, value) => {
let ids = [value.split(',')];
return query.where({
permissionId: ids
});
}
}
}
Adding >
, <
, >=
& <=
comparison operators is a little more effort. Here's a pretty quick attempt at how it may look...
import { Controller } from 'lux-framework'
class UsersController extends Controller {
filter = {
permission: (query, value) => {
let modifier = value.match(/[<>]=?/gA);
if (modifier.length) {
let id = value.replace(modifier[0], '');
return query.whereRaw(`permissionId ${modifier[0]} ?`, [value]);
} else {
let ids = [value.split(',')];
return query.where({
permissionId: ids
});
}
}
}
}
As for filtering by relationship attributes, such as /articles?filter[tags][name]=foo
, that's much more difficult. However, it'd be nice to have a pattern for it without writing raw custom SQL queries.
I like the idea that filters could be implemented in a similar way to computed properties in Ember. Perhaps we could do something like so:
import { Controller, filters } from 'lux-framework';
const {
belongsTo,
eq,
hasMany
} = filters;
class UsersController extends Controller {
filter = {
isAdmin: eq('isAdmin'),
permission: belongsTo('permission'),
tags: hasMany('tag')
}
}
belongsTo
and hasMany
would ensure we look for the right relationship key (permissionId
and tagIds
in this instance).
We could even include a final param options hash to enable/disable aspects of advanced filtering.
permission: belongsTo('permission', { operators: true })
from lux.
Relationship filtering and comparative operators out of the box sounds 👌 to me. We'll need to maintain the functionality of specifying which filters are allowed. Maybe configurable for the related resource, and allowed to be overridden on the parent resource? Also curious about thoughts on ?filter[tags][name]=foo
vs ?filter[tags.name]=foo
. Seems the latter would line up better with inclusion and sorting. (I haven't actually used Lux extensively yet, so I'm just assuming those work that way. Please correct me if I'm wrong.)
from lux.
Related Issues (20)
- Disconnect event not listened to on worker shutdown
- Generate type descriptors for TypeScript and Flow
- Error un cluster module usage
- Offer access to data gathered from queries in actions after they are executed.
- api requests made over https contain links to http endpoints (not https) (when behind a reverse proxy/load balancer)
- Update for changes in remark, remark-lint
- Partial updates with PATCH not working HOT 2
- Updating hasMany => through relationships HOT 2
- (page) links not serialized properly when one of the params is a date HOT 2
- Attribute added in `beforeCreate` hook not serialized into payload HOT 1
- db:create with mysql : unknown database
- Model scope method is not a function
- db seed with mysql database : Cannot read property 'concat' of undefined
- Relationship with falsy ID (i.e. 0) not serialized HOT 3
- Circle v1 not supported after Aug 31, 2018
- [BUG] PK not set properly when creating a record w/ a hasOne relationship HOT 1
- Controller params default to empty array, not to serializer attributes
- Switch from fb-watchman to chokidar
- include nested relationship HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lux.