908950 - [Sms] Consider having DOM nodes imported from standalone files.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::SMS, defect)

Description

[Kevin Grandon :kgrandon]

The app currently lazy loads the DOM via comments inside of HTML files. It should be possible to use our new import polyfill to have a cleaner dom.

Comment 1

[Julien Wajsberg [:julienw]]

We don't really lazy load the DOM via comments, rather we use those comments as templates we can render several times with different parameters.

Could the library do that ?

I don't think the initial markup in the Messages app is big enough to warrant lazy loading DOM nodes.

Comment 2

[Kevin Grandon :kgrandon]

Gotcha, well in the immediate term it would be possible to use our new build step to move the HTML templates to an external HTML file and people would be able to view the DOM normally - with syntax highlighting. We could do this with zero javascript changes. If we did this there would be no impact to performance (we would just be importing content into the comments at build time). 

Let me know if you'd like me to submit a patch for this - I'd be more than happy to.

Comment 3

[Julien Wajsberg [:julienw]]

But if we do this we're not using the WebComponents spec at all, right ? And we would need to do the XHR in dev mode also, but without using the lazy load part.

Then we would rely on your polyfill library without using the "polyfill" part, and therefore when you'll want to remove it, you'll be quite stuck.

I guess we need something more dynamic. Say "I want to inject via Javascript this customized node", and I think your polyfill does not support this, which is OK of course.

Am I missing something ?

Comment 4

[Kevin Grandon :kgrandon]

We would still be using the WebComponents spec, just with some additional caching to speed it up. The dev mode in XHR is already being handled in in Lazy Loader, but I am planning on moving this into a plugin, making it fully invisible. We also have plans to make our polyfill more comprehensive and add things like script script support where we don't have it.

Essentially, you can have templates in external files without being wrapped in comments today. It's a question of, "how do you want to edit the dom"?  In a single file with comments, or in multiple files without?

Comment 5

[Julien Wajsberg [:julienw]]

Let's ask Rick, as he wrote our templating library, he'll have an informed answer.

Comment 6

[Rick Waldron [:rwaldron]]

The use case that Julien outlined in https://bugzilla.mozilla.org/show_bug.cgi?id=908950#c1 isn't adequately satisfied by Web Components (http://www.w3.org/TR/components-intro/#template-section). Corey and I have reviewed the current WebComponent "polyfill", as well as the proposed patch for Clock and agree that what we need is templates (ie. a string represented by a function that accepts an object with properties, and fills in the DOM/text completely), not components, which still will require further DOM manipulation to populate with real data. What we really want from a web component/template is data-binding and interpolated source strings, and it doesn't seem supported in the polyfill.

With regard to progressive platform and language feature adoption, Object.observe and Template Strings are the correct replacements for our use case.

Comment 7

[Kevin Grandon :kgrandon]

Thanks for the info Rick! We do need a better implementation of templates when it comes to the polyfill, so I will file bugs on those and update when implemented.

Comment 8

[Rick Waldron [:rwaldron]]

(In reply to Kevin Grandon :kgrandon from comment #7)
> Thanks for the info Rick! We do need a better implementation of templates
> when it comes to the polyfill, so I will file bugs on those and update when
> implemented.

That doesn't solve the problem—the problem is that Web Component "templates" as specified and illustrated (http://www.w3.org/TR/components-intro/#template-section) don't satisfy our use cases; in fact, they are a regression back to the patterns that we replaced.

Comment 9

[Kevin Grandon :kgrandon]

Closing bugs in favor of spending time on Haida which will address the same problem if it exists.