Coordinating multiple updates

Flux is not limited to one target at a time. If multiple elements on the current page are registered for updates, Flux will refresh all of them from the same returned document.

examples/components/counters.php is the clearest demonstration. The page has two independent counters and a third <output> showing their sum.

Register several targets

<form method="post" data-flux>
	<h1>Counter A</h1>
	<output data-flux="update" class="a">0</output>
	<button name="do" value="incrementA">Increment A</button>
</form>

<form method="post" data-flux>
	<h1>Counter B</h1>
	<output data-flux="update" class="b">0</output>
	<button name="do" value="incrementB">Increment B</button>
</form>

<output data-flux="update" class="ab">0</output>

When either form submits, Flux parses the new HTML document once and refreshes every registered target that applies to that kind of response.

Because the forms use bare data-flux, each form is also an update target by default. In a small counter, that is often exactly what we want. If we only want a few child elements to change, we can make the form submit with a data-flux="submit" button instead, and mark only those child elements with data-flux="update" or data-flux="update-inner".

Respect hypermedia

By building our app with traditional server-rendered techniques, we can keep our server code simple, predictable, traceable, and testable.

• update state on the server
• render the normal page
• have a single and predictable distinct logic authority
• let Flux manipulate the matching pieces on the client

Mixing forms and passive targets

A Flux target does not have to be the form that triggered the request. Any element can be updated, including:

• <output>
• <section>
• <main>
• a single card in a dashboard
• the site's navigation menu
• all of the above

As long as the new document contains the corresponding element in the same position, or an element with matching id, Flux can refresh it.

Choosing container vs child targets

In practice, we often choose one of these two patterns:

• make the form itself the target when the whole form should rerender
• mark specific child elements with update when only a few values need refreshing

Example 03 uses the second style so the two forms remain stable while the outputs change.

If both a parent and a child are registered as update targets, Flux favours the containing outer update and skips the nested child update. That avoids wasting work on an element that has already been replaced as part of its parent.

---

So far we have only submitted forms. Next we will make ordinary links feel fluid in link navigation.