Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Form recovery not working when targeting forms in Live Components #3527

Open
ammancilla opened this issue Nov 26, 2024 · 6 comments
Open

Form recovery not working when targeting forms in Live Components #3527

ammancilla opened this issue Nov 26, 2024 · 6 comments

Comments

@ammancilla
Copy link

Environment

  • Elixir version (elixir -v): 1.15.7 (compiled with Erlang/OTP 26)
  • Phoenix version (mix deps): 1.7.14
  • Phoenix LiveView version (mix deps): 0.20.17 - a61d741f
  • Operating system: mac OS - sequoia
  • Browsers you attempted to reproduce this bug on (the more the merrier): Firefox, Chrome, Safari.
  • Does the problem persist after removing "assets/node_modules" and trying again? Yes/no: Yes

Actual behavior

A recoverable form rendered through a Live Compnent does not recover after a Live View crash/disconnect. In fact, not only the form does not recover but the Live View remains broken with:

no component found matching phx-target of 1 undefined

Demo 🎥

deterministic

Expected behavior

A recoverable form rendered through a live component, recovers successfully after a Live View crash/disconnect.

Solution

The bug was resolved in Live View 1.0.0-rc.7 through commit 628f885. Unfortunately, this fix was not included in the LiveView ~> 0.20.7 release. Therefore, my question is: Would it be possible to backport the fix and release it as part of the 0.20.x series for users who are unable to upgrade to Live View 1.x.x?

@drtheuns-enreach
Copy link

Experienced the same issue. Worked around it by changing the phx-target to a selector to the live component.

@SteffenDE
Copy link
Collaborator

@ammancilla can you elaborate on why you are unable to update to 1.0?

Concerning backporting, that's up to @josevalim or @chrismccord :)

@ammancilla
Copy link
Author

@ammancilla can you elaborate on why you are unable to update to 1.0?

Concerning backporting, that's up to @josevalim or @chrismccord :)

Hey @SteffenDE ,

The main two reasons at the moment are:

  • The final version 1.0.0 is not there yet.
  • Project dependencies that depend on ~> 0.20.17 and who knows when they will support version 1.0.0.

@SteffenDE
Copy link
Collaborator

The final version 1.0.0 is not there yet.

There is no difference in stability between the 1.0 release candidates and any other release we did in the past. Looking back, I do think we should have done a 0.21.X instead of naming them 1.0.0-rc.X, but it is how it is now.

who knows when they will support version 1.0.0.

Apart from the phx-feedback-for changes, there is no backwards incompatible change in 1.0 compared to 0.20, so if you use the shim mentioned in the changelog, you should be good to go. I encourage you to try moving to the RCs. You can add override: true to your dependency declaration to use the latest version even if a dependency officially only declared support for 0.20.

I think it is also worth mentioning that we do rely on people trying out the RCs to find issues and report them. While we try our best to not mess things up, sometimes unexpected issues do still arise. So if you find any issues when updating, please open an issue!

@ammancilla
Copy link
Author

ammancilla commented Nov 26, 2024

The final version 1.0.0 is not there yet.

There is no difference in stability between the 1.0 release candidates and any other release we did in the past. Looking back, I do think we should have done a 0.21.X instead of naming them 1.0.0-rc.X, but it is how it is now.

who knows when they will support version 1.0.0.

Apart from the phx-feedback-for changes, there is no backwards incompatible change in 1.0 compared to 0.20, so if you use the shim mentioned in the changelog, you should be good to go. I encourage you to try moving to the RCs. You can add override: true to your dependency declaration to use the latest version even if a dependency officially only declared support for 0.20.

I think it is also worth mentioning that we do rely on people trying out the RCs to find issues and report them. While we try our best to not mess things up, sometimes unexpected issues do still arise. So if you find any issues when updating, please open an issue!

Thanks!

There are certainly a few ways to stay on 0.27.x and get form recovery working without requiring a backport. Additionally, you provided a helpful tip on upgrading to 1.x.x by leveraging override: true to manage dependencies that haven't been updated yet. That said, I'm okay with you deciding to close the issue, though it would still be great to have a fully functional form-recovery feature in a 0.27.x release.

@SteffenDE
Copy link
Collaborator

I'll keep this open to see if we might get feedback from José or Chris. Personally, I'd like people to not stumble into this (long fixed) bug on 0.20, but I don't do the releases. That being said, there are also other bugs that are already fixed, so it's not always easy to decide what is worth backporting and what not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants