You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@JohannesHoppe Seems like the the discussen revolved around the issue with systemJS and barrels.
But as CLI is now completely on webpack, and webpack works great with barrels.
Also in the node community, working with barrels is becoming more and more common.
I would like to see barrels back into the CLI. Makes importing things way better.
Right now the single usage of the last remaining barrels is inconsistent. That’s the first point.
The other point is the general future of the style guide. Will be barrels deprecated or not?
In my opinion they make things more complicated, when people start to add more code into the index.ts. One example is adding a bunch of components to an array, for later imports. Before angular-modules this was a doable approach, but now we don’t need both solutions (in my opinion).
I would also vote for not having barrels at all, since I don’t want to have Angular code that depends on the module loader and/or the cli. The CLI should be transparent enough, that I could switch to any other approach (e.g. SystemJS) at any time.
But my arguments are not important here. I can live with both. But I really wonder about "StyleGuide 04-10 - Barrels" and what this means for the CLI.
@JohannesHoppe You can use barrels pretty seamless with ngModule. I wrote a small article over just that. It reduces the amount of boilerplate lines, and simplifies importing things in your application.
Reducing boilerplate is making better readable code.
I have not seen a technical reason for rejecting barrels. Even after digging in a bit more. Also talked a bit about it with @robwormald, He also liked the idea of using barrels the way I showed. there are some things that need attending, but he agreed that this use-case was a very valid one.
So I still think support for barrels should be back in. Perhaps behind a flag, that optionally enables it.
The big problem of barrels is not just a stylistic thing, it is that they make it exceedingly easy to accidentally have circular dependencies among your type script modules (not angular modules). As of at least a few betas ago with webpack, this broke everything. Although in theory the type script and es2015 module systems should handle circular dependencies fine, support is stuff in-progress for webpack 2.
Circular dependency do work OK with System, which is why the barrels were mostly OK with the older CLI. Once webpack supports this properly, then it may be suitable to revisit the idea of reintroducing barrels here. The problem was a couple of webpack betas ago - maybe it's already fixed? I don't know, but someone who does know, should lead the charge on this.
The official stance right now is that barrels are not a style guide recommendation per se, as the introduction of NgModule makes them less necessary.
Reexporting is still a useful technique with ES6 Modules though, so it's common enough to have a couple of reexporting barrels in an application. Hence we still have these barrels.
As @kylecordes says, there are webpack issues with circular dependencies, see #1831 for one such case.
I am finding a problem with barrels when used in Angular-cli. If a component is imported from a barrel, it is not being picked up and shown on the screen. However, when I import the component from its .ts file, it works fine. This is getting me amazed, why would this happen?
In my case, I have this structure:
common-data module
agency module
agency-list.component.ts
index.ts
common-data.module.ts
common-data-routing.module.ts
The index.ts contains this:
export * from './agency/agency-list.component';
Inside the common-data-routing.module, I do this:
import { AgencyListComponent } from '../common-data'
The above doesn't work. What works is only this:
import { AgencyListComponent } from './agency/agency-list.component'
No error is generated, it is just the screen is not displayed.
Any idea?
angular-automatic-lock-bot commented on Sep 7, 2019
Activity
SanderElias commentedon Sep 15, 2016
@JohannesHoppe Seems like the the discussen revolved around the issue with systemJS and barrels.
But as CLI is now completely on webpack, and webpack works great with barrels.
Also in the node community, working with barrels is becoming more and more common.
I would like to see barrels back into the CLI. Makes importing things way better.
JohannesHoppe commentedon Sep 15, 2016
Right now the single usage of the last remaining barrels is inconsistent. That’s the first point.
The other point is the general future of the style guide. Will be barrels deprecated or not?
In my opinion they make things more complicated, when people start to add more code into the
index.ts. One example is adding a bunch of components to an array, for later imports. Before angular-modules this was a doable approach, but now we don’t need both solutions (in my opinion).I would also vote for not having barrels at all, since I don’t want to have Angular code that depends on the module loader and/or the cli. The CLI should be transparent enough, that I could switch to any other approach (e.g. SystemJS) at any time.
But my arguments are not important here. I can live with both. But I really wonder about "StyleGuide 04-10 - Barrels" and what this means for the CLI.
JohannesHoppe commentedon Sep 15, 2016
FYI, after #2056 the guilty guys are now here:
https://github.com/angular/angular-cli/blob/master/packages/angular-cli/blueprints/ng2/files/__path__/app/index.ts
https://github.com/angular/angular-cli/blob/master/packages/angular-cli/blueprints/ng2/files/__path__/app/shared/index.ts
SanderElias commentedon Sep 15, 2016
@JohannesHoppe You can use barrels pretty seamless with ngModule. I wrote a small article over just that. It reduces the amount of boilerplate lines, and simplifies importing things in your application.
Reducing boilerplate is making better readable code.
I have not seen a technical reason for rejecting barrels. Even after digging in a bit more. Also talked a bit about it with @robwormald, He also liked the idea of using barrels the way I showed. there are some things that need attending, but he agreed that this use-case was a very valid one.
So I still think support for barrels should be back in. Perhaps behind a flag, that optionally enables it.
kylecordes commentedon Sep 15, 2016
The big problem of barrels is not just a stylistic thing, it is that they make it exceedingly easy to accidentally have circular dependencies among your type script modules (not angular modules). As of at least a few betas ago with webpack, this broke everything. Although in theory the type script and es2015 module systems should handle circular dependencies fine, support is stuff in-progress for webpack 2.
Circular dependency do work OK with System, which is why the barrels were mostly OK with the older CLI. Once webpack supports this properly, then it may be suitable to revisit the idea of reintroducing barrels here. The problem was a couple of webpack betas ago - maybe it's already fixed? I don't know, but someone who does know, should lead the charge on this.
filipesilva commentedon Sep 21, 2016
The official stance right now is that barrels are not a style guide recommendation per se, as the introduction of
NgModulemakes them less necessary.Reexporting is still a useful technique with ES6 Modules though, so it's common enough to have a couple of reexporting barrels in an application. Hence we still have these barrels.
As @kylecordes says, there are webpack issues with circular dependencies, see #1831 for one such case.
ovitrif commentedon Oct 7, 2016
Good decision. Barrels are a smart thing for large scale applications, it should be something that developers get used to ;)
bhaidar commentedon Sep 4, 2017
I am finding a problem with barrels when used in Angular-cli. If a component is imported from a barrel, it is not being picked up and shown on the screen. However, when I import the component from its .ts file, it works fine. This is getting me amazed, why would this happen?
In my case, I have this structure:
The index.ts contains this:
Inside the common-data-routing.module, I do this:
The above doesn't work. What works is only this:
No error is generated, it is just the screen is not displayed.
Any idea?
angular-automatic-lock-bot commentedon Sep 7, 2019
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.