Polymer Plunge: Diving In

Not long after completing my previous post, Polymer Plunge, I started running into a few more things to note regarding the web_ui to Polymer transition. Rather than editing the previous post, I decided to try and collect a few more and create a follow up post. And here we are.

First I want to note that the Dart site has already been updated with changes for the latest and greatest version of Polymer. From the index page, to the first 5 tutorials to the Polymer specific page. If you haven’t already, I highly recommend that you check out the Polymer Dart page, and as well the dedicated page Upgrading to Polymer.dart from Web UI (possibly featuring a few tips from my last post).

Without further adieu, here’s a few more caveats to be mindful of when working with Polymer. (Note: not all are specifically related to web_ui to Polymer porting, but are related to Polymer itself).

Conditional and Iteration Templates require PolymerExpressions
Firstly, if it’s been a while since you worked with web_ui, recall that we now have to use if="..." and not instantiate. Similarly we now use repeat="..." and not iterate="...". But these aren’t new changes and did come into play just prior to the Polymer dart port.
Of note however, is that with web_ui we could put our boolean tests or iterate statements just in the quotes. Now we must ensure that we use the moustache braces as well to make them Polymer Expressions. For example: <template if="{{ someBool }}">...<template>.
Can use noscript in Polymer Elements
When the Dart port of Polymer first showed up, it was required that every custom element has a corresponding dart class registered to it (usually using the @CustomTag() annotation). However that is no longer required, and if you have a very simple element, you can easily add the noscript attribute in your Polymer Element declaration. See Seth Ladd’s sample: simple_custom_element_without_script.
Important Note: If you plan to have a polymer element without a script, but forget to put in the noscript attribute; OR if you have a polymer element but forget to include the script in your polymer element (ie: forget to put in the <script type="application/dart" src=".."></script>), then your element will not display on the page at all. It won’t just be non-functional, it will not be there at all. I’ve been bitten by that one a couple of times.
Place your Imports properly
If your component uses another custom component and you need to import it with: <link rel="import" href="...">. It’s important to make sure that you place the import inside of your polymer-element tags, but outside of your template tags. Otherwise your imported resource won’t work. In my case, it just didn’t display anything.
Don’t use onPropertyChange for ObservableLists
I mentioned how you can use onPropertyChange to setup observable getters. However if you want to bind a getter to an ObservableList, then we need to listen for changes in the list itself. Similar to:

var list = toObservable(myList)
..changes.listen((_) => notifyProperty(this, #myGetter));

Note the cascade so we still return our ObservableList and not a StreamSubscription.

ObservableList.sublist() does not return an ObservableList
This is a little bug that I ran into that I thought I would mention as well. Per Issue 13965: An ObservableList.sublist returns a standard List, not an ObservableList as one might expect. Simple solution if you still want an ObservableList is to wrap the call in toObservable. toObservable(observList.sublist(0, 4));.
DocumentFragment.queryAll() does not return an ElementList
A recent update to the dart:html library made a change so that instead of a List<Element>‘s being returned from queryAll(), an ElementList object was returned instead, which would provide direct access to variables such as classes which enables us to easily access the classes of all returned elements without manually iterating through each. However for some reason DocumentFragment, and thus ShadowRoot, did not get the new return type for their queryAll() methods. As such if you try to use the classes property it will work, but you will get warnings in the editor. It’s my suspicion that their code was updated but the method signature was not. See Issue 14015.
No Package Layout Conventions
As per a question I posted on Stack Overflow, and as well a corresponding issue in the tracker. There are currently no package layout conventions for Polymer projects. Due to Issue 12867 we are unable to use package: URL schemes in HTML Imports. As such making relative file look-ups awkward at best and failing at worst. My thought thus far has been to simply create a web/src/ directory for my polymer implementation files and reference things from there. But I’d love to hear your thoughts on the subject!

[Edit: Oct 23-2013]A few additional changes to Polymer since this post should be noted. See A new Dart and Polymer Update[/edit]

This entry was posted in Dart and tagged . Bookmark the permalink.

Have Something To Add?

Loading Facebook Comments ...
Loading Disqus Comments ...