Hi, thanks for your amazing content. There is not a lot of elixir content on RUclips and almost no live view content so these videos will be very helpfull to a lot of people. I have been working with elixir for 3 years and have some expreience with live view as well. I love using live view and I could write a lot on why I love it and what are the good things about it, but here I want to discuss some concerns and questions I have about live view. * Websockets and state Ideally, I would love if the state of the page is completely maintained on the server side but with the new live view versions I see the team has introduced the Phoenix.LiveView.JS module, I am not sure but I think this allows us to update the DOM without server network round trip. I would love if you guys would create some videos explaining why this is required and what problems does it solve? Also, while webockets are cool I think to keep our applicatiuon fast we will need to deploy it over multiple regions so that the client has the websocket connection with the closest region, otherwise the connection to the server might be slow leading to slower UI updates through the live view websocket. Making elixir distributed is not that difficult but still creating a distributed setup adds to the complexity. With the usual SPA javascript apps unlike live view not every UI update requires server round trip so they might not face this problem. * Global State When working with live view I have found there is no nice way to maintain a global state for example libraries like react have redux which acts as a global store. With live view if I want to use current_user assigns iniside a deeply nested component I will have to pass it from the top level live view all the way down the component tree. I see some people suggest storing stuff in the Process dictionary since live view works in a single process so all live components have access to the process dictionary. This works however things stored in process dictionary are not change tracked and only socket.assigns are change tracked by live view. I do think we need a nice global state management system with live view. * No javascript Although live view claims that we won't have to write any javascript but I often find myself writing live view javascript hooks to perform common tasks like infinite scroll, etc. This is fine but I would love if it was all elixir but I guess thats not possible always. * New improvements I see the live view team is doing amazing working adding new things slots, JS modules, etc to live view. While this is all great but unfortunately it makes things difficult for people who are using live view in big production applications and want to stick to the lastest standard. They might have to re-write many parts of their live view codebase to use the new things that are added. I prefer to use new frameworks when they have reached a certain checkpoint in terms of stability and I know the team wont be adding lots of new changes to the framework in every few months. * Mobile API and Live view I need a suggestion regarding this. Say we have a graphql api for mobile and a live view for the web app. Now there are 2 options, the live view can either call the context functions directly or use the graphql apis using something live Absinthe.run/3 so that we have a single point of entry to the app. What do you think is the correct approach here? Thanks again for the free content you are sharing with us, I am going to recommend this channel to anyone who is interested in elixir and live view.
Arpan! Thank you for your kind words! I’m reading through your concerns here and ALL of them are very well thought out. I will go through this comment thoroughly and address all of these. I may need two Software Sophistication episodes, but we will get it done!!
Phoenix.LiveView.JS is there for DOM updates where a round trip to the server is an overkill or the update should be _instant_. E.g., showing a modal or toggling a fold.
> Say we have a graphql api for mobile and a live view for the web app. You may need a cut at the business logic interface level. Extract as much of the business logic as you can into reusable modules, then let the mobile app connect to it via graphql, while LiveView connects to it directly.
Often your desktop app does more than a mobile app, and that's where you can be faster with LiveView than the frontend/backend split. However, another approach would be to actually make LiveView your mobile app, via a webview-like native component.
![Jack Harlow - Hello Miss Johnson [Official Music Video]](http://i.ytimg.com/vi/Q86_nlRoIGw/mqdefault.jpg)
Not a lot of Elixir content out there right now. Your explanations are very accessible. Great follow!
Thank you for this!
As there is not so much content on Elixir/Phoenix down here, your channel is welcome in my follow list
Very welcome! We're trying to change that. Elixir and Phoenix are incredible. More people should be using them!
Your answers were exactly what I thought they should be. Really loved seeing confirmations of my own thoughts from a fellow developer.
Arman, heck yeah!
Hi, thanks for your amazing content.
There is not a lot of elixir content on RUclips and almost no live view content so these videos will be very helpfull to a lot of people.
I have been working with elixir for 3 years and have some expreience with live view as well. I love using live view and I could write a lot on why I love it and what are the good things about it, but here I want to discuss some concerns and questions I have about live view.
* Websockets and state
Ideally, I would love if the state of the page is completely maintained on the server side but with the new live view versions I see the team has introduced the Phoenix.LiveView.JS module, I am not sure but I think this allows us to update the DOM without server network round trip. I would love if you guys would create some videos explaining why this is required and what problems does it solve?
Also, while webockets are cool I think to keep our applicatiuon fast we will need to deploy it over multiple regions so that the client has the websocket connection with the closest region, otherwise the connection to the server might be slow leading to slower UI updates through the live view websocket. Making elixir distributed is not that difficult but still creating a distributed setup adds to the complexity.
With the usual SPA javascript apps unlike live view not every UI update requires server round trip so they might not face this problem.
* Global State
When working with live view I have found there is no nice way to maintain a global state for example libraries like react have redux which acts as a global store. With live view if I want to use current_user assigns iniside a deeply nested component I will have to pass it from the top level live view all the way down the component tree.
I see some people suggest storing stuff in the Process dictionary since live view works in a single process so all live components have access to the process dictionary. This works however things stored in process dictionary are not change tracked and only socket.assigns are change tracked by live view. I do think we need a nice global state management system with live view.
* No javascript
Although live view claims that we won't have to write any javascript but I often find myself writing live view javascript hooks to perform common tasks like infinite scroll, etc. This is fine but I would love if it was all elixir but I guess thats not possible always.
* New improvements
I see the live view team is doing amazing working adding new things slots, JS modules, etc to live view. While this is all great but unfortunately it makes things difficult for people who are using live view in big production applications and want to stick to the lastest standard.
They might have to re-write many parts of their live view codebase to use the new things that are added.
I prefer to use new frameworks when they have reached a certain checkpoint in terms of stability and I know the team wont be adding lots of new changes to the framework in every few months.
* Mobile API and Live view
I need a suggestion regarding this. Say we have a graphql api for mobile and a live view for the web app.
Now there are 2 options, the live view can either call the context functions directly or use the graphql apis using something live Absinthe.run/3 so that we have a single point of entry to the app. What do you think is the correct approach here?
Thanks again for the free content you are sharing with us, I am going to recommend this channel to anyone who is interested in elixir and live view.
Arpan! Thank you for your kind words!
I’m reading through your concerns here and ALL of them are very well thought out. I will go through this comment thoroughly and address all of these. I may need two Software Sophistication episodes, but we will get it done!!
Phoenix.LiveView.JS is there for DOM updates where a round trip to the server is an overkill or the update should be _instant_. E.g., showing a modal or toggling a fold.
> Say we have a graphql api for mobile and a live view for the web app.
You may need a cut at the business logic interface level. Extract as much of the business logic as you can into reusable modules, then let the mobile app connect to it via graphql, while LiveView connects to it directly.
Often your desktop app does more than a mobile app, and that's where you can be faster with LiveView than the frontend/backend split. However, another approach would be to actually make LiveView your mobile app, via a webview-like native component.