loading

v32.1.1

select option
Getting started
Components
How to contribute to ink
Support and feedback

Tools

Playroom
Primer
Figma library
Usage

Deprecation

Start here
Deprecation list and dates
Codemods 101

Design Guides

Icons
Colors
Guides
Accessibility
Component patterns
UX Writing

Component Categories

Accessory
Form
Formatter
Hooks
Illustration
Layout
Navigation
Spreadsheet
Table
Typography
Preferences
Github
Version 32.1.1

Code Style Guide

How we keep code consistency in ink

In order to maintain code consistency in ink, we have some rules of how names and files should be written and how the folders should be organized.

ESLint

Our linter runs automatically within all scripts and will catch most issues that may exist in your code. You will see the status of your changes in real time, regardless of the script you choose to run.

JavaScript / TypeScript

If you are unsure about something, looking at Airbnb’s Style Guide will guide you in the right direction.

React

We also have some specific conventions which should be followed above and beyond the Airbnb Style Guide:

  • Favor functional components over classes, and use React hooks
  • Any internal methods which are not dependent on component state should be considered helper methods
    • Helper methods should be stored in a sub-folder called helpers
    • One helper method per file inside helpers (e.g. if you have getHelpA() and getHelpB() they should be in herlpes/getHelpA.ts and helpers/getHelpB.ts respectively)
    • Each helper file should be accompanied by a test suite next to the code itself (e.g. helpers/getHelpA.spec.ts)
    • Component identifiers and their filenames should use PascalCase
  • Constants should also be moved into a separate module, called constants.ts
  • File names:
    • for Components or Classes the name should match the name of the Component or Class (and therefore be in camel-case)
    • for anything else, like helpers or constants should start with a lower-case letter (eg constants.ts or helperFunction.ts for a module containing a helper of the same name)
    • file names should reflect the file’s primary export

Building a new Component

When building a component, take care that new code meets these criteria to save time in the code review process:

  • The component code itself should:

    • be a function, not a Class (We use React hooks);
    • have its own folder inside src/components;
    • be written in Typescript;
    • have // ink-component on the first line of the main tsx file;
    • all components should export their props interfaces. Parent components should also import/export their children props;

  • Styled Components and Tokens:

    • To understand how we use styled components with tokens in ink, refer to the CSS Style Guide.

  • Samples and Usage guides

    • each component should have a _________.md file with important information about the usage of the component. They should have the file even if no information is added;
    • each component should have a samples.js file where samples for the components are to be written following the samples guidelines.

  • References in ink/src/index.ts:

    • an import for the new component
    • an entry in export {...}
    • an entry in export default {...}

  • Tests:

    • Each new component should have a test suite (including non-public components and sub-components). Read Testing in ink to learn more about how we test components and functions in ink.
    • Any helpers go in the helpers folder. See React to learn more about helpers.

If you need any further help navigating the ink folder, you can ask for help from any ink team member. One of us can probably hop on a quick zoom call to explain it better.

Is this page helpful?