Very timely, I've been working on Svelte integration for Phoenix Liveview, started working on it this week[1]. It's very cool to see LiveView expanding as a paradigm outside of Phoenix.
That's something I need to look into.
- Should be possible by saving the store in the localstorage and fetching it again on a different page.
- Or saving the store to the window[1], as long as the page transitions happen through a live redirect[2] it should still be there.
I'm building a collection of examples[3] and if I can get it working I'll add it.
Yea, for sure it should be possible to do it with local storage but the real cool thing would be to be able to keep state in js between live redirects. Like you said it should be possible if using live redirect. Would love that. Good luck! Hope to be able to use your library in the future.
Hey, I got a simple example of using stores where you live redirect between 2 liveviews but the store information is kept. Was able to do it with saving the store to the window:
We're using our own protocol right now - haven't really looked too deeply at the Phoenix protocol. We use templates (like Solid or Blockdom) to build and patch the page which is pretty specific to Dioxus.
Cool. We went with re-using/adopting Phoenix's because it is battle-tested and allowed us to not have to rebuild/find edge cases on browser event handling and DOM morphing and optimizing diffs. If you ever want a walk through lmk.
I would support liveview defining the entire process. I've written a lib myself to do liveview type things and coming up with a solid descriptor for things like conference talks was basically impossible. I write a lot of elixir and I would presume "phoenix liveview" is probably what people use to describe the elixir lib to people outside of the ecosystem anyways.
Also I feel like the BytecodeAlliance too much focus on their cloud runtime use case while seamless wasm + dom interop is where its adoption will skyrocking. I would rather write Rust/Go/Roc/any-sane-typing instead of TS.
It's okay. It actually produces the smallest wasm binary size AFAIK. I'm just tired of niche languages already. If I were to go niche why not https://grain-lang.org/ ? It's even a wasm-first lang. Zig is also good and produces small wasm binary. That said, I think Rust/Go is fine.
AssemblyScript seems like a pointless also-ran. Why pick a language with very little support or community for your native code when you could pick Rust or C++? For any substantial app, I think an investment with Rust would be much better than an equal sized investment into AssemblyScript.
I think Rust will be around in 5 years. Will AssemblyScript?
LiveView is just updating the HTML DOM through a websocket. Instead of using a conventional API, everything happens through the websocket.
This way you can write server side templates to update the client automatically on server side state changes without needing to use an API on the client to fetch the state or even manipulate the state.
The state of the app lives in an async task which can be multithreaded or distributed. Rust webservers can handle tens of thousands (hundreds of thousands?) of connections at once.
[1] https://github.com/woutdp/live_svelte