best practice to avoid naming collisions?

[Seth Ladd]

Hi,

Any thoughts on the best way to avoid naming collisions for custom elements? I suspect there will be potentially a few <x-button>'s out there, and wondering how we might let a user use different tags with the same name in the same app.

Thanks in advance!

Seth

[Scott Miles]

Right now the spec leaves us to our own devices.

My first suggestion is for people to use better prefixes. Ours are particularly qualified now, which seemed like it would be annoying, but it's not bothering me so far (and I'm usually the one complaining about long names). For example, <polymer-ui-toolbar>.

After that I can imagine some kind of override of 'document.register' which can add a prefix or a version tag. That way, you would have the possibility of loading 'x-foo' and having it actually register as 'extra-x-foo-v2' or something.

Scott

Seth

--
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Seth Ladd]

Thank Scott. +1 for some control when importing or registering, and meanwhile we'll educate our component authors to create slightly more explicit names.

Seth

[Torben Köhn]

I guess this is all about how big the framework-writing company/project group is and how much it is involved in current web technologies

e.g. it's almost clear that Google's namespace will be "g-*", Facebook's namespace will be "fb-*", Twitter's may be "t-*" or "twit-*"

Of course it wouldn't be really wise, if your project is called "FedBears Framework", using the prefix "fb-*"

For that you'd rather go for "fedb-*", "fbear-*" or just use "fedbears-*"

Anything else may or may not result in unexpected behavior (Since facebook elements will be included in almost any website you'll see haha)

[Chris Farmiloe]

I'll run a prefix registry, prefixes cost $100/yr and are enforced by me sending angry emails to people who use your prefix, they'll be sun-rise period where you can pre-order your trademark protected prefix for $10K.

Oh god I hope nobody actually does this :)

Chris

[Alex Komoroske]

How to handle this is an open question.

Also, note that the namespace for Google's elements isn't necessarily g- . We just needed something to put in the video.

There's a tension between keeping the names short (to conserve typing) and keeping them long (to avoid conflicts). Currently we use "polymer-" to be on the conservative side. We want to be mindful that the first movers in web components are setting an example for others.

I could imagine a wiki-style table being maintained at some neutral location where people could note which libraries use which prefixes. That would ideally help folks avoid conflicts where possible. You'd need a strong norm about "the length of your prefix should be inversely proportional to how commonly used your library is" (with attendant community shaming) to prevent people from just "squatting" on short ones. Of course, that norm would have to be established early and strongly enforced by the community to have even a hope of working.

I think this is a problem that we'll have to solve as a larger web components community. I'm interested in hearing what other folks think.

[Chris Farmiloe]

Somewhat related to this, or maybe the inverse of this (and again probably a little early for a thorough discussion) is also a interoperability between elements that solve the same problem.

Say I have big application that uses SomePackage's <geo-input> tag to accept a geographical location. I later find SuperPackage that supplies a lovely <geo-input> component, which has almost the exact same functionally but with a slightly better UI. It would be great to just swap out one HTML-include for the other. 

I guess my point is that while preventing clashes is obviously important, if two components have the same name (and those names are semantically meaningful) they may well also be solving the same problem, and could have benefited from some kind of informal (un)standards spec of their API rather than each being treated as separate namespaced-off entities. 

It's certainly going to be interesting to see how the community deals with these things.

Chris

[Torben Köhn]

Well, a "geo-input" would somewhat defeat the purpose of having a "vendor" tag

A dash is required because the element should be vendor-prefixed, not module-prefixed

"geo" would be a very, very generic tag and probably should rather be something like (assuming the Library is called "SomePackage") "sb-geo-input" or "some-geo-input"

This will also increase readability because you can directly see which element comes from which library

This is just my opinion, of course

[Alex Komoroske]

Torben's right--the prefix I think is most properly used to namespace the vendor, not the functionality. As long as the API surface (e.g. attributes, events, and what kind of elements go inside) is the same, swapping to another compatible implementation should be just a simple find and replace of tag names in your codebase.

