Skip to content

Instantly share code, notes, and snippets.

@LaurentGoderre
Last active August 29, 2015 14:06
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save LaurentGoderre/650cf0375cca759fdfe3 to your computer and use it in GitHub Desktop.
Save LaurentGoderre/650cf0375cca759fdfe3 to your computer and use it in GitHub Desktop.
Web Experience Toolkit - Next Steps

Web Experience Toolkit - Next Steps

New Plugin Structure

Background

Currently in WET, there is a lot of duplication of code, particularly around plugin initialization and lifetime. Additionally, plugins are sealed in an anonymous scope to prevent conflicts but this approach makes it very difficult for implementers to override or customize plugins. To solve this problem, plugins need to switch to a more open architecture and duplicated code need to be regrouped and shared among plugins. This new structure also need a full unit test suite (see the Unit Testing section for more details). To acheive this goal, several options are available: Prototypal Inheritance (Native), Base2 Library, ES6 Classes w/ Google Traceur

Options

Prototypal Inheritance

TODO

Base2 Library

TODO

ES6 Classes w/ Google Traceur

TODO

Theme CSS Overrides

Background

In version 4 of WET, themes were seperated into seperate repository to give theme more flexibility. The intent was also to make it easier to create new themes (the project generator-wet-boew-theme was created for this purpose). One of the current limitations for theme is that WET plugins can't easily be customized. Themes are stuck with colour choices from the WET theme. It was the intent from the start of the development for v4 to allow theme to customize the way WET plugins look.

Implementation

To allow theme to customize the look of WET plugins and avoid duplication of style, themes need to compiled their SCSS styles to include WET core styles and Bootstrap styles and overrides. This would render the use of a wet-boew.css file obsolete and would introduce a markup change. Additionally, customizeable values need to be converted to SCSS variables and added to the _variables.scss file. This would allow theme to add an override for any of thes variables in their own variables files to customize the look of plugins.

Unit Testing

Unit tests is an essential part of any development project because it gives developers confidence that their work doesn't break any functionality. Currently in WET, code is tested using both a headless browser (PhantomJS) and virtualized browsers using SauceLabs. Unfortunately, the core and two third of plugins and almost all polyfills don't have test cases (see issue #6070 for more details.

The core framework and the 24 remaining plugins and 7 polyfill need unit tests. This will allow us to better deal with issues logged by users. Either the individual who logs the issue or a WET developer could create a test to prove or disprove the bug.

i18n Workflow

TODO

Note:

  • Documentation i18n
  • Transifex

Documentation

TODO

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment