Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Filtering etc on API queries #1

Closed
mrichar1 opened this issue Oct 11, 2018 · 2 comments
Closed

Filtering etc on API queries #1

mrichar1 opened this issue Oct 11, 2018 · 2 comments
Labels
enhancement New feature or request

Comments

@mrichar1
Copy link
Owner

mrichar1 commented Oct 11, 2018

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.

  1. Add another 'reserved' tag to the destructured data alongside _jv - something like _jvopts?

  2. 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.

@mrichar1
Copy link
Owner Author

mrichar1 commented Oct 11, 2018

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

This means that the actions only take params, though there could potentially be other options that might want to go in the config object (see e.g. https://github.com/axios/axios/blob/75c8b3f146aaa8a71f7dca0263686fb1799f8f31/index.d.ts#L41)

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...

@mrichar1 mrichar1 added the enhancement New feature or request label Oct 11, 2018
@mrichar1
Copy link
Owner Author

mrichar1 commented Oct 16, 2018

Decided to use full axios config object in 2d1fe77

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant