1 of 28

Component Library for React Components

Advanced Components Helping Everyone

​

​

​

​

​

​

​

​

​

Shivratna Kumar

2 of 28

Agenda

​

  • Problem
  • Why Not Existing Solutions
  • Solution
  • Challenges
  • Outcomes
  • Demo

3 of 28

Problem

  • UI and UX Consistency
  • Code Duplication
  • Development Pace
  • Maintainability
  • Open source module dependencies
    • Updation/Replacement

4 of 28

...problem

​

  • UI and UX Consistency
    • Products with different look and feel.
    • Following the common design system/guidelines that our organization has.
    • Not so good impression on customers.
    • Varied user experience.

​

Button

Input

Dropdown

5 of 28

...problem

​

  • Code Duplication
    • Multiple developers working on the same components.
    • Every team having their own common components.
    • Results in same code siting at multiple repositories.

6 of 28

...problem

​

  • Development Pace

​

7 of 28

...problem

​

​

  • Maintainability
    • Maintaining multiple components at different places.
    • Handling change requests.
    • Fixing bugs in multiple components and testing them separately.

​

8 of 28

...problem

​

​

  • Open source module dependencies
    • Keeping all of them to their latest version at multiple places.
    • Better maintainability in case of open issues.
    • Not knowing the best open source component/module available for a specific problem.
      • pros/cons or some known issues.

9 of 28

Why not Existing Solutions?

​

Component

Reactstrap

Semantic

Orion

Table

Yes

Yes

Yes

Table with virtualisation

No

No

Yes

Tree

No

No

Yes

Progress

Yes

Yes

Yes

Circular Progress

No

No

Yes

Autocomplete

No

No

Yes

Form with validation

No

No

Yes

10 of 28

...why not existing solutions?

​

  • Orion is not a generic library like reactstrap, semantic etc.
  • Built using reactstrap.
  • Has components serving to our specific use cases, over and above reactstrap having additional features and props.

11 of 28

Solution

  • Repository
  • Defining a Component’s APIs
  • Versioning of the library
  • Release and Documentation
  • Change Logs
  • Deciding on a new requirement

12 of 28

...solution

​

​

  • Repository
    • Use the appropriate platform for your needs.
    • We have used Gitlab private repository for hosting our code.

13 of 28

...solution

​

  • Defining a Component’s APIs
    • Unified API’s
      • Ex - Possible size values sm, md, lg, xl across all components.
      • Ex - Possible color values success, info, warning, danger across all components.
    • Use composition with care

​

14 of 28

...solution

​

  • Defining a Component’s APIs
    • Avoid using boolean variants.

​

15 of 28

...solution

​

  • Defining a Component’s APIs
    • Have default props wherever possible.

​

16 of 28

...solution

​

  • Defining a Component’s APIs
    • Take confirmation on the finalised API contract.
    • Try not to be product biased.

​

​

17 of 28

...solution

​

  • Versioning of the library
    • major.minor.patch (semantic versioning)
      • Major - Updated if changes are not backward compatible.
        • Removed/Renamed component, Major visual changes
        • Adding a new Tree component
      • Minor - Updated if changes include backward compatible new functionality or public API’s.
        • New component, Minor visual changes
        • Adding a hover color to all the table rows
      • Patch - Updated if changes include backward compatible bug fixes.
        • Bug fixes, Tiny visual changes for consistency
        • Decreasing the font-size of tooltip
    • ​

18 of 28

...solution

​

  • Release and Documentation
    • Version based playground for designers and developers.

19 of 28

...solution

​

  • Release and Documentation
    • Document all the components with every possible combination of props.
    • All the props, its type, default value and description should be documented.
    • No dependency to be installed by consumers.
    • Minimum breaking changes possible.

20 of 28

...solution

​

  • Change Logs
    • Version based change logs are as important as component documentation.
    • Change logs enable consumers to do informed and confident upgrade of the library.
    • Should include -
      • All the changes done in that particular version.
      • Specify if the change is Improvement, Bug Fix, New Component, or Breaking Change.
      • Known issues (if any).
    • Having commit link per change is something good to have.

21 of 28

...solution

​

  • Change Logs

​

​

22 of 28

...solution

​

  • Handling new Requirement

​

​

23 of 28

Challenges

​

  • Conflicting styles from different products
    • Problem -
      • Products were already using customized bootstrap styles.
    • Solution -
      • We prefixed all our css with OUI (Orion UI).
      • We did it by running a small postcss rule.
  • Deciding on what should be part of the library
    • No product specific components
    • Not every new change qualifies for a new component

24 of 28

Outcome Before

​

25 of 28

Outcome After

​

​

26 of 28

...outcome

  • 3 Times faster development
  • Better maintainability in case of open issues.
  • Better Communication
    • Different team members from different products actually know what’s happening in other products.

27 of 28

Demo

28 of 28

Thank You!!