The following is an initial strategy, along with some insight behind our thinking.
RENAMING TO FXOS-* We will be renaming the *Github* organisation 'gaia-components' -> 'fxos-components' along with namespaces for each component (eg. <gaia-header> -> <fxos-header>). This is to improve transparency and solidify our message. Many people have heard of *FirefoxOS*, but not 'Gaia'. Let's tear-down these confusing barriers to contribution/understanding and align our vocabulary. PLATFORM STABILITY We've been using web-components in production across *FirefoxOS* for over a year in various places: - <gaia-header> (all apps) - <gaia-dialog> (spark apps) - <gaia-switch> (spark apps) - <gaia-toast> (system app) - Vertical homescreen - New homescreen - All Music NGA UI - Other stuff I've forgotten :) This has given us confidence that what we have in the platform right now is fast and reliable enough for production. Shadow DOM V1 (the latest spec all vendors agree on) has shipped in Chrome and WebKit Nightly. We're currently working on our implementation. Word from DOM team is, that once complete, they too will be happy to ship. I have been given a *ballpark* estimate of Q1 2016. All vendors have not yet agreed on the intricacies of Custom Elements. They will be meeting in Dec/Jan for a face-to-face to present proposals and iron our the remaining kinks of a more ES6 centric design. In * Gaia* we're using *Google's* initial specification which we haven't preffed on by default yet. Third-parties are able to use this API (and Shadow DOM V0) by using the "moz-extremely-unstable-and-will-change-webcomponents" permission in their app manifest. Imagining optimistically by May 2016 we'll have Shadow DOM V1 preffed on, third-parties will be able to use our fxos-components in Gecko by either using the above pref, or a custom-elements polyfill <https://github.com/WebReflection/document-register-element> (currently used by the *Google AMP* project). For the time being we have confidence that the current implementation is sufficient for our internal needs. New Shadow DOM and Custom Element APIs will land parallel alongside the old, before being deprecated, giving us ample time to upgrade. We have also abstracted core APIs behind our gaia-component <https://github.com/gaia-components/gaia-component>wrapper, which reduces the number of code changes required to migrate if/when platform changes. SEPARATE REPOS Component will continue to live in their own repos on *Github* under the newly named 'fxos-components' organisation. Each repo will contain source-code, live demo(s), tests and documentation. PACKAGE MANAGEMENT After much discussion both on mailing lists and person to person, we have decided to make the following changes to how we manage external components in *Gaia*. We will move from *Bower* to *NPM3*. *NPM* has become the package manager of choice for the majority, with *NPM3*, comes with several nice front-end features <http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging> (some borrowed from *Bower*). Due to the reasons I outlined in this thread, <https://groups.google.com/d/msg/mozilla.dev.fxos/-Gou264FGa8/gAAnE7GSAAAJ> components will be installed locally to each app referenced within a `package.json` at the app root. This adds a small amount of learning/friction to our workflow, but brings stability to our process (similar to writing tests). Today external dependencies are checked-in to the *Gaia* tree. This avoid complexities with install, version mismatches, build systems and dependency on third-party servers. The downside is that it adds weight to the tree and noisy diffs. We'll be sticking to this approach unless more attractive options come to light. 'LIVE' STYLE GUIDE We will build a single style-guide index page that will link to each component's individual gh-page demo. This will act as an index of the components that we deem 'production ready' and will be Gaia devs' go-to catalogue. The style-guide will link to each demo, which is turn will link to source Github repo with code, documentation, tests and issues. Incorporating a 'readiness' checklist within README, following on from the hard work Fred did, <https://wiki.mozilla.org/Gaia/Shared/Components> would quickly highlight stability and feature gaps. I'd also love to have visual/UX specs checked in alongside source-code as a proof implementation matches specs, but this may require significant changes to visual/UX workflow. FOSTERING CONTRIBUTION Many of these changes are an attempt to lower the barrier to entry for contribution to *FirefoxOS*. Having components separated from *Gaia* increases discoverability and sends the message that these components can be used stand-alone. The scope of 'required understanding for first commit' is shrunk dramatically when contributors have less code to look at. Using common tools and patterns of the community, we're doing open-source in a familiar/approachable way to others. --- Let's stop duplicate efforts, save engineering time, give designers a fast/reliable upgrade channel and overall increase quality. If you're as excited by this as me, we're looking for help to make this a success. Ping me if you have questions, suggestions or time to lend. Peace :) *W I L S O N P A G E* Front-end Developer Firefox OS (Gaia) London Office Twitter: @wilsonpage IRC: wilsonpage
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
