-
Notifications
You must be signed in to change notification settings - Fork 139
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
Lazy Loading Engines Attack Plan! #154
Comments
@nathanhammond thanks so much for putting this together. |
@nathanhammond Awesome doc! I'd like to help out on the ember-cli changes |
@sivakumar-kailasam which part? There are a bunch of pieces there; I'd encourage you to choose one of them and get a WIP PR open. 😊 (So that I can track progress and help keep the effort moving forward.) |
The first one to copy over engine-addons.js to ember-cli. Created ember-cli/ember-cli#6065 to start off. Will update and reach out when its good for review. |
This is looking awesome, thanks @nathanhammond for putting so much time into this. With regards to the build section, it states:
Does this mean that it will not be possible to build engines independently? For my use case, the engines would not be known or present at build-time of the application itself and would instead need to be built separately. The application would then need to "discover" the engines at run-time. Is this something that will be at all possible? |
@mike183, since I know your use case let me expand a bit. For everybody else this is probably nonsense and you can ignore it. No matter what you will need to modify at least one asset for the host application, either The other thing to address is the insertion of For people who wish to extend your application you can write an addon which people must include if they're targeting your platform. It does two things:
In your host application you:
|
Thanks @nathanhammond, I've messaged you on slack to avoid creating too much noise for everyone else. @peStoney - I think you had a similar use case to mine, you may also find the previous comment useful. |
@mike183 I updated the above comment for more clarity. |
@nathanhammond Thanks, I'll attempt to take a deeper look into all of this in the next day or so. |
@nathanhammond I did go through the manifest recently and stumbed over the approach for the router:
Maybe my english capabilities are failing but this sounds contradictory (?) In our use case it would be important that the engines |
I believe we have a similar need to @peStoney and @mike183 - currently we're discovering micro-uis hosted from separate docker micro-services. We would like to convert this to discovery of engines, but we won't have prior knowledge of the engine in the main app. At this stage we have a pre-engine solution to this that gives us a dynamically discovered navigation and dashboard, but the ultimate goal would be to use engines to provide a full SPA experience. @cstolli @psbanka @sandersky @job13er this will be of interest |
@peStoney @sglanzer see the approach I described here. The key snippet is:
You will need to change the default behavior in your build using an addon of your own writing but it will be entirely possible to accomplish. Further, we are aware of this use case and don't intend to make it impossibly difficult to implement. It will likely never be the default as a consequence of requiring additional network requests and out-of-band editing of a manifest file. |
@nathanhammond excellent, thanks for keeping this case in mind 👍 |
Strike Team Meeting Notes: 2016-07-21The strike team got together and had a conversation about the next steps and how we're progressing. These are the notes from that conversation. No timeline estimates yet, but the scope of work is better and better understood. Please review the new RFCs and give us feedback! Asset Manifest RFC
Asset Loading Service RFC
Build Time
|
Future investigation: notifying the Asset Loading Service of bundles that are reachable via /cc Marc Lynch at one of his three GitHub handles: @marclynch @lynchbomb @Ginormous |
For the build assets, we need to determine where they go in
So ideally we have paths that look somewhat like:
We need to determine what the name of |
@nathanhammond: "@marclynch" and "@Ginormous" are now but a faded ghost of the past and have been deleted ::tear:: |
Strike Team Meeting Notes: 2016-08-10Action Items
Discussion TopicsRouter Changes
Lazy Load Build
RFCs
0.4 Alpha to Beta to Stable
Road to 1.0
|
@rwjblue this issue can be closed? Or Is there anything still needing to be done with these checklists? |
Come one, come all! It's time to begin the process of extending
ember-engines
to support lazy loading! This document should describe every single step to get us from beginning to end, provide points of contact, and help you identify places where you can help us deliver it sooner. This top-post will be continuously updated.Background
As
ember-engines
exist right now you should consider them to be an isolation primitive. They allow you to provide guarantees as to the boundaries of your engine in its interaction with the host application and no more. This provides approximately zero benefit at runtime. However, this isolation primitive was built with the goal of being able to leverage that runtime isolation guarantee at build time to do clever things and allow us to asynchronously load engines. And if you're interested in that, you're in the right place!Effort
Most of these changes will be made inside of the
ember-engines
addon. Our goal is to land most of the functionality there first to iron out how it is going to work. As we identify pieces that we can migrate into Ember and Ember CLI we will do so behind feature flags.Participating
We want you to be able to dive in on any of this and are continuously updating this document with details on how to do particular pieces. Please feel free to claim portions of the effort by leaving a comment on this issue!
This effort is being organized by the Engine Lazy Loading Strike Team: Dan Gebhardt (@dgeb), Miguel Madero (@MiguelMadero), Nathan Hammond (@nathanhammond), Robert Jackson (@rwjblue), and Trent Willis (@trentmwillis). All of us will be able to review and provide guidance across most tasks. If you have detailed questions in specific areas try to track down the people that we've assigned to be responsible for particular sections first.
Issue Changelog
loader.js
approach.No edits yet required! Substantive changes will appear here.Build - @nathanhammond, @rwjblue
Ember CLI is responsible for doing all sorts of things at build time. This is area is concerned with what gets spit out after running
ember build
in an Ember application which includes lazy-loading engines. Note: engines may not have circular dependencies.Goals
index.html
will contain the asset manifests for all engines using a meta config module.vendor.js
will be updated if the engine'sroutes.js
file changes.Approach
All occurrences of
{engine}
below are the name of the engine according to thename
property in the module export of theindex.js
file inside of the engine.Asset Manifest
broccoli-asset-rev
.meta
tag config inside of the host application'sindex.html
Router
{engine}/routes.js
must be present at boot of the host application as well as anything it imports.{engine}/routes.js
{engine}/routes
.vendor.js
. Presence inside of the host application'svendor.js
is consideredundefined behavior
and may change in the future.Engine Code
{engine}/addon/*
dist/assets/{engine}.(js|css)
Engine Vendor
{engine}/vendor/*
dist/assets/{engine}-vendor.(js|css)
Engine Static Assets
{engine}/public/*
dist/{engine}/*
public
have no default behavior and must be manually loaded by the engine code.Tasks
EngineAddon
object handle the production of the correct assets. [PR] [Owner: @nathanhammond]EnginesAddon
build process.Asset Manifest - @trentmwillis
It is possible that engines can be included into an application multiple times at different mount points. We should support the ability to do so. This is an easy area to participate in.
Goals
Approach
This is non-normative and provided as a sketch for the beginning of an implementation. It assuredly has gaps. We probably want to have individual named manifests for each engine. We will need a way to map route path microsyntax to the engine's
moduleName
which can come as a separatemeta
config item.Sketch global engine config definition appearing at something like
config/engines
:Sketch engine manifest appearing at something like
config/engines/neat-engine
:Tasks
index.html
as a meta tag from the ember-asset-loader addon usingcontentFor
. [PR] [Owner: @trentmwillis]Asset Loading Service - @trentmwillis
This is a service that should be implemented which receives an Asset Manifest and returns a promise which resolves once all of the assets from that manifest have finished loading. This is an easy area to participate in.
Goals
Approach
This is non-normative and provided as a sketch for the beginning of an implementation. It assuredly has gaps.
Tasks
loader.js
cache miss should probably be reset on each engine load.The following may not work, but should be explored as an isolation guarantee:
loader.js
alias for the modules at the engine's mount point.define
for each of them.neat-engine
and will simply insert a duplicate module inside ofloader.js
at the appropriate mount point.Runtime Routing - @trentmwillis, @nathanhammond
Support for async loading of route handlers. The route files themselves won't be present at time of transition, so routing will have different outcomes dependent upon host application or crossing engine boundaries.
Goals
Approach
This has been pretty-well-distilled into tasks in that there is little that still needs design work.
Tasks
Document[Owner: @trentmwillis]inaccessibleByURL
behavior in ember-engines.getHandler
being called synchronously. No additional work needed. [Owner: @trentmwillis]Community Breakage - @MiguelMadero
It's possible that some of these changes will break tooling that exists in the Ember community, such as the Ember Inspector. It is hard to anticipate what these may be. Plan to review behaviors in Ember Inspector and
LOG_RESOLVER
.LOG_RESOLVER
eager resolution.Routeless Lazy Engines - @dgeb, @rwjblue
Routeless lazy engines are engines which are mounted using the
{{mount}}
helper. They will be discovered at build time while walking the dependency tree and packaged identically to above. They can be thought of as "lazy components" which also bundle all of their own dependencies.Goals
mount
keyword is encountered in the template?Approach
How this will function is poorly defined as template rendering is currently a synchronous behavior. The "easiest" solution likely requires us to know of
{{mount}}
usage in a template during the transition lifecycle.Tasks
Upstream to Ember Core
resolveEngine
. [PR]mount
keyword upstream to ember.jsNon-Goals
These are things we're not aiming to address at this time.
The text was updated successfully, but these errors were encountered: