Skip to content

Tablekit 3.0 (Draft)

Jump to bottom
Joan Mira edited this page Jun 15, 2022 · 5 revisions

❇️ Roadmap Example: View the official GitHub public product roadmap1

Roadmap

Placeholder: https://github.com/orgs/tablecheck/projects/1/views/1

Requirements

  • Replace FontAwesome icons with IBM Carbon icons. We’ll try to add custom icons to the IBM repo, but if they don’t accept it, we’ll have to use it as an SVG
  • Build a documentation static website
  • Use Figma as the single source of truth
  • Colors are driven by CSS variables
  • Implement theming examples in all UI components, not just classic/dark mode
  • Replace react-select with a lighter version
  • Get rid of the classic naming. Always use the light term for themes
  • Get rid of bold font-weight on standard components like buttons. Save bold for times when the bonafide emphasis is needed
  • Let’s add page sections as components… standardize things like form rows
  • Simplify the color palette

Technical Architecture

We should apply a standard format to our variables and exports so that we could extract all styles as CSS. For example the following code could be parsed to provide a css file with .button { ... } and then our CLI package could provide options to build and compile a CSS file depending on the needs of the user. Every app needs a different subset of TableKit, why include modal dialog styling if the app doesn’t use it? Intend to support Phoenix webapps, or just simple non-react web apps.

const buttonStyles = css`...`;
const Button = styled.button`
  ${buttonStyles}
`;

All variations/appearances/theming etc should be achieved with data-* props, standard pseudo-selectors (like :invalid) and CSS Variables. This will help the portability of our code as it's less reliant on React specific features and relies more on inbuilt CSS/HTML features which has wider applications. But this way still gives us the type-safety and DX that normal props would. See below for illustration of what this would look like in practice. An temporary implementation has also been added in settings project for experimentation purposes https://github.com/tablecheck/settings-frontend/blob/d1f19b6e7c20e69ad085d081b0369ed0679f54d0/src/Tablekit/Button.ts

Button.tsx

const buttonStyles = css`
  // base styling
  background: purple;
  &[data-appearance="secondary"] {
    background: blue;
  }
`;
const Button = styled.button<{ 'data-appearance'?: 'primary' | 'secondary' }>`
  ${buttonStyles}
`;

Generated Stylesheet Fragment

.button {
  background: purple;
}

.button[data-appearance="secondary"] {
  background: blue;
}

Usage in some React App

<Button>Primary Button (default)</Button>
<Button data-appearance="secondary">Secondary Button</Button>

HTML Output of react app / HTML usage

<button class="button">Primary Button (default)</button>
<button class="button" data-appearance="secondary">Secondary Button</button>

Our exports should be the “atoms” of the design system. Anything that can be relegated to Radix-UI or React-Aria or similar should be. Tablekit should include “examples/boiler plates/templates” to get started using these other libraries with our design patterns. Where possible we should encourage using the inbuilt HTML features as much as possible.

Small example of using data-props and css variables for themeing to be react agnostic.

Discussion points

With the aim of severely reducing the amount of code we ship, we should take some time to consider whether we should continue publishing many small packages or switch to a single @tablecheck/tablekit package. I think the best structure would be;

  • tablekit-core - contains only emotion CSS and metadata like what selector this applies to.
  • tablekit-css - contains pure css files, generated from the core package.
  • tablekit-react - contains styled components equivalent of the css output (maybe this can be generated as well if the types are in core?)
  • tablekit-XYZ - other complicated packages with more react and/or JavaScript implementation an top of the pure css/react styled components.

We can still maintain multiple sub-imports like @tablecheck/tablekit/button via the following system

References and assorted articles

Clone this wiki locally