The broader point of allowing folks to stabilize on APIs for common elements is important, I think.

The answer I had imagined to that is again, a wiki-style page in a neutral location that documents the semantics of tags. It's not normative--the goal is simply to capture the most common APIs for given element types. That way, if a third person comes along and wants to implement the same element type, they can just use the same API by default instead of having to invent a new API on their own. Interoperability results--and who knows, down the road that makes it easier to make a case that that element should be standardized and added to HTML. I don't have any illusions that every component would be interoperable (especially not higher-order components that organize layouts, for example), but some common "leaf" components probably could gel.

Daniel Buchner and I have talked quite a bit about such a world.

[Chris Farmiloe]

Yeah I can see a wiki going a long way to helping in many cases assuming it can gain enough traction/respect.

And just to be clear; I definitely wasn't advocating the use of Elements in that way, just trying to show that there may be a reason to intentionally clash element names. And if there is a reason, somebody will probably do it.

Chris

[Seth Ladd]

A wiki will be nice in the beginning, but I'm concerned it won't scale. I'd love to give the importer control over the prefixes. I imagine something like:

<link rel="import" prefix="foo" href="http://awesome.com/button.html">

<link rel="import" prefix="bar" href="http://cool.com/button.html">

and then I can use both:

<foo-fancy-button>

<bar-fancy-button>

This puts control in the hands of the consumer. The prefix attribute is of course optional, and we'd encourage people to pick short names for readability.

Thoughts?

Seth

[Daniel Freedman]

I can think of a few immediate problems with this approach.

1. If the element prefix is set at import time, then it's nigh on impossible to make CSS stylings that would match that element
2. If the prefix is optional, then there is no guarantee that one will be specified at all. In that case, authors will be conservative and prefix them anyway. Thus, you can end up with <jq-jq-button>
3. This is likely to just push the collision down further. If <google-button> depends on <gizmo-button>, and imports it with prefix "giz", and <google-button> itself is imported and extended (<element name="giz-button" extends="google-button">) into <giz-button>, who wins?

[Domenic Denicola]

X(HT)ML namespaces? Is that you?? I’ve missed you buddy!!!

[Jon Rimmer]

I don't think this will actually be a big problem in the wild. Yes, there will probably be thousands of Github projects with developers' first attempt at a component, all sharing names like x-button, but how likely is it that you'll be using them in a real project? Let alone using two and having a problem with them colliding. Most developers who create a component that provides significant value will expend the effort to think of a unique prefix and name, I think, and will have enough knowledge of the wider dev space to know what's already taken.

For the situations when a collision does occur, I think it can be better addressed by the kind of community consensus already discussed, and by good tooling, than by trying to design clever namespacing mechanisms.

If we speculate about the future of web components, I imagine that *most* components used in real projects will be hosted in one of two ways:

1. On the same server as the web site/application

2. In a few CDNs that specialise in component hosting.

In the first case, since the developer has control over the component resources, it's possible for them to manually resolve any collisions simply by changing the element name. I imagine people will write Grunt tasks and other build tools to automate this, and conventions for packaging components will evolve to make it easier. Component libraries could also provide download tools, akin to those used by libraries like jQuery UI, that let you download a build with a specified prefix.

In the second case, the hosts themselves can enforce unique names within their own registries, and with a bit of collaboration, amongst themselves as well. They can also provide ways to mitigate collisions. For example, if I ran a CDN called componenthost.com, I might offer two versions of each library, one with a convenient short prefix, and another with a longer, more likely unique one. So, the Polymer components might be available with a pol- prefix at http://componenthost.com/polymer and with a polymer-project- prefix at http://componenthost.com/polymer/full, or some such.

[Ti nk]

My experience over the last 10 years building large RIA's with Flex tell me different.

So to clarify there will be no way of packaging custom elements into a namespace?