TLDR; A recoverable form rendered through a Live Component doesn’t recover after crashes or disconnects.
DETAILS
Specifications
Phoenix 1.7.14
LiveView 0.20.17 && 1.0.0-rc.7
Context
A form is being rendered through a Live Component. It fulfills the requirements to be recoverable after crashes and disconnects, as per Form bindings — Phoenix LiveView v0.20.17
Has an ID.
Is marked with phx-change.
all forms marked with phx-change and having id attribute will recover input values automatically after the user has reconnected or the LiveView has remounted after a crash.
Expected Behaviour
After the live view crashes or disconnects, the form rendered through the Live Component is recovered.
Current Behavious
After the live view crashes or disconnects, the from rendered through the Live Component is not recovered.
Hello , can’t try it right now, but don’t you need to use the same id for the form in the live component? You will end up with a different id when you render the live component after the crash, no?
The second thing that I noticed is that using a deterministic ID (i.e “unique-form-id”) for the form, would result in the Live View not recovering at all from the crash or the disconnect but failing with:
no component found matching phx-target of 1 undefined
I had to use a completely random value as the ID of the form, otherwise the live view wouldn’t recover at all from the crash/disconnect but rather fail with:
no component found matching phx-target of 1 undefined
You should still be generating distinct ids for each logical form in the assigns and then using that assign in the template. You’re going to get super weird behavior doing an impure call like that in the render itself, which is supposed to be deterministic from the assigns.
I can’t comment on the error you’re getting with a hard coded value, but I would definitely chase down that error and not go with an impure render, which is explicitly called out as a bad idea in the docs.
Please try with a constant ID and see if that works. Because right now on a fresh render the Live Component passes a different ID to the form which does (of course) not match the ID stored in the browser and the whole recovery process goes haywire.
I can’t comment on the error you’re getting with a hard coded value, but I would definitely chase down that error and not go with an impure render, which is explicitly called out as a bad idea in the docs.
Yes, that makes sense. I’ll revise the original post to emphasize on the Live View crash happening when using static IDs under this scenario.
I just tried your code, with LiveView 1.0.0-rc.7 and Phoenix 1.7.14 and I can’t see any problems. No matter if it’s a crash or disconnect/reconnect, the forms are recovered correctly. This is by taking your code almost as is but changing the id of the form in the live component to be static (id="sub_form").
I was recently looking to confirm that fact and MDN seems to suggest that this is not actually the case that plain numbers would be invalid IDs. They might just need excaping to be used in css selectors.
After reading your comment, I tried the code again on LiveView 1.0.0-rc.7 and the form is recovered as expected. On the other hand, the error keeps happening on LiveView 0.20.17 when using static IDs.
no component found matching phx-target of 1 undefined
I wonder, did you manage to test the code on version ~> 0.20.17 too?
In the scenario I described using LiveView 0.20.17, I consistently encounter the error, even when using a static ID that is neither an integer nor contains integers. The live view fails and does not recover, displaying the mentioned error.
I verified and can confirm that the error does not occur with LiveView 1.0.0-rc.7.