Description
@ocombe so I guess since 1.5 will have lazy-loading there is no need for ocLazyLoad in the near future :(
As you may know, Angular 1.5 will include the possibility of lazy loading components. The draft is here.
The proposed implementation will be:
The implementation would consist of a new method on Angular Modules and a new service.
You would register some placeholder in the injector. Then you use a service to add the provider later.The only change to the behavior of the injector is that trying to inject a service that only has a placeholder, and not a corresponding provider implementation will throw a new type of error. The injector is still synchronous. HTML that has already been compiled, will not be affected by newly loaded directives.
To avoid situations where it's ambiguous which implementation of a module is used in an app, once an app has been bootstrapped, any modules that include a placeholder cannot be redefined. Trying to redefine a module like this will throw an error
To avoid situations where it's ambiguous what is actually included in a module, once a module with placeholders has been included in a bootstrapped app, it cannot have new placeholders or providers added to it.
Scenarios that this won't cover:
- loading a module without knowing its name: let's say that you want a service, and you know that this service in defined in a module, but all you want is the service, then you don't really need to know the name of the module (since ocLazyLoad 0.6.0), just the name of the service
- loading a module without knowing the name of all its components (to be confirmed, but I think that the current implementation will force you to define placeholders for all the components of a module, which will be really tedious...)
- lazy loading, the implementation won't include the loaders so you will still need something to do that (requirejs, systemjs, or... ocLazyLoad)
- a lazy loading directive such as the one from ocLazyLoad that combine a loader & a call to $compile
- the simplicity: ocLazyLoad lets you lazy load with just a file url. With the new implementation from angular 1.5 you will have to define the placeholders, it means more code to write
Also I'm working on new things for ocLazyLoad such as:
- a node module to create a tree of dependencies and a list of all the routes of your modules: it will preconfigure ocLazyLoad and then just let you lazy load components by name, no need for you to remember where your files are. Also, if you lazy load a component/module that has dependencies, ocLazyLoad will be able to find them in external files !
- a better integration with systemjs. You can do it right know with ui router future states, but it requires more code. I'd like to do something that would just work, you wouldn't have to write anything more than "import ..." in ES6, and ocLazyLoad would automatically register new components loaded by systemjs
- a whole new integration with webpack based on the two developments above: this webpack module would be able to parse your files, find the angular modules & components and suggest to webpack how it should pack the files!
As you can see, ocLazyLoad will still be useful once Angular 1.5 is out :)
Activity
amcdnl commentedon Mar 8, 2015
Wow, didn't think of those edge cases. I'm excited about your system integration!!!!!!
lookfirst commentedon Mar 8, 2015
👍 👍 👍
lookfirst commentedon Mar 8, 2015
I see that you're working on that angular issue too. I think if you can convince them to integrate your functionality directly into angular, that would be most ideal.
ocombe commentedon Mar 8, 2015
They won't (I already asked them) because my solution can lead to unexpected results.
Also it's a hack :)
lookfirst commentedon Mar 8, 2015
I guess my view is that it would less of a hack if it the functionality was integrated directly. No monkey patching angular.module/bootstrap(). ;-)
ocombe commentedon Mar 8, 2015
Yes, but they say that it can lead to unexpected results that would be hard to debug.
It's debatable, should they add a better functionality that would be flawed and probably unfixable, or should they add a something that works but is less useful.
I guess that they prefer something with no bugs :)
dmackerman commentedon Apr 7, 2015
Super looking forward to the SystemJS implementation! I punted on using this library because the future states and ui-router extras was just too much boilerplate for an existing app.
amcdnl commentedon Apr 7, 2015
@dmackerman check out my implementation. i've narrowed the gap somewhat - https://github.com/Swimlane/angular-systemjs-seed
lookfirst commentedon Apr 7, 2015
@dmackerman listen to @amcdnl =)
11 remaining items