React in patterns

[_greim_]

Ugh, the dependency injection stuff is just Angular all over again.

    export default wire(Title, ['title'], function resolve(title) {
      return { title };
    });

Now I have to register "title" somewhere. Where is it registered? Did I remember to register it? I no longer know what's going on just by looking at the file in front of me, and my linter is silent. Then I have to annotate the function and declare it in the argument list. Items will be added and removed from the two lists as the app evolves, introducing more mental overhead and increased surface area for bugs, since once again my linter will have nothing to say on the topic.

Surely I'm in the minority given how popular Angular was, but I felt "DI" was the absolute worst thing about Angular's approach—basically a DSL layered over JS requiring yet more specialized tooling. The ability to look at just one file and understand it goes hand-in-hand with static analyzability, and I'd hate for the React community to abandon that and go down this path.

[edit] In the spirit of not dwelling on the negative, I should also say I did find most of the article to be a good summary of design patterns. Nice job!

[dceddia]

Completely agree. I don't see many people in the React community advocating the use of DI though, so that's a plus.

The DI in Angular made a little bit of sense because JS modules weren't very widespread back then. But now, with ES6 imports (and/or 'require') there's no need. We have real modules now, and they can be dynamically injected for testing purposes with something like inject-loader[0].

I think Angular and/or DI's popularity has something to do with Java devs learning frontend development, and feeling more comfortable with more structure.

[0] https://github.com/plasticine/inject-loader

[munro]

Agreed, it serves no purpose. For testing, dynamic languages have the ability to ... dynamically replace dependencies. :) For building a library, a function that takes in dependencies and returns the component works extremely well & is straightforward to understand, no tooling required.

[quantumhobbit]

Angular's DI is my main reason for switching to react. If it becomes standard in react then what?

[kin]

Yeah, I'm also not a fan of the DI example. I would rather explicitly pass it down the component tree or use Redux's connect. I believe React's docs advise against using context.

[hccampos]

Well, InversifyJS https://github.com/inversify/InversifyJS

[chrisabrams]

You are actually in the majority :)

[msane]

I don't mind DI, in Angular or elsewhere. I'm not sure in what way you think of it as a DSL, or even that it requires tooling. It's a useful pattern in OOP.

[gf263]

I literally don't know where to get started with React. Does anyone have any resources for a web design newbie?

[noinsight]

I started last week and got decently up to speed with these three articles:

[1] "ReactJS for Stupid People" - this explains what React is in simple meaningful terms.

[2] "React.js Introduction For People Who Know Just Enough jQuery To Get By" - this shows you how things are usually done with just jQuery compared to how it's done in React. It really allows you to see why the jQuery way sucks.

[3] "Flux For Stupid People" - by reading this you'll understand what the Flux stuff is about and can decide whether you need it or not - I chose to skip it.

Finally, if you want to get up to speed with ES6 classes at the same time, [4] shows you a simple example. I personally started writing my React stuff this way straight away.

I'm liking React a lot at this point.

[1]: http://blog.andrewray.me/reactjs-for-stupid-people/ [2]: http://reactfordesigners.com/labs/reactjs-introduction-for-p... [3]: http://blog.andrewray.me/flux-for-stupid-people/ [4]: http://www.tamas.io/react-with-es6/

[falnatsheh]

So I just started a week ago, there's a lot of outdated tuts on the web, here is what I think could be a good route for somebody who starting today:

1- Create an app following the info here[0]. This was released officially few days ago, and it removes the pain of setuping React dependencies.

2- Use this [1] youtube tutorial to learn about React. I stopped at #9 since I didn't want to use Flux.

3- I think if you want to build something with React consider using Redux. Same youtube channel have a good tutorial[2] as well.

[0] - https://facebook.github.io/react/blog/2016/07/22/create-apps...

[1] - https://www.youtube.com/watch?v=MhkGQAoc7bc&list=PLoYCgNOIyG...

[2] - https://www.youtube.com/watch?v=1w-oQ-i1XB8

[dsp1234]

I started with this tutorial[0] that covers react with no JSX, no Flux, no ES6, and no Webpack.

It is just a couple of script includes and normal html/javascript.

From that tutorial, I was able to understand exactly what react is. Then I started adding in the other items on top.

It's definitely not a boilerplate "site in 5 minutes", but it's also a lot less confusing when trying to learn what's going on underneath the hood with react.

[0] - http://jamesknelson.com/learn-raw-react-no-jsx-flux-es6-webp...

[acemarke]

The links in the other replies are definitely good.

