angular
Change this repository name
Now that we have added the CSS Grid feature in this PR and we need to change this repository name.
According to me, the most suitable name for this repository is "angular/ui-layout"
Personally, my vote is for @angular/layout because it seems more to-the-point. But if the community feels a certain way, I'll leave this thread here as a means to vote.
If we get enough votes either way, this is definitely something we can run up to the Core team.
I don't really care about names myself, but we'd have
@angular/layout using stuff from @angular/cdk/layout then. Looks weird, and will raise the question for new users why those are seperate, even though the LayoutModule in the CDK is a different beast.
Also, and I know this is unrelated, we need to promote this package a lot better. It's getting really old telling users on the angular2 subreddit and elsewhere that "use Bootstrap because Angular and Angular Material don't have layout functionality" about this one.
@D2KX I usually draw the comparison between @angular/animations and @angular/platform-browser/animations. One is clearly a utility for animations, and one is a utility to help construct animations (ie one is higher-level, and one is lower-level).
I agree it may be confusing for some, but before we make any change, we'll make sure to well document it. (Not to mention that in the material2 README, the section on layout already links here instead of to the CDK. I get the feeling that a lot of people don't even realize it's a thing).
Re promotion, we can definitely launch an awareness campaign if/when the name for the package changes, or after ng-conf if it doesn't (to promote the new Grid functionality). As it is, this package is already pretty popular. Although we don't have nearly the same functionality, we're about half the size of Material in terms of downloads.
+1 To @angular/layout; IMHO.
To me as a user, it wouldn't look weird at all that @angular/layout would be using stuff from the "Component Development Kit"'s layout module. Semantically, actually, makes perfect sense. =P
But here's the thing: people that like the CDK-Layout functionality like BreakpointObservers etc. to do Mobile/Desktop layout switcheroo already have
import { LayoutModule } from '@angular/cdk/layout';
in their app.module.ts today. If flex-layout renames to @angular/layout, and there will be a meta module to import both flex and grid modules, it would surely also be LayoutModule as the exported name. But we can't import two "LayoutModule".
Sounds picky, but this is not an unlikely thing to happen.
Doesn't it make sense to have different modules (FlexLayoutModule and GridLayoutModule) instead of just one (LayoutModule)? @angular/forms works like this (FormsModule and ReactiveFormsModule).
@D2KX Ah, I see your concern. Thankfully, with the advent of scoped injectables in Angular v6, the LayoutModule in @angular/cdk/layout is an empty shell and doesn't need to be imported for use (see here). It will likely be removed in a minor release after v6 final.
Since @angular/layout would likely debut as compatible with Angular v6, I don't see an issue.
@julianobrasil We already have scoped modules like that FlexModule and GridModule, but we also bundle everything into the top-level for those who want everything at once (similar to the old MaterialModule)
@MGazi42 How are you measuring that? While the number of votes is helpful, it's really entirely up to the Angular Core team. We're in discussions with them, and will update here when we have something. In the meantime, for those just reaching this issue, adding to the vote total will only help the cause.
I agree, the name makes it sound it strictly uses FlexBox. Kind of sad i just discovered this awesome library. Love it tho, thank you!
I would go with @angular/layout too and I don't think it is confusing.
As much as I know it is using (or will be using) @angular/cdk/layout under the hood.
That means it isn't different from @angular/material/table, which is using @angular/cdk/table.
However, I would preffer to see this library as part of the CDK itself sometimes.
@angular/material itself references this repository as it's layout implementation, so I would like to see a closer collaboration between the 2 libraries.
Does renaming will be taking place soon closer to RC release or something?
@angular/material itself references this repository as it's layout implementation
@Springrbua, I don't think that is quite accurate, but I can see how there could be some confusion. I've made some updates in PR https://github.com/angular/material2/pull/15784 which hopefully help. I think that the Angular Material docs should provide more guidance on layout than they do today, but there are unfortunately a lot of other higher priorities atm.
As for the naming, the only update that I can provide is that internal discussions are continuing and decision has not yet been reached.
The ui- prefix is in wide use in the AngularUI community organization. While that organization may not be as active as it once was, it is still in use. So I'd try to avoid using "their" prefix to avoid any possible mis-conception about the origin of this project.
I'm voting for @angular/layout too! 👍 💯
When is it planned to rename this repository and the NPM package? Because, when I first came to know about this project last week, I thought it only supports flex-box layout. I was later surprised to know that it also supports grid. The name really needs to be changed to avoid this confusion.
Angular 9 is very much around the corner, is this ever coming out of beta of 8 then?
So ... is this still something? Seems like people are OK with @angular/layout
Also what about the beta tag? People will keep using Bootstrap just because it says it's beta, but is it still beta? Shouldn't it be dropped now? And since angular releases are more frequent now, it could be easier to do braking changes that way.
cc @d2kx
@DejfCold Unfortunately as much as popular opinion may prevail in one direction, that doesn't dictate the direction of the project, especially in the eyes of the Angular team. I'll reiterate what I've said before across multiple issues: this project is stable. It is not coming out of beta any time soon, because that would have support implications for the Angular team. It is not changing names either for a similar reason. Do with this information as you will, and as much as I'd love to see as many people using this project as possible, inevitably some will be turned off by the beta label. I try not to lose sleep over this; to each their own.
@CaerusKaru, then could you please close this issue as won't solve ?
Because keeping the issue open only keep people hope up. And if there is no possible change in the foreseeable future, then there is no reason to be ambiguous about it.
There is no indication either way right now, which is the reason this issue is open. If it changed either way, this issue would be closed by now.
It is not coming out of beta any time soon, because that would have support implications for the Angular team. It is not changing names either for a similar reason.
There is no indication either way right now
Those two sentences directly contradict each other. It's only increasing confusion. And you'll keep getting people asking about it forever. Having a clear answer, which may change in the far future, would help everybody here, maintainers and users.
How about at least tagging it?
Won't fix, Blocked seem relevant even without closing the issue.
Discussion is not really relevant here anymore and it doesn't even look like it's wanted.
@PowerKiKi I'm sorry you feel that way, but I disagree. The definition of an issue is something that a group (in this case the community) would like to see action on. Closing it would be a definitive action by the Angular team, and we're not prepared to take that step. This is no different than a feature request the team would consider. Just because you're frustrated does not mean that a) something needs to happen; and/or b) you're the only one who's frustrated.
@DejfCold That's just it though, it's not blocked, it's just in limbo. The Angular team has X number of cycles, and they don't include deciding this matter. I think there's a case for continued discussion, e.g. the community may wish to move this package to third-party distribution. Either way, the state of the issue as it is stands for now.
