Get rid of morpdom for svelte templates

[dkuku]

I love the idea of having a dedicated sigil for the templates but I just looked at the payload with the svelte template and it sends the whole props for the todo list. Maybe removing the morphdom from the svelte templates may be a good idea and just consume the messages directly - I think live view native allows created a common library for different types of clients - https://native.live/

You may also have a look at https://github.com/hansihe/live_data - https://www.youtube.com/watch?v=I4vVxtrow-E https://github.com/Miserlou/live_json

[woutdp]

I'm definitely up for a better way of passing props, as we don't need morphdom with live_svelte, we might be able to do something more clever and faster like live_data or live_json. Especially when handling bigger payloads, this should bring an improvement in speed.

Some things that should stay the same:

• It shouldn't make it harder to setup
• It should be possible to use both a sigil and component based
• It should support deadviews - live views - phoenix components - live components (like it does now)

PR's are super welcome!

[woutdp]

I'm working on a project that sends a lot of data to LiveSvelte. It's obvious in that project that we'll need to optimize this a bit so it only sends the data that got changed instead of the entire thing.

live_json seems the way to go.

[woutdp]

https://github.com/phoenixframework/phoenix_live_view/issues/2695

[woutdp]

It's actually not so easy.

Since we're using function components, we don't have access to the socket. Morphdom happens inside the LiveView layer.

Moving away from function components means that dead views won't work anymore.

Another approach is having 2 components, depending on if we're in a LiveView or not.

[woutdp]

https://github.com/phoenixframework/phoenix_live_view/issues/2695#issuecomment-1591883401

You can have the same function component and have it render the LiveComponent internally. You need to ask users to pass the @conn or @socket as a context={...} attribute and then render accordingly (or ask them to pass the value of connected?(socket)).

I think this is the best approach. It adds one extra field the user has to set to make things work though... I think the api is quite clean now. I'll let it ruminate for a bit in my head.

[conn]

I think you should ask me first before asking users whether they want to pass me around. I should at least have some say in this!

[woutdp]

Seems fair, should have asked you first, my apologies

[dkuku]

@woutdp You can also check how liveview native plans to solve this-I know that they plan to allow to have multiple implementations of the frontend code.

[woutdp]

I cooked up something in https://github.com/woutdp/live_svelte/commit/7df27c86cfb6159b5b72534722b1a0b3fb21f670.

It doesn't make it so morphdom isn't used anymore, instead it allows the user to choose when to use LiveJson. This requires the user to setup LiveJson in their own project.

I couldn't see a solution where we could automatically always use LiveJson instead of morphdom, but at least there's the option now to configure it manually. It seems to work, but I'll try it in a production project first and if everything is working I'll document it.

[woutdp]

Closing it for now. live_json is now supported, but it's opt in and requires a little bit of setup, outlined in the readme. So if you want to use it, it's there, but morphdom is the default.