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.

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

---

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