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.

example/03-multiple-forms.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.

Why this is useful

We can keep our server code simple:

• update state on the server
• render the normal page
• let Flux extract the matching pieces on the client

There's no need to build a custom payload describing which fragments changed.

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

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.

---

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