For me it was building reusable components. It’s a bit harder to design such a component to be that flexible but in the end it helped me a lot reducing code. It’s also simpler to test and maintain. At least for the Frontend there is a WIP library Surface which tackles the problem.

One other thing is to split the concerns. The UI related code is handled in each component while the parent LV is handling only the relevant information of the application. And there you can also split the callback algorithms (logic) in discrete Modules which you can reuse in other Projects.

Hope I could help.

Hey @Menkir! I heard about Surface before, but haven’t tried using it yet. I’ll keep exploring LV until I seed the need to use another abstraction on top of it.

How are you making the distinction between “UI related code” and “relevant information of the application” in your LiveViews? For my scenario, there’s constant communication between the LV and the LiveComponents which compose the LV state. So, everything inside the LV is already part of the UI and the “relevant” portion is handled by application contexts.

What are you defining as “page behavior” for your application? Thanks for the reply!

Hi @bluejay! I haven’t heard of your lib before, I’m definitely gonna check it out. Are you using it in production? If so, what major gains have you noticed so far?

@tfwright I’m also doing the same thing as you - all of the events are handled inside the components, but since I have to keep the main LiveView up-to-date when changes happen, I also have to handle a lot of events in the LV itself, mainly regarding the LV state (idk, perhaps I should break things in more components).

Yes, using it in production and the major gains from my standpoint are as follows (for simplicity I am using the word module to refer to LiveViews and LiveComponents)

1. By declaring all my assigns (as props or state) at the top of my module, I can see at a glance what data the module needs to function. I also have an easy place to look when I can’t quite remember what I named a particular assign)
2. By declaring default/initial values, I can greatly simplify my mount/update callbacks for modules that have a lot of state (or even bypass them entirely)
3. Props are automatically added to a LiveComponent’s module documentation, so I can easily see what props a LiveComponent expects without navigating to and opening the file.
4. Setting props as :required will raise errors if those props are not passed in to a LiveComponent, which helps spot errors more quickly
5. If i have “computed props” inside a LiveComponent, those will be refreshed whenever the props are updated. For instance, the following snippet is for a LiveComponent that expects as :user_id to be passed in, which we use to fetch the user from the database. Anytime the :user_id changes, :user will be refreshed. Again, this saves me from having to write my own update callbacks.

use Phoenix.LiveComponent
use LiveProps.LiveComponent

prop :user_id, :integer, required: true
prop :user, :struct, compute: :get_user! 

def get_user!(assigns) do
  Repo.get!(User, assigns.user_id)
end
  
 # ... rest of LiveComponent