upgrade our mobile UI to polymer 1.0?

[devoncarew]

https://elements.polymer-project.org/browse?package=iron-elements
https://elements.polymer-project.org/browse?package=paper-elements

bower dependencies should be updated to:

"iron-elements": "PolymerElements/iron-elements#^1.0.0",
"paper-elements": "PolymerElements/paper-elements#^1.0.0"

[kasperpeulen]

@devoncarew I really want to learn polymer 1.0, so I would like to help with this.

Is thsi only about updating the bower dependencies, or should the polymerjs wrapper also be updated ?

[devoncarew]

There's a lot involved here :)

• updating the bower deps, for sure
• we're using an older version of the vulcanize tool; we'd need to remove the version constraint and ensure that the new version of the tool works with us (the build had been failing with the newer version)
• the names of the components have changed (or rather, their categories). You'll have to introduce an lib/polymer/iron.dart library, and move some of the elements from core.dart to iron and some to paper.dart. I think core.dart would be empty at the end.
• at the end of web/mobile.html you'll find a script used to patch-up events when polymer is running. Dart gets JS event objects that it doesn't know how to translate when polymer's dom patches are active. We handle the events in javascript instead, and proxy them forward to custom dart event listeners. These workaround may not be necessary with the new polymer shady dom. Or, other workarounds may be necessary! A lot to investigate.

And the net net for our use of polymer is that we're consuming the polymer JS components directly, and have written light-weight dart wrapper classes around those components. Happy to have you take a look at this! It'll be a bigger chunk of work, and would have to be done in stages in its own branch. I don't think there's any bit that we could land incrementally in master. Happy to take a look at in-progress work if that helps.

[kasperpeulen]

@devoncarew okay, thanks for clearing this up

I also see that some methods in polymer.dart are outdated. I think we need to make these changes:

• Polymer.whenReady => HTMLImports.whenReady
• Polymer.import => Polymer.Base.importHref
• Polymer.waitingFor, Polymer.forceReady => ? I can't find these two, but we also don't seem to use it.

[devoncarew]

If things aren't used we can remove them, or perhaps comment them out w/ a note if they seem like they might be useful in the context of the new polymer. The logic to detect unregistered elements I think only worked on chrome. It probably implicitly depends on having a real shadow dom or something. It's not necessary to move that functionality forward. It's a nice to have, so you know why your page isn't loading at dev time, but not a critical feature.

[kasperpeulen]

This is quite a bit more work than I thought. So many elements have changed.. But a very good exercise to learn polymer ^^

@devoncarew I have first focussed on finding the right elements, and building just a static dom with those elements. Do you mind if I rewrite the code so that we have the dom just made by html in mobile.html (and not in mobile.dart) ? I think that would be a bit easier now, as I already got this static dom build. But I'm not sure if there may be an important reason to not build the dom using html ?

[devoncarew]

It's in dart currently in order to keep the app logic in one place (the dart source), instead of it being split up between dart and html. However, sgtm re: re-doing the UI in html. If we redo the UIs (combine the desktop and mobile UIs), we'll probably converge on polymer, and likely choose to build up most of the UI in dart code at that time. But we'll cross that bridge when we come to it.

[devoncarew]

Fixed by #452!