Problem
Right now filters are passed to BaseResource.find as an object and are parsed inside every adapter separately.
- Passing object is ugly because we have to create it on AdminBro core and pass to the adapter
- Current filter structure doesn't allow to filter by let say greater than in integers, or by relation.
We have to change Filter instance to a simple filter object with the strict interface.
Interface proposal (example)
type FilterQuery = {
eq?: string,
gt?: string,
lt?: string,
contain?: string, // for like
in?: Array<string>
}
type Filter = {
[path: string]: FilterQuery | Array<FilterQuery> | {and: Array<FilterQuery>}
}
Array would be for "or"
Acceptance criteria
In this task:
- unify the filters programming interface
- the best would be if it will be backwards compatible
- allow adapters to define which operations they support. Mybe some new adapter couldn't support
in?
- it should be possible to filter by nested properties
Possibilities after this change
- we will be able to add
filter to ResourceOptions which will restrict the list/search actions - or to list Action interface.
- we could pass filter in useRecords hook
- we could pass filter in PropertyOptions of the property responsible for handing one to many relationshipp
Problem
Right now filters are passed to BaseResource.find as an object and are parsed inside every adapter separately.
We have to change Filter instance to a simple filter object with the strict interface.
Interface proposal (example)
Array would be for "or"
Acceptance criteria
In this task:
in?Possibilities after this change
filterto ResourceOptions which will restrict the list/search actions - or to list Action interface.