Bug with double nested forms

[wulffeld]

I think there's bug when using in a form with multiple nested associations. Like a Survey -> Questions -> Answers situation for example.

When clicking Remove the code here https://github.com/stimulus-components/stimulus-rails-nested-form/blob/master/src/index.ts#L34 will grab the first _destroy input which in a double nested situation might be wrong (depends on where you put the remove button) and you'll end up removing a nested child instead of the parent child sometimes.

If the line instead is written like

const input = wrapper.querySelector(":scope > input[name*='_destroy']")

everything works but the precludes that the input element is a direct descendent of the wrapper class. Not sure what the ideal fix would be.

[guillaumebriday]

Nice catch! Can you open a PR with examples and the fix?

[iejfd930r2jfo32]

Hi, I had the same problem.
To resolve the issue, we need to wrap each template within a different div with it's data target and action. And it works

[wulffeld]

Hi, I had the same problem. To resolve the issue, we need to wrap each template within a different div with it's data target and action. And it works

You have two separate relations, which yes, needs two separate setups. The bug I'm talking about is when you need to have deeply nested forms :)

[alexspark]

I ran into this issue as well, but i noticed it where label elements were linking to the first sibling's inputs. What I noticed was that when you have nested nested-form stimulus controllers, the <template>'s NEW_RECORD for new nested associations (2 associations levels deep) all share the same ID as their parent (1st level nested association). it's icky for now but i used stimulus-component's content-loader to load the 2-levels deep so that their NEW_RECORDs get unique IDs from their parent IDs.

[thubamamba]

Hi, I had the same problem. To resolve the issue, we need to wrap each template within a different div with it's data target and action. And it works

Thanks, this solved my issue.