Thinking in React

Yeah, surprised that is just getting posted for the first time here.

Yea when I started reading the introduction I was like 'wait, that sounds familiar'...

I was surprised too and checked if there was something new.

This is how I met and learned react in the first place and inspired my first react project, http://hasgluten.com

This has been one of the recommended readings for our workshop students for quite some time: https://reactweekend.eventbrite.com

We also recommend the following:

9 things every React beginner should know. Take it with a grain of salt, but it's a good intro to some common React best practices. https://camjackson.net/post/9-things-every-reactjs-beginner-...

ES6 Guide. A nice resource for anyone new to ES6. Only sections 1-5 recommended. https://mrzepinski.gitbooks.io/es6-guide/content/

Edit: add additional recommendations.

#4 is really my favorite. I know a lot of people who were hardcore opposed to React until they watched that presentation.

> React — Basic Theoretical Concepts

"Basic"

Let's just say, save this one for last.

Throwing mine in there too: http://blog.reverberate.org/2014/02/react-demystified.html

What do you mean?

The intercooler.js example seems to be iterating over the results, building up a string of <tr> items, and then appending the string to the DOM?

Yeah, React is for stuff where you never want to do that... it's for when you write your table rendering stuff once, and then just change/update the data.

React also holds the entire UI state as data, things like: what information is typed in the text box, when to clear the text box, whether the checkbox is checked. The intercooler.js example seems to have a technique for showing a processing indicator based on an ID, so their approach to this kinda thing seems to be more 'implicit'. React doesn't have any UI-level abstractions like that, so you do have to implement things like that yourself. (Edit: I looked at the intercooler homepage and it's a specialized AJAX library, which explains what's going on in their example.)

This is one thing I find a little bit frustrating with the tutorials of various JS tools. They fail to accurately describe a problem that they solve.

Usually you just get a quick paragraph going on about what you can do with the tool, then a quick example of something you could have easily done without the tool, then straight into the full API documentation.

And after I've read all that I'm still saying "Ok, that's kind of cool. But why would I add another dependency to my project when I can code your example up in clean, vanilla JS (or more often in these days, plain old React)".

I'd love to start seeing tutorial documentation address this more. Having a basic example is great, but it shouldn't be the only example. You should follow it up with a more complex example that really captures the reason you built the tool in the first place.

React is pretty easy to start with, for me the question is when does redux and the madness in redux starter kit become worth it.

Reusability is React's real value prop IMO. Other libraries and frameworks may give you the illusion of good encapsulation and composeablity but in reality it breaks down once something changes.

If you have a lot of same or similar views in your app used in different contexts then React becomes worth it really quickly.

I've only played with react wrapped in reagent (cljs), but seeing the underlying code here, I feel comfortable saying you can benefit from this pattern relatively early. Just having the virtual dom/view-as-projection-of-state concept saves you a lot of mental overhead about state management. If you're going to build an SPA and you're not already totally sold on yourFavoriteJSFramework, give react a try.

I've actually found working with react/reagent to be substantially simpler to reason about, and lower complexity pays dividends far before any performance or scalability gains do (though I hear react is quite good in that respect as well).

React is worthwhile no matter how small it is.

Flux/Redux is the question. Thinking in those is much more difficult.

If what you have is a "site" (e.g. online newspaper, blog, brochure-ware etc.) don't bother.

If it's a web app, though, consider it, if you have lots of forms, controls, changing parts etc. (If you only have a few simple forms, e.g. a shopping cart + "buy" buttons, you won't really need it either).

I'd love to hear what things you find complicated. I hear you though. Vue has a great abstraction. Although it does too much magic and quite slow at times.

You would need some familiarity with npm first but after that the current practice is to use webpack with 'loaders' to transform JSX, ES6 etc.

This is intermediate: webpack-howto https://github.com/petehunt/webpack-howto

A simple guide? Sadly not, because the ecosystem around JS today is ludicrously over-complicated and changes so fast (and not always for the better) that any guide that wasn't maintained almost daily would be out-of-date within a few weeks at most. Fortunately, Babel[1] is actually one of the few relatively sane areas, and if you combine it with a couple of other tools, you can get most of the benefits of the modern tools while avoiding almost all of the crazy complexity and instability that plagues the ecosystem at the moment. I hesitate to continue with what will probably become quite a long post that dates just as fast here on HN, but since no-one else seems to have answered your implied question yet, here goes...

So, what is Babel? The short version is that recent versions of JavaScript (ES6 aka ES2016, and more recently ES7) offer some very nice new features. Unfortunately, they aren't universally supported in browsers yet, so you can't just use those features in .js files loaded from your pages. What you can do is mechanically translate your future JS code into today's JS that will run in browsers just fine[2].

Babel is a tool that does that translation. It's so much better than anything else that was around that for once pretty much the whole community does use the same tool for that job. It is also both well-documented (see the home page linked below) and reasonably transparent in what it does (you can look at its output and usually see clearly how it's converted any future language features in the input into code that uses only the features supported in browsers today).

