Fix param handling for nested embeds

[nduitz]

This fixes two things:

a) It picks up the correct action (not from the changeset but from the parent form)
b) It fixes handling parameters for cardinality :many

If you remove the first commit you will see the test is failing and it will produce the incorrect form.
Instead of generating two forms per polymorphic type it will generate only one form for the device type

[rmoorman]

This PR seems to fix some of the immediate form validation problems I was having (even though the issue you were mentioning this PR in (#113) is about polymorphic_embeds_many, and I was having trouble with polymorphic_embeds_one).

There seems to be one failing test though

  1) test form with improved param handling for different param types (PolymorphicEmbedTest)
     test/polymorphic_embed_test.exs:3234
     Assertion with == failed
     code:  assert f.params == %{"ref" => "789"}
     left:  %{"0" => %{"ref" => "789"}, "1" => %{"address" => "012 Oak Ave"}}
     right: %{"ref" => "789"}

I am not sure why this is happening though, as right now I didn't dive deep enough into phoenix form handling yet. Maybe it is happening because recent changes in phoenix html/form handling?

Furthermore, you mentioned in #113 that there were issues with the sort params as well, specifically with the approach taken in this PR.

Did you find some time to have another look at this yet @nduitz ?

[nduitz]

Hey there,
we are currently running this branch in our project which works well so far: https://github.com/nduitz/polymorphic_embed/commits/patch-2

One thing I noticed yesterday which caused me a lot of headaches was that polymorphic_embed_inputs_for does not render hidden id inputs even though we do not specify skip_hidden: true.
Will look into that once we finished implementing all forms and continue to refine them.

[nduitz]

Hey there, we are currently running this branch in our project which works well so far: https://github.com/nduitz/polymorphic_embed/commits/patch-2

One thing I noticed yesterday which caused me a lot of headaches was that polymorphic_embed_inputs_for does not render hidden id inputs even though we do not specify skip_hidden: true. Will look into that once we finished implementing all forms and continue to refine them.

Never mind my comment about polymorphic_embed_inputs_for not rendering a hidden id field. That is the same for the inputs_for implementation of phoenix_live_view. Somehow I assumed inputs_for does this.

[coladarci]

I would love for this to be merged as we just ran into this today and are jumping through hoops to get around it.

[mathieuprog]

@coladarci @nduitz it is currently in Draft status and it has conflicts. Can anyone resolve and test this?

[coladarci]

My fix was off latest release but it appears master is pretty far ahead? I'll investigate how to apply my fix to latest master and open a new PR as a backup.. thanks for the reply! I love this library and find myself going to it in project after project!

[nduitz]

I am actually running another commit in prod right now that fixed all of my issues. Good thing is, I implemented tests for all problems I encountered. I will have a look at it next week, checkout the latest main, apply the tests and see if I can reproduce the issues and fix them again.

[nduitz]

Nevermind, could do it now.

2fcfcbe and 0bd61b5 apply the fixes of the original PR
Additionally I added:
a34caba and ee6d450which show and tries to fix that params are not carried on when using polymorphic_embed_inputs_for
Changes simply get lost in certain cases and are replaced with empty structs.

But I can't remember in which cases. I could investigate more and create a minimal reproduction repo if you want. But that would take some time :)

[coladarci]

Thanks @nduitz !! Yeah I had issues with deeply embedded changesets being nuked.

[nduitz]

With #115 now being merged, this only two commits could be dropped from this. I didn't realize I had another PR open actually :D It's been a while. Sorry for that

[mathieuprog]

I asked ChatGPT 5.4 xthink for a review and it says:

Child error visibility no longer follows the parent form action. In helpers.ex:116 the %Ecto.Changeset{} branch skips apply_action(parent_action), even though the helper’s own contract says a parent with no action should suppress child errors at helpers.ex:144. I reproduced this on the PR head with a parent form whose action was nil: the nested child changeset still had :insert, and the rendered child form exposed validation errors. The changed expectation at polymorphic_embed_test.exs:2803 now locks that regression in.

wdyt?