quinten-kamphuis
Hi,
I’m running into an issue with a form inside of my rich editor live component. For the editor I have a button that opens a modal with a link insertion form. The problem is that the editor itself is also rendered inside a form of course. This causes issues and is invalid html right?
First I tried not having a form in the modal but saving the fields values on change in the assigns of the editor component. But pressing enter would still submit the parent form. I experimented with javascript to prevent the enter event but this felt too hacky.
Then I tried moving or “portalling” the modal component to the so that it’s form is no longer part of the form the editor is part of. But I could not get this to work, live view could no longer perform any updates and I believe it lost track of the modal since it was no longer in the same place. I also tried teleport with Alpine.js but I had similar issues here.
Hoping anybody knows a proper solution to handling nested form structures. Or proper live view portalling that would solve this.
Thanks!
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #ai
- #phoenix_html
- #iex
- #elixirconf-us
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming










Showing Posts 1 to 8- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
gushonorato
This is not a Phoenix/LiveView issue; the HTML5 standard prohibits nesting
<form>tags. My first choice to address this would be to find another rich text editor that doesn’t generate<form>tags inside modals. If that’s not an option, could you please provide more details about the rich text editor you’re using and the structure of the parent (LiveView) form?quinten-kamphuis
Hi, Thank you for helping out!
I created the rich editor myself, the problem is not necessarily about the editor, I should’ve been clearer about that. The issue is that I have a modal with a form inside a live component and that live component lives in another form. I can’t really lift the modal portion out. That’s why I tried moving or portalling or teleporting the modal to the body element but this caused issues with live view updates.
I could be wrong, but I feel like this is a fundamental framework issue. Other frameworks and even Alpine.js support simple portal or teleport operations and with react this would be even easier. Not to bash on Phoenix, it’s best, I love it, but if you’re deeply nested in a component there should be a way to render stuff elsewhere to prevent collision or invalid HTML while live view keeps working correctly.
I recreated my situation in a very basic manner to outline the problem better:
cmo
You can split the modal into its own component and put it after the other form in the HTML.
There is talk of portals in the liveview issue tracker, if you want to give your 2c.
quinten-kamphuis
Yes, agreed. Although I would need PubSub or a hook for the modal to talk to the editor. And it does not make sense for the parent component to have a link insertion modal in it, they belong in the editor since they’re tightly coupled.
This is basically the best option for now right? Portals would probably solve this so I’ll take a look at that issue. Thanks for providing your insights!
cmo
I don’t see why showing/hiding that modal or adding a link to the text should involve the backend. I would use a hook for the link adder.
You can look into using a self closing form tags for the outer form so that the editor form id not nested inside another.
quinten-kamphuis
It’s not a question of server vs client side right? In both cases we would end up with either a nested form or highly controlled input fields inside of the wrong form.
And totally don’t understand what you mean with
Forms don’t have self-closing tags according to my knowledge.
cmo
I was speaking a little off topic. Every time you send an event to the backend to change the visibility of an element, a latency fairy dies.
Sorry, empty form tags, not self closing ones.
quinten-kamphuis
Right, pretty clever! But it would make the editor no longer self-contained. Not the biggest issue since I only use it in one place, so this will solve my issue for now. It doesn’t solve the bigger problem though, we should just be able to have self contained components with forms in phoenix without them clashing with the form they’re rendered in, either with portals or something else, right?