

React Tips and Best Practices - grandpa
http://aeflash.com/2015-02/react-tips-and-best-practices.html

======
themgt
One of the things I didn't realize at first was the degree to which
Relay/GraphQL appear to effectively replace a lot of Flux:
[http://facebook.github.io/react/blog/2015/02/20/introducing-...](http://facebook.github.io/react/blog/2015/02/20/introducing-
relay-and-graphql.html)

Learning Flux sort of seems like learning how to drive stick shift on an '97
Civic while we wait for the new Tesla to arrive - useful, also a bit annoying.
A central store architecture does seem a better match to what Relay will look
like though.

~~~
picardo
Don't forget that Relay means replacing your RESTful routes. If you still want
to work with RESTful endpoints, you are going to work with Flux.

~~~
grandalf
Exactly -- nobody (yet) has written any kind of general purpose mapping from
rest concepts to relay endpoints. Relay appears to leverage graph db
functionality/semantics pretty heavily.

~~~
jbhatab
Pete hunt said it should be relatively easy to wire up a RESTful api to flux
relay. And since mapping data to complex front ends is hard, but defining
restful endpoints is easy, I'd rather design my database to be optimized for
the complex front end scenarios. I imagine that you would be able to make a
standard REST api from graphql.

------
amelius
Let's be real. It's 2015 and we need quite some hoops to get, in most cases,
some very simple data rendered on the screen. And even with all those hoops,
we are still not sure that it works in all cases. Isn't it time for better
tools than react? Like functional languages that support incremental
computation?

~~~
lukev
It's easy to speculate that better solutions are possible, but _noone has ever
actually done it_. React (used from a more functional language, like
ClojureScript) is the closest system to the world you describe which actually
exists.

And no, papers and toy proof-of-concepts don't count. They are extremely
interesting, and a necessary first step, but someone needs to build something
large and demonstrate effectiveness in the real world before you can make an
honest bid for large-scale adoption. As far as I know, no other FRP or
functional UI system has done any better than React on that front, yet.

~~~
amelius
True. But consider this: if we had a functional-style language that did not do
any incremental computation, only the minimal React-style of re-rendering,
that would already be infinitely better. Because it would mean we wouldn't
have to totally rewrite our code whenever incremental computation became a
reality.

In other words, we can do it in steps.

------
lopatin
Great article. One thing I would like to mention is that using component state
(this.setState) is _okay_! Central stores, and the flux architecture, are very
helpful but if your state shouldn't persist after an unmount, there's no point
in extracting to a central store and passing it through your entire app as
props. (i.e. Whether or not a certain dropdown is expanded). Just keep that
state local.

~~~
aeflash
My point was that the state of the dropdown is something that perfectly fine
to manage directly in the component (nothing else needs to know about it).
Things like the selected value would not be something to manage using
component state.

------
susi22
Has anybody in the client side community ever made the connection to rules
engines? This flow of logic is awfully close to how a rule engine works. I
wonder if people will at some point arrive at it.

There isn't a whole lot of rules engine in JS. Just nools [1] which is huge.
I'd love to see a very simple forward chaining rule engine + Immutable + React
and see how that would work out.

My guess is that they aren't popular at all because they have the notion of
being enterprisey (Drools/Jboss). I'm a big fan of them. They /can/ make life
& code very nice and elegant. Maybe somebody writes an JS adapter to clara
rules [2].

[1] [https://github.com/C2FO/nools](https://github.com/C2FO/nools)

[2] [https://github.com/rbrush/clara-rules](https://github.com/rbrush/clara-
rules)

~~~
saosebastiao
I see some similarities with a stateful recursive Rete implementation. I still
wouldn't go so far as to say that it is basically a rules engine.

The Rete algorithm (which is the underlying algorithm of most rule engines)
trades off memory use for an O(1) execution time (where n==1 and n is the
number of rules in the system). You really only gain any benefit once the
number of rules grows significantly, and by then memory usage is significant
enough that I wouldn't want it running in my browser. If I had a the need for
a rule engine in the browser, I would invest most my effort on offloading rule
processing to the server instead.

------
netcraft
What are the best resources for someone looking to learn react and jsx?

~~~
jdub
Quite seriously: [http://facebook.github.io/react/docs/getting-
started.html](http://facebook.github.io/react/docs/getting-started.html)

~~~
serve_yay
Wow, really? As much as I have enjoyed playing with React, the docs seem very,
very sparse to me. I wish I had a better suggestion, but for me it was a lot
of trying things in code and googling Stack Overflow answers -- you know, the
usual. (And this was, like, a week ago, not 6 months ago or whatever.)

------
konstruktor
Alternatively, there is a very similar example, including a talk, right from
the source:
[https://github.com/facebook/flux/tree/master/examples/flux-c...](https://github.com/facebook/flux/tree/master/examples/flux-
chat)
[https://facebook.github.io/flux/docs/chat.html#content](https://facebook.github.io/flux/docs/chat.html#content)

~~~
konstruktor
Sorry, wrong react thread - and I cannot delete this post.

------
nemothekid
With PureRenderMixin, doesn't that also prevent child components from updating
in response to state changes? For example if a child component must update due
to some event, but none of its parents care about that event, doesn't that
cause the child not to update?

Edit: Turns out my render methods aren't pure. I query stores right render,
which causes problems when using this mixin.

~~~
grrowl
An often overlooked pattern in React is controller-views. When using Flux (or
really, with any external-to-the-component data) you should put this Store
logic in the nearest parent to the components who use it. This component is
the "controller" which gets the data and passes it _as properties_ to the
child components (who pass it as required to their children down the
hierarchy).

This keeps your child components pure (fast, renders directly from props, uses
PureRenderMixin) and keeps data access centralised to the nearest common
controller-view component. It's okay to have a parent component that simply
collects data to pass directly into a single child within the render() call —
the parent fetches data and sets props, the child re-renders only when the
props update, and there's a clear separation of responsibility between the
two.

------
z5h
These are all excellent points that resonate strongly with my experiences with
React. Thanks for the article.

------
piran
Data passed to the controller view should be state from stores, not props.
read the docs plz.

~~~
aeflash
That's only true if you're following the canonical Flux architecture to the
letter. There's little difference between having your store trigger setState()
on a root component and having your store trigger
React.render(<RootComponent/>) with new props.

