Without this commit, the design tokens would contain the folders
"/" in their names, which is not compliant with most of generators
output we implement.
Since last dependencies storybook, it appears there are missing babel
dependencies to be able to run storybook properly. So we install
missings deps in order to fix that.
Volta.js is a tool to manage easily several versions of Node locally.
This tool is able to switch automatically to the right Node version by
parsing package.json of the project. So we run volta pin node@16.15 for
each of cunningham package.
Vite automatically inline assets in CSS in lib mode and this is
hardcoded in it. After multiple approaches it seems that this one
is the most trivial and easy-to-maintain one.
The DataGrid component can be considered as the core one, which provides
a full controlled component, but more complicated than SimpleDataGrid
which is based on DataGrid. SimpleDataGrid is intended to give a simple
ready-to-use data grid for client side data for example.
We need to be able to use localized texts for various components, like for
accessible labels. We decided to setup a lightweight implementation of
localizable to avoid relying on an existing heavy library.
The Provider includes by default full translations for english, and it is
also made to be able to load easily any custom locale directly from the
Provider.
Even if we haven't started to work on a complete set of inputs
we need a generic Input to implement the "goto" feature on the
Pagination component. This component is not intended to be used
in by the librarie's dependent, so we mark it as "WIP" for the
moment.
We need to ensure that our components are accessible. In order to ease
this task, we decide to install this package to display an a11y report
for each component into the storybook interface. In this way, developer
can check if the component it is developing violates or miss so a11y
rules.
Previously, when using the cunningham bin to build tokens, the CSS
file always included utility classes, resulting in duplicated CSS
utility classes on the consumer side if no specific CSS optimizer
is defined ( its local cunningham-tokens.css + the one from the
react package ). Now, this new feature introduces a param named
--utility-classes that must be provided to generate those classes.
This params is henceforth only provided to the bin inside the tokens
package.
Fonts were de-facto included in the bundled dist/style.css file which
wasn't convenient in situations were consumers wanted to import fonts
by themselves.
Previously using Button with only an icon made it render with an
internal offset, that wasn't really nice-looking. Now we force the
button to be squared.
Updated various parts of existing documentations to make a clean path
to learn how to install the library. I let the most complicated part in
the tokens's README.md file, which is referenced from the Storybook.
We needed a tool to automate the handling of monorepo's changelogs and
packages publishing. We want to make the CI responsible to automatically
publish bumped packages and create associated tags.
In order to make the storybook visible to everyone. Some changes
had to be made to make index.scss compiled with the rest of the
codebase, it had to be imported from preview.js, not directly from
preview.html.
Previously the docs order was defined by the default behavior of
Storybook: discovery order. But, in our situation we want the
"Getting Started" part to appear above "Components", and "Doc"
above any other stories. So we needed to create a custom sort callback.
In order to make this storySort callback to be taken into account by Storybook
it was needed to rename the file to preview.js. Strange but .. meh.
These were the missing parts in order to use every design tokens
of Cunningham. Including: spacing, font weight, size, family, and
colors. In order to be really versatile and to allow users to
define new design tokens I had to re-organize the way those tokens
are sub divided in sub objects in cunningham.ts file. That's why
sub division are created for theme.typ.sizes for instance.
We adding do's and don't to the documentation I realized that the
danger button was really important in some cases even if the style
was not delivered by designers. Example: Delete buttons.
Based on the work delivered by designers, we simply replicates those
in the storybook documentation in order to centralize everything
related to the Button component.
