Things every React.js beginner should know

However, the React ecosystem is really not that complex. You can write clean, sizable apps with vanilla React.

Then you might need a state management system like Redux. Its quite easy to roll out your own that fits your project and does not have all the pluggability whistles like Redux.

All other things are really not needed for most people, and if you do, you are facing problems so large, evaluation of libraries is a small fraction of the effort.

It's more the mindset of people "I'm missing something great" that drives them crazy and into framework fatigue. (OMG server-side rendering, falcor, relay, immutable.js arrgggh)

Usually, you are missing something you don't need, otherwise you would be looking for it actively.

If widespread use in production by Facebook isn't real world enough for you, then perhaps it's best to find a slower-moving part of the stack.

It's really severe, but articles from DHH and Rails itself really really help with that. I can't really put enough emphasis how greatly that has helped me.

The reason I'm doing front-end development is because I enjoy it. I'm not doing it only to 'get shit done'. And part of that enjoyment means not always having to deal too much with other people's choices, because sometimes they feel like straitjackets.

So as long as the client doesn't suffer from me making choices based on enjoyment, I'm going to use RethinkDB, React for the back-end, and roll out my own custom-built CMS if I so desire. Because I'm responsible enough to know when this is okay, and it's just hella fun to do.

But yes, when in doubt lean towards the thing that has been tried and tested over your own (possibly disastrous) sources.

But also no, the most I've learned has been by making terrible choices and having to figure things out, truly figure things out myself instead of relying on frameworks from the start.

I mean, it's not like things will explode when we fail in the front-end world, generally speaking.

It's not about complexity per se, it's about use cases the framework designers did not envision beforehand. Soon as you're in one of those, your goose is cooked. If the framework just does what you want and gets out of the way then great. But in my experience the pain is not worth whatever benefit a framework provides.

https://facebook.github.io/react/docs/jsx-in-depth.html

[NB Not that I know, just checking my own understanding].

From the side it might look like a bad practice, but I promise - this "HTML" in JS leads to fantastic testability. And I certainly prefer to work this way instead of filling HTML with numerous of "ng-" attributes where you're trying to force app generate code that you want.

Sidenote: even though it looks like HTML, it is not exactly HTML.

https://www.youtube.com/watch?v=x7cQ3mrcKaY

It turns out there is no good reason to separate code and templates, because they are intrisically linked; one cannot work without the other. The separation should rather happen on units that are really independent, such as 2 separate pages of your application.

It is possible to separate JSX elements from the rest of your code if you use ES6 React components or functional components (that is, you don't use React.createClass), because in those cases there is no need to compile the components themselves, so in theory you could separate the "HTML" bits into separate, dedicated files. It's not really a problem I've faced so far, but might end up doing in the future.

the main difference between React and everything else is that React brings HTML to Javascript (and not vice versa). The result is code, that's easy to understand, test, develop. Code and templates should be decoupled, but in UI development, template is just the visual representation of behaviour (code), which means it makes sense to couple them. Plus when you develop in React, most of the logic should be outside of components in any case (I use Redux so it's in reducers and middleware + some util files).

Granted, not all recent developments are bad, of course - eg compiled & typed languages being back in "fashion" is a good development imho. It just feels to me we're either not very good at passing knowledge down or just collectively don't care much about learning history to avoid the same mistakes.

everyone else please stop replying

While I'm not entirely sure what the original reasons were, I can see a big difference between the way, say, PHP was embedded in HTML and now JSX is embedded in JavaScript:

1. PHP was embedded in HTML, not the other way around.

2. The preprocessor basically concatenated everything as strings without caring about what DOM would end up being a result.

Because of these two reasons it was extremely hard to protect against improper injection of data into the resulting HTML. There was no way to make the preprocessor understand the different types of "placeholders" in HTML and what kind of data should be allowed within them.

In contrast, JSX embeds HTML within JS. Furthermore, JSX (pretty much) compiles to function calls, not string concatenation. This means that the engine has great degree of control over the interpretation of the data: its impossible to get malformed HTML, or for an attribute value to escape the actual attribute and so on. Which in turn eliminates the original problem that was present in PHP.

As for separation of concerns, thats still possible with JSX. We have CommonJS (or ES6) modules and we can move the render functions anywhere we want. But now its up to us to decide whether it makes sense or not.

Basically, adding html to javascript is much more powerful than adding "some" parts of javascript to html. Every time I go back to django and need to create filters and other craps to put something in the html I feel like I'm wasting time with bureaucracy.

First, in practice what everybody turned up doing was the inverse (add programming logic inside their HTML).

So you still had mixed HTML and JS, but in a way worse way: with ad-hoc and incompatible pseudo-languages (e.g. Angular's ng-repeat etc, Knockout's template instructions, etc), spiced with "JS inside HTML attributes", with no syntax checking (a typo could blow your code in runtime) and convoluted to boot.

