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
sevenseacat
Author of Ash Framework
AHBruns
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
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
garrison
That’s ridiculous and should be considered a bug.
Huh, the more you know. But like you I simply refuse to live like this.
0
AHBruns
I mean, yeah, you can’t magically make latency go away. If the sever is responsible for updating, you gotta wait for a round trip to see the result. That said, with normal typing speed you’d probably get
“f” → “fo” → “foo” → “FOO”
because the sever replies would always be behind until the user stopped typing. In this case I’d probably just suggest the client do the upcasing though.
The place where this comes in handy is places like live updating select inputs where you can search for options and that hits the DB. That fundamentally doesn’t work with vanilla live view. You’ll notice all the libraries (aka LiveSelect) that try to do it end up exposing imperative APIs to update the options (e.g. you have to call send_update).
1
garrison
What I’m getting at is there are classes of problem for which something like foo -> FOO is an unacceptable (i.e. broken) solution, and this cannot be fixed in general. You can make latency very small by rendering on the client and this is exactly what e.g. React does by default. This is not an accident btw, modern React has an engine that is entirely capable of running asynchronously and the fact that input events trigger a synchronous render is an intentional choice, because otherwise you would have exactly this problem.
LiveView could fix a lot of things, just not this one particular thing. Maybe there is some API that would make it less bad, though. Personally I think it would be better to always client-render components for which this is a concern (also an imperfect solution).
Note that this is an edge case where users have been extensively trained to accept the unnatural idea that search results are out of date for the query they’re typing.
0
AHBruns
Yeah, that’s fair. I would agree, logic that doesn’t need to be run on the server should be run on the client, but self proclaimed backend devs don’t like to write JS, and so users suffer…
1
FlyingNoodle
I think your discussion should be moved to an own topic.
It doesn’t have very much to do with “should the installer have a no daisy flag” IMO.
0
BartOtten
Should it have a flag? Always
But let’s nog forget that a larger project is made once in a while while hobby projects are made al the time (POC included). So having it as default saves a lot of time compared to to not having it.
0