

Moving From Backbone To React - vju
http://usepropeller.com/blog/posts/from-backbone-to-react/

======
anondesign
[http://i.imgur.com/Xhs5jOC.png](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](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](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.

------
ericclemmons
I just spent the full day moving an Angular admin to React and so far, my
initial optimism has died down a bit.

Yes, Angular has more concepts to learn (most of which you already know if
you've used any complex framework), and custom directives are a mine-field of
changing one property at a time until everything finally works, BUT, once
everything's working in Angular, maintenance & updates within the existing
architecture is quite simple.

So far with React, I've married Backbone.Router + RequireJS + React
successfully, but it certainly feels like I'm still writing lots of
boilerplate. That is partially RequireJS' fault (I've never cared for the
bloat), and the other part how messy my views end up by rewriting much of
Angular's "filter"s and "ng-" directives.

~~~
vjeux
Can you give some examples of filters and ng-directives that you had to
rewrite? I found that most of them can easily be translated with underscore
functions.

~~~
ericclemmons
Re-implementing 'filter' & 'orderBy' (especially when reversing) were great
examples of extremely common functionality that I eventually abstracted out
into React's "Mixins".

So, to rephrase, Angular (much like Dojo did over a half-decade ago) gets you
90% there while Backbone (and to a less degree React) puts some of the
boilerplate burden back on you.

I'm still doing a re-factor trying to figure out the optimal way of using
React (we're talking in IRC now!), so I'm not done with it yet! :)

