SelfDecode Component Library

The SelfDecode Component Libary (SCL) was built with intention of speeding up the development of all products under SD, by creating a single source for all shared components such as form components which are re-used across our different products.

Exploring the library

npm run storybook

Start the storybook server. Open http://localhost:6006/ to view it in the browser.

The page will auto reload if you make edits.

npm run build-storybook

Builds an HTML production version of the style guide.

The develop branch of the repository is also deployed and available at https://sd-component-library.netlify.app/.

Prerequisites

To understand the library, add to it and work with it, 3 prerequisites are required:

1. TypeScript.
2. Rebass - used for the styling logic.
3. Emotion Theming - the library which Rebass is built upon. OPTIONAL: Undrstanding Rebass would be enough.

Idea behing the business logic

The CLS architechure is built as a reverse pyramid and is built from the ground up. At the low level, we built more abstract components which handle any functionality and validation which would be shared by all child components which extend it. As we progress "up" in the pyramid, components get more specific for the specific task they need to serve.

Example

• All input field components, in their core, are based on the base Input component. The base Input component is never intended to be rendered as it is, has no styling, and is only used for extension by more defined components.
• Within the base input component, we do the error handeling for when an invlid input was provided by the user. What exactly qualifies as an invlid input would be defined by each child element.
• The TextInput component which directly extends the base Input component, adds an optional label on top of the inut itself, and passes down "text" to the base Input component as the type of input. It becomes more specific to a certain purpose.
• The NumberInput components, extends the TextInput component, and passes down its unique onChangeWrapper, whic validates our input as numbers only, and between a minimum and maximum values (provided by the client who implements this component).

Idea behind the styling logic

For styling, we use Rebass which is a styling system that is built on top of Emotion Theming.

With Rebass, there are 4 options for styling a component. In SCL, we use 2 of these options:

• variants: used for non-changable styling properties.
• sx: used for changable styling properties, with potential defaults for some components.

variants

For al end components, certain properties are set and are unchangable. For example, for input fields, the font properties and the height of the component are set in the library, and should never be changed by the client. To do so, these properties are set as variants in our theme, which could be found in src/core. To understand the structure of the theme, reffer to Rebass documentation.

sx

sx (a Rebass proprety) allows us to style components similarly to React.js' inline-styles. We use the sx property to define styles whih could be passed by the client (with some having default fallbacks). For example, for the primary buttons, we use a default width of 236px, but the client could decide that they need this buton to have a different width and pass a different size to out component, which would than be applied instead of our 236px default width.

In a lower level example, we can look at the base Button component. All buttons have a disabled mode (each button handles its own logic to when it should be disabled). When the base button receives disabled to equal 'true', we set the buttons opacity to 0.3, otherwise, if 'false', it is set to 1.

Add more components

To add more components, start by looking at the existing components and see:

1. Is there already a group of components where this new component should fit in? If it's a type of input look at inputs. If it's a type of button look at buttons.
2. If a relevant group was found, explore existing components to understand if your new component could use one of the base components, and build on top of it to save redundent code. SLC was built with intention to save time and code for the client, and in a manner that should save time and code within itself for future components as well.