[anondesign]

http://i.imgur.com/Xhs5jOC.png

I was really excited about react, until I heard the loss of #id selectors. To me this comes off as extremely dirty, since this limits your actual CSS (id's are useful for layout-based static elements (#big-logo), or containers for similar layers (#modals)). QA departments that test web apps also love #id selectors, since they don't have to waste their lives unwinding proper nested selector syntax, which is brittle anyways. Otherwise react seems like a perfect complement to Backbone. I ended up using Backbone.Marionette, which is a lot of boilerplate but solves the nesting problem in a flexible and thought-out way.

I assume React wants to optimize its subqueries for instant DOM lookup (I believe they calculate the ID based on ancestry, and ID-based lookups are O(1)). Why not use a better technique like maintain your own lookup hash, and store data on the actual JS objects representing each DOM element. I prefer not to cringe anytime I look at my markup :(

[peterhunt]

This is one of our top priorities and we're hoping to have it fixed by the next release.

While I don't know all the subtleties of your use case, I've found that by simply swapping your IDs with class selectors this hasn't been a problem either for Selenium or for CSS. It's pretty straightforward to convert an existing codebase with codemod: https://github.com/facebook/codemod

If you're still curious about React, feel free to drop us a line at https://groups.google.com/forum/#!forum/reactjs with any questions or concerns you might have. Thanks for giving React a shot.

[anondesign]

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.

[peterhunt]

Hey there!

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 :)

[anondesign]

Yay! Awesome news! Will have to reevaluate it at the end of july. Thanks again for your team's great work on pushing a polished open source framework.

[dustingetz]

Switch '#foobar' to '[data-mycompany-id="foobar"]'. A nice byproduct is your selectors now work against detached fragments. A negative is your selectors are no longer o(1) but this has not been a problem for my team in practice