3 ms·
Check out our "temporary assign" documentation – you only hold on to the state you need. That said, you are right that a LV application will necessarily use mor
by chrismccord 7y ago
Check out our "temporary assign" documentation – you only hold on to the state you need. That said, you are right that a LV application will necessarily use more memory than a stateless JSON API, but there is more nuance to the story. A LiveView application will use less resources under application operation than a single page app, for example:
- because LiveViews are stateful, we don't have to refetch/reload the state we need on every "request". Things like current_user, current organization, preferences, etc. So what we lose in memory load, we gain in reduced DB and system load, caching strategies, etc
- because LiveViews are stateful with change-tracking, we actually can send less data than the best hand-written SPA/JSON application you could write. So what we lose in memory load, we gain in reduced latency and overall data on the wire.
Direct link to data-on-the-wire example from my keynote for those curious: https://youtu.be/txk4WAlabvI?t=873 https://youtu.be/txk4WAlabvI?t=873
- verttii 7y agoNot only that, but a lot of the state is essentially the same for many/all users/connections and can be shared. Let's say in a chat app with a Redux setup I'd maintain channel users, messages, own profile details etc. in the app's own local state. With LiveView I'd only need to store the user specific stuff in this user's own state. Some of which I'd store in the socket.assigns of Phoenix Channels subscriptions even now with a conventional Redux setup.