Form Support

[trans]

I was seriously considering using LiveSvelte for my current project. It would be a good fit for my SPA. But I ran into a snag. I could not find any info on how to handle forms -- and I don't mean just a couple of inputs which I can hand code end-to-end form scratch. I have close to 100 inputs in my (tabbed) form, so I need relatively smooth and seamless integration with the backend.

Is there any current thought on how to approach this? Is it simpler than I am imagining? That is, we need a bunch of specially designed Svelte input components made to interface with the to_form(my_struct) data that would be sent to the client?

[woutdp]

Unfortunately there's currently no good way of handling Phoenix forms in with LiveSvelte. I'd be up for adding Svelte specific components that handle Phoenix forms out of the box, but that work hasn't been done. PR's are always welcome if anyone is up for it though!

[trans]

I've decided to take a crack at it. I have been able to translate most of the core components. A few considerations...

1. I would like to add these components to a sub-directory of assets/svelte (eg. assets/svelte/phx/) instead of dropping them directly into assets/svelte/, but then use LiveSvelte.Components can't find them. Here is the related code. What can we do about this? Should it search sub-directores too? And if so, should it/can it adjust the names automatically?, e.g. /assets/svelte/phx/Foo.svelte becomes PhxFoo ? Or should there be an additional key in _opts instead? Maybe a prefix option too to adjust the names if possible?

2. Some of the Phoenix core components have sub-slot structure. I am not quite sure how to translate those to Svelte yet, and according to the README, support for slots is experimental anyway. So I am thinking of leaving these particular components out of the first pull request (for example header).

3. In addition to the Svelte component files, I created a svelte_components.ex module file which acts (almost) as a drop in replacement for core_components.ex. I say "almost" because socket={@socket} still has to be added to attributes. There doesn't seem to be any way around that.

I am going to fork the project and add my work so far, including a usage example utilizing a changeset. Would you like me to put my changes is dedicate branch or is the main branch of my fork sufficient?

[woutdp]

Super cool, thanks for contributing.

1. I'd like automatically adjusting the name to PhxFoo etc if it's possible. You'll need to change the related code you mentioned.
2. I wouldn't do anything with slots. I'd pass props only for now. Slots are a little bit unstable.
3. That's fine.

Main branch of your fork will work! Whatever is most convenient to you.