Skip to content
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

Angular 1.5 & ocLazyLoad #138

Closed
ocombe opened this issue Mar 8, 2015 · 19 comments
Closed

Angular 1.5 & ocLazyLoad #138

ocombe opened this issue Mar 8, 2015 · 19 comments

Comments

@ocombe
Copy link
Owner

ocombe commented Mar 8, 2015

@amcdnl wrote:

@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 :)

@ocombe ocombe mentioned this issue Mar 8, 2015
@ocombe ocombe modified the milestones: 1.0 - Stable api & modularity, 1.1 - Website & documentation Mar 8, 2015
@amcdnl
Copy link

amcdnl commented Mar 8, 2015

Wow, didn't think of those edge cases. I'm excited about your system integration!!!!!!

@lookfirst
Copy link
Contributor

👍 👍 👍

@lookfirst
Copy link
Contributor

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
Copy link
Owner Author

ocombe commented Mar 8, 2015

They won't (I already asked them) because my solution can lead to unexpected results.
Also it's a hack :)

@lookfirst
Copy link
Contributor

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
Copy link
Owner Author

ocombe commented 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
Copy link

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
Copy link

amcdnl commented Apr 7, 2015

@dmackerman check out my implementation. i've narrowed the gap somewhat - https://github.com/Swimlane/angular-systemjs-seed

@lookfirst
Copy link
Contributor

@dmackerman listen to @amcdnl =)

@ocombe
Copy link
Owner Author

ocombe commented Apr 7, 2015

Yep the work from @amcdnl is really good for systemjs :)

@yellow1912
Copy link

Given that this issue is very old already, what is the current status on this?

Angularjs 2 is still a bit far away, plus many 3rd party plugins wont be ready for it soon so we will get stuck with Angular 1 for at least another 6 months and in the mean time it would make much sense to find a solution for 1.x instead of waiting for 2.x to mature.

@ocombe
Copy link
Owner Author

ocombe commented Feb 23, 2016

They postponed the lazy loading part of angular 1.5 to an unknown version (probably never) :(

@amcdnl
Copy link

amcdnl commented Feb 23, 2016

@ocombe I got the impression it wasn't gonna happen ever for 1.x and in my prototyping I'm not sure even if 2.x can do it.

P.S. @ocombe i invited u to chat on gitter!

@yellow1912
Copy link

Too sad. I'm keen on migrating to angular2 soon for the chance to use lazy load, but seems like it's stll a bit too early for this (even with the beta 2 version). I have too many angular 1 module right now.

I wonder if there is any online demo that shows how angular 1 and 2 can run side by side? I have seen this mentioned lots of time without seeing any real world example

@amcdnl
Copy link

amcdnl commented Feb 26, 2016

@yellow1912 A2 can not lazy load out of the box, I'm sure @ocombe could elaborate more though.

I'd avoid the upgrade for now, the code d/l is like 700+ kb right now. They plan to trim it down by release but thats a lot of weight...and not to mention the moving target API.

@ocombe
Copy link
Owner Author

ocombe commented Feb 26, 2016

You can lazy load in Angular 2 but it's a bit tricky right now, I might work on a lib to do that one day (but I have many things on my plate right now).
Also they plan to pre-compile a lot of stuff to dump the template parser (to reduce the size), which means no more lazy loading.

@amcdnl I don't use gitter (and didn't receive any invite?), you can find me on the angular buddies slack, or on gtalk (olivier.combe@gmail.com) or twitter

@sukrosono
Copy link

@ocombe They postponed the lazy loading part of angular 1.5 to an unknown version (probably never) :(

what is the main reason for that? do you know?

@ocombe
Copy link
Owner Author

ocombe commented Feb 29, 2016

Lack of man power, and Angular 2 coming soon with the ability to lazy load

@ocombe ocombe closed this as completed Apr 16, 2016
@olibri-us
Copy link

Damn, i'm sad to hear that :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants