Undocumented breaking change in polymorphic_embed_inputs_for/4 - type parameter precedence changed in v4.0

[jonathan-baernthaler]

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)