
The Simplest React Stack – Part 1: Bootstrapping and State Management - thenewestkid
https://medium.com/@solkimicreb/the-react-stack-challenge-5fd166e1245f
======
whalesalad
Surprised to see the state store caring about events. Checking for a keycode
in your system to add an event to a store feels like a violation of separate
concerns. That was an immediate turnoff for me with this post.

~~~
thenewestkid
Valid point. You can move that logic to the component and leave the store for
pure data manipulation and handling only. I do that for bigger projects, but
in this case I wanted to make things short.

The goal of this series is not to teach patterns but to promote a simple and
flexible stack that you can use with the patterns that you like. (In your case
you can move the view specific logic to the level of the components).

~~~
cies
I came here to say the same as whalesalad. This is not just a "you can do that
if you wish" situation. This is more a case of "so much anti-pattern that it
turns off readers".

~~~
thenewestkid
As you wish (: You convinced me, I edited the gists and removed the
antipattern. Please review it if you have a spare minute. Thx!

~~~
cies
Most welcome. Looks so much better. And it was whalesalad to report it first
:) Have a great day!

------
_pdp_
In our shop where we have built many high-performant, and pretty complex
(various types of security tools and all that) react apps, the state is
managed at the top-most component and it is passed down to all other
components as props. It works great and it is functional all the way.

~~~
girvo
Yeah, especially if you combine that idea with Flow/TypeScript or Reason. In
fact that's why Redux isn't really used in Reason very much, with algorithmic
data types, exhaustive pattern matching and all the power of OCaml you don't
need it!

I enjoy the simplicity of it so much that I've now entirely adopted Elm --
type safety, super simple but powerful, and completely based on uni
directional data flow with a compiler that is the most helpful I've ever used
all wrapped up in the same State -> View function hierarchy that I adore in
React.

~~~
uryga
You probably meant "algebraic data types" :)

~~~
girvo
I most definitely did :) remind me not to type while still half asleep!

------
faitswulff
Neat. Did you get any inspiration from Vuex in creating the store? The global
store and building it out of a POJO are pretty similar patterns that I happen
to like.

~~~
thenewestkid
No, I have never used Vuex, but I think Vue is an awesome framework. My main
inspiration was monitoring my problematic situations and state management
needs during app development in various frameworks.

------
sigden
I'm a big fan of react-easy-state. Unfortunately its foundation of ES6 proxies
precludes its use in Internet Explorer.

~~~
yttrium
What about react-easy-state stops you from transpiling to ES2015?

~~~
thenewestkid
Author here. As sigden mentioned, ES6 Proxies can not be transpiled. That is
one reason why they are not yet commonly used. You can find out more about
them here:
[https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Proxy)
(They are pretty awesome).

------
jbergens
Nice idea!

Did you check out mobx?

My guess is that it would be almost as easy and a bit more mature.

~~~
thenewestkid
Sure, I know about MobX. I use ES6 Proxies instead of the getter/setter based
transparent reactivity they use. It allows me to have less edge cases in
exchange for narrower platform support.

MobX is also moving in the Proxy direction with v4, but I do not agree with
some of their architectural decisions (mostly the synchronous execution), so I
made a separate library. We can discuss these later if you are interested.

------
molly0
get completed () Is "get" som es6 thing?

~~~
RobertKerans
No, just not commonly used; getters and setters aren't terribly useful in a
language that allows such easy direct modification of objects (as opposed to
say Java)

~~~
Symen
But transparent getters and setters can be used to emulate private or
immutable properties:

    
    
        function Foo() {
          var _bar = 42;
          return {
            get bar() {
              return _bar;
            }
          } 
        }
    
        var foo = Foo();
        foo.bar
        /*
        42
        */
    

However the fact that you can transparently replace a simple property by a
computed one (e.g. for backwards compatibility or to trigger side effects in
observables) does make explicit, Java-style, getters and setters less useful.

