Skip to main content

Resolving Method-Name Collisions at the Call Site

Some mixins expose a configurable method name instead of a hardcoded one — @geastack-community/query's withQuery is one (see Configurable Method Names for Ecosystem Interoperability for why library authors build mixins this way). As a consumer, you'll only ever need to reach for this when two mixins you're combining would otherwise install a method under the exact same name.

The Pitfall: Aliasing an Import Doesn't Rename the Method​

It's tempting to assume that this solves the problem:

import { withQuery as withGeaQuery } from '@geastack-community/query'
import { withQuery as withOtherQuery } from 'some-other-query-library'

It doesn't — not by itself. as withGeaQuery only renames the local variable you use to refer to the mixin function. It has no effect on what method name that function installs on the resulting class. If both withGeaQuery and withOtherQuery install a method called createQuery by default, you still end up with one silently overwriting the other, even though your imports look perfectly distinct.

Passing the Name Explicitly​

If the mixin's second parameter accepts a name (check its docs — not every mixin does), pass a distinct one for each:

import { withMixins } from '@geastack-community/utils'
import { Component } from '@geajs/core'
import { withQuery as withGeaQuery } from '@geastack-community/query'
import { withQuery as withOtherQuery } from 'some-other-query-library'

class Dashboard extends withMixins(
  (Base) => withGeaQuery(Base, 'createGeaQuery'),
  (Base) => withOtherQuery(Base, 'createOtherQuery'),
  Component
) {
  a = this.createGeaQuery('a', fetchA)
  b = this.createOtherQuery('b', fetchB)
}

Note the shape here: withMixins expects each argument to be a function of one parameter (Base) — that's what makes (Base) => withGeaQuery(Base, 'createGeaQuery') necessary instead of passing withGeaQuery directly the way you would for a mixin with no extra arguments. Forgetting the wrapping arrow function and writing withGeaQuery(Component, 'createGeaQuery') directly as an argument to withMixins won't type-check, since withMixins is expecting a (Base) => DerivedClass shape for every argument, not an already-applied class.

When You Don't Need Any of This​

If you're only using one query-creating mixin (or, more generally, only one mixin from any given "family" of similarly-shaped mixins) in a given component, the default method name is fine and there's nothing to configure. This only becomes relevant once you're deliberately combining two libraries that happen to solve a similar problem under a similar name.