As a bonus, in addition to translating future JS code into today's JS, Babel can also translate JSX code into today's JS at the same time. JSX is an HTML-like mark-up language that you can use to make working with React more convenient, but ultimately it's just nice syntactic sugar for some underlying ordinary JS (and as such it's completely optional, though in my experience almost everyone who works with React does use it because it's much neater than writing out the underlying JS manually all the time).

As I said before, there is plenty of ludicrously over-complicated tooling around for JS today, but you absolutely do not need most of it to be productive with the best tools. You can run Babel to translate a new-code JS file into a browser-compatible old-code JS file with a simple CLI command if you want. However, if you're looking to do modern front-end JS development work, I would suggest that there are two other tools you should become familiar with sooner rather than later.

First, if you're going to use almost anything in the modern JS ecosystem, you will probably want to install Node on your development machine. Node lets you run JS as a scripting language more like Python or Ruby instead of in-browser. Many of the modern JS ecosystem tools are themselves written in JS and run under Node, so it's necessary if you want to use any of those. Its accompanying package manager, NPM, also lets you install many useful things from a centralised source with a single command, including everything else I'm talking about in this post.

Second, if you're building projects of any significant scale, you'll probably want to divide your JS code into modules, and combine them together with proper respect for dependencies between them to produce the actual .js file(s) you'll use in production, much as you would in almost any other programming language. There were a couple of common ways of doing that historically, but they're now giving way to standardised language features that are part of ES6/ES2015. There are a variety of tools for doing this combination and dependency resolution, some much simpler than others. A sensible place to start is Browserify, which is widely used and simple-but-effective. Again, running this is a one-liner at a command line, and it plays nicely out of the box with any JS packages you install with NPM.

Finally, you have Babel itself to complete the trio. If you decide to work with Browserify, you may find it convenient to replace vanilla Babel with Babelify in your tool set. Babelify is essentially Babel wrapped up as a plug-in that integrates neatly with Browserify, which means you can run everything together with a single command, instead of manually transforming all your source files with Babel first and then running Browserify as a separate step to combine them.

With those tools, you can write almost anything you might want with the modern JS language features, easily fetch and include almost any modern JS library in your projects, and then combine everything with a quick command into a single .js file that you can include in your web pages as normal. Although these tools are much simpler than some you'll probably encounter, they are actually some of the best things out there, and for many projects they'll be perfectly sufficient even to generate production code for real sites. Once you're more familiar with the possibilities, you will probably want to explore other tools as well, but please don't let anyone tell you that you "must" have a task runner like Gulp or Grunt or that it's "best practice" to use a heavyweight bundling tool like Webpack. These claims are never universally true, IMHO, and they certainly aren't true while you're first trying to navigate the brave new world of modern front-end JS development.

[1] https://babeljs.io/

[2] There are a few exceptions that really do need built-in support from the browser that isn't there yet. Neither Babel nor any other tool or polyfill can help with those.

Source[1] hasn't been updated in over a month, so it's just a repost.

[1] https://github.com/facebook/react/blob/master/docs/docs/thin...

>it sometimes seems like a minor change to the UI can require a major change to the source, cascading through multiple components.

>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.

It sounds like you don't have a good understanding of state vs props. You should use state as little as possible and try to do as much as possible through props, passing them down from the parent components as necessary.

When I create a react app I use the flux architecture, define a state on the top parent component and then add most of the other components as children to this parent component, passing down state as props, and adding listeners to update the components when the state of the parent changes.

As far as moving elements around I mostly do that through CSS and wasn't aware react had much to do with positioning elements

>taking a UI widget/component that previously was only one one page and realizing it had to be re-used on another(s)

Import it into the component that renders the other page and use different props. If you define a lot of stuff in the state of the component then the component isn't as portable.

>moving a UI widget from one part of the page to another;

This just sounds like CSS and possibly markup to me.

>taking a UI widget that previously just displayed something and realizing it needs to have an 'edit' capability too

Not sure what you mean by this.

Sounds like you could use more practice.

https://github.com/uberVU/react-guide/blob/master/props-vs-s...

Yeah you definitely need Redux or another state management solution. One of the unorthodox practices React encourages (through the Flux architecture) is to have 'global' state that components can access without passing down props all the time. Currently I limit setState usage to things that only the current component cares about, like if a button is disabled. Every event that may affect another component dispatches an update to the Redux store which holds the global state object.

Some Redux resources:

1) Getting Started with Redux, videos from its creator: https://egghead.io/series/getting-started-with-redux

2) Simplest Redux example (including ES5): https://github.com/jackielii/simplest-redux-example

3) I added Redux to the example app from the docs: https://medium.com/@firasd/quick-start-tutorial-using-redux-...

4) Offical Redux repo, including many examples https://github.com/reactjs/redux