Comments (16)
Looks like ember engines may be what I'm looking for especially lazy-loading. In my modular structure, several engines will be distributed in different directories. Will it be possible to load engines that are not explicitely installed with ember install command but by telling ember (maybe in the html or via rest-api) where to find an engine at which mount point?
This is something that I am also interested in.
For my use-case, a majority of engines wouldn't actually be installed into the main application at build time. They would instead be built independently and the application would be required to locate, configure and mount them at runtime.
from ember-engines.
This issue has been superceded by #154
from ember-engines.
Yeah, we do. I'll try to take some time in the next day or two and comment with some of the ideas...
from ember-engines.
Their have been several issues opened in the past, I believe the RFC has some relevant comments.
From memory the following needs to be fixed:
- Router.js needs to support routing to handlers that are not yet loaded
- Likely something about query params
- slight addition to concat-phase of ember-cli + some config to enable a quick path for this. (Although more intelligent packaging aka linker/packager work will likely be able to solve other relevant issues, like splitting vendor etc but in a more automatic way)
- in the past, the route serialization stuff was a concern but i believe right now we don't allow link-to between engines, is that correct?
- be sure to add support for lazy-loading fingerprinted bundles
from ember-engines.
thanks @stefanpenner, that summarizes the path pretty well
from ember-engines.
Will this feature have to be used with fastboot, or will the dist contain everything necessary? Like will the paren't app append engine script tags to the DOM when the user triggers an engine for the first time?
from ember-engines.
When we have written the code, we will let you know. 😺
In all seriousness though, we do not plan to require fastboot for anything in this addon.
from ember-engines.
Excellent 👍
from ember-engines.
or will the dist contain everything necessary?
likely this
from ember-engines.
The last time I explored this for ember-admin I believe it could be possible by modifying how the resolver does look ups. If a module is not found locally the resolver would defer to fetching the resource remotely then try the lookup again. At that point the resolver has the resource cached.
Its been a while since I mucked around inside the resolver code but it would be ideal if however the remote fetch is done that the resolving itself is promise-based the consuming application can give some state indication that the engine's loading is pending
.
from ember-engines.
Looks like ember engines may be what I'm looking for especially lazy-loading. In my modular structure, several engines will be distributed in different directories. Will it be possible to load engines that are not explicitely installed with ember install
command but by telling ember (maybe in the html or via rest-api) where to find an engine at which mount point?
from ember-engines.
Its been a while since I mucked around inside the resolver code
I don't believe this should be a resolver concern, or atleast shouldn't be at the per-module granularity as they would force all possible module loads to be async. I believe that would result in much more complexity then we want to deal with. Instead larger slabs, like per engine async'ness is likely the best balance. This keeps async to explicit points where async can be correctly handled, not at every possible resolve step.
from ember-engines.
@stefanpenner and @dgeb I spent time working on lazy-loading for an app. Some of this work could help engines and I have some time to work on it. I solve some of the points that you mentioned above:
Router.js needs to support routing to handlers that are not yet loaded
I solved this by using a catch-all route, abort the transition, load the bundle with the route and then resume the transition. You can see an example on routes/catch-all#redirect.
I wanted to do it in a way that I didn't have to patch Ember, but I could do something similar in router.js
Likely something about query params
I've been ignoring it for now, but it might just work with the approach above.
slight addition to concat-phase of ember-cli + some config to enable a quick path for this. (Although more intelligent packaging aka linker/packager work will likely be able to solve other relevant issues, like splitting vendor etc but in a more automatic way)
This is a bit hacky and I still plan to extract it. Likely the packager
will be a better long-term solution, for now, I'm basically using a different EmberApp for each "package" (you can think of them as engines, but I wanted to use a different term to make it clear that this isn't the same thing). You can see an example on ember-cli-build, but this could be encapsulated in something that looks like:
var emberApp = EmberAppWithPackages({
sharedConfig: {},
bootAppConfig: {},
packagesConfig: {}
});
Alternatively, we could provide the configuration for each engine's index.js
file, but still let the consuming app provide overrides. Although this works, I don't think it's they way to go, it is just the way I solved it without tweaking CLI internal's or re-doing this work directly in broccoli and breaking add-ons.
in the past, the route serialization stuff was a concern but i believe right now we don't allow link-to between engines, is that correct?
For now, I'm avoiding that or simply using a new {{link-to}}
helper that uses the default serialize behavior until we get a way to override it in Router.map
.
be sure to add support for lazy-loading fingerprinted bundles
Still WIP, but the idea is to define the list of asset URLs based on the names of the bundles in a map {engine-name: /assets/engine-name.js} and let AssetRev tweak it. You can see an example on index.html. The map isn't used yet at runtime, I want to move away from the global, so that's why it still needs some work.
I have an example of all of this working on https://github.com/MiguelMadero/ember-cli-packages-demo/. I would love your feedback on this and as I mentioned, I have some time to see help push this forward.
from ember-engines.
Just wanted to get this out there, but if the query params API was a service, it would be simple to integrate between different engines.
from ember-engines.
For my use-case, a majority of engines wouldn't actually be installed into the main application at build time. They would instead be built independently and the application would be required to locate, configure and mount them at runtime.
@mike183 - that's exactly what I'm looking for as well. @dgeb - will this be possible with ember-engines in the future? That would allow users to customize an app by selecting the engines they actually need. At the moment it looks like every engine to be consumed needs to be defined at build time...
from ember-engines.
@mike183 @peStoney Sorry to delay with a response. It is theoretically possible that routeless engines could be lazy-loaded by a parent that doesn't have any foreknowledge of the engine. However, routable engines need to eagerly provide their route maps to their parents to support routing into them that triggers lazy-loading.
from ember-engines.
Related Issues (20)
- Pod style with tailwind inside in-repo engine doesn't processed correctly HOT 3
- [RFC] Deprecate `{ 'engine-service': 'host-service' }` syntax for service dependencies HOT 1
- Lazy loading changes output path of assets HOT 1
- [RFC] Provide `externalRouter` to Engines HOT 5
- `@embroider/macros` macro conditions can sometimes be evaluated incorrectly HOT 1
- Unknown object passed to sourceOfConfig() error HOT 6
- How to install an addon in an engine? HOT 2
- getOwner doesn't return the context for the route HOT 3
- cannot find module "@ember/routing/link-component" in ember ~4.1 HOT 2
- Class extends value [object Object] is not a constructor or null HOT 3
- Could not find module `@ember/legacy-built-in-components` HOT 2
- error reading "inaccessibleByURL" is undefined sometimes
- build error after upgrading to 0.9.0 HOT 3
- Service dependencies do not pass through properly in embedded engine (Ember 3.28) HOT 3
- Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'on') HOT 1
- dependencies do not pass through properly in embedded engine under single spa
- 0.8.22 breaks compatability with Ember > 3.24 HOT 2
- Transitioning from one engine route to another triggers a Cannot read properties of undefined (reading 'shouldSupersede')
- Rebuild crash on Ember 4.12.1 apps - Ember CSS file HOT 1
- Getting ember-source dependency conflict with ember-source 5.3 HOT 10
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ember-engines.