Roadmap - HelixDesignSystem/helix-react GitHub Wiki

Blockers

As of HelixUI 0.14.0 (latest version at the time of this writing), it ships the following assets.

node_modules/helix-ui/dist/

.
└── scripts
│   ├── helix-ui.browser.js     # Syntax: ES5, Module: UMD
│   ├── helix-ui.browser.min.js # ^^ compressed
│   ├── helix-ui.es.js          # Syntax: ES6, Module: ESM
│   └── helix-ui.js             # Syntax: ES6, Module: CJS
└── styles
    ├── helix-ui.css            # Shared CSS class utilities + ShadyCSS styles for polyfilled browser support
    └── helix-ui.min.css        # ^^ compressed

HelixUI not Optimized for Bundling

HelixUI is shipped in ES6 syntax using CJS or ESM module formats for consumption in node-based workflows. If the bundler supports ESM, it'll import the ESM asset.

Based on experiments with create-react-app, the default webpack configuration will add HelixUI (uncompiled, in ES6 syntax) to a separate bundled asset for consumption in a React application. This breaks IE11 compatibility, because it does not understand ES6 syntax.

It might be possible to configure webpack to compile specific 3rd party libraries, but it defeats the purpose of using 3rd party libraries. External libraries have been thoroughly tested, so you can trust that the assets they ship work as designed. Recompiling these libraries breaks that trust and introduces doubt, because you've changed how the assets are built and has a high likelihood of introducing unwanted bugs.

HelixUI is not optimized for tree shaking

Based on the same create-react-app experiments, it's not possible to deep import small bits of functionality from HelixUI without bringing in the entire module. We're investigating how to correct this in HelixUI.

Tentative Roadmap

Phase 0 (0.x)

  • Document contribution guidelines
    • glossary of terms (if needed)
    • core maintainers
    • review process
    • etc.
  • Initialize Wiki to document standards
    • naming
    • file structure
    • tabs vs spaces
    • etc.
  • Prototype dev pipeline (How will a contributor add/update features?)
    • React storybook (or equivalent library) to easily publish component documentation

Considerations

  • New features must be functional
  • Unit tests are highly recommended (if possible)
  • API consistency is recommended (if possible)
    • As inconsistencies are identified, discussions will take place to define standards.

Phase 1 (v1.0.0)

  • Finalize dev pipeline
    • Automated Unit Testing (TravisCI, CircleCI, etc.)
      • Enzyme? Jest? Jasmine? Other?
    • Automatic Linting (eslint)
    • Continuous Deployment
      • master branch for edge/unpublished, release for stable/published
  • Build component for every HelixUI element that emits custom events
    • see "Custom Elements" docs for HelixUI

Phase 2 (v2.0.0)

  • React components built for all CSS-based HelixUI components (e.g., radio, select, pagination, etc.)
    • Full list TBD