
React/Redux Links: a curated list of tutorials for React, Redux, ES6, and more - acemarke
https://github.com/markerikson/react-redux-links
======
lhorie
Maybe I'm missing something, but isn't the appeal of the React/Redux stack
that it is simple?

Does one really need to read dozens of articles as a starting point to get
into this stack? Or is the learning curve to the latest and greatest patterns
actually significant? (Note: I'm not trying to shoot this down, I'm
legitimately curious about the perspective of those who are starting to learn)

~~~
d0m
The surface area of react and redux is small and simple, but that doesn't mean
that building complex applications with it is easy. Essentially, redux is
_just_ a big reduce on an immutable object. The _just_ here is what makes
redux great and open many possibilities with the time travel, etc.

That being said, I'm still trying to figure out how to build a few parts of my
app the "Redux" way and I feel like it's making it way more complex instead of
simplifying it.

For instance, in most redux trivial examples, the store and the views are
directly mapped. I.e. 4 tasks in the store = 4 tasks on the screen. But in
practice, sometimes the view evolves differently. Maybe we don't want to show
the new task because it would confuse the user and it would be better instead
to show a "Show new changes" button.

But then, you're now duplicating the state of the app. Since redux only tells
you when the AppState has changed, how do you figure out how to update that
UIView strictly from the AppState()? Yes, you can regenerate UIState every
time but you need to store additional stuff in the AppState to be able to do
that (For instance, was the "Show Change" button shown or not?). Also,
regenerating a very big object on every change in the store can truly degrade
performances.

There are some libraries (Such as reselect), but it's essentially the same
thing, your view object needs to be recreated from scratch when there's a
relevant change in the AppState.

One possible solution is to have components listen to the store actions and
they would have their own reducer to update the "UIState" accordingly. But
then it's moving away from the current "Redux Way".

That's just one example of how it can get complex even though the redux idea
(One store, one reducer) is simple.

By the way, anyone knows how to solve the issue I just mentioned? :)

~~~
acgourley
This performance tip seems relevant to you:
[https://facebook.github.io/react/docs/component-
specs.html#u...](https://facebook.github.io/react/docs/component-
specs.html#updating-shouldcomponentupdate)

~~~
d0m
I'm already using immutable objects, this is a separate issue. The question is
about how to keep the UIState (Say inside a component) in sync with the
AppState considering they both evolve differently?

~~~
acgourley
The official Redux answer way is to use app state for _everything_. See
libraries like [https://github.com/erikras/redux-
form](https://github.com/erikras/redux-form) which move all the field state
into your app state. Personally I break that rule when I know I can. The only
other state I can think of is animation state - but using css transition
animations has just worked out for me so far.

~~~
acemarke
Actually, no, it's not. In fact, the Redux FAQ flat-out says "It's up to you
to decide what state goes where":
[http://redux.js.org/docs/FAQ.html#organizing-state-only-
redu...](http://redux.js.org/docs/FAQ.html#organizing-state-only-redux-state).

There's certainly some good reasons to put as much of your UI/app state into
Redux as possible, but there's also entirely valid reasons why you might not
want to put some state in there.

------
mythz
I've also created a fairly comprehensive zero to nuts TypeScript + Redux
tutorial that could be added to this list at:

[https://github.com/ServiceStackApps/typescript-
redux](https://github.com/ServiceStackApps/typescript-redux)

~~~
Justen
I'm just about to start a large redesign with redux for work, and I'm just
getting into Typescript vs Flow. Do you have any comments about how they
compare?

~~~
eric_bullington
TypeScript is fairly mature and conservative, whereas Flow has some reasonably
innovative and bold (for JavaScript!) features.

I'd say go with TypeScript if you're looking for a type system closer to C# or
Java (including extensive OOP features), and go with Flow if you're looking
for a type system closer to F# or Scala (including things like type inference
and disjoint unions), although Flow supports ES6 classes, too. In my opinion,
the Flow approach is a more natural fit for JavaScript.

That's not to say that either project can actually achieve the coherence and
completeness of _any_ language designed to be statically-typed from the start,
but those are kind of the the type system ideals that each project seems to
lean toward.

Also, Flow is fully integrated into the React ecosystem, since it's built by
Facebook. TypeScript can work with React, too, but TypeScript also tries to
give first-class support to many other frameworks.

TypeScript is undoubtedly the more mature of the two projects (Flow is much
newer), but I'm very happy that both exist since they're taking pretty
difference approaches to the "JS problem".

~~~
DanRosenwasser
Hi, dev on TypeScript here. I would not just say that TypeScript "can work"
with React, but that it is really very good, especially in terms of JSX
tooling. Give it a try some time!

I also wouldn't say TypeScript strives to focus on OO features - we try to be
a type system that works well for JavaScript programming as it exists, while
paving the way for the future. We don't even use classes in the compiler!

Also like you mentioned, we try hard to work well with many other frameworks
and I think that will show. Angular 2, Dojo, Ionic, RxJS, and others are even
written in TypeScript and provide a pretty great experience.

~~~
eric_bullington
> Give it a try some time!

If you mean give TypeScript a try, I have! In production. And it was very
solid. I haven't yet tried the JSX tooling, since that's a somewhat recent
development and predates my last serious use of TypeScript.

> I also wouldn't say TypeScript strives to focus on OO features

Every single tutorial and howto I've ever read for TypeScript, official or
otherwise, has emphasized the OO capabilities of TypeScript. And for good
reason, TypeScript adds multiple OO features, and features associated with OO
languages like Java and C#. I've heard more than one C# dev say that it feels
almost like programming in C#. So I don't think I'm off base here.

That said, it's great that you're looking to emphasize your support for more
traditional/idiomatic JS as well, as well as your support for React. (and I
admit I'm surprised you don't use any classes in the compiler. Every
TypeScript project of significant size I've ever seen uses lots of OOP. But
I'm sure you're aware of many that don't.)

I do wish that TypeScript had disjoint union/sum types like Flow does, but I
just checked and it looks like you might be seriously considering it! That's
great.

Actually, it looks like you're getting closer to the behavior I'd like with
your recent string literal type PR. If you add some nice to use type guards, I
could program in TypeScript in somewhat approximating the style I've come to
love with Rust/Ocaml/Elm/Scala.

There's no way you could encode exhaustivity checks to that, is there? I'm
pretty sure that would require true disjoint unions, right?

In any case, I'll have to take another look at TypeScript, I'm glad to see
you're pushing things forward. I'll keep my fingers crossed that you'll end up
adding disjoint unions as well.

------
andrewvijay
Any help is awesome is Mark! You've done a great job. It's more than decent
list. Kudos!

------
jbmorgado
Can anybody point something like this but specifically for React Native?

