I've used LiveView as it was meant to be used in a couple of small personal projects but in my latest (much larger) project I'm using it in a way that (given what I just read in this post) would make Chris' head spin.
Basically I'm using it as a container wrapper for a large React app and keeping all the state on the client. This is only for the app pages on the site, the rest of the pages are either traditional "deadviews" or LiveViews.
Why?
1. I have a lot of state. Its an accounting app and I want the UI to be zippy. Because I don't want to keep all that state on the server (per user connection) I would have to use temporary assigns to keep the server state small which means lots of queries and data shipping when searching/reordering/generating reports. Nothing beats only shipping the data once over the wire. And I do know about all the hacks to update local lists using components - that doesn't help when I need to use/display the same data in different ways.
2. While I love the expressiveness of Elixir the lack of a type system makes UI development/refactoring much slower for me as opposed to React+TypeScript. Note: I have several years experience in both Elixir and React+TypeScript over many projects so I don't come to this conclusion lightly.
3. Using LiveView is much nicer than using Channels since I can delegate common elements of the page to it instead of replicating it in React. Sort of a Russian nesting doll of rendering. Plus the LiveView is colocated with the other pages in the site which makes it more tidy.
4. I don't have to write an API - its just LiveView messages.
5. I don't care about SEO for the app pages (and explicitly don't want it indexed).
6. I'm using Elixir/Phoenix/Ecto for its best parts - supporting lots of websocket connections and hosting the core logic (and the non-app pages). I shudder at the thought of running a fleet of node apps to do the same.
I'm not sure why I wrote this other than to let folks know that LiveView can be used in ways that might not be obvious from an initial look.
I don't know if would feel comfortable if my accounting apps state was mostly local and if my pc decided to take a nose dive I don't have the state on the server that assumed I have.
The data would be in the server database not in memory hogged by state for each client's active connection.
I seriously don't understand server-side rendering when toasters are more powerful than a mid tier pc i bought 15yrs ago. Why not do apis and just send the data?
Basically I'm using it as a container wrapper for a large React app and keeping all the state on the client. This is only for the app pages on the site, the rest of the pages are either traditional "deadviews" or LiveViews.
Why?
1. I have a lot of state. Its an accounting app and I want the UI to be zippy. Because I don't want to keep all that state on the server (per user connection) I would have to use temporary assigns to keep the server state small which means lots of queries and data shipping when searching/reordering/generating reports. Nothing beats only shipping the data once over the wire. And I do know about all the hacks to update local lists using components - that doesn't help when I need to use/display the same data in different ways.
2. While I love the expressiveness of Elixir the lack of a type system makes UI development/refactoring much slower for me as opposed to React+TypeScript. Note: I have several years experience in both Elixir and React+TypeScript over many projects so I don't come to this conclusion lightly.
3. Using LiveView is much nicer than using Channels since I can delegate common elements of the page to it instead of replicating it in React. Sort of a Russian nesting doll of rendering. Plus the LiveView is colocated with the other pages in the site which makes it more tidy.
4. I don't have to write an API - its just LiveView messages.
5. I don't care about SEO for the app pages (and explicitly don't want it indexed).
6. I'm using Elixir/Phoenix/Ecto for its best parts - supporting lots of websocket connections and hosting the core logic (and the non-app pages). I shudder at the thought of running a fleet of node apps to do the same.
I'm not sure why I wrote this other than to let folks know that LiveView can be used in ways that might not be obvious from an initial look.