DEV Community: Michael Rawlings

Two-way Binding can be a One-way Street

Michael Rawlings — Thu, 01 Aug 2024 21:55:10 +0000

Ryan wrote a lovely article about two-way data binding… but I do take a bit of issue with Marko getting lumped 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
—Ryan Carniato

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:

const Component = ({ count }) => {
    return <Child count={count} />
}

Is count a signal or a number?
If it is a signal, does Child only read count.value or does it also write it?
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.

2. Potential for infinite loops

it does not take much to create "invisible" loops where updates travel up and down the render tree
—Ryan Carniato

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
—Ryan Carniato

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.
—Ryan Carniato

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":

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:

<let/name="world" />
<Input value=name onUpdate(v) { name = v } />

// Input.marko
<input
  value=input.value
  onInput(e) { input.onUpdate(e.target.value) }
>

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 (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:

<let/name="world" />
<Input value=name valueChange(v) { name = v } />

// 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:

<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:

<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:

<input
  value=input.value
  valueChange=input.valueChange
>

And both of the following are equivalent to the above:

<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" 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.

  <button onClick() { input.countChange(input.count+1) }>
    ${input.count}    
  </button>

Uncontrolled components own their own state and can update it directly.

  <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:

<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. 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:

<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:

<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:

<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.

<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:

<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:

<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:

<let/name="world" />
<Input value:=name />

// Input.marko
<input value:=input.value>

Is functionally equivalent to:

<let/name="world" />
<Input value=name valueChange(v) { name = v } />

// Input.marko
<input
  value=input.value
  onInput(e) { input.valueChange(e.target.value) }
>

And…

Data flow is explict
There no way to introduce implicit loops
It's performant
You can opt-out of the sugar at any level
(bonus) The convention opens the door for 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!

Your SSR is slow & your devtools are lying to you

Michael Rawlings — Tue, 22 Mar 2022 22:12:29 +0000

As developers we want our sites to be fast, and it takes many small wins to add up to a performant site.

I want to talk specifically about two performance factors, and how your devtools might mislead you to believe they're not worth pursuing, leaving your users with a slower experience. Those two factors are rendering and streaming.

Rendering

Let's start with rendering. The reality is, many of us are building websites using tools that are primarily focused on client-side updates. It's typically easiest for these tools to replicate the browser environment on the server to generate the initial HTML, so that's what many of them do - whether it's a full-blown headless browser, jsdom, or a virtual dom.

On the lighter end of this spectrum (vdom), the performance is typically considered "good enough", where that's often tens of milliseconds, compared to a purpose-built, string-based HTML renderer that may be more like 1ms.

These same frameworks also perform a process called "hydration" which typically involves serializing a lot of data down to the browser to make the page interactive. This serialization process consumes valuable cpu time and further delays the response.

Okay, but does it really matter if your page takes an extra 50ms to load? Maybe not. But what about concurrent requests? See, rendering is a cpu-bound (blocking) task: if rendering takes 50ms and 10 requests come in at roughly the same time (to the same render process), the 10th is left waiting for 450ms before it can start doing its work and respond. Looking at the response time of a single request isn't giving you the full picture.

Streaming

Next up, streaming. Specifically, early flushing of HTML before we have all the data necessary to render the entire page. If you don't stream, your page is going to be as slow as your slowest upstream dependency. Streaming decouples your Time to First Byte (TTFB) from your data sources and enables the browser to start rendering and fetching known resources earlier. Depending on the speed of your upstream data sources, this can have a significant impact.

It doesn't only affect your TTFB but hastens First Contentful Paint (FCP) allowing the earlier display of available content and loading indicators. And depending on how broken up the page is, it also allows hydration to occur earlier and piecewise. Ultimately streaming can have a positive impact on Time to Interactive (TTI) as well.

Even if your data sources are pretty fast, at worst your content ultimately reaches the end-user at the same time. But when your API, database, or network hits an outlier on latency, streaming has you covered.

Emulating Slowdown in Devtools

If you're testing performance, you typically want to understand the worst-case scenario. Everything's going to look fast for the person on the Mac Studio M1 Ultra with 10 Gigabit Ethernet. No, you want to understand how your site feels for the person on an older android device over a spotty cellular network. And that last part, the slow network, is where we run into trouble.

The way devtools emulates slow networks hides the impact of server-originated delays. If we dig into what the presets, such as "Slow 3G" and "Fast 3G" are doing we can see why:

You'll see here there is a "latency" setting, which ensures the request takes at least that long, but...

DevTools doesn’t add an extra delay if the specified latency is already met.
- Matt Zeunert, DebugBear

What? So on "Slow 3G" where the latency is 2s, that means whether the server responds instantly or takes the full 2 seconds to respond, devtools shows the same timing for those requests? Yup.

You can try it yourself. Take a look at the timing for these two pages without devtools network throttling and then with "Slow 3G":

Takeaways

You'll notice I didn't include any hard numbers in here. Things like server architecture will make these factors more or less relevant. Do your own testing on real devices & networks. Even more so, look at what your actual users are experiencing—especially at the long tail.

It doesn't help that we're often locked into a certain class of SSR performance before we ever get to the stage of testing these things. If you've built your app using one of the afore-mentioned client-focused tools, you may have to reconsider that decision or hope you can find enough wins elsewhere.

While there may be other factors impacting your site's performance, making your server respond faster is only going to improve things. And don't let your devtools fool you: if something's slower over a fast network, it's going to be slower over a slow network as well.