Inertia configuration mismatch when custom `prop_transformer`

[pedrofs]

I'm doing prop_transformer to maintain naming conventions between React and Rails:

  inertia_config prop_transformer: ->(props:) do
                   # We need to parse to JSON and parse back to force ActiveRecord::Base instances to be serialized
                   # otherwise `deep_transform_keys` won't work on their attributes
                   serialized_props = JSON.parse(props.to_json, symbolize_names: true)

                   serialized_props.deep_transform_keys { |key| key.to_s.camelize(:lower) }
                 end

I'm seeing an issue now with merge and deep merge functionality. The deep merge response result comes with snake_case while the prop is camelCase:

I was wondering if we could expose a similar feature as prop_transformer to expose a transformer for the merges. Or, is there a better way to solve this inconsistency?

Thanks!

[bknoles]

Should we just run the same prop transformer from the configuration on mergeProps, deepMergeProps, and matchPropsOn? I can't think of a reason why someone would want a different transformer for props vs. merge props.

[skryukov]

Inertia will add more keys-related logic, and we will fail repeatedly in updating it. I would simply update the docs with this limitation: "don't use prop_transformer to modify keys, modify them on the frontend using axios interceptors." Or smth like that.

[bknoles]

Well the entire purpose of prop_transformer from #254 is to modify keys. I agree that having the props concept split up into props, mergeProps, deepMergeProps, as Inertia.js now has, makes that feature (and anything touching prop rendering) more awkward.

But short of removing prop_transformer altogether, I'd say that just doing the shotgun surgery is an ok path forward.

(fwiw, my team doesn't use this feature... we serialize with Blueprinter and camel case keys in a transformer)