You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There needs to be a way to pass in JSONAPI params to actions so that queries can contain filters, includes etc.
I can see 2 ways to achieve this.
Add another 'reserved' tag to the destructured data alongside _jv - something like _jvopts?
Make the arg to actions a (optional) list - the 2nd item of which is query params.
1 means that string args can't have options, unless they're in 'raw' jsonapi form. This could work, but makes it harder to extend this to things like getter params when filtering store lookups. It also means that the opts need to be removed from the object as it enters the store, which is more work.
2 works for both strings and data objects. It keeps data and params separate, though it requires that the arg is always an array, or needs a little bit of introspection - i.e.:
if (Array.isArray(data)) {
[ data, params] = data
}
As to the structure of params, the ideal form is an object with keys corresponding to jsonapi params (filter, include etc). Since some of these aren't strongly defined in the spec (filter and pagination) there should potentially be a param_string key which just contains a list of params which will be verbatim added to the query string. This could even be the first implementation, with specific keys added later where it makes sense to add structure.
The text was updated successfully, but these errors were encountered:
The simplest solution for filtering is to take an optional list, as described above, and just make the 2d argument a dictionary of query params, axios-style. These are then passed to axios as the config object in the form { "params": params }. This is implemented in 6d67dcc
Need to consider whether or not to always make this a full config object (requiring a params key) or whether being able to set these in the initial axios instance is enough...
There needs to be a way to pass in JSONAPI params to actions so that queries can contain filters, includes etc.
I can see 2 ways to achieve this.
Add another 'reserved' tag to the destructured data alongside
_jv
- something like_jvopts
?Make the arg to actions a (optional) list - the 2nd item of which is query params.
1 means that string args can't have options, unless they're in 'raw' jsonapi form. This could work, but makes it harder to extend this to things like getter params when filtering store lookups. It also means that the opts need to be removed from the object as it enters the store, which is more work.
2 works for both strings and data objects. It keeps data and params separate, though it requires that the arg is always an array, or needs a little bit of introspection - i.e.:
As to the structure of params, the ideal form is an object with keys corresponding to jsonapi params (filter, include etc). Since some of these aren't strongly defined in the spec (filter and pagination) there should potentially be a
param_string
key which just contains a list of params which will be verbatim added to the query string. This could even be the first implementation, with specific keys added later where it makes sense to add structure.The text was updated successfully, but these errors were encountered: