1016819 - [Email] Update to use gaia-header

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Comment 1

[Wilson Page [:wilsonpage]]

asuth: The headers building block will be deprecated in v2.2. Can we discuss a strategy on how we'll achieve this is Email? Happy to have a Vidyo chat if that helps :)

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

(implied context: https://groups.google.com/d/msg/mozilla.dev.gaia/2hZBSJ-_7-Q/frMJ1pFwMMsJ)

James Burke is the owner of the email frontend but is on PTO for another week or so; it sounds like we can wait for him to get back and weigh in if things only start to become an issue in v2.2.  needinfo'ing him for tracking for after he gets back.

Comment 3

[James Burke [:jrburke]]

We have arranged a meeting for next week, so clearing ni.

Comment 4

[James Burke [:jrburke]]

We talked in person, and I went off and did some experimentation and further investigation:

The basic issue is dependency management. gaia-header has a JS dependency, an inlined HTML template and depends on gaia-icons/style.css to be loaded.

Until HTML Imports come along, for me, the only reasonable way to manage those dependencies is with a JS module system. Even with HTML Imports, it is hard to see how the optimization will work for for nested script tags and CSS files for dependencies, without fairly invasive import and main document rewriting to avoid CSP concerns.

Plus, HTML elements use URL/path references, so it will need all the dependencies to be laid out in a specific directory structure. A module system, with module IDs that can be mapped to different directories, is more flexible.

Trying to use gaia-components now is further complicated by the approach used currently to get scoped, inline styles. Since those are style tags, I thought the CSP policy was changing for certified apps to disallow those types -- bug 968907, I left a comment to try to get clarification.

While that bug has not landed, it makes me uncomfortable relying on a mechanism that may run afoul of it. However, perhaps HTML Imports or scoped styles will be allowed by the CSP policy.

The current `styleHack` in gaia-header/script.js around a scoped <style> tag whose body is an `@import url()` also seems hard to optimize. The gaia-icons/style.css also uses a font icon, which I thought still had perf concerns.

This is how I see the choice now:

1) If wanting to use custom elements now, construct them using a JS module system syntax. You can create an adapter script that can be used by apps that do not use a module system. I prototyped this with gaia-components-bootstrap:

https://github.com/jrburke/gaia-components-bootstrap

The adapter script is fairly small and I believe will pay for itself since it centralizes baseUrl setup, ID resolution and specifying dependency relationships. So consumers of gaia-components do not need to use a module system.

2) Wait until HTML Imports is further along before going further for the shared components. Revisit the open questions around optimization and dependency references at that time.

---

So, if the desire is to try to push the shared UI pieces of Gaia into components now, I think the gaia-components-email approach is the way to go: both non-modular apps and modular ones can use it. It stills needs a bit more fleshing out for modular apps, but I believe it is attainable. Some of the style stuff may need more discussion too.

Otherwise, I would wait until the dependency story for Custom Elements is better, and reevaluate at that time. Hopefully some of the style/CSS reuse is also cleared up.

I believe the current state of gaia-header has enough TODO/hack style comments to indicate that it is fairly experimental, not ready for general production re-use. I think this is fine though. The experiment should continue forward and I am happy to contribute to that effort, just as a background effort, and not as a blocker for email completing 2.1 work, as discussed in the in-person meeting.

Comment 5

[Wilson Page [:wilsonpage]]

(In reply to James Burke [:jrburke] from comment #4)
> While that bug has not landed, it makes me uncomfortable relying on a
> mechanism that may run afoul of it. However, perhaps HTML Imports or scoped
> styles will be allowed by the CSP policy.


> The current `styleHack` in gaia-header/script.js around a scoped <style> tag
> whose body is an `@import url()` also seems hard to optimize.

We could move to writing CSS in the JS, similar to how we do with the template to avoid the @import step?

> The gaia-icons/style.css also uses a font icon, which I thought still had perf
> concerns.

There was an initial 50ms penalty to using custom-fonts via @font-face. I'm working closely with mwu and other font people to fix this. We have a solution being worked on that will make icon-fonts free to use. Having our icons centrally managed via the gaia-icons repo will be great step forward for visual consistency in Gaia. Scalable, vector based icons that work on any device that are fully theme-able is a massive efficiency win for engineering and visual teams that we shouldn't pass up.

> This is how I see the choice now:
> 
> 1) If wanting to use custom elements now, construct them using a JS module
> system syntax. You can create an adapter script that can be used by apps
> that do not use a module system. I prototyped this with
> gaia-components-bootstrap:
> 
> https://github.com/jrburke/gaia-components-bootstrap
> 
> The adapter script is fairly small and I believe will pay for itself since
> it centralizes baseUrl setup, ID resolution and specifying dependency
> relationships. So consumers of gaia-components do not need to use a module
> system.

This solution is well thought through, and I could see it working. My main concern is that this is a stop-gap for us before html-imports are ready for use. As we expecting full support to land pretty soon, I'm not sure it's worth our time switching from our existing solution, to the modular solution, only to switch again to html-imports. 

My other concern is that we are ignoring how other large projects and the rest of the community are managing web-components. Polymer and X-Tags are (AFAIK) fully on-board with html-imports. The community is starting to build re-usable components built for interoperability. If we go down this 'amd-style' route, we aren't playing ball with the rest of the community.

I think gaia-components has great potential to collaborate with the community, as well as other parts of Mozilla (Brick, AppMaker etc). I want to make sure our components are as open and unopinionated as possible.

That being said, I would love a way that components could be digested by module systems. My currenty thought is that once html-imports have landed, that this might be best done via a build step. Perhaps we could author as html-imports and build to AMD? We could extract <template> and replace `<link>` and `<script>` tags with `require()` calls.

I'm just looking for a solution that appeals to the majority.

Gaia-header is currently in a form that can be digested by AMD loaders (see Camera app). What do we gain by breaking the template and CSS down into their own modules? As a user do I care about sub-dependencies of a module?

I think I need more perspective to understand what you need. I hope we can find a solution that meets everyone's requirements :) But I do fear this will require some sort of build step :(

Comment 6

[James Burke [:jrburke]]

(In reply to Wilson Page [:wilsonpage] from comment #5)
> We could move to writing CSS in the JS, similar to how we do with the
> template to avoid the @import step?

Sure. I wonder what the overhead is for the platform if each injected template for a custom element has a set of duplicate styles. Even for the existing approach with the @url, how that works out. I could see where HTML Imports would allow for deduping.

> > The gaia-icons/style.css also uses a font icon, which I thought still had perf
> > concerns.
> 
> There was an initial 50ms penalty to using custom-fonts via @font-face. I'm
> working closely with mwu and other font people to fix this. We have a
> solution being worked on that will make icon-fonts free to use. Having our
> icons centrally managed via the gaia-icons repo will be great step forward
> for visual consistency in Gaia. Scalable, vector based icons that work on
> any device that are fully theme-able is a massive efficiency win for
> engineering and visual teams that we shouldn't pass up.

I am looking forward to using custom fonts for icons, so agreed on their usefulness. This comment was more about explaining why I was hesitant to push to get this in 2.1.

On the themability, with module ID-vs-path, being able to map a module ID that points to the css file with the icon font to another path would make switching themes easier. ;)

> I think gaia-components has great potential to collaborate with the
> community, as well as other parts of Mozilla (Brick, AppMaker etc). I want
> to make sure our components are as open and unopinionated as possible.

Last I looked, both xtag and polymer made other authoring choices that required bootstrap scripts. For xtag I believe it is how it bound events together/constructed the prototype, for polymer, adding additions like model driven views. The point of the two efforts existing is that they have opinions on parts that are above the base APIs, because usually more is needed to make a full set of components than the base APIs.