Now, having HTML and logic together makes sense when creating widgets/components, as you have all functionality for widget in the same place. After all in every native UI framework you have instructions to draw the widget IN your code -- not as some external additional technology. A widget's C/C++/Obj-C/Swift/Java/C# etc code encapsulates everything about creating it and showing it.

So, the better way is to have all your widget drawing depending on external (or internally stored if you must) state, happen inside the widget code itself. Not to try to manipulate a string template by sprinkling ad-hoc instructions like for-each and if-then.

And here's the better part. React doesn't really mix HTML inside JS.

JSX might look like doing such, but it's just sugar for calling Javascript functions. <div> is essentially something like: React.createElement(null, "div"); So, the "HTML" is just calls to DOM manipulation methods.

So, with React there's just JS, and it handles all the creation of the HTML code for a "component" (widget). It's also composable, so your panel is just a components embedding other components.

I can't say for Angular but the thing about React is that it is the V in MVC. The fact that JSX apparently mixes JS (logic) and HTML/CSS (presentation) is kind of a red herring. The JS logic in JSX is actually the view logic, not but domain logic!

Also, as an experiment you can prove to yourself that you can separate out all the actions, views, and states in React. Here states=model, views=view actions=controller -- but wait you say, this is MVC so React is in fact MVC and not V! No! The thing is MVC can be arranged hierarchically into levels, so you can have M(MVC)C... if you like :) Don't believe me? Check it out: https://en.wikipedia.org/wiki/Hierarchical_model-view-contro...

These days everyone seems to think they need an application style site, and whilst some sites really do benefit from this approach, others don't.

The trinity of web standards (html/js/css) are still valid for informational, mostly static web pages, but are impractical for developing applications.

The discussion of what is a web application is a tricky one to put a finger on, with a lot of grey area. I think of a classic web page being the about us page of a website, while an application is something like photoshop. In between you have things like twitter, or gmail, amazon, facebook etc.

I mean it doesn't get any more straightforward than this.

<div id="app"> <p>{{ message }}</p> <input v-model="message"> </div>

new Vue({ el: '#app', data: { message: 'Hello Vue.js!' } })

It does result in a tight coupling of template and code, but I'm yet to see a downside to that. Separating template and logic has been the dream forever but is never realised in any non-simple project. Embracing that coupling has been great for me.

The thing that I don't agree with about the blog post is the inclusion of State in the main App props in the form of maxSomething (forgot already the prop name) App configuration should be gathered in one place as a set of constants, IMO. App state should only contain the data, not the meta.

<MyComponent mySuperCoolProp={this.state.someState}></MyComponent>

This is not traditional HTML from the early days and because it is not it has a higher chance of reuse outside of just an internet webpage, and makes it easier to transfer across other view layers, canvas, native desktop/mobile views, etc

You need some sort of logic in your views, no matter what system you use, i. e. loops or formatting dates.

Because people are raised on the "don't mix logic & layout" maxim, they feel dirty when they write sich logic in their usual language.

.. so they invent template languages...

... that then expand to be turing-complete and basically offer everything their primary language offered in the beginning.

So you end up with a new language to learn, which is usually clunky and ugly just for the bragging rights of "not mixing logic & views". Which is completely stupid. Views can (and almost always need) to contain some logic and the best language for that is the one you're using everywhere else.

The alternative view is "things that are tightly coupled should live together" which I think is generally a better maxim.

In theory views can be loosely coupled, but in practice they seem to be almost always coupled 1:1 with whatever layer is above them, controllers or view models or whatever.

Separate HTML and JS? That's a small implementation detail. You can have your view layer as JSX files, separated from business logic, data access, etc. That's actually recommended.

Even when you are using purest HTML template engine, completely separated from JS logic, you still can make a mess, moving lots of logic into HTML or moving all your layers into a single JS file. File boundary is very artificial separation. It doesn't always help. And often it makes things worse, because you have to work around limitations.

    [% BLOCK foo %]
        <td>[% payload %]</td>
    [% END %]
    ...
    [% INCLUDE foo payload=something %]

    function foo ({ payload }) {
        <td>{ payload }</td>
    }
    ...
    <Foo payload={something}/>

The danger you run into is PHP nightmares where the programmer has e.g code that accesses and fetches items from a database in the middle of the view.

React enforces 1-way data binding and renders everything in one clean pass (HTML/CSS/JS).

Back in the day, I thought it would be a great addition to Perl if xml/html was also added to the language syntax. This was before html templating systems existed, and CGI.pm wasn't a good choice for my web application, so my code was full of print statements, quoted strings containing html, and having to use qq!...! for my quotes to avoid problems with " and ' characters in the output I wanted.

