
Master these five concepts to master React - ziodave
https://medium.freecodecamp.com/the-5-things-you-need-to-know-to-understand-react-a1dbd5d114a3
======
eternalban
Components and "higher-order component factory function". Waiting for "factory
factories" and an iteration of Spring in Javascript.

I'm being a bit snide here since the Java community had to endure years of
_uninformed_ ridicule regarding the meta gymanstics required for component
oriented programming.

I remember talking to a react or backbone (or whatever, it was the current
'thing') developer 1.5 years ago and giving a brief history of GUI toolkit
frameworks before browsers. I swear, his eyes lit up like I was spilling
occult secrets. Back to the future, par per course in this forgetful field.

[p.s. it's not just the browser side people. Many years ago I mentioned in a
Go community group to take a look at the Servlet architecture (circa ~2000)
and its minimal but powerful abstractions. I think it was yesterday that we
had people cheering "context" in Go 1.8.]

~~~
unculture
You know, this information isn't really readily available to us user interface
people. At least, it's not obvious where to go to read about it.

I would love a brief history of GUI programming concepts and patterns if you
could point to one.

~~~
eternalban
Smalltalk:
[http://www.create.ucsb.edu/~stp/PostScript/mvc.pdf](http://www.create.ucsb.edu/~stp/PostScript/mvc.pdf)

Fowler has a good overview of GUI architectures:
[https://martinfowler.com/eaaDev/uiArchs.html#HumbleView](https://martinfowler.com/eaaDev/uiArchs.html#HumbleView)
\- note that this is at this point dated and does not cover the 'reactive'
model.

He also recommends this survey:
[http://aspiringcraftsman.com/2007/08/25/interactive-
applicat...](http://aspiringcraftsman.com/2007/08/25/interactive-application-
architecture/) (Haven't read it myself.)

Java also used to have a funky toy like thing in the beginning called Bongo
(by a company called Marimba). It was a bit of a toy, but I found it an
interesting, if flawed, take on _scriptable_ GUIs. This is all I can dig up
today:
[https://people.apache.org/~jim/NewArchitect/webtech/1997/10/...](https://people.apache.org/~jim/NewArchitect/webtech/1997/10/note/index.html)
(If anyone here knows where I can download Bongo I'd hugely appreciate it. It
was really fun to play with.)

I haven't seen anything about 'design-surface' & 'design-time' in context of
Javascript frameworks yet but I have a feeling that will happen in due course.
Can't dig up anything that is not .NET specific but it is a generally
applicable idea for component based systems. Think GUI builders in visual
studio or NetBeans. This is more of interest if you want to create your own
framework.

Component models are a huge topic.

In the beginning (NATO, 1968):
[http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PD...](http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF)

Hope this is of use to you.

~~~
acemarke
There's quite a few "component playgrounds" out there for React. Storybook is
one, Carte Blanche is another, and there's a few more besides that.

A quick search turned up this list of several tools along that line:
[https://github.com/xyc/til/tree/master/react/devtools](https://github.com/xyc/til/tree/master/react/devtools)

~~~
eternalban
Good to know, thanks. I don't really follow the frontend tech anymore and
obviously no longer buzzword compatible!

------
acemarke
If anyone's interested in learning React, I keep a big list of links to high-
quality tutorials and articles on React, Redux, and related topics, at
[https://github.com/markerikson/react-redux-
links](https://github.com/markerikson/react-redux-links) . Specifically
intended to be a great starting point for anyone trying to learn the
ecosystem, as well as a solid source of good info on more advanced topics.

------
IgorPartola
Smart and dumb components are one of the reasons why I quickly jumped ship to
Vue. It's too complicated and the starter apps make it worse. You get four
level deep directory structures where each dir contains a single file of like
five lines. It feels like knitting a castle.

Vue certainly has its own cruft, but it's at least somewhat simpler when it
comes to how components compose.

~~~
android521
Untiil there is a Vue Native. Vue.js will never be appealing to a lot of
people.

~~~
91bananas
It's in the works: > "Native Rendering The collaboration with Alibaba’s Weex
project has made some substantial progress. Our first major goal — making Vue
2 the actual JavaScript runtime framework on top of Weex’s native rendering
engine — has been completed in the latest 0.9.4 release. In 2017 there will be
revamped documentations, better onboarding experience and API improvements
based on feedback from the community and large-scale production use at
Alibaba."

[https://medium.com/the-vue-point/vue-
in-2016-8df71d98bfb3#.u...](https://medium.com/the-vue-point/vue-
in-2016-8df71d98bfb3#.uzzbgq7wj)

------
whatever_dude
Subjective content opinions aside, this article is short and to the point.
Well written.

------
k__
These and 3rd party integration, I think.

HOC aren't to bad to know either, if you want to end up with maintainable
code.

shameless plug: [https://github.com/kay-is/react-from-
zero](https://github.com/kay-is/react-from-zero)

------
tyingq
Would you put "filling in the rest of the stack" as another finger of death?
There doesn't seem to be good consensus on that bit.

~~~
peterbonney
Nor should there be a consensus. Back-end use cases are far more diverse than
front-end use cases. Front-end frameworks should never prescribe the rest of
your stack, IMHO.

~~~
tyingq
I'm not a front end expert...but the variety of choices around filling the
stack for react seems broader than it was in the past.

It feels like there's more risk in making the wrong choice. I see lots of
regrets around redux, for example, adding more complexity than initially
wanted. Or, selecting a tool that becomes abandonware, etc.

~~~
k__
Yes, there are a bunch of regrets about Redux, but I have the feeling it got
better last year.

In 2015 we had countless Flux implementations and most of them have been
abandoned. I did an app with Flummox, for example and switched to Redux later.

But now? Redux and MobX are basically the major players and you can still do
small to medium sized apps without them.

------
rquestion
React best practises question - At what level should event handlers be
installed? At lowest level components or the highest level?

How are events in React supposed to be propagated from low level components to
their parent components when the low level components should not have any
knowledge of their parents?

~~~
acemarke
By passing down callback functions as props. One of the basic patterns of
React is that parents communicate to their children by passing down data as
props, and they also pass down callback functions that a child can execute to
communicate upwards.

There's a great article that describes various component communication
patterns at [http://andrewhfarmer.com/component-
communication/](http://andrewhfarmer.com/component-communication/) .

~~~
rquestion
Thanks. Exactly what I was looking for.

~~~
neurostimulant
Also, take a look at optional libraries such as redux (and its friends, e.g.
redux-saga or redux-thunk). You don't have to use them, but when your codebase
starts getting complicated with lots of callback, perhaps using those state
management libraries would help.

------
tonyneel923
Good article besides the nonsense about some of the react lifecycles being
voodoo. You will use it if you program extensively.

------
drivingmenuts
> the component approach means that both HTML and JavaScript code live in the
> same file.

Something about this makes me want to facepalm and wonder why we bothered with
separation of concerns, when React just undoes all of that.

~~~
prof_hobart
That's exactly what I thought when I started using it.

But as I've got more used to it, I'm not sure it's really an issue, or at
least doesn't have to be.

Firstly, JSX isn't really HTML. It's a bit of syntactic sugar around
JavaScript "createElement" functions. If you don't want to have something that
looks similar to HTML in your JS, you don't have to.

Secondly, if you want dynamically generated HTML, you're going to need some
form of logic embedded in there somewhere (loops, conditionals etc). Most
template languages end up with their own directives, like Angular 2's "ngFor".
The React answer is to use standard JavaScript for that control.

And if you then want to separate out the non-display logic, you can use a
combination of "smart" (pure JS logic) and "dumb" (JS/JSX display) components,
and treat the JSX files as templates. "Separation of concerns" in this context
isn't about not mixing code and markup, it's about not mixing business and
display logic, and there's nothing in React that stops you doing that.

