Open thomas-darling opened 8 years ago
@ahmedshuhel You've recently been in this code...how hard do you think it would be to make this work? Basically, before running the configure methods we would need to track which module is running config and then use that information the same way that we do in the globalResources helper method. Any interest in taking this on since you've been working in that code most recently? It would be pretty nice to have this, even for 3rd party plugins that might include other 3rd party plugins. I think we would need this to make it work correctly.
@EisenbergEffect I would love to work on it. I will talk about it in details on gitter channel tonight.
@EisenbergEffect, @ahmedshuhel Awesome, thank you!
A related question:
Have you guys thought about how features and lazy-loaded routes might work together?
We're building a large site here, and it would be good for maintainability if each area of the site could be implemented as a feature, so e.g. any area-specific globalResources
calls can be defined within the area, instead of in the site root - but the thing is, each of those areas are bundled separately, which means they are only loaded when the user actually navigates into the area. Would it be possible to support this?
I actually just tried putting this in the file containing the root component for an area, but it seems to break things - the configure
function is actually invoked when I navigate into the area, but the use
argument is undefined and afterwards the Area1
class is never instantiated. If I remove the configure
function, then the area loads as expected. No errors in the console though, so not sure what's going on... it may just be me trying to abuse things here, but I think it it could be handy if it worked :-) Thoughts?
import {FrameworkConfiguration} from "aurelia-framework";
export function configure(use: FrameworkConfiguration)
{
console.log("configure area"); // This is actually invoked when navigating into the area
}
export class Area1
{
constructor()
{
console.log("create area"); // This is only invoked if I remove the 'configure' function
}
}
We have the ability, in the future, to make global resources be global only to a plugin/feature area. It hasn't been implemented yet.
To have routes trigger a plugin configuration, we would also need to extend the router. That's the more tricky part, but it could be added to the pipeline at the very beginning. We would need to add an additional configuration parameter on the route config so a plugin could be associated with it.
If those things interest you, they are separate from this issue. Please create for us issues, one on the templating engine for feature-visible resources and one on the router for the ability to confirm a plugin's installation prior to routing.
What do you expect in the following case: plugins X and Y load internally plugin Z, and an application loads X and Y.
@EisenbergEffect Thanks, sounds good - I'll create issues for it when I get back from my holidays :-)
@StrahilKazlachev I would expect the configure
function of Z to be executed only once - it just needs to register it's resources and stuff like that, and that should only happen once :-)
Is this the reason for, or related to, the fact that:
aurelia.use.standardConfiguration()
.globalResources([
"xx/xx"
]);
Loads xx/xx
relative to the current page instead of relative to the module with the configure
function?
Say I have an app that contain a
feature
that itself is structured as a set offeatures
. Here,infrastructure
is a feature, and so islocalization
andlogging
:Now, in
app.ts
I load theinfrastructure
feature like this:And in
infrastructure/index.ts
I load the nested features like this:This works, but I expected that the paths to the nested features would be relative to the current feature - i.e. just "./localization" and "./logging". That way it would be more resilient to refactoring, and consistent with the way
use.globalResources
works - if I use that inside theconfigure
function of a feature, then it expects paths that are relative to that feature.