# Two-way Binding can be a One-way Street Ryan wrote a [lovely article](https://dev.to/this-is-learning/two-way-binding-is-a-two-way-street-2d3c) about two-way data binding… but I do take a bit of issue with [Marko getting lumped](https://dev.to/this-is-learning/two-way-binding-is-a-two-way-street-2d3c#:~:text=But%20I%27ve%20also%20worked%20on%20Marko%20which%20does%20and%20resembles%20Vue%27s%20approach.) into the same category as Vue when it comes to its approach to data flow, so I wanted to set the record straight. And maybe show a better path that other frameworks could adopt. 🤷 ## Recap: Problems with two-way binding Ryan lays out the problem with two-way binding and it boils down to a handful of issues: ### 1. Unpredictable data flow > the creator of that state has no idea if and how the child will mutate it > &mdash;[Ryan Carniato](https://dev.to/this-is-learning/two-way-binding-is-a-two-way-street-2d3c#:~:text=the%20creator%20of%20that%20state,will%20mutate%20it) {% details Example %} This is a problem for libraries that don't have read-write segregation. Where passing a value implicitly grants access to modifying that value as well. Take the following Preact Signals example: ```javascript const Component = ({ count }) => { return <Child count={count} /> } ``` 1. Is `count` a signal or a number? 2. If it is a signal, does `Child` only read `count.value` or does it also _write_ it? 3. If the child _does_ write to `count.value` and we're debugging, we see that write, but then jump into internals and it's not immediately clear where that write propagated to. {% enddetails %} ### 2. Potential for infinite loops > it does not take much to create "invisible" loops where updates travel up and down the render tree > &mdash;[Ryan Carniato](https://dev.to/this-is-learning/two-way-binding-is-a-two-way-street-2d3c#:~:text=it%20does%20not%20take%20much,the%20render%20tree.) <!-- This was a much bigger problem in MVC architecture where you had Models that contained values and could both emit events and listen to changes in other models. It wasn't too uncommon to have circular data flow with the possibility of loops forming. --> ### 3. Unpredictable performance > A top-down rendering approach(like a VDOM, or dirty checker) might realize a change had happened part way down its update cycle and then have to start over again > &mdash;[Ryan Carniato](https://dev.to/this-is-learning/two-way-binding-is-a-two-way-street-2d3c#:~:text=A%20top%2Ddown%20rendering%20approach,still%20impacts%20traceability.) ### 4. Limits refactoring > One can always opt out of two-way binding if they need to intercept the change event on the native element. But propagating that ability to split it up through component hierarchies is a new consideration. If not available you may be left breaking out of these loops on the way back down. > &mdash;[Ryan Carniato](https://dev.to/this-is-learning/two-way-binding-is-a-two-way-street-2d3c#:~:text=One%20can%20always%20opt%20out,breaking%20out%20of%20these%20loops%20on%20the%20way%20back%20down.) ## Solving these problems These issues are something we on the Marko team have thought extensively about. And there's a solution where we get to have the terseness of two-way binding while preserving one-way data flow and avoiding the issues listed above. The solution: **Convention** 🤝 & **Sugar** 🍬. But let's start from the beginning. Look at the Solid example Ryan showed under the heading ["Read/Write Segregation Everywhere"](https://dev.to/this-is-learning/two-way-binding-is-a-two-way-street-2d3c#:~:text=3.%20Read/Write%20Segregation%20Everywhere): ```javascript function App() { const [name, setName] = createSignal("world"); // How do you 2-way bind this? You don't... return <Input value={name()} onUpdate={setName} /> } function Input(props) { return <input value={props.value} onInput={e => props.onUpdate(e.target.value)} /> } ``` Here we have a nice, explicit, one-way flow of data: ``` onInput → onUpdate → setName → <Input>.value → <input>.value ``` ### What about Marko? The same components look very similar in Marko: ```html <let/name="world" /> <Input value=name onUpdate(v) { name = v } /> ``` ```jsx // Input.marko <input value=input.value onInput(e) { input.onUpdate(e.target.value) } > ``` <!-- ``` <let/name="world"/> // How do you 2-way bind this? We'll see... <Input value=name onUpdate(v) { name = v } /> <define/Input|props|> <input value=input.value onInput(e) { input.onUpdate(e.target.value) } > </define> ``` --> > **NOTE**: Despite using an assignment, Marko still has read-write segregation: you can't modify the `name` passed to the child, you _have_ to provide a function that modifies it in the local scope. Marko retains [Locality of Thinking](https://dev.to/this-is-learning/thinking-locally-with-signals-3b7h) (another great article by Ryan). ### Adding Convention 🤝 This is a common pattern, so let's add some convention around it. If an event soley exists to propagate some value, let's name it as such: ```html <let/name="world" /> <Input value=name valueChange(v) { name = v } /> ``` ```jsx // Input.marko <input value=input.value onInput(e) { input.valueChange(e.target.value) } > ``` This is exactly the same as the above, except `onChange` is now `valueChange` (to match the `value` attribute). This convention is the recommended way to propagate data up the tree in Marko: add `Change` to the attribute name when passing a change handler for another attribute. Perhaps we make a specific `NameInput` and it's used like this: ```html <NameInput name=name nameChange(v) { name = v } /> ``` ### Adding Sugar 🍬 Now that we have this convention where it's easy for us to see `someAttribute` and `someAttributeChange` correspond to each other, it's also easy for a compiler to see. Marko introduces the `:=` shorthand, which makes these two lines equivalent: ```jsx <Input value:=name /> <Input value=name valueChange(v) { name = v } /> ``` Using `:=` is a lot more terse, but it still explictly gives the child a function to update a value. **It's just syntax sugar.** The child doesn't care whether the parent used this shorthand or not. We haven't lost locality of thinking. > **NOTE**: Sourcemaps even map the generated `valueChange` function to the `:=` in the source template, so when you're debugging as you step into the call to `valueChange` from the child, you'll see where it was passed from the parent. ### Upgrading the DOM So this convention is great, but what about the simple case with `<input>`? Marko adds several `*Change` attributes to native HTML elements. So instead of using the `onInput` event, you can use `valueChange`: ```jsx <input value=input.value valueChange=input.valueChange > ``` And both of the following are equivalent to the above: ```jsx <input value:=input.value> <input ...input> ``` > **NOTE**: Adding these attributes was a difficult decison; the purist in us really didn't want to, but it's a big win for consistency and composability within Marko. And you're probably already used to some extra attributes from other frameworks you use (`key`, `ref`, `on:`, `@`, etc.) This is great! For the common propagating case, we can use `:=`. It's clear that we're giving the child a way to request a change, and if we need to do more we can add our own `valueChange` function without needing to refactor anywhere else in my app. ### Additional benefit: Controllable components You might have heard the terms ["Controlled" and "Uncontrolled"](https://react.dev/learn/sharing-state-between-components#controlled-and-uncontrolled-components) in regards to components before. Quick recap: - Controlled components receive their state from their parent. They may _request_ changes to that data (through events), but they don't actually _control_ it. ```jsx <button onClick() { input.countChange(input.count+1) }> ${input.count} </button> ``` - Uncontrolled components own their own state and can update it directly. ```jsx <let/count=0 /> <button onClick() { count += 1 }> ${count} </button> ``` Generally, native HTML elements are uncontrolled. You can set an initial `value` for an `<input>`, but once you start typing in it, the `<input>` maintains its own state. However, it's often useful to have a form element (or other native element) controlled by your application state. #### Other frameworks React acknowledges this: it supports both `value` (controlled) and `defaultValue` (uncontrolled) on `<input>`. So if you use `value` with no listener, you essentially get a read-only input: ```jsx <input value="world"> ``` Most other frameworks operate in a partially controlled state where the `<input>` maintains its own internal state, but you can update `value`. So there's no guarantee the two are in sync. [But even React is inconsistent](https://codesandbox.io/s/react-controlled-input-forked-uleknq). For example, `<dialog>` in React doesn't have `open` and `defaultOpen`. It also operates in a partially controlled state. #### Marko's solution In Marko we're using the change handler to signal the desire for control. If you don't listen for changes you get an uncontrolled component. If you _do_ listen for changes, you now take full resposibility for the corresponding value. To illustrate this, in Marko the following yields an `<input>` that ignores your keystrokes: ```jsx <input value="world" valueChange() {}> ``` We passed valueChange which causes the input to be controlled, but it's an empty function, so no state is ever updated. The `<input>` effectively ignores our keystrokes. #### Extending to components This ability to operate as either controlled or uncontrolled isn't only useful for native tags. We want to be able to write our own controllable components! Marko enables this by making its core state primitive, the `<let>` tag, controllable. Let's take our uncontrolled counter component: ```jsx <let/count=0 /> <button onClick() { count += 1 }> ${count} </button> ``` In Marko, we have an unnamed attribute that defaults to `value`, so the following are equivalent: ```jsx <let/count=0 /> <let/count value=0 /> ``` In this usage `<let>` is uncontrolled: it maintains it own internal state that it provides to us. But if we pass a `valueChange` handler, it no longer maintains its own state and reflects the `value` passed to it. For example this counter would `alert(1)` every time it was clicked _without updating count_. ```jsx <let/count value=0 valueChange(v) { alert(v) } /> <button onClick() { count += 1 }> ${count} </button> ``` **Okay, so how is this useful?** We can pass an optional change handler from the parent: ```jsx <let/count value=input.value valueChange=input.valueChange /> ``` Now, if the parent passes `valueChange`, it controls the internal `count`. If it doesn't, the `<let>` maintains the `count`. And of course, we can still use the `:=` shorthand, so here is our **controllable** counter: ```jsx <let/count:=input.count /> <button onClick() { count += 1 }> ${count} </button> ``` ## Conclusion So Marko introduces a zero-cost abstraction that _looks_ like two way data binding, but is _ackchyually_ one-way data flow: ```jsx <let/name="world" /> <Input value:=name /> ``` ```jsx // Input.marko <input value:=input.value> ``` Is functionally equivalent to: ```jsx <let/name="world" /> <Input value=name valueChange(v) { name = v } /> ``` ```jsx // Input.marko <input value=input.value onInput(e) { input.valueChange(e.target.value) } > ``` **And…** 1. Data flow is explict 2. There no way to introduce implicit loops 3. It's performant 4. You can opt-out of the sugar at any level 5. (bonus) The convention opens the door for [controllable components](#Additional-benefit-Controllable-components) Win-win-win-win-win 🎉 ## Marko Everything we discussed is available in Marko 6 which is currenly in pre-release, but getting more stable every day. I hope you'll try it out!