Skip to main content

Composition Order in Practice

withMixins covers the syntax; Composition Order and the Dispose Chain covers why order affects cleanup, from a mixin author's perspective. This page is the short, practical version for anyone just consuming mixins in an application.

You Only Call dispose() Once​

Whatever order you list mixins in, calling .dispose() on the component tears down every mixin's resources — you never need to manually dispose of each mixin's state yourself:

class MyComponent extends withMixins(withA11y, withForm, withQuery, Component) {}

const instance = new MyComponent()
// ... use it ...
instance.dispose() // tears down the a11y instances, the forms, the queries, and finally the base Component — all in one call

This is true regardless of how many mixins are stacked or what order they're in. If you find yourself trying to call some mixin-specific cleanup method separately, that's usually a sign something's off — a single dispose() call is the whole point of the dispose chain pattern mixin authors follow.

Does the Order You List Mixins In Matter?​

Most of the time, no. If the mixins you're combining don't touch each other's state (an accessibility mixin and a query-fetching mixin, say), you can list them in whichever order reads most naturally and nothing observable changes.

It can matter when one mixin's cleanup logic depends on something another mixin manages — this is rare, and specific to the mixins involved, so there's no general rule to apply here. If you're combining mixins from different libraries and something behaves differently depending on the order you pass them to withMixins, that's worth flagging to the mixin's author (or checking their docs first — a well-documented mixin should call out any such dependency itself).

A Quick Sanity Check​

If you're not sure whether order matters for the specific mixins you're combining, the safest default is: list them in the order that matches how naturally you'd describe the component — "a form, with query-backed autocomplete, that's also keyboard-accessible" reads left-to-right as withForm, withQuery, withA11y. This won't always be technically required, but it keeps the composition line readable for the next person (possibly you) who has to make sense of it later.