Naming collisions in AngularJS definitions #2447

Open
brettpostin opened this Issue Apr 19, 2013 · 12 comments

Projects

None yet

10 participants

@brettpostin

I'm currently trying to organise my Angular application in such a way that it will scale appropriately to an enterprise level. However I'm finding that there seems to be an over-reliance on naming conventions within the framework, and trying to avoid naming collisions is a real issue.

For example, when defining any constants / controllers / directives / factories / filters / providers / services, a name is supplied to be implicitly used during dependency injection.

This works great with a just a few definitions. However when there could be hundreds (maybe thousands) of these definitions, trying to manage and prevent duplicates seems to be a bit of a maintenance nightmare!

Another issue is the naming of directives. As there doesn't seem to be a way to apply any context to directives, it is not possible to have something like the following (i.e. reuse the name "button"):

<toolbar>
  <button></button>
</toolbar>

<customform>
  <button></button>
</customform>

Therefore we are again reliant on verbose naming conventions. If you include the recommended vendor prefix, you end up with something like this:

<company:toolbar>
  <company:toolbar-button></company:toolbar-button>
</company:toolbar>

<company:customform>
  <company:customform-button></company:customform-button>
</company:customform>

Which I admit isn't horrific, but it highlights the reliance on naming conventions to avoid collisions.

Is there anything on the Angular roadmap to address the problem of namespacing?

@paullryan

I would agree that this is a must for utilizing open source angular components. Looking forward to hearing if there is a current path the angular team is taking. If not it appears that xml namespaces (though I know a number of people are allergic to them) would be the perfect way to resolve this.

@antonsamarsky

That would be great feature!

@gaevoy
gaevoy commented May 30, 2013

It will be really useful feature.
For instance, it can help to make reusable directives/plugins which can't be included in your app without any fear of collision.
Also developers who apply http://stackoverflow.com/questions/933723/what-is-component-driven-development or http://stackoverflow.com/questions/11733267/is-package-by-feature-approach-good can do independent parts of app

@agsha
agsha commented Jun 19, 2013

+1, I'm always worried about this when I define new modules

@btford btford closed this Aug 24, 2013
@btford
btford commented Aug 24, 2013

As part of our effort to clean out old issues, this issue is being automatically closed since it has been inactivite for over two months.

Please try the newest versions of Angular (1.0.8 and 1.2.0-rc.1), and if the issue persists, comment below so we can discuss it.

Thanks!

@brettpostin

Having checked over the release notes, I believe this is still an issue that needs attention.

@btford
btford commented Aug 28, 2013

For now, prefixing (either <foo-my-directive> or <foo:my-directive>) is the way to go.

Does anyone have a concrete suggestion?

@btford btford reopened this Aug 28, 2013
@groner
groner commented Sep 10, 2013

There's some discussion of this in #2767.

@igdtl igdtl referenced this issue in benzen/angular-bootstrap3-datepicker Jun 26, 2014
Open

angular-bootstrap3-datepicker conficts with angular-ui-bootstrap #1

@resistdesign

+1 Namespacing is a basic feature, this really needs to be added.

@Toilal Toilal referenced this issue in angular-gantt/angular-gantt Oct 22, 2014
Closed

Wrong debounce function is used #189

@Toilal
Toilal commented Oct 22, 2014

👍

@Nactive
Nactive commented Nov 10, 2014

Although namespaces would be very nice I would be happy if we could just get an exception if there is a name collision detected while parsing the controllers / directives / ...

@Toilal
Toilal commented Nov 10, 2014

@Nactive I'm not sure it's the solution, it may be useful in some case to override a service or directive provided by an 3rd party. But there should be at least a warning message for sure.

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