Saturday, December 28, 2013

Less Fun with Transformed Dart Polymers


Bleeding edge. Pre-alpha. Under rapid development. I love it all.

Sure, it makes writing books hard, but seeing people smarter than me solve old problems in new ways or just solving new problems is fascinating. And, if something does not work, I usually just have to wait a couple of days before it gets fixed. For example, my @observable problem seems to have cleared up in recent Polymer.dart / observerable builds. Even more useful to my recent internationalization struggles, it seems that the Polymer transformer for Dart Pub has become slightly less hostile to <link> imports.

I have been toying with using <link> imports to pull in Polymer configuration data. This works fairly well in both the JavaScript and Dart version of Polymer. But the Dart transformer that prepares an application for deployment has been silently deleting references to these imports:
    <link rel="import" href="packages/i18n_example/hello-you.html">
    <link rel="import" href="packages/i18n_example/hello-you-en.json">
    <link rel="import" href="packages/i18n_example/hello-you-fr.json">
    <link rel="import" href="packages/i18n_example/hello-you-es.json">
Any solution that I come up with is useless unless it can be deployed, so the silent deletion left me flummoxed.

But after a recent pub upgrade to grab the latest package dependencies in my application, I noticed something odd with the transformed Polymers:



That seems workable. Sure, I might have style that data to display: none and I will have to conditionally check the DOM for that data directly embedded by the transform, but that seems a minor inconvenience. If it works. Which it does not.

This will not work because, no matter where I place those <link> imports (in the document or in the Polymer template), the result is that the imported data is added directly to the document without structure. Even if I wrap the <link> tags in <div> tags, the result is the same—the transform adds the imported locale JSON directly to the document without structure:
...
  <body>{
  "hello": "Hello",
  "done": "Done",
  "how_many": "How many?",
  "instructions": "Introduce yourself for an amazing personalized experience!"
}
{
  "hello": "Bonjour",
  "done": "Fin",
  "how_many": "Combien?",
  "instructions": "Présentez-vous une expérience personnalisée incroyable!"
}
{
  "hello": "¡Hola!",
  "done": "Hecho",
  "how_many": "¿Cuántos?",
  "instructions": "Preséntese para una experiencia personalizada increíble!"
}
<polymer-element name="hello-you">
...
Bummer. I suppose from a transformer point of view, that makes sense. The transformer is converting the multi-filed application into something deployable. For Polymer, that means inserting the custom element declarations directly into the page. The transformer is not smart enough to know not to do so with JSON files and, even if it were “smart” enough, I am unsure how it ought to handle this case. Bundle them into the page in a way that somewhat mimics the <link> tag semantics? Ignore them and force these resources to continue to go through the “normal” <link> tag? The latter has its appeal, but it is being polyfilled by the Polymer platform to begin with, so ugh.

It is a shame, because defining an element in the JavaScript version of Polymer would work:
<link rel="import" href="hello-you-en.json">
<link rel="import" href="hello-you-fr.json">
<link rel="src" href="hello-you-es.json">
<polymer-element name="hello-you">
It is possible to access the <link> elements via the Polymer's element property:
this.element.previousElementSibling.import.textContent
Actually, now that I think of it, this is not even possible in non-transformed Dart Polymers. The declaration property of a Polymer is the closest analogy to Polymer's element property, but it does not include the <link> elements in the previousSiblingElement property.

Bother.

So after all that, life on the bleeding edge remains a little rough. I still think the <link> import solution is a nice one for loading configuration data in regular Polymer. But in the Dart-flavored Polymer, it is looking more and more as if I will need to rely on <polymer-ajax> to load this kind of data.


Day #979

No comments:

Post a Comment