I have a state in Hologram lets say %{age: “40”} I have an input like so <input type="text" name="age" value={@age} /> I want to bind the value of input to the age. I can do this <input type="text" name="age" value={@age} $change="update_age" /> And then I can do def action(:update_age, %{ev…

There’s an important limitation to be aware of in v0.5.0. The issue you’re experiencing is that text-based input DOM elements are stateful and prioritize user-typed input over value attribute updates (this is a general DOM/HTML behavior, not specific to Hologram). This is actually the same problem …

[image] jam: IMO, “controlled input” is unclear. I would go with something that is more on the descriptive side, maybe your 2nd idea. You can always have a little callout if you want to cater to React devs, e.g. (if you’re coming from React, you may know this as “controlled input”). Yeah, ma…

[image] bartblast: The core concept is that Hologram maintains unidirectional data flow while solving the DOM synchronization problem that LiveView can’t address. Can you please expand on this?

I assume you’re asking about the second part of that quote - “solving the DOM synchronization problem that LiveView can’t address.” The fundamental issue is that the DOM is inherently stateful and LiveView’s architecture creates an unavoidable state consistency problem between DOM and server that r…

[image] bartblast: There’s never a consistency gap because the DOM’s inherent statefulness is managed within the same execution context as the component state - one source of truth that gets updated atomically. Thank you, so I assume the above and then this: [image] bartblast: You can’t …

[image] bartblast: The key difference: LiveView must continuously resolve state inconsistencies between the inherently stateful DOM and server, while Hologram prevents state inconsistencies from occurring in the first place. That’s not fully true though. Yes there’s no network boundry and lat…

[image] bartblast: The fundamental issue is that the DOM is inherently stateful and LiveView’s architecture creates an unavoidable state consistency problem between DOM and server that requires ongoing reconciliation. Fundamentally, the latency is the problem. A distributed program has to sol…

[image] garrison: With the web frameworks, it’s exactly the same problem. A React controlled component executes its JS in lock-step with the DOM, preventing you from observing an inconsistent state. But a LiveView app cannot do that, because the latency would be too high. Yes JS in some cases…

[image] LostKobrakai: But I do remember all the aweful input mask javascript code of the past, which was not at all better in breaking peoples ability to properly write in an input field. I see where you’re coming from here, but this is strictly an interface design problem and orthogonal to t…

[image] garrison: There was a thread on here the other day where somebody had a form with two inputs that updated each other and they were having trouble making that work with LiveView. I didn’t reply because I actually cannot think of a way to do that properly in LV. You literally have to write…

The particular case was a bit trickier than that. And, ahem, you were the one to suggest a hook :slight_smile: But the underlying problem there is a consistency problem: the state the client receives back from the server is out of date (user has typed more) since it was sent. The bit about debounci…

Does Hologram support two way data binding?

Questions & Help Questions

bartblast August 19, 2025, 11:48am 17

Yeah, makes sense!