Once HTML Imports come along, they may be able to hide those bootstraps inside the HTML Imports themselves.

> That being said, I would love a way that components could be digested by
> module systems. My currenty thought is that once html-imports have landed,
> that this might be best done via a build step. Perhaps we could author as
> html-imports and build to AMD? We could extract <template> and replace
> `<link>` and `<script>` tags with `require()` calls.

I'm expecting it may just work by constructing a loader plugin that knows how to create rel="import" tags for those things, and that plugin can call whatever optimization tool is used for HTML Imports during builds.

It is just awkward that there are two dependency mechanisms now. Apps need one for their app JS already (once ES6 modules get out, I think it will be just silly for apps to use script tags, and the complications around choosing modules for JS will less of an issue). But HTML Imports is constructed around HTML, with ordered script tags and paths has their own thing.

For example, assume ES6 modules and HTML Imports are available. A custom element created with HTML Imports wants to use an ES 6 module for a dependency for its JS code. JS modules have async resolution semantics. HTML Imports block and from what I can tell, want the custom element prototype defined before that HTML Import is considered done. The app may risk multiple paints or some small reflows if the custom element definition is registered later because it waited for the ES module to load.

Since the JS module system and the script tag/HTML Import pathways are likely not aware of each other's scripts, it seems like it would lead to a double load of the scripts, or at least more problems to sort out to avoid it. For example, gaia-header uses font-fit.js. Other parts of an app's interface, that may be constructed via modules, might want to be able to use that function to size text.

Not to provide stop energy. We will just need forge ahead (probably slower than we would like) and figure something out, just highlighting the bumps to overcome.

> I'm just looking for a solution that appeals to the majority.
> 
> Gaia-header is currently in a form that can be digested by AMD loaders (see
> Camera app). What do we gain by breaking the template and CSS down into
> their own modules? As a user do I care about sub-dependencies of a module?

For the current gaia-elements approach, it was just a way to provide some base "library" functions to avoid repeating code in the custom element scripts. For example, once two of the components need gaia-icons available, it was just nice to use one function call to do the appendChild('link') work. It also avoided the UMD boilerplate in the modules themselves, so I believe it would lead to less overall code to download. 

And as indicated above, all of these custom element solutions require some extra bootstrap script to fully enable them, so it did not seem unreasonable in this case either. And there was a bonus for the gaia AMD projects, they would not need all of that bootstrap.

> I think I need more perspective to understand what you need. I hope we can
> find a solution that meets everyone's requirements :) But I do fear this
> will require some sort of build step :(

I am hopeful it will not require builds, loader plugins can bridge, just be enhanced by builds, for optimization purposes. 

But if you want to avoid the bootstrap script, then I think it best to wait to see how a fully realized HTML Imports might help in solving the problems. That will help avoid some of the code duplication that was one of the main goals of the bootstrap.

Comment 7

[Stephany Wilkes]

Marking this bug for 2.1 since the web components Header is the one committed web component for 2.1. Other web components for 2.2 depend on Header going first. 

I know, however, that email (and SMS) are more complicated in terms of implementing the header, which means that they may not make until 2.2, which we are both aware of and OK with. This particular bug should not block.

Sorry for doing this late; Hema just brought this bug to my attention today, but it reflects agreed scope and is in the agreed 2.1 plan.

Comment 8

[Wilson Page [:wilsonpage]]

jrburke: Have you been able to think any more about how custom-elements might integrate into Email's current startup approach?

Comment 9

[James Burke [:jrburke]]

The only new thing I have been doing for custom elements is working on bug 1005446 to convert the email cards to custom elements. Those are not using a shadow dom, just an injected template (the cards are very coarse grained units), and the plumbing for the cards know not to inject a template if a data-cached attribute is set on the card. So we can still maintain an HTML cache.

If there are new developments that you have been working on that change some of the items discussed above, feel free to share them!

Comment 10

[BMO Automation]

Firefox OS is not being worked on