Roadmap

Roadmap

This roadmap is a living document, and the priorities listed may change, but its main purpose is to provide an indication of our future plans for Glints Aries.

Created with reference to Material-UI.

Methodology

Glints Aries is driven by developer impact - issues that have the most impact on our developers at Glints get the most attention. Please create or upvote the issues that will have the greatest impact on your workflow.

Priorities

Here are our top priorities:

1. 100% Test Coverage. New components should have unit test written by default and tests for existing components will be added incrementally. This is a top priority because it helps us guard against any unexpected breaking changes as we work on the roadmap to enhance our components.

2. More components. We aim to develop the full range of components required for our front end use-cases at Glints. However, developing a full-fledged component takes a considerable amount of time. The strategy we adopt is as follows:

   • Identify commonly used components. We do so by conducting quarterly developer surveys/interviews, searching on sourcegraph (in particular the shared components folder in each of our codebases), and relying on our own developers to highlight such components to our maintainers.
   • Prioritize the creation of these components. Some heuristics we use are the re-usability, the complexity, and the availability (on third-party packages) of the component. Components with high re-usability, high complexity, and/or low availability will be prioritized.

3. More intuitive APIs. Components should be designed with APIs that are intuitive to the developer. The key principles to abide by are composability (can be assembled in various combinations), flexibility (able to serve a range of common use-cases) and customizability (can be adapted to suit specific use-cases). It is also good to refer to components by well known libraries such as Material-UI or Ant Design and replicate their APIs if they are suitable.

4. Better styling customization. Currently, it is difficult to customize the styling of our components without using styled-components. To solve this, we plan on passing a classes object to each component to enable developers to easily customize styling (this is similar to the Material-UI approach).

5. Better documentation. This falls into two broad categories:

   a. Docs for developers

   • Add Knobs to allow developers to edit props dynamically on Storybook
   • Show all possible variants or states of the component on Storybook
   • Update any unclear prop definitions
   • Add a "When To Use" section similar to antd
   • Include complete code examples (refer to Usage in Typography)
   • Create a changelog to reflect any changes

   b. Docs for contributors

   • Create a Pull Request template with a code review checklist
   • Update component design guidelines to be more comprehensive
   • Document the process for publishing a new version

6. Consistency with Glints UI. Glints UI is our in-house design library which contains the design mock-ups of our components. Currently, not all components are consistent with their mock-ups. We are working with the design team to get their help to conduct a design check for all components while our maintainers update them to fix the inconsistencies.

7. Accessibility. New components should have accessibility built in by default and existing components will be made accessible incrementally. The 3 measures of accessibility we will use are Focus indicator, Contrast ratio and WAI-ARIA compliance as mentioned in this article.

8. Others. Anything that impacts developers or contributors that does not fall into the above categories.

   • Enable automatic version bumping using mversion.
   • Enable publishing of review apps so any changes can be tested first before publishing a new version.