Overwriting styles vs Extending styles

[milesj]

Aesthetic aims to solve the following two ownership scenarios:

• Owner - You own the component in your application and can easily set styles.
• Provider -> Consumer - You use a component provided by a third-party library (NPM package) and want to change its styles. (It must being using Aesthetic).

The first scenario is rather easily solved without much hassle. The second scenario is what Aesthetic tries to solve via the static setStyles method on a wrapped component (provided by a styler function).

Now for the comparison. I will use Toolkit components as an example, even though they don't use Aesthetic. Just assume it does use Aesthetic, and defines external classes as its style, like so:

// toolkit/components/Accordion
export default style({
  accordion: 'accordion',
  accordion__collapsible: 'is-collapsible',
  accordion__multiple: 'is-multiple',
}, {
  styleName: 'ToolkitAccordion',
  lockStyling: false,
})(Accordion);

Both approaches need to satisfy the following criteria:

• Styling pattern can be changed (class names -> style objects, or vice versa).
• Provided styles can be completely overwritten with custom styles.
• Provided and custom styles can make use of themes.

Overwriting

Overwriting allows us to change the styles without having to create a new local component. The original styles can be referenced by using style functions.

// bootstrap.js
import Accordion from 'toolkit/components/Accordion';

Accordion.setStyles({
  accordion: { ... },
  accordion__collapsible: { ... },
  accordion__multiple: { ... },
});

// App.js
import Accordion from 'toolkit/components/Accordion';

<Accordion />

Pros

• No local components or files.

Cons

• Provided styles can only be overwritten once, which applies to all instances of the third-party component. (Can be worked around using themes).
• If another third-party library uses Toolkit (for example), overwriting it's styles may break the other package. However, either a) you'd want it to match your new styles, or b) this requires another Aesthetic layer which wouldn't cause collision.

Extending

Extending allows us to change the styles but creates a new local component in the process (another layer of composition).

// components/Accordion.js
import Accordion from 'toolkit/components/Accordion';

export default Accordion.extendStyles({
  accordion: { ... },
  accordion__collapsible: { ... },
  accordion__multiple: { ... },
});

// App.js
import Accordion from '../components/Accordion';

<Accordion />

Pros

• Provided styles can be completely overwritten multiple times, with each call of extendStyles.

Cons

• Requires composition, which equates to more local files.

[milesj]

I'm leaning towards switching to extending so you can do things like:

import BaseButton from 'toolkit/components/Button';

export const Button = BaseButton.extendStyles({
  button: { ... },
});

export const PrimaryButton = Button.extendStyles({
  button: { ... },
});

export const SecondaryButton = Button.extendStyles({
  button: { ... },
});

[milesj]

Went with the extending styles approach.