
React in patterns - rzky
https://github.com/krasimir/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](https://github.com/plasticine/inject-loader)

~~~
_greim_
Makes sense. My frustration in part stems from having worked on an app that
used Angular DI and a module loading system (RequireJS) side by side. The
conceptual dissonance and fallout between the two systems was an endless
source of bickering and confusion for the team. I came to the situation having
worked on a CommonJS/Browserify project, and it was like walking into a brick
wall.

~~~
dceddia
I worked on a project that had Angular + RequireJS too. I don't think having
RequireJS added anything at all. It was just additional overhead - every
module we added caused at least 3 files to change. We eventually ripped it out
and just dealt with Angular's own module system.

------
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/](http://blog.andrewray.me/reactjs-for-stupid-people/) [2]:
[http://reactfordesigners.com/labs/reactjs-introduction-
for-p...](http://reactfordesigners.com/labs/reactjs-introduction-for-people-
who-know-just-enough-jquery-to-get-by/) [3]: [http://blog.andrewray.me/flux-
for-stupid-people/](http://blog.andrewray.me/flux-for-stupid-people/) [4]:
[http://www.tamas.io/react-with-es6/](http://www.tamas.io/react-with-es6/)

~~~
gf263
Thanks for your insight :)

------
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 :)

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

~~~
mparr4
This.

If your component hierarchy matches your application state hierarchy, don't
use flux. If you need to pass pieces of state around to a bunch of different
components (like sharing state across views), use flux.

My first react application was complicated enough (enterprise analytics
application) to require a flux implementation. I went redux and would highly
recommend it both due to its ease-of-use and popularity. However, in
subsequent applications I haven't needed it and have enjoyed writing vanilla
react.

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

~~~
tengbretson
To be clear, I wasn't meaning that use of local state was an anti-pattern in
itself. I only meant that dumping all of the state of a wrapper component into
the child should be avoided. Ideally, the complexity of the data in the props
of a component should lessen the closer one gets to a leaf in the view tree.

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

~~~
msane
_...the benefit of React is that you can choose an architecture..._

I don't see that as a benefit... you must choose, and hope you chose well,
based on poorer information and docs. It's an expense and a risk.

Some are more confident about the cost and risk than others, but less
conscious of it I presume.

~~~
acemarke
The great thing about React is that you get to choose something that works for
your team in your situation.

The bad thing about React is that you need to choose something that works for
your team in your situation.

~~~
msane
It takes more time and energy than the team realizes, which would otherwise be
spent building the app.

Its the frontend after all... what matters is UI and features. Component
communication patterns and all this low level stuff is time lost.

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

------
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/](https://babeljs.io/repl/)

