New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Asset Loader Service #158

Closed
wants to merge 3 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@trentmwillis
Member

trentmwillis commented Jul 22, 2016

Pre-reading/context: Asset Manifest RFC

Rendered.

@nathanhammond nathanhammond referenced this pull request Jul 24, 2016

Closed

Lazy Loading Engines Attack Plan! #154

18 of 29 tasks complete
@rwjblue

This comment has been minimized.

Member

rwjblue commented Nov 8, 2016

Where are we at with this?

@dgeb / @MiguelMadero / @nathanhammond / @trentmwillis - Have y'all reviewed?

@rwjblue rwjblue referenced this pull request Nov 8, 2016

Closed

Adds lazy-load-overview #141

1 of 4 tasks complete
@trentmwillis

This comment has been minimized.

Member

trentmwillis commented Nov 8, 2016

We have a working implementation in ember-asset-loader that has been used successfully for both lazy loading Engines and generic use cases (e.g., loading a charting lib).

Primary open question to me is where does this Service live in the future? For many use cases, having a standalone, core-maintained addon seems sufficient. But, for the lazy Engines use case, it needs to integrate with some of the internals of Ember's Router, which makes it seem like this could potentially be part of Ember itself. At the very least, if it continues as a separate addon, we likely need a solid API for hooking into the Router.

@nathanhammond

This comment has been minimized.

nathanhammond commented Nov 8, 2016

Have reviewed the RFC and many of the PRs that went into the implementation. This is set by my estimation.

@trentmwillis

This comment has been minimized.

Member

trentmwillis commented Dec 3, 2016

@rwjblue clarified some wording. I think this is ready to move to FCP.

@rwjblue

This comment has been minimized.

Member

rwjblue commented Apr 28, 2017

We discussed this during todays Ember core team meeting today, and we are 👍 on this moving forward.

Given that there is little conversation here, and the core team is in favor I an moving this forward into the final comment period.

`loadAsset` will return an `AssetPromise` that will resolve when the asset is successfully loaded or reject when the asset fails to load.
Subsequent calls to `loadAsset` with the same arguments will return the same `AssetPromise` object to ensure a single source of truth for determining asset state as well as to prevent duplicate requests being made for the same asset.

This comment has been minimized.

@courajs

courajs May 4, 2017

Can we clarify here that this is true unless/until retryLoad is called, and link down to the Provide A Way To Attempt Recovery section?

@rwjblue

This comment has been minimized.

Member

rwjblue commented Mar 9, 2018

Discussed this a bit with @tomdale and we decided that we should close this. Not as "wontfix" but more as "already done" in addon space without needing more detailed core framework involvement. This is absolutely public API from ember-engines point of view, and it will be supported as such.

@trentmwillis - Thank you very much for your hard work on this, and I'm very sorry that we let this sit for sooo long.

@rwjblue rwjblue closed this Mar 9, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment