FWIW, this has been in the React documents from near the beginning:<p><a href="https://github.com/facebook/react/commit/a0ecf472421937545ff5843b5fee6ba5e6991685#diff-388df072689cb3c458ca3ef0d0cac717" rel="nofollow">https://github.com/facebook/react/commit/a0ecf472421937545ff...</a><p>I've frequently referred to it when I need to refresh my memory on how to start in React from scratch.
This is a very useful walkthrough.<p>Some links for those who are also interested in "Thinking in React" in a more conceptual way (#4 is a presentation from the same person who wrote the walkthrough):<p>1) React — Basic Theoretical Concepts: “A description of the conceptual model of React without implementation burden.” <a href="https://github.com/reactjs/react-basic" rel="nofollow">https://github.com/reactjs/react-basic</a><p>2) Pure UI: “A lot has been written about the merits of React as a framework. Today I’m compelled to write about the benefits of a programming model it enables and its implications to the design and creation workflow." <a href="http://rauchg.com/2015/pure-ui/" rel="nofollow">http://rauchg.com/2015/pure-ui/</a><p>3) Removing User Interface Complexity, or Why React is Awesome: “I’m mostly concerned with the core problems of data binding and componentizing UIs. After much research and usage of the technologies mentioned above, I found React to provide the best solution.” <a href="http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome" rel="nofollow">http://jlongster.com/Removing-User-Interface-Complexity,-or-...</a><p>4) Pete Hunt: React: Rethinking best practices (youtube): “building views with JavaScript, ‘re-rendering’ your entire application when your data changes, and a lightweight implementation of the DOM and events.” <a href="https://www.youtube.com/watch?v=x7cQ3mrcKaY" rel="nofollow">https://www.youtube.com/watch?v=x7cQ3mrcKaY</a><p>5) Nothing new in React and Flux except one thing: “What is it that makes React so innovative and compelling?… The Virtual DOM allows us to convert a mutable retained mode graphics API to an immutable functional immediate mode API.” <a href="http://staltz.com/nothing-new-in-react-and-flux-except-one-thing.html" rel="nofollow">http://staltz.com/nothing-new-in-react-and-flux-except-one-t...</a><p>(I collected them to go along with something I wrote in the same vein: <a href="https://medium.com/@firasd/interface-from-data-using-react-to-sync-updates-and-offline-activity-across-devices-f672b213701c" rel="nofollow">https://medium.com/@firasd/interface-from-data-using-react-t...</a>)
For folks just a little further into React, there's a great project called Storybook[1] which lets you put your JSON and React components, individually, into a really nice UI to try them out. Earlier HN discussion[2].<p>[1] <a href="https://github.com/kadirahq/react-storybook" rel="nofollow">https://github.com/kadirahq/react-storybook</a><p>[2] <a href="https://news.ycombinator.com/item?id=11411020" rel="nofollow">https://news.ycombinator.com/item?id=11411020</a>
I know it's just a demo and I'm sure it scales very well, but I can't help but think that's a lot of code for a such simple UI. The intercoolerjs equivalent is pretty simple:<p><a href="http://intercoolerjs.org/examples/activesearch.html" rel="nofollow">http://intercoolerjs.org/examples/activesearch.html</a><p>Don't misunderstand me, there are a lot of places where react is appropriate and intercooler isn't, but for something like this...
<a href="https://github.com/kay-is/react-from-zero" rel="nofollow">https://github.com/kay-is/react-from-zero</a><p>for people who want to look into react itself without webpack, es2015 etc.
I'm a dab jQuery hand and I absolutely love the idea of React - reminds me of the best parts of XSLT. I'm struggling a bit with the pre-required tooling - not that it's there, but I'm just out of date with what a Babel is, what ESX is, how do I get Javascript 1.7 rendering in the browser, etc etc etc.<p>Is there a simple guide to <i>that</i>?
Not an experienced frontend developer per se, each time trying to study React it seems daunting, will things like vue.js a better method for 90% of the problems?<p>Angularjs is also complicated, if not more than React, especially it's now more like C# (typescript etc) which I don't like.<p>Maybe I'm just too dumb, or things move so fast and getting so complicated and I just can not catch up.<p>I will try to use jQuery and possibly vue.js for now, for the sake of KISS.
The problem I've had developing with React (I've just done a little, I'm still a beginner), is it sometimes seems like a minor change to the UI can require a major change to the source, cascading through multiple components.<p>I think maybe this is reflected in this guide, such as the advice in the "Identify where your state should live" section (which they say is "often the most challenging part for newcomers to understand", which matches my experience), which suggests you should be looking at every single component involved and how they all relate to determine where the state should live.<p>This is very different from my previous (mostly OO, lately ruby) experience, where you really want to look at a component (in the broad sense, not neccesarily a view-layer, I just mean any object or 'piece') in strict isolation, identify what it's inputs and outputs need to be, and from that alone, in isolation, you know what it's API should be. And from this technique, you hope to wind up with components that that do not assume or depend on too much about their context of use and can be re-used and re-mixed in different ways without a rewrite.<p>I've found I've had to change my whole approach designing React -- when using my previous time-tested techniques, I would wind up putting props/state in the wrong place. I found that indeed I had to consider the entire graph when determining props/state. But that this has led me to situations where what my intuition would say would be relatively small changes to the UI create a cascading waterfall of changes I have to make to lots of and lots of components in the existing graph, as where state (including props) is kept needs to change, requiring cascading changes to many components in the previous graph.<p>Examples of such UI changes would be taking a UI widget/component that previously was only one one page and realizing it had to be re-used on another(s); moving a UI widget from one part of the page to another; taking a UI widget that previously just displayed something and realizing it needs to have an 'edit' capability too; taking something that showed up just once on the page and changing it to be say at both top and bottom of page. All things that my usual techniques and approaches from OO experience would have been able to accomodate no problem if I had designed the components well from the start, but that in React I'm finding result in needing to change where state is kept (or what things are state and what things are props), requiring cascading changes to many components.<p>Which is frustrating. I hoped I'd get better at avoiding this as I got better with React, and I'm sure that's true, but if even the advice from those most experienced says you can only determine state/props architecture by looking at the entire object graph possibly involved in that state....<p>I dunno. Comments from people more experienced with react very welcome.