mathieuprog
Undocumented breaking change in polymorphic_embed_inputs_for/4 - type parameter precedence changed in v4.0
Summary
During an upgrade from polymorphic_embed v3.0 to v4.0, We discovered an undocumented breaking change in the polymorphic_embed_inputs_for/4 function that affects its public API behavior. While the function signature remains the same, the internal logic for handling the type parameter has changed, breaking existing functionality. This relates to the issue.
The Change
In v3.0, when calling:
polymorphic_embed_inputs_for(form, field, type, fun)
the provided type parameter would always be used for the hidden field generation, regardless of the field's current value. In v4.0, the behavior changed:
-
If the field is nil, the provided type parameter is used (same as v3.0)
-
If the field is not nil, the field's existing type takes precedence over the provided type parameter
this happens in the internal PolymorphicEmbed.HTML.Helpers.to_form/4
Impact on Public API
This change breaks use cases where developers relied on the type parameter to control form rendering with existing field data Specifically:
Our Use Case (Now Broken)
We used polymorphic_embed_inputs_for/4 to:
-
Render different form types dynamically based on user selection (via select dropdown)
-
Allow users to switch between different polymorphic types while editing an existing dataset
Workaround
We had to switch to using polymorphic_embed_inputs_for/2 and manually manage the hidden type fields with the correct value attribute assigned.
polymorphic_embed_inputs_for(form, :my_field, fn f -> hidden_input(f, :type, value: specified_type)
Form fields...
end)
