Moving From Backbone To React(usepropeller.com)
usepropeller.com
Moving From Backbone To React
http://usepropeller.com/blog/posts/from-backbone-to-react/
2 comments
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.
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.
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.
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.
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 :)
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 :)
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.
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
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.
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.
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.
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! :)
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! :)
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 :(