On Wed, Nov 4, 2015 at 3:19 PM, Guillaume Marty <[email protected]> wrote:
> That's really exciting news! I support all the proposals in your email. > > I have a question though. What of the web components that currently lives > in Gaia tree only (the /shared/elements/gaia_* folders)? Are they going to > move to their own repos? > As these are just shiny wrappers around old building-block styling I suggest they will remain in the tree until they are replaced by the latest fxos-componet equivalent. Once usage has dropped to zero they can be deleted. > On 4 November 2015 at 14:56, Wilson Page <[email protected]> wrote: > >> 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 >> >> > > > -- > Guillaume Marty > @g_marty > http://gu.illau.me >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