Beyond that, I maintain a big list of links to high-quality articles on React and related topics, at https://github.com/markerikson/react-redux-links . It's specifically intended to be a great place to start learning the ecosystem. Just for React, my list points to a couple dozen tutorial articles, a number of build-a-project tutorials, a number of articles that dig into how React works internally, and several paid courses and full books ( https://github.com/markerikson/react-redux-links/blob/master... ).

[magerleagues]

I really like Stephen Grider's class on Udemy: https://www.udemy.com/react-redux/

[Fifer82]

I am struggling a little with Flux, everyone has their own implementation of it. I mean that is grand, but what does it actually mean for me? Contextless.

Thanks for sharing :)

[Stenerson]

When I was learning Flux I thought this video series[1] was really helpful. That being said, I've switched to Redux now and am much happier for it. If you're into videos I highly recommend Dan's (creator of Redux and on React core team) Egghead series[2].

[1] - https://www.youtube.com/watch?v=Pd6Ub7Ju2RM

[2] - https://egghead.io/courses/getting-started-with-redux

[clay_to_n]

Don't implement Flux or Redux until you need it. This is what most React experts keep saying, but there are a ton of entry-level tutorials trying to teach both React concepts and Flux concepts (probably because it's a cool pattern). For most small apps, it's unnecessary. Pass state down as props.

[AnkhMorporkian]

Honestly, people are just settling on redux. It builds on flux and really is pretty easy to use. Is it the best solution? No idea, but it works and it's quickly becoming the de facto implementation.

[rrecuero]

For more advanced examples, I recommend checking out these great boilerplates

https://github.com/erikras/react-redux-universal-hot-example Universal Web Rendering. React + Redux + Express + ES6 + Webpack https://github.com/este/este For Web & Mobile (React Native, Redux, ES6...).

[tengbretson]

In the section on higher-order-components:

    var enhanceComponent = (Component) =>
      class Enhance extends React.Component {
        render() {
          return (
            <Component
              {...this.state}
              {...this.props}
            />
          )
        }
      };

Shouldn't `{...this.state}` be considered an anti-pattern?

[liquidise]

This comment is sure to prove controversial among the more rigorous React followers, but i disagree with the anti-pattern claims. Having built a startup on Backbone and React, i find that referencing `this.state` is a fine way to handle data shifts in our views.

While i have read the oft-presented reasons for not using `this.state`, the arguments feel more academic to me than being based in practical examples. Your milage may vary, but in my experiences `this.state` is one of the more powerful features in React. To me, removing read access to component state also removes one of the more compelling reasons to include React into your codebase at all.

[mudetroit]

There are some legitimate reasons to use state, and I would argue that an HOC is legitimately one of them. (In fact fundamentally that is what redux's connect function really is)

[cnp]

This is just passing state as props

[StreamBright]

Thanks for sharing this, we were just looking for something like it after struggling with some of the concepts in React.

[rzky]

Glad you liked it. Cheers!

[msane]

One thing I prefer about Angular is all of these patterns are established and documented by the same people who designed the framework. In React they are distributed among hundreds of blogs and individual github repos, which all debate each other.

How long has React been out? Simple patterns such as component communication are debated, and third-party documentation about them is newsworthy?

[_greim_]

The patterns handed down by the authors of Angular were one team's idea of how to do things, at a specific moment in time, which subsequently got enshrined and frozen in place for everyone for the next several years. And it works! It's a legitimate way to run a framework.

But, in such an environment, there's no marketplace where ideas can compete and evolve. There's a trade-off where you have to do the hard work of navigating and choosing among competing ideas, but the benefit of React is that you can choose an architecture, today, that isn't a four-year-old snapshot of a small group's idiosyncratic architectural preferences.

[LELISOSKA]

here is some advice: don't use redux or any sort of state library, just use a normal state object, it only clutters your code.

[Dr_tldr]

I think this is great advice for a beginner on their first project. Using React's localState for everything is a huge anti-pattern, but Redux adds cognitive overhead and boilerplate.

Later, when you do a real project, Redux makes debugging and state consistency about 10 times easier, especially on a team or coordinating between multiple teams.

[smac8]

I find a mix is good. I went without a flux implementation for a while and eventually ran into issues with figuring out what components to implement business logic and typical action reducer type work.

I'd say really good advice I wish I had known was don't start with a flux implementation. Build out your app with standard react state, use state only at last cost (ie derive logic off of props or whatever else via functions before storing state data), and only when you get into a bit of mess with a really large application and too much difficulty deciphering what components are providing logic and how they interact with each other should you implement a flux.

Also, it's worth watching Dan Abramov's learning redux course on egghead just for how it gets you to think about react, javascript, and GUI development in general.

[vinceguidry]

Can you add regular javascript versions of the patterns rather than only es6?

[firasd]

I find the Babel REPL useful when trying to figure out es6 code samples: https://babeljs.io/repl/