Closed panbanda closed 6 months ago
Thanks for the solution suggestions. Unsure on which one to go with at the moment 🤔 Wondering if there’s any consistency to how other frameworks handle Arrays in POST. Will have to dig into it.
Yeah totally get it. I wonder if there is a way to just defer the merge params? So its a method and merges when it is called rather than in an earlier middleware? I think other frameworks just allow you to grab the body
data and it doesn't get merged into a variable with query and body together. However, in my case, I wouldn't need the params I would just need the body but its failing before the action is called.
No longer applies. Jets 6.0 deploys a Rails app now. So whatever that's needed can just be implemented as a Rails engine or plugin, etc.
Related
Checklist
jets upgrade
command that makes this a simple task. There's also an Upgrading Guide: http://rubyonjets.com/docs/upgrading/My Environment
Expected Behaviour
Allow POST with an Array for a body, but allow developer to deal with it manually
Current Behavior
I have an angular apollo batch http request that batches requests from the frontend for multiplex processing on the backend. This library used to send a [:_json] parameter but now it looks like its just sending the post body as an array. This causes issues in the initialization functions for deep merging the parameters of body into the
params
as it treats it as a hash.Step-by-step reproduction instructions
lib/jets/controller/params.rb:20
Code Sample
An example body payload that causes issues:
Solution Suggestion
https://github.com/tongueroo/jets/blob/master/lib/jets/controller/params.rb#L20
I think its as simple as adding this to the line in order to avoid deep merging an array and expect the developer to deal with
body_params
manually if it's an array. The body can probably also be refactored into a hash [if array -> set :json with array]