JSON:API Parameters

My hope for this project is that whatever api we use to decorate a JSON:API request to include parameters doesn't hide what the eventual url is.

Seeing that full jsonapi url is a helpful way of having confidence that the request building code is doing the right thing.

@brianperry Can you confirm the outcome for this issue is to allow adding query parameter(filter) while retrieving content? If true then we should implement it like below
- get method will have additional parameter filter get(type: string, filter?: [string, any][])
- use received filter to prepare the query parameter.

@pratik_kamble and @CobyPear sorry for the lack of detail here. Yes, the intent was to support all possible JSON:API query params.

Existing projects have slightly different APIs for this.

Drupal State has a params option that allows you to pass either an instance of DrupalJsonApiParams, or a full query string. https://project.pages.drupalcode.org/drupal_state/en/including-related-d... (sorry for the unstyled/busted docs...)

The Next for Drupal client can accept either an object defining the query params (https://next-drupal.org/docs/fetching-resources), or the equivalent result of DrupalJsonApiParam's getQueryObject method.

It isn't completely obvious what the ideal approach is here and I'm open to thoughts. But for the POC I'm leaning in the direction of a params option that is just a query string that is applied to the fetch request. This would allow a developer to construct the query manually, or use DrupalJsonApiParams and convert the result to a query string for use with our params option using getQueryString()

@brianperry @CobyPear, just wondering how cache should work with api parameter. Should we add query param(by doing base64 encoding) in the cache key?

> how cache should work with api parameter. Should we add query param(by doing base64 encoding) in the cache key?

Yeah, a hash of the query string added to the rest of the key makes sense to me.

@coby.sher I have tried to add the base64 encoded query params to cache key. Though it work. I just feel cache key will be too long based on the query params so reverted it.

BTW PR is ready for review.

Reviewed the latest updates. Functionally this looks good to me. However, one thing I noticed was that the use of Crypto (most likely the polyfill) inflates our bundle up to 1.45 MB (from about 2 KB.) I tried removing the polyfill, but as expected the build failed. I also tried a more specific import, but it didn't do much to reduce the bundle size.

Instead, I refactored to use @aws-crypto/sha256-js instead of Crypto. I'd prefer not to add a dependency here, but I think bringing the bundle size from 1.45 MB back down to 2.5 KB is worth the tradeoff.

Automatically closed - issue fixed for 2 weeks with no activity.