I mean, it just means they needed to be trained in a different way 
My first real experience with React was on a greenfield project that started roughly two weeks before hooks where officially released (which we immediately switched to) and we ended up creating a rabbit hole of side-effects (though possibly that was always a problem with React). I suspect a lot of confusion around LiveView’s model is largely from people being used to React. Conversely, one reason LiveView clicked quickly was having a single parent that is in control and I’m sure that has everything to do with using a similar concept back in my PHP days (“page controller” that fetched data and passed it down to “blocks”). That was a framework created by a co-worker… there was even a way to do JS without writing any JS
sodapopcan
garrison
Oh yeah for sure, in particular you still have to be trained about when to lift state up and so on. But I think it makes it easier since there is no “component dichotomy” to worry about. And it’s nice to be able to switch between a stateless/stateful component just by adding/removing a line of code. I believe this was a design goal for them.
I would imagine this is mostly orthogonal to which framework you’re using. Having a “single parent” as you say is more a hallmark of a simple app. Of course it always feels better to work on something simple, before things spiral out of control 
It would be perfectly valid to design a React app with a single parent holding all the state, where all other components are pure function components. But as the app gets larger this is impractical, and it’s the same way in LiveView.
Really LiveView is very similar to pre-hooks React, with a few unfortunate warts that make it compose a bit worse. I do think LiveComponents having global ids is a mistake, now. I’m not sure if it’s something that should be corrected, or if we should create a new type of component, or if we should leave LiveView as it is and build something else.
One path would be to add something like React’s hooks to function components and get rid of LiveComponents. Essentially do exactly what they did. That’s what I was alluding to, there.
sodapopcan
You would have to define “simple” here as I personally wouldn’t characterize anything I’ve worked on professionally as simple. I don’t mean “single parent” for the whole app (ie, not “SPA”) but single parent per “page.” At the same time, I’ve worked on an SPA-style LiveView that was pretty massive and had all the callback handlers in one place. It’s a whole other conversation around notions of file size but I personally really liked that. In my spaghetti PHP days we used to have an actions.php which just every single side-effect the app did in one file (delegating to functions calls, of course, just like handle_event) I may not be properly addressing what you’re saying here, though.
But ya it certainly does depend on what you’ve worked on and how you like to structure things. The React app I worked on for 2.5 years was a very complex gantt chart for scheduling shift work (the chart itself was off-the-shelf thankfully but there was a lot more to it). It was components calling components calling components with side-effects at all levels, and too much stuff shoved into context (which is something I’m hoping HEEx never gets). Everyone on the team was pretty competent so it wasn’t as bad as it could have been, but still not fun to work with. I would have much rather had the giant parent controlling everything with properly composed components at the top level to reduce (or completely remove) the need for react context.
But ya again, I’m sure many are side-eyeing the heck out of me right now.
garrison
I don’t mean that there’s some sort of “simple cutoff”, just that as complexity increases it becomes much harder to keep all of your state and business logic “in one place”, without factoring it out into abstractions. I think we all have a good idea of with simplicity and complexity feel like in our code, even if we can’t give an exact definition, though I know some have tried.
It’s a bit different when you can cleanly factor things out into “pages”, as that is of course one way to break up an app. The sort of “desktop app experience” I personally covet (as you have probably noticed) doesn’t quite work this way, though, as more interactive apps tend to have the same components appear in multiple places, or all at once. There is still a notion of “screens” of course, but you need the ability to compose components. Generally in an old-school form-driven webapp you don’t compose pages (iframes notwithstanding…); it’s a different UX.
When you mention using LiveComponents for a search/select input, for example, that is a component you’re composing. But imagine you want to include an entire “new comment” form inline under a post, but also inline replying to another comment. You could split it off to an entire new page, but that’s a clear UX compromise.
You could use a function component, but let’s say it renders markdown (on the server, this is LiveView after all). So it needs state, and event handlers, and the ability to mount and unmount itself declaratively based on the template.
In the limit, if you want highly interactive apps that feel like desktop apps used to, you need components that can compose, declaratively. LiveComponents almost can except for the global id thing. Function components definitely cannot, as the OP demonstrates.
Definitely not, your experience is still valid! But I think you have to keep in mind that you could just as easily recreate a spaghetti React app in LiveView if you wanted to. It would be, mostly, the same. It’s on the craftsman, not the tools
josevalim
Hi @slouchpie, we should probably have an option that allows you to replace the existing hook, so you don’t need to do this dance:
|> attach_hook(hook_name, lifecycle_function, &handle_event_hook/3, replace: true)
Which basically says that, if it already exists, replace it. A PR is very welcome (please ping me if you do). The reason we raise is to avoid accidental overlaps but in this case it is very intentional.
I am very willing to accept that once we use more hooks, we will see some cracks in that approach too, but I really don’t think this thread is one of them. We have a safety in place, which is easy to bypass with detach_hook, and we can improve it further through pull requests.
I honestly regret writing that comment because many have read “LiveComponents being overused” as “LiveComponents being useless” while they still have many use cases. The goal was mostly to have folks discuss and evaluate alternatives.
To be clear, if you don’t have state, a function component should always be preferred over live components. When it comes to live components vs hooks though, my go-to canon is this:
-
Live components are great for sharing parts of your application (such as a form embedded in different places, as you mentioned) or encapsulating complex parts of a page. They usually interact with specific parts of your domain.
-
Hooks are great for creating abstractions that are meant to be generic and focused more on the UI.
However, it is completely fine if your team arrives to a different conclusion. The most important is what you have said before: “also motivated by discussions here with my team, we started to investigate how to refactor parts of our app”. Discuss between yourselves, try a couple of approaches, and then establish the pros and cons based on your experience in your project. And if you can share them later with the community, I am certain it will be very valuable.
sodapopcan
garrison
I’m not entirely sure about this. The problem in the OP is a key collision, which is a direct result of this pattern not properly composing. Maybe in this case making the attach idempotent obviates the problem, but there are cases where you would want both hooks attached. I think this is a symptom that something is wrong, somewhere.
I would like to amend my first reply to this thread: I do not think the pattern you posted is a mistake. Actually, I think what has happened is we have discovered the very same problem the React community discovered many years ago: you want the ability to re-use stateful logic between components. When you say people are over-using LiveComponents (which I fully, 100% believe is true) I think this is a big part of why.
React’s solution to this problem was hooks, particularly the idea of custom hooks.
And before I continue, I should explicitly point out: the fact that React hooks and LV’s lifecycle hooks have the same name is a coincidence. The analog to React hooks here, in the pattern Jose showed, are the functions which register LV hooks or state. That is to say, the analog to a React custom hook in the OP is AvatarComponent.attach_hooks(). And in fact, React hooks are also functions. The name collision is unfortunate, but ironic in context!
Anyway, the React team went to great lengths to ensure their “re-usable functions” (which they call Hooks) are composable. The solution they went with was to make them rely on call order. They evaluated using keys, and explicitly chose not to because that approach does not compose.
Now, our analogs to React’s built-in hooks (e.g. useState and useEffect) are assign() and attach_hook(). They both use keys, and I don’t think LiveView is going to get away from that choice at this point. And I’m not saying we should have used call order, either. That solution does not “feel right” to me, for Elixir, and I suspect many would agree.
So we need some way to make these “re-usable stateful functions”, which by the way we should really come up with a name for (not Hooks lol), compose. Since we’re pretty set on keys already, a good solution would be to namespace them somehow. Preferably this would be done mostly automatically.
I’m not sure what an API for this would actually look like. I’d be very curious to hear what others think. Perhaps some way to call a function like MyModule.attach_hooks_and_state() which receives a namespaced socket with its assigns/hooks encapsulated somehow, similar to how a LiveComponent receives an “editorialized” socket.
garrison
BTW, I don’t think you should regret the post. It seems to me that it was quite successful, seeing as we’re discussing alternatives right now!
I am curious what others think of the idea of finding a way to add optional state to otherwise pure functions. Another advantage of React’s hook approach (as I mentioned somewhere above) is that they got rid of the dichotomy of “class/function” components, which seems to be a problem we’re dealing with here.
I think the biggest argument against would be that, since Elixir functions are (generally) actually pure, we would be violating that mental model by mounting state within them. On the other hand, that’s essentially what LiveComponents are doing, and we get by, so I’m not sure.