Introduces pluggable styling API

[kettanaito]

Introduces pluggable styling API to use Atomic layout with any tag-based CSS-in-JS solution (styled-components, emotion). Provides any related adjustments to the library to be used style-agnostic.

GitHub

• Closes [RFC] Pluggable styling API #57

Specification

1. Atomic layout uses a designated required produceStyles function that generated styled components (similar to styled from styled-components).
2. When not provided the produceStyles option, Atomic layout prints an error asking to provide it. The error message includes an example of API usage with styled-components.
3. You should provide produceStyles, as there is no default behavior on purpose. This is to make Atomic layout usable with any component-based CSS-in-JS solution without listing any of them as the library's dependency.
4. To provide a style producer function pass it as a value of produceStyles property:

import emotion from '@emotion/styled'
import Layout from 'atomic-layout'

Layout.configure({
  produceStyles: emotion,
})

4. Style producer can be specified only once, just as the rest of layout options via Layout API.

Release

Prior to version 1.0 the library's API should be treated as experimental, meaning that it may introduce breaking changes in minor versions. Although it's not a proper semantic release process, I see no reason to establish a stable API only somewhere around version 12.x.

Roadmap

• Provide parametric integration tests to assert the same test suits but using emotion as the style producer
• Ensure proper references and evaluation of custom styles producer

[coveralls]

Coverage increased (+0.06%) to 91.077% when pulling 695e9d1 on 57-pluggable-styling-api into 1ff70cd on master.

[kettanaito]

Evaluation of Layout.options.produceStyles happens before the user-defined custom value, meaning before the call of Layout.configure() on the developer's side.

[kettanaito]

Accepting a style generator function is a working, but not practical solution. Various CSS-in-JS libraries may have different API, adjusting to which would be garbaging the internal logic behind Layout.configure(). Overall, this is not a good solution in the long run.

Closing in favor of #261 and the latest update in #57.