When I first saw JSX it seemed like a great thing, finally satisfying that old desire to have html markup as a native language syntax feature. I feel like it can be transformative, in the way you write your code, just like Perl's regex syntax or like having functions as first-class values can be in functional languages.

Having used React.js a bit, I'm not so sure. But I'm probably biased because I don't think React.js fits well with what I'm trying to do: ASP.NET MVC web applications that are mostly traditional full-page-refresh style apps, with some SPA-like AJAX-based interaction on some pages. I wanted to use React.js for those SPA-like pages, but it doesn't integrate well (or at all) with Razor-based server-side rendering, and in my testing it had a significant 1000ms+ startup time when the page loaded even for pretty trivial components, with caching of the React and Babel javascript files.

Whether the scope of your business can be used by this architecture would determine whether it would come up in your day to day.

(Note: I've minimal Angular experience so I won't comment on that. I've spent the last year on React)

The real problem is mixing business logic and presentation, not mixing HTML and JS. React is purely presentation & presentational logic (or should be, you can of course implement it poorly)

For Presentation, the HTML and JS are always coupled, whether you have them in separate files or not. So in that sense, all React is doing is admitting a truth.

While embracing the coupling of that mix, React is ALSO pulling out a lot of logic: React encourages one source of truth (the state is in one spot, and drives the markup, but you never consult the markup to determine the state). An error that is commonly seen in, for example, jQuery apps, is that some state is hanging around in application variables, while other times it's in the current markup state, and the app will consult the markup to see what's happening. That's not a built in jQuery problem, it's just a common problem of implementation.

I'm not sold entirely on the React boat, but it does seem to directly address problems that I've encountered in other systems, and I expect whatever comes next will build from React principles rather than reject them.

With "stateless functional components" (added in React 0.14) and ES6 you can have "templates" that look like this:

    export default ({ title, author, body }) =>
      <div>
        <h1>{title}</h1>
        <h2>By {author}</h2>
        <p>{body}</p>
      </div>

    { array.map(object =>
      <div>{object.whatever}</div>
    ) }

    { foo ?
      <div>yes</div>
    :
      <div>no</div>
    }

The only real issue I see is that if you move HTML into JS, you might make it harder for a pure visual designer to step in and work on HTML/CSS, but outside of that I can't see an issue as long as you keep reasonability of the code in mind. And if you have a good designer, I have a feeling they'll be more than glad to learn how to navigate around Javascript.

2) Best practices focused on separation of concerns, and in particular, on avoiding embedding logic into your static HTML. The canonical example to avoid historically was to put JS directly into a links href attribute, but some have suggested Angular is guilty of something equivalent with its ng-* attributes.

3) Conversely, React advocates agree 100% on separation of concerns, but feel the "nothing that looks like HTML can be in the same file as something that looks like JS" injunction is actually an example of separation of technologies.

    $('<div>').append($(<h1>).text('...')).addClass('...').appendTo($('#selector'));

In the beginning of JS+DOM, it was a common practice to write HTML with DOM events (in JS): (`<button onclick="doSomething()">`). Server rendered most things anyway so you could (`<button onclick="toggle(<%= someId %>)">...<div id="item-<%= someId %>">...`). Problem was tons of global functions all over the place, or many big objects and maintainability issues.

In the "jQuery era", you'd write your initial HTML in .html files and jQuery all the events. It brought infinite amount of ways to write code, which often led to many styles and no conventions.

    <button class="toggle" data-target="item-<%= someId %>">
    <div id="item-<%= someId %>">div</div>
    $('.toggle').click(function () { $($(this).data('target')).toggle() })

    <button class="toggle">+</button><div>div</div>
    $('.toggle').click(function () { $(this).next().toggle() })

    <button class="show" data-text="hello">+</button>
    $('.show').click(function () {
       var $this = $(this)
       var $div = $('<div>').text($this.data('text'))
       $this.after($div)
    })

Many problems with this approach:

- You can't tell which element has events bound to it just by looking at it. Any JS file can decide to do that - Usage of a CSS class to find elements is just a hack - Poorly named IDs/classes create collisions - After an action, the initial HTML no longer represents the current state - Server can render some HTML, then client changes it, and if things get out of sync, the only way to reset the state is to reload the entire page. Imagine a user signing in, and many parts of the page need to show things for a signed in user. Doing this manually would probably be error-prone, so it's just easier to reload the page and let the server do that.

And then came the modern front end libraries/frameworks like React, Angular, Ember etc.

The main difference is that now the HTML representation is ALWAYS in sync with the data, AND the functional code that's attached to each element is at the same place.

