Hacker News Reader

Some unsolicited advice from someone who has also been down a similar path.

I normally suggest eschewing the javascript class model in favor of using stateless functional components.[0] I've found them simpler to understand and it cuts down on unnecessary typing. I almost never use 'this' in javascript, and instead have favored an OLOO[1] or pure functional style as it fits into a simpler mental model for how things are working.

I normally only test the actions that modify state in my javascript applications. I care that I'm correctly changing the state of my application, not what that state renders. (This is similar to rails apps not typically testing html output) I normally use mocha[2] for testing and if something goes wrong I can open up a normal chrome js debugger using the --inspect-brk flag when running via the cli.

You will eventually find yourself needing to support multiple routes in your react applications. Most people would recommend the "react-router" library, but I've found a lot more success with "redux-little-router"[3]

[0]: https://reactjs.org/docs/components-and-props.html

[1]: https://github.com/getify/You-Dont-Know-JS/blob/master/this%...

[2]: https://mochajs.org/

[3]: https://github.com/FormidableLabs/redux-little-router

And I 100% disagree. If you're new to React I strongly recommend sticking with classes and embracing React's 'component' model which is one of its strengths and which Redux + trying to use only stateless functional components throws out with the bathwater.

>I normally suggest eschewing the javascript class model in favor of using stateless functional components.

So I do this whenever possible, but the way this advice is worded (both here and often in the wild) makes it sound like you can just use them everywhere.

Most UIs have state. I can't imagine a UI that doesn't. Every third component or so I write I end up using classes for, so I've got a mix of classes and functional components throughout the codebase. Do you _never_ use classes? If so, what do you do instead? Otherwise if you're like me, you get to use functional components occasionally which is nice, but are nowhere near being able to get rid of the class syntax.

I only use classes when I need to use a ref within a component (which is quite rare). I use redux for all my state management instead of storing state within the component itself. Everything else is a stateless functional component. A typical component would look like

    import React from "react";
    import { connect } from "react-redux";

    function _HelloWorld({name}) {
      return <div className="intro">{name}</div>
    }

    function mapState(state, ownProps) {
      return {
        name: state.name
      }
    }
   
    function mapDispatch(dispatch, ownProps) {
      return {}
    }

    export const HelloWorld = connect(mapState, mapDispatch)(_HelloWorld)

I realize this is just a snippet and probably written off the top of your head (rather than reflecting real code), but a couple quick suggestions for improvement there:

- Only add the `ownProps` argument to `mapState` or `mapDispatch` if you actually need it, because `connect()` will now call those functions more often (whenever the incoming props have changed). If you're not actually _using_ values from `ownProps` in there, don't add those arguments.

- The `mapDispatch` function isn't doing anything at all in that example, and can be omitted completely

- I personally recommend using the "object shorthand" form of `mapDispatch` instead. To me, there's never actually a good reason to write a separate `mapDispatch` function. Just write action creators, and pass them in an object to `connect`, like this:

    import {addTodo, toggleTodo} from "./todoActions";
    
    const actionCreators = {addTodo, toggleTodo};
    
    export default connect(mapState, actionCreators)(TodoList);

I see. I don't really have a need for redux but that clarifies things.

+1 for testing actions / reducers.

Snapshot testing probably makes sense if you're making a design system of component building blocks or a purpose-built re-usable component. Anything more and your tests will probably end up being brittle.

For routing, I usually recommend "connected-react-router." [1] Never heard of "redux-little-router" - will have to check it out!

[1]: https://github.com/supasate/connected-react-router

Same here. Learning React for me was pretty simple. I think many get confused as to what React is and what it isn't. Like many view or template libraries, a React "app" is really just a function that takes properties and outputs markup. In React's case, there's a little more behind-the-scenes magic as to when changes propagate to the DOM, but the concept is still very similar. React isn't MVC/MVVM/MV*/etc, it just manages the view layer. With React, you also get the ability to render server-side and target other platforms such as iOS, Android, etc.

Redux on the other hand was a little more confusing for me to learn (the concept makes complete sense, it's the implementation and debugging that gets confusing). The great thing about Redux is that you don't have to use it or learn it. The React ecosystem is pretty well decoupled so you can choose how you want to manage state and async tasks. That is it's biggest selling point for me personally.

My experience with front-end frameworks started with Backbone + a ton of jQuery to AngularJS to React (with many different state management libraries). I found that Backbone didn't really provide much on top of jQuery + lodash/underscore, but I liked that it didn't make too many decisions for you. Angular (v1) on the other hand, forces you into some unconventional patterns (ie: the whole service vs factory fiasco and it's own dependency management system). It's fine if you aren't using a separate dependency management library (or ESM), but if you are, you have to declare dependencies twice. Angular 2/4/5/whatever-arbitrary-number-they-are-on-now has been way more confusing for me to learn as they make you learn their own templating language for things like loops, control flow, etc and still have some weird patterns around dependency injection. JSX is a lot simpler if you know basic JS. React seems to have the least amount of boilerplate code as well especially if you make use of functional components.

>>* The tooling was a disaster before create-react-app. But now there's create-react-app, so the tooling isn't a problem.

But what happens when you inevitably need to step outside the boundaries set by create-react-app? From that perspective, it simply delays the problem, rather than solving it.

I don't know, because haven't needed to step outside those boundaries. I'm sure it will be painful when that happens, but by that point, I'll have gotten so much done that I probably won't care too much.

I had a gulp build process I used before create-react-app; it was gross to get working, but then worked just fine. I could live without create-react-app, but why would I?

I've never used create-react-app and I still love React.

If you hit the point where you're considering ejecting, check out react-app-rewired. If you just need additional Webpack plugins, react-app-rewired can do that for you without the need to completely eject your app.

My last and current job have both uses react-app-rewired to monkey-patch create-react-app.

You can eject the app to exit CRA's umbrella. All of your configuration and code still works, you just also gain access to the project config and Webpack config that CRA formally dealt with for you.

A lot of the time, simply using react-app-rewired is sufficient in place of ejecting, especially if the only thing you need are some Webpack plugins.

I guess it depends on how you learn. I personally used CRA in my learning process and it helped me get up to speed in understanding React fundamentals (reconciliation, lifecycles, state management..) Then I started going down into the stack and understanding Webpack, etc..

For me personally it would be exasperating to learn all of the stuff that CRA bootstraps before actually getting to learn React.

> But what happens when you inevitably need to step outside the boundaries set by create-react-app?

Been working on a real-world c-r-a based project for 8 months and this is yet to happen. And the upgrade process has been a dream (update 1 dependency), no breakages so far.

In fact I now regret my other attempts to go off the rails (adding Sass), it wasn't worth it.

I still have no idea what the right way to test things is

At my company, we use cucumberjs (https://github.com/cucumber/cucumber-js) to write scenarios for basic front-end testing. I wouldn't go overboard and start writing test to measure padding or font sizes, but you can easily see isolated scenarios and write automated tests to simply verify that a react component actually put the right element in the dom or to check conditional class names.

We also unit test many of our Redux reducers which is pretty simple with any unit testing library. Just create an initial state and expected state, call the action creator, and deep compare the new state with the expected state.

I similarly love plain React and ES6 as it reduces my cognitive load. create-react-app is fantastic as well.

What I do wonder about is inline styling in JSX that I encounter so much in React code.

It feels "wrong" to me as inline styling has been considered a "bad" thing forever.

Among React pros is inline styling not considered a code smell?

Shouldn't style live nicely in CSS files?