Comments (5)
Will this allow the engine router to route to external routes without the necessity of mapping external routes. Our app has a ton of routes. We use engines to share the same experience across multiple routes. Initially we started mapping external routes but this created a bit bloat in the code for little benefit as we do not use engines as a "separate app".
So back to the question will this allow us to
this.router.external.transitionTo('home.foo.bar')
where home.foo.bar
is a route in the consuming (parent) app?
from ember-engines.
Will this allow the engine router to route to external routes without the necessity of mapping external routes
It's not true Luis! As you can see on the proposal the routes continue to be declared on dependencies
as externalRoutes
.
from ember-engines.
Thanks for keeping progress on the router moving, @villander.
I'm unclear on how this proposal intersects with:
Consider allowing an experimental build flag to allow usage of an alpha engine-specific router which we can iterate upon.
Are you seeing the proposal in this issue (i.e. router.external
) as separate from the alpha router we discussed experimenting with?
My impression was that the alpha router would be used to experiment with all engine-specific routing concepts, including external routes.
from ember-engines.
Are you seeing the proposal in this issue (i.e. router.external) as separate from the alpha router we discussed experimenting with?
No! it's the same, we going to release the engine-specific
(i.e. route.external) with the build flag as an experimental feature. It's only a breakdown
@dgeb what I understood so far is that we going to use engine-specific
including all external routes passed down to Engines. Since the engine-specific
router, like the *External
methods will have access only for externalRoutes
as usual. Is that ok for you?
from ember-engines.
No! it's the same, we going to release the engine-specific (i.e. route.external) with the build flag as an experimental feature. It's only a breakdown
Gotcha, thanks for clarifying.
So I think we really have two alternatives on the table for handling external routes:
A) The one described in this RFC, in which an external
namespace on the router
service contains alternative external-route-specific methods.
B) An external
route helper (or perhaps just external:
string prefix) for namespacing external routes that can be used directly with the engine's router
service and the standard LinkTo
helpers.
Perhaps the best path forward will be to fill out option B as an RFC similar to this one, and at the same time fill in any gaps here for option A. Hopefully, we'll then be in a good position to decide if one approach is clearly better. If so, we can implement that behind the experimental flag. If not, perhaps we implement them both for comparison purposes in separate branches and then decide?
It will be good to talk this over in our monthly meeting and hear from @rwjblue, @buschtoens, and others who are interested in this space.
from ember-engines.
Related Issues (20)
- Loading substate isn't entered when lazily-loaded engine is mounted to root of host app HOT 1
- app.import() content can end up in app's vendor instead of engine's HOT 1
- Prepare for addition of engine-specific router service HOT 5
- 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
- `@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
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.