Allow arguments

Thanks! Adding arguments is definitely a feature we'll need to add.

I've tried to add the arguments support. Unfortunately I didn't find a good way to get argument map from the request object, so I used routeMatch service, but I hope some better way to do this exists.
Also I spotted one bug, which probably can be a separate issue. I'm always getting sorting from the default display applied. For fixing that I've replaced viewExecutable route param with just a view name string and added code for loading executable in the "process" method.

Re-rolled patch #3 and allowed any type of display to be have router

This will need tests as it's a significant piece of functionality.

It's just a re-roll against 8.x-1.x.

Hello,

With my patch, you can pass arguments to the view using the following structure:
/{jsonapi}/views/{view_id}/{display}?views-argument[]={argument_1}&views-argument[]={argument_2}.

Thanks @ABGEO,

It is a more consistent and simpler solution.

I still see the use case for both options though, so it might be worth collaborating and working on a combined solution?

Regardless, there absolutely needs to be tests for either of these patches to be committed, and if y’all don’t write them, I will have to, and I don’t currently have the time to do that.

Hi @Deciphered, will try to add tests, but it may take some time as I'm able to work on D.org issues only on weekend nights :)

Thanks, @Deciphered,

I will provide tests for my patch.

@Deciphered, I added some tests for this functionality.

#11 works for me

@geek-merlin,

The approach in #7/11 relies on passing arguments via query string, but the traditional behaviour of Drupal Views (like I need to tell you) is to handle arguments by route.

Given that JSON:API Views is already defining routes for the per View display, it would sense to add more route based functionality that is consistent with the traditional Drupal behaviour.

I do agree that it is much simpler though, and I will likely opt to get #11 committed and then move the route based approach to a followup issue.

I'm going to go ahead and commit #11, it works well and has good test coverage.

Thanks for the work, and patience.

I'm open to more work being done, and certainly stand by my reasoning in #14, but the only thing I can see that it specifically adds at the moment is code complexity.

A frontend router can still resolves routes with arguments in the URL and have it sent through to the JSON:API Views using the querystring format.
E.g.: https://frontend.env/view/arg1/arg2 -> https://backend.dev/jsonapi/views/view/display?views-argument[]=arg1&views-argument[]=arg2