Async main page import changes upgrade order of subimport deps

[miztroh-zz]

I've written an app shell element that provides little other than the structure to my app. All the functionality is brought in as separate elements in the light DOM. I'm async-ing those imports. This works fine for all but one. That one provides several paper-dialogs to the app. It appears that async-ing a top-level import also asyncs any dependency imports. This causes the paper-dialog to not render correctly (e.g. transparent background / no paper-material effects, etc.). Changing the top-level import to sync fixes the issue, but there's probably a first render performance hit. Is there any way to async an import but force its dependencies to be synchronously loaded?

[ebidel]

This might be similar to what happens in #2481. Some of the elements assume to be in a synchronous world and they really shouldn't. IMO, we need a lot more work here.

I'm also experiencing this with updating Polymer's TodoMVC app. There definitely seems to be timing issues when you make the main page import async. The elements inside elements.html get their created() callback in the correct order (document inclusive order), but the app different timing issues between chrome and polyfill'd browsers. The solution is to dev without async and to use it on your vulcanized bundle for prod:

<link rel="import" href="elements/elements.build.html" async>
<!-- <link rel="import" href="elements/elements.html"> -->

That seems to always work for me.

[miztroh-zz]

@ebidel How can I use vulcanize to bundle a set of elements for importing into another element without Polymer being included multiple times or not at all? Every time I've taken a swing at vulcanizing elements, I've encountered breakage.

[ebidel]

You can use vulcanize's --strip-exclude flag to remove all polymer.html imports. Then load it instead in your main page.

[miztroh-zz]

@ebidel Using the following, vulcanize goes through just fine. However, the resulting import gives the following errors.

vulcanize -p /var/www/html --strip-exclude "/polymer_1.0/bower_components/polymer/" polymer_1.0/elements/app-shell/elements.html > polymer_1.0/elements/app-shell/elements.build.html

Uncaught NotSupportedError: Failed to execute 'registerElement' on 'Document': Registration failed for type 'dom-module'. A type with that name is already registered.

Uncaught TypeError: Polymer.Base._getExtendedPrototype is not a function

Uncaught TypeError: Cannot read property 'dashToCamelCase' of undefined

Uncaught TypeError: this._desugarBehaviors is not a function

[ciampo]

@ebidel trying to use your strategy (dev non async, vulcanized async) on the Polymer Starter Kit, but no luck. Looks like some of the styles are not being applied. Any news on this?

[dfreedm]

I'm not sure what you mean by making the dependencies synchronous.
When the async'd import finally loads, its dependencies should resolve in order.

[miztroh-zz]

@azakus This question was me grasping at straws to try to understand why async'ing imports was breaking things. Specifically, I'm having the issue described below but the issue was erroneously closed and we can't get anyone from the Polymer team to reopen / answer.

PolymerElements/iron-overlay-behavior#23

[ebidel]

@azakus, if you add async to the main page import, it changes the upgrade order of subimports. This might be a bug in Chrome b/c it only affects browsers wth native HTML Imports. Also related: #2481

Repo

From #2678 (comment). Check out that repo and run the app. I used his vulcanized elements.html. Toggling async changes the subimport upgrade order. I added logging in each element's created callback:

Using <link rel="import" href="elements.html">:

created gallery-data
created gallery-albums
created artifact-grid

Using <link rel="import" href="elements.html"> async:

created gallery-data
created artifact-grid
created gallery-albums

This causes bindings to misbehavior b/c gallery-data updates the albums property before <gallery-albums albums` has that property. Therefore, it's lost to the polymer ethos

<template is='dom-bind' id='app'>
  <gallery-data artifacts='{{artifacts}}' total-artifacts='{{totalArtifacts}}' albums='{{albums}}'></gallery-data>
  <gallery-albums albums='[[albums]]' count='[[totalArtifacts]]'></gallery-albums>
  <artifact-grid artifacts='[[artifacts]]'></artifact-grid>
</template>

[ebidel]

#2653 would help the binding case

[jshcrowthe]

Any updates on this?

[ciampo]

+1

[IntranetFactory]

It seems that this problem still exists in 1.7.1 and impacts also async importHref. When I import elements with importHref with async=true I get all kind of wired errors (like [paper-radio-button::_flattenBehaviorsList]: behavior is null, check for missing or 404 import where paper-radio-button is imported by the element I'm loading with importHref). When I change async to false these errors disappear again.

So are there any plans to address that issue in 1.x ?

[newlukai]

For me it seems that there are race conditions regarding the HTML Import map if you have multiple asynchronous HTML Import workers processing the same file/import. See StackOverflow for more information.

[johnlim]

Hi, any update regarding this? I'm also experiencing :_flattenBehaviorsList]: behavior is null, check for missing or 404 import issues intermittently.

[gitact]

any update? i had similar problems and i lost DAYS to understand that "async" was the problem!

[mgibas]

Same here (:_flattenBehaviorsList]: behavior is null) - weird that it fails only with paper-slider for me :/

[TimvdLippe]

Sadly this appears to be an upstream bug at https://bugs.chromium.org/p/chromium/issues/detail?id=669710 I am not sure what the Polymer team can do, other than poking that issue. Eventually, async loading is changed to dynamic import with Polymer 3.

[TimvdLippe]

Closing this issue per above comment. Native async HTML imports have an upstream bug in Chromium linked above that results in sub-dependencies loading being out of order. Since we are moving to ES modules with Polymer 3 and adopt dynamic import, this issue will be gone. Any potential fixes to async HTML import have to be published to Chromium, thus we have no further action available here.