And the jQuery example becomes this:

    // react

    <button onClick={::this.toggle}>+</button>
    {this.state.isVisible ? <div>div</div> : null}

    toggle() { this.setState({ isVisible: !this.state.isVisible }) }


    // angular 1.x

    <button ng-click="toggle()">+</button>
    <div ng-if="isVisible">div</div>

    scope.toggle = () => scope.isVisible = !scope.isVisible

I do wonder if things like Typescript can solve a lot of the speed issues.

This is partly because of the overhead of having to learn another library, and partly because you have to learn by making mistakes, experiencing the pain, and then badly hand-implementing parts of Redux yourself to truly understand its value, and how it should be used. At that point you're way beyond beginner level.

Same goes for '8. Use JSX, ES6, Babel, Webpack, and NPM' - JSX aside, setting up this tool stack is totally unnecessary for a beginner getting started hacking on a Hello World app. This is something you do after you've learned React, and you want to use use it in a 'real' project. Depending on your knowledge of these tools it could take literally days of work to get started.

I'll be honest, if someone with no knowledge of React asked me how to get into it, I'd also be tempted to mention Redux or Relay, the tool stack, all those things in the React ecosystem that are fantastic and essential for a real production React stack. But it's just too much information, it's not what a beginner wants or needs to know.

I think there's a general lesson here - learning frameworks, how they fit together, and what tooling to use is really complicated and only seems 'obvious' once you have the big picture. You have to remember what it felt like when you were a beginner, and just wanted to learn the basic rudiments of React itself - that's more than complicated enough to get started with. When giving advice to beginners, it needs to be laser-focused, ignoring everything but the exact thing they're interested in learning. Forget about all the extra stuff they'll need in the 'real world' - they'll figure that out along the way anyway.

As an example of how much this helps, one React-heavy page of mine dropped from 1500ms to 300ms by switching versions, according to my browser profiler.

[1] https://facebook.github.io/react/docs/reusable-components.ht...

[2] https://facebook.github.io/react/downloads.html#development-...

I've been writing React SPAs for roughly two years now.

Very few things have changed. The first app I've written roughly looks like the newest one. Couple of lessons learned here and there like everywhere else.

Yes, there are many Flux libraries and different implementations. However, a decent State management solution for React is roughly 200-300 LOC. So there are many of those 200-300 LOC libraries. So what?

If it's a big project, you should spend the time to figure out what fits YOUR project and YOUR team the best.

If it's a side project, use the most popular with the best documentation and be done with it.

Damn progress :(

https://webpack.github.io/docs/code-splitting.html

Since we started using Webpack where I work we've stopped using all other build tools. There's very little Webpack can't do, and the main advantage is that there's no need to hook things up to eachother since it's all part of the same system.

That means (1) it can do incremental recompilation, which I can't live without since my build takes 20 seconds; and (2) it can block requests while compiling, which is way better than having a background thing (e.g. watchify) recompile your code, since it means you're never interacting with a stale (or god forbid partial) compile.

The dev server also does automatic page reloading on recompile via some injected script magic. In my case that means I often don't even need to alt-tab to see my updates, like if I'm messing around with styling.

Webpack also has a whole paradigm that expands the use cases of require() in a pretty interesting and useful way. For example, you can tell it that require("../../icons/lolcat.png") should resolve to "static/lolcat.[8 chars of base64 SHA-256].png" and also do the appropriate file copying. Or you might want require("./stuff.csv") to resolve to a parsed JSON table, or any such transformation. There are a bunch of plugins for common uses. It's common to use require() even to load your CSS, because then Webpack can handle running it through your auto-prefixer or whatever.

It might seem kind of bloated, and I love Browserify for its simplicity, but I've come around to really like Webpack now that I've spent the proverbial 4 hours.

In short, I've used both, and I'm currently happy with webpack, and I have a decent configuration on my current project with a dev server, good production builds, support for CSS modules, and hot module replacement, all of which I could have in browserify.

Oh, webpack makes it a lot easier to dispense with gulp; my last browserify config was driven by gulp, but my current webpack config is just driven by a few lines of vanilla node.js code, which is kind of nice.

> What part of my life would actually get better if I took the 4 hours of my life I will never get back to make this switch?

Probably none of them. But if I had two boilerplate configs, one using gulp+browserify and the other webpack, I'd choose webpack because I think it's VERY SLIGHTLY clearer and more maintainable.

In fact, my single biggest criteria for any tech I add to my stack is that it doesn't get in the way of server-side rendering (the second biggest criteria is that it doesn't add significant weight to the client-side JavaScript payload).

On e.g a newssite react doesn't make much sense though (except, possibly on the backend).

Is there a way to override or extend the webpack config though? (without having to fork it) What if some projects need different loaders or want to use code splitting, etc?

If you need an object (say to use it in something like Redux), you have to write a wrapper like so: https://gist.github.com/ebi/d186c4297c84d562aeae