|
|
|
|
|
|
by anondesign
4733 days ago
|
|
|
Peter, First of all, can't tell you how awesome it feels to get a response from someone working on the library. Your fix won't work for me unfortunately, changing id's to classes in your CSS inherently changes the "weight" of the selectors, which can cause the wrong CSS rules to be applied (especially if you have old rules hanging around from iterating on your interface a couple times). Another thing that you guys might have missed about why writing IDs are shitty: They pollute window's namespace. If I have an element with id "narc", then window.narc returns that element. Which can lead to confusing JS situations. Anyways, glad to hear you guys are moving ahead and improving your library! I will try it out again in a few months, love the work so far. |
|
|
Thanks for the kind words. We actually recently (yesterday? 2 days ago?) landed a change that uses a data-reactid attribute instead of taking over ID. So problem solved! It will be in our next public release in early July.
Wanted to acknowledge a few other things too:
Changing the specificity sucks so YMMV with switching to classes. I prefer to use only classes because it's a bit easier to reason about specificity IMO. Also, we like to think of all components as reusable, so IDs don't make sense.
But I totally hear you about integrating with a legacy codebase, so I'm really glad that we're now using data-reactid instead of id.
As far as polluting the window namespace, we actually prefaced our IDs with "." so you can't accidentally reference them and we're unlikely to clobber anything you'd reference.
But again none of this matters anymore since we stopped using IDs, but wanted to vindicate your concerns :)