That's a bit like looking at the source code for Linux's TCP stack and saying "All that work just to make a TCP connection? I'm definitely not using Linux".
If all you want is a select in React, you can just do `<select><option value="A">A</option><option value="B"></option></select>`. The tutorial is showing how to roll your own select-like control using divs. I doubt that it is much easier to do that using any other JS framework.
I think there's something to be said about this being analogous to a language whose homepage example is starting an http server, vs one whose first example is merely fibonacci but using pattern matching (or whatever tickles your fancy).
If "enlightenment" is realizing you can use React to reinvent [insert-library-here], then what's so special about it? Any half-decent framework can do that. I think the argument about composability and scalability (which imho are the real value-add that React brings over e.g. jQuery) is a bit lost in that example because it spends so much time on stuff that looks rather pointless and mundane.
No, I'm saying that implementing something is usually harder than using something. The tutorial is about how to implement a select; not about how to use a select.
> Using a <select> is still much easier than using React's implementation of it.
Yes, of course it is. But reading a tutorial about how you could implement something so understandable as <select> using React is a pretty good guide to understanding React! At least, to me it seems pretty great.
If you're rendering your webpage with Javascript, because your <select>s are dynamically generated, then you're going to write a lot of code anyway to render the HTML, keep it in sync with the underlying model, bind the user events to trigger actions, etc.
It's a lot of code compared to a static website, but not a lot of code compared to doing it in some other framework, and, for many cases, it is much, much more maintainable.
THAT SAID, I agree that it's a horrible example to have on the first page.
"Here, let me show you pages and pages of scary code that won't make any sense until you've read the entire book, in an attempt to give a brief overview of this framework."
I think there could be a much gentler introduction, preferably using JSX.
For a static website with a few pages, you wouldn't need to. But for more complex apps, that's where the pay off is. A brief example: In one of our apps, we needed various select menu behaviors. Sometimes it would accept normal attributes (strings for values). Sometimes arbitrary objects having a toString method. Sometimes it needed to load data. Sometimes it needed to load data given only a model name, and know how to page it. In react, I was able to do this with a single base select component, with a few wrappers (decorators) to add in the various behaviors. All encapsulated, and abstracted behind a relatively simple interface. With honestly not that much more code than the example in this tutorial. And it all felt natural -- like I was just writing javascript. Thats the good side to React.
Do you have a link you want to share to one of your apps that uses React? I'd like to know where the threshold for when an app is considered complex is.
I've asked other React developers the same before, but so far the links I've seen are of "apps" that could be made with tops ~120 lines of vanilla JS... :|
Here is an open source React Native app that I recently did for The Andy Warhol Museum: https://github.com/CMP-Studio/TheWarholOutLoud. (Some of it's more complex features: Floor and region detection through BLE beacons and an audio player that slowly learns preferences and rearranges content.) React Native targets native views instead of the DOM, but other then that it's conceptually and technically very similar to React and should serve as a example of a complex app using React ideas.
I've played around with react native, and I will say it feels nothing like normal react (where "normal" is writing for a web app). The only thing that is similar is syntax. Everything else is new/different: elements, styling, interaction listening, etc.
This is the thing most people confuse about React. The similarity you see is React, the differences are the implementation for that platform.
The elements, styling, and interaction listening is React for Web.
The equivalent of the above in React Native is... React for native.
Remove all that stuff specific to each platform.
What is left is React.
Honestly React could be considered it's own design pattern [or a renaming of existing], with fb/ReactJS and fb/ReactNative being the most well known implementations.
For the example in question its an internal company tool, so can't link it. Its about 20k loc, excluding css (etc.). Most of the app's i've been working on (for work or side projects) are in the 10k-100k area. My general stance on it is there's a difference between a static content site and an application -- if its the latter your almost always going to be better off going with something like React.
You know, this sounds like a story about the soldier who made the soup from the axe. Maybe after all these wrappers and decorators you could drop react too and do just fine without it?
One of the benefits of React is how is scales, so small examples like this make it seem like it's a lot of complexity. But scale it out to lots of components all interacting with each other and then the benefits of a pure render function, declarative UI, make sense. I highly suggest going through this example to help see the benefits of React: http://reactfordesigners.com/labs/reactjs-introduction-for-p....
The example isn't real-world scenario. TBH, I'd say it's anything but enlightening.
What React does, is keeping the DOM tree in sync with the data (components' states and properties). If you don't have the state - it might be the case that you don't really need React, something like Handlebars.js or jQuery templates (if there's even a need for templating at all) would do just fine.
I mean, there's no real practical difference[1] between something like
// A stateless React component, so no need for React.Component boilerplate
const MySelect = (props) =>
<select name={props.name}>
{ props.values.map((v, i) => <option value={i+1}>{v}</option>) }
</select>;
// For this example to be short, no trees here. Only one component.
// (although internally <select> and <option>s are - but we don't care yet)
// And, actually, in my opinion React only starts to make sense
// when there's a big enough hierarchy of components (stateful or not).
ReactDOM.render(<MySelect name="x" values={["foo", "bar"]} />, targetEl);
And something like
const MySelectT = Handlebars.compile(`
<select name={{name}}>
{{#values}}<option value="{{@index}}">{{.}}</option>{{/values}}
</select>`);
// Same as ReactDOM.render for one-component case. For nested, use {{include}}
// However, note now here's an important difference - unless the templating
// library is more powerful, the state is monolithic (and has to be defined
// implicitly, in full) with this approach.
$(targetEl).html(MySelectT({name: "x", values: ["foo", "bar"]}));
[1]: But there's no difference only when you keep it at this level.
But if your UI is dynamic enough and you start to care about the state (e.g. you don't want to lose user input to template re-rendering, when user switches the tabs back and forth) - React provides a way to handle this by one-way binding between your data structure and DOM tree it handles. All it does, though, is only handling of that DOM tree and handling/propagating state updates (esp. if you combine it with Redux) - all the rest is yours to code.
This appears to just be a contrived example implementing a familiar component to give you an idea of how React works. Of course, in practice, you just use a select when you want a select.
I find this often isn't the case unless, say, the dev comes from an Angular background (who is more likely to structure code in a top-down fashion, rather than React's recommended bottom-up components-first structure). I've seen a certain tendency to overcomponentize upfront (because hey, "Thinking in React" says to make a lot of very small components), and then see the components gradually grow in configurability over time, exposing more and more ad-hoc props for whatever "configuration" is needed at the time.
I think one of the 'problems' of React is that the problem it solves is not "how do I easily build a web app?" So, any tutorial that shows how to easily build a web app using React makes it look much more difficult than building a web app has to be. The problem React solves is "How do I sensibly organize a large complex web application?" If you don't already have that problem, learning React can feel like you are learning how to build a transit system when all you really want to do is walk down to the corner store.
Depends on your use case. For a simple website with maybe a form or two, React is overkill. When you're dealing with hundreds of pages with dynamically rendered elements, it helps to keep things consistent and DRY. React helps achieve this through the use of components. For example, let's say I want to allow any button on my page to send a tracking event to Google Analytics on click if a certain attribute on the element is set. With React, I can add this feature for every button by modifying the `Button` component I built. This ends up being a lot easier than having to manually bind the tracking callback event to every `<button>` element that is rendered at some point (and also guarantees that event delegation takes place within the component rather than some other module in your application).
The component pattern is certainly not unique to React but it is a good design pattern that the framework encourages through JSX, component lifetime cycles, etc. While I can't speak for everyone, React has certainly made my life and the life of developers I work with easier since integrating it.
I'm not sure I'm convinced by "different problem explanation" - in both cases you produce a reusable component to use in your application.
> WebComponents provide strong encapsulation for reusable components, while React provides a declarative library that keeps the DOM in sync with your data.
You can use something like reflux with web components to do this too. The fact that react uses virtual dom is an implementation detail I think.
Components are not the big story as they've been around since the advent of UIs and are present in plenty of JS frameworks before and after React. The big story is the idea of expressing your UI as a pure function of the form f(data) = view and being able to compose those functions together. Before React, you couldn't do this in a performant, UX-positive way.
The big story is the idea of expressing your UI as a pure function of the form f(data) = view and being able to compose those functions together. Before React, you couldn't do this in a performant, UX-positive way
Maybe I wasn't clear. The big idea is not components. The big idea is expressing your view hierarchy as a single snapshot in time, and when the data changes you conceptually throw out the old view hierarchy and re-render from scratch and React manages the native view updates to ensure that it's fast and doesn't adversely affect the UX by, say, resetting scrollbar position.
Contrast this with two previous approaches. The first is where you have a component hierarchy that renders the initial state of the view, but when the data changes you need to write imperative code to transition the native views to reflect the new state. The second is traditional data binding, which doesn't help when you want to change the view hierarchy itself (rather than properties of existing views) based on an underlying data change.
ot: I saw the title and thought some crazy fool had ported the enlightenment window manager to reactos.
I suspect quite a disjoint venn diagram of target audiences.
FYI, I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem.
For some people, the best things about React are some of the libraries written on top of it, such as Om for ClojureScript, that allow them to enjoy its architectural ideas without writing javascript at all.
