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
which then overrides our custom implementation if called after our custom initialisation.
We have this set up in quite a few repos but for one of our repos the initialisation process (for some reason I'm not sure of) is reversed and the order of the calls are as follows:
Our custom initialiser is called
graphiti-rails Railtie is called overriding our custom parser
I'm not quite sure what determines the order of the Railtie call and our initialisation but I'm thinking that perhaps the gem should be resilient to this and only assign the transformer if one does not already exist, i.e. instead of the current code:
@svobom57 Unfortunately, I'm not working with Rails at my current job and have no bandwidth to help here. It looks like that may be true for the other contributors to this project as well. If you (or anyone else) have interest in picking up ownership, please let me know. Sorry!
svobom57
added a commit
to svobom57/graphiti-rails
that referenced
this issue
Jan 30, 2024
We are facing a peculiar issue where we override the
jsonapi
parser in order to make the incoming payloadsnake_case
instead ofcamelCase
.We use a solution similar to the one proposed here:
graphiti-api/graphiti#286
where at some point we call:
ActionDispatch::Request.parameter_parsers[:jsonapi] = transformer
Now the problem is that
graphiti-rails
does the same thing here in the Railtie:graphiti-rails/lib/graphiti/rails/railtie.rb
Line 75 in 759db8d
which then overrides our custom implementation if called after our custom initialisation.
We have this set up in quite a few repos but for one of our repos the initialisation process (for some reason I'm not sure of) is reversed and the order of the calls are as follows:
graphiti-rails
Railtie is called overriding our custom parserI'm not quite sure what determines the order of the Railtie call and our initialisation but I'm thinking that perhaps the gem should be resilient to this and only assign the transformer if one does not already exist, i.e. instead of the current code:
run:
The text was updated successfully, but these errors were encountered: