That’s ridiculous and should be considered a bug.
Huh, the more you know. But like you I simply refuse to live like this.
garrison
garrison
I guess this hinges on what “can be fixed” actually means. I understood what you’re suggesting but it makes me uncomfortable.
For example, take a simple controlled component that just upcases its input. With latency, your solution would produce:
f -> F -> Fo -> FO -> FOo -> FOO
With more latency:
foo -> FOO
Note that this simple case is in fact conflict-free and will always converge to the correct solution. But it displays intermediate states that are not valid under the user’s expectation, which is that the contents of the input should always be uppercase.
They might make a valid CRDT if you declare that those states are valid under the rules of your CRDT (you can make up any rules!), but in practice I think you will have a hard time designing a general API that solves this problem. The fact that “multiplayer editing” solutions are often extremely domain-specific is a good hint.
0
AHBruns
I wrote a framework for data loading and injection à la React Query (now TanStack Query I think) that had to solve this exact problem. The issue with phx-remove is that it’s not called when a parent of a component that has phx-remove is removed. It’s only called when the component is removed directly. The more reliable, though equally silly solution is to use the internal telemetry event that live view emits when it removes a component. That was added relatively recently though.
Before that I was doing some process state dark magic to make every component that read data record itself in a lookup table then after every render I checked which components that “should” have rendered didn’t. It work reliably, but trying to explain to people the value of such a library was too draining. It was/is called LiveQuery if you’re interested.
2
AHBruns
sevenseacat
Author of Ash Framework
wait, if I’m actively focused and typing in an input, the server should just be able to update that input right under me? I think if I ever saw that, I’d consider it a bug
2
AHBruns
It can. I did it last year for my job. The trick is that, while you can’t get strongly consistent rendering, you can get eventually consistent rendering. Client components just have to track both their state and what the server thinks their state is, and then you version every state change. If the server’s state is the same version as the client’s state, it takes precedent, if the client’s state is a version ahead of the server’s state, the client’s state takes precedent, but only until the server gets the update and sends back its copy of state for that version.
What gets really tricky is when state changes don’t originate from the client. To handle that I needed to implement the notion of branching. Effectively, when the server pushes an update all on its own, it is forking the version history and the client has logic to merge that forked version history back into its own. In our case that logic was basically to just let the server entirely overwrite the client’s state, but it could be a fancier CRDT based solution if needed. E.g. multiplayer form editing where you want multiple people to be able to type in the same field at once
Anyway, point is, it can be done, though you’re right it does require giving up strongly consistent rendering. My bigger point is that this is absolutely something I would expect a framework like LiveView to do for me, or at least to make straightforward to do myself.
0
garrison
The problem with composition is much deeper than you suggest. LiveView’s component structure is completely flat. Components are mounted with global ids, and the responsibility of choosing those ids is passed onto the developer. The id requirement itself does not compose; each parent must pass an id to its children, which means it must have an id of its own, and so on. The concerns of the components become quite badly intertwined, defeating their purpose. It’s actually a pretty textbook example of what Hickey was talking about.
I do not know LV’s engine in extreme detail, but I know enough to know that it’s mostly template-based and treats conditionals as first-class citizens. This structure is actually very problematic, because it means the component tree is not a strict superset of the DOM tree as it would be in, for example, React. That in turn makes implicitly mounting stateful components by their tree positions very messy if not outright intractable. So instead the engine cheats with global ids.
This can be fixed, but it’s not easy. The whole thing probably has to be rewritten from scratch, the template approach thrown away in favor of a full element-level tree, the server/client protocol rewritten, and so on. Backwards compatibility would likely be broken because it’s good to know whether a component should be unmounted during the local diff cycle, so the “teleportation” ability should probably be removed.
It’s a lot of work. So the question becomes: does anyone using Phoenix actually care? And given that you are the only individual I have ever seen (other than myself) voice this concern, I think the answer is “not really”.
This actually cannot be fixed as far as I can tell. It’s an inherent tradeoff with latency.
I strongly recommend you avoid reading the thread where I unsuccessfully attempted to explain this to I think at least four different people lol.
Strangely it is actually possible, as after a week of wasting my time thinking about it I realized that you can abuse the client-side phx-remove binding to run a callback on the server. Utterly cursed, of course.
0
AHBruns
So, this comes at two levels. The first is fixing the framework’s component APIs.
Top level live views are have a bunch of features that nested components (be they live components or functional components) don’t have. This is a problem because it means if you want to do a bunch of things you have to do them in the root live view, this breaks composition. There should be 1 component API, that has a mount, update, render, and unmount callback (the lack of this makes a whole class of things impossible in live view because you can’t reliably clean up after yourself). All the other stuff live views are doing should be mix-ins (though we’d probably end up calling them hooks). Want to get/set URL info, that’s a hook. Want to run in a separate process from the parent component that’s rendering you, that’s a hook (really more like a flag), and it shouldn’t change your rendering semantics one bit. Want to get/set the page title, that’s a hook.
Okay, once that’s done, time to fix core components. First, build a suite a headless components. Then build a suite of concrete components on top of that suite. I could maybe be convinced that skipping the headless/concrete division is okay given most apps are not going to ever have a need for multiple concrete versions of the same headless component (though a flag would still be nice). Anyway, components shouldn’t be using margin, I would have hopped this would be obvious in 2026, alas… These components should be decomposable to the smallest unit of design that a UI will need to render. That is not a whole ass form field that includes a label and errors. Finally, these components should allow you to provide the rendering semantics you want. Vanilla live view forms are fundamentally unusable for a whole class of apps that need to drive forms from the server because ultimately they make the decision for you about what is the source of truth and when. E.g. if an input is focused it will ignore any updates from the server, this breaks ui = f(state) in a really profound way.
Also, just to get ahead of it, no I’m not going to do any of this myself. I have a job, and even if I had the time outside of work, I’d spend it building my own thing or improving a different framework that I thought was making better decisions. There always seems to be this defense when something is criticized that unless the person doing the criticizing is willing to fix it themselves, the criticism isn’t valid. That’s silly.
1
garrison
This is entirely true, and it’s why feedback can only get you so far. There is no accounting for taste.
The React team practically had a pitchfork mob chasing after them when they introduced hooks, yet they were completely right. The difference between them and the mob in question was that they had spent a whole lot more time thinking about the problem.
1
garrison
Okay, well, I guess I was too quick to discount the possibility that your opinions are the same as mine.
Take your argument to its logical conclusion. How do you make the components compose? What needs to be done?
0