908717 - [Clock] Implement a lazily loaded DOM, based on WebComponents

Status: RESOLVED WONTFIX

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

Description

[Kevin Grandon :kgrandon]

Clock lazy loads the edit form today, but it would be nice to move this into our new WebComponent infrastructure.

Comment 1

[Kevin Grandon :kgrandon]

Attachment: Github Pull Request

Comment 2

[Kevin Grandon :kgrandon]

Comment on attachment 794728 [details]
Github Pull Request

Hi Mike - Think you could review this one? There are two commits here, but only the changes in clock/ need to be reviewed. This is just moving the content to a standalone file. Thanks!

Comment 3

[Mike Pennisi [:jugglinmike]]

Hey Kevin,

Thanks for demonstrating the WebComponent shim! Is there any documentation on how it may be used? We're particularly interested in two pieces of functionality:

1. Programmatic usage (i.e. `document.createElement('edit-alarm')`). This will make unit testing far simpler (no more reliance on the state of the test environment's document object)
2. Template interpolation. Is there any support for "expanding" a template based on a "context" object? For example, in the Messaging application, we made heavy use of a `Template` utility [1] to help de-couple JavaScript and HTML [2].

It looks like the first commit in the pull request has already landed in `master`, but with a different SHA. Is this the case?

[1] https://github.com/mozilla-b2g/gaia/blob/50b3e3ae7cff0db311cb98cd6b83d6650e9dd584/apps/sms/js/utils.js#L559-L624
[2] https://github.com/mozilla-b2g/gaia/blob/50b3e3ae7cff0db311cb98cd6b83d6650e9dd584/apps/sms/index.html#L275-L294

Comment 4

[Kevin Grandon :kgrandon]

(In reply to Mike Pennisi [:jugglinmike] from comment #3)
> Hey Kevin,
> 
> Thanks for demonstrating the WebComponent shim! Is there any documentation
> on how it may be used? We're particularly interested in two pieces of
> functionality:
> 
> 1. Programmatic usage (i.e. `document.createElement('edit-alarm')`). This
> will make unit testing far simpler (no more reliance on the state of the
> test environment's document object)

Hi Mike! We are planning on adding a requireElement() or similar to unit tests. This would basically allow you to import any required dom element into the unit test as desired. Be it a template, element, or whatever you need. Currently we have a lot of duplicate DOM inside of unit tests and applications. We should no longer have this problem in the near future. I can fast-track this work if it's something you need soon.


> 2. Template interpolation. Is there any support for "expanding" a template
> based on a "context" object? For example, in the Messaging application, we
> made heavy use of a `Template` utility [1] to help de-couple JavaScript and
> HTML [2].

This would be nice to have, and there was some discussion about this in the sms bug. The nice thing is that you can simply populate the template content in different files with this, and use the same templating that SMS does if you wish.


> It looks like the first commit in the pull request has already landed in
> `master`, but with a different SHA. Is this the case?

Sorry, I've rebased the commit. The first part has already landed in master and work has begun in porting other apps to use this.

Comment 5

[Kevin Grandon :kgrandon]

Let me know if you have any other questions/concerns Mike. Basically all this does is move the dom to another file and actually lets us view it with syntax highlighting. I think I would like to land this, as from here we can add additional features like unit test support and template interpolation as desired.

Thanks!

Comment 6

[Kevin Grandon :kgrandon]

Comment on attachment 794728 [details]
Github Pull Request

A new solution is required after the alameda refactoring lands.

Comment 7

[Marcus Cavanaugh [:mcav]]

Kevin, is this bug still actionable?

Comment 8

[Kevin Grandon :kgrandon]

There are some nice improvements we can still have here. At this point though, I think I would rather focus on Haida, which will have the same effect down the road.