16 ms·

React/Redux Links: a curated list of tutorials for React, Redux, ES6, and more

125 points by acemarke 11y ago

mythz 11y ago
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 11y ago
  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?
  - mythz 11y ago
    Haven't use Flow in anger but TypeScript has a lot more momentum, tooling, community and dev resources behind it which are the main reasons why I've adopted it. TypeScript + JSPM really provides a nice productive and enjoyable dev experience vs regular ES5 - it's definitely my choice power combo going forward.
  - eric_bullington 11y ago
    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 11y ago
      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 11y ago
        > 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.
  - AgentME 11y ago
    If you have an existing codebase already using Babel and Webpack or Browserify, then using Flow only requires tweaking Babel's config a little (or not at all if you're already using the React preset). You use Flow like a linter tool. It doesn't try to take over your build process; You don't have to leave Babel and Webpack/Browserify behind. Flow is also great for allowing you to gradually add typing to an application.
- Keats 11y ago
  Did you manage to get hot reload working with TypeScript (without going through Babel in the middle)? Currently using webpack + typescript but still have Babel in the middle for the occasional hot reload. We could drop hot reload but it is occasionally nice
  - mythz 11y ago
    No I've opted to go with the least moving parts and am not using hot reloading or any runtime transpiling/transformations/etc. The TypeScript tools for Visual Studio automatically regenerates the .js file every time you save its TypeScript file so it works statically without needing any background process to monitor for changes. So my JSPM doesn't know about TypeScript, it's just loading the pre-generated .js files every time I hit refresh. If you've configured React Routing and are saving/reloading Redux state in localStorage on change it's a pretty good dev experience as most of the time a refresh brings you back to where you left off.
  - davidspiess 11y ago
    Look at this recent pull request by Dan https://github.com/reactjs/redux/pull/1455 https://github.com/reactjs/redux/pull/1455 It removes the need of the hmr plugin and babel completely, since it uses webpack hot reload directly
    - Keats 11y ago
      I've seen that before but I couldn't get the hot reload to work for the react components. You also need to `module.hot.accept` every file one by one I think?
- alexisnorman 11y ago
  Was going to ask for a TypeScript suggestion, thanks! I wonder how far off the VS Studio setup is from Visual Studio Code as I've been using the latter lately.
lhorie 11y ago
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)
- dcwca 11y ago
  It keeps simplicity low for large and complex projects, but isn't simple to get started with.
  - mooseburger 11y ago
    You mean complexity low, not simplicity low, yes?
- acemarke 11y ago
  There's varying aspects of complexity involved: * Both React and Redux have very small API surfaces, but do involve very different ways of thinking for someone coming from a jQuery or Backbone background * While the "Javascript Fatigue" argument is a bit worn out by now, there _is_ validity in the point that there can be lots of moving pieces to set up * There are some significant nuances with both libraries once you get past the "Hello World" stage. State shape, performance optimization, managing more complex use cases, etc. Beyond that, there's a _lot_ of articles and tutorials out there, and the quality of the information varies considerably. I did a lot of bookmarking while I was learning these things last year, and have found myself answering many of the same questions over and over on Reddit and Reactiflux. I wanted to put together a consolidated reference of good information that I could point people to. So no, you probably don't need to read "dozens" of articles to get started, but one person might find a certain 3 or 4 articles more useful than someone else (kind of along the lines of how "everyone uses 20% of MS Word's features... but everyone uses a different 20%").
- switz 11y ago
  No matter how simple a piece of technology is at face value, people often use its simplicity to solve complex problems. Sure, building a TODO list with react and redux is easy enough, but once you start building a large or complex application you need to establish patterns and design decisions in order to scale the codebase well. I can't speak to the quality of this list, but I gather that, rather than a defacto list of how to go from 0 to expert on react and redux, the author intended to curate a list of tutorials that they found insightful so you don't have to go digging around Google.
andrewvijay 11y ago
Any help is awesome is Mark! You've done a great job. It's more than decent list. Kudos!
jbmorgado 11y ago
Can anybody point something like this but specifically for React Native?

125 points by acemarke 11y ago

mythz 11y ago

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 11y ago
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?
- mythz 11y ago
  Haven't use Flow in anger but TypeScript has a lot more momentum, tooling, community and dev resources behind it which are the main reasons why I've adopted it. TypeScript + JSPM really provides a nice productive and enjoyable dev experience vs regular ES5 - it's definitely my choice power combo going forward.
- eric_bullington 11y ago
  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 11y ago
    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 11y ago
      > 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.
- AgentME 11y ago
  If you have an existing codebase already using Babel and Webpack or Browserify, then using Flow only requires tweaking Babel's config a little (or not at all if you're already using the React preset). You use Flow like a linter tool. It doesn't try to take over your build process; You don't have to leave Babel and Webpack/Browserify behind. Flow is also great for allowing you to gradually add typing to an application.
Keats 11y ago
Did you manage to get hot reload working with TypeScript (without going through Babel in the middle)? Currently using webpack + typescript but still have Babel in the middle for the occasional hot reload. We could drop hot reload but it is occasionally nice
- mythz 11y ago
  No I've opted to go with the least moving parts and am not using hot reloading or any runtime transpiling/transformations/etc. The TypeScript tools for Visual Studio automatically regenerates the .js file every time you save its TypeScript file so it works statically without needing any background process to monitor for changes. So my JSPM doesn't know about TypeScript, it's just loading the pre-generated .js files every time I hit refresh. If you've configured React Routing and are saving/reloading Redux state in localStorage on change it's a pretty good dev experience as most of the time a refresh brings you back to where you left off.
- davidspiess 11y ago
  Look at this recent pull request by Dan https://github.com/reactjs/redux/pull/1455 https://github.com/reactjs/redux/pull/1455 It removes the need of the hmr plugin and babel completely, since it uses webpack hot reload directly
  - Keats 11y ago
    I've seen that before but I couldn't get the hot reload to work for the react components. You also need to `module.hot.accept` every file one by one I think?
alexisnorman 11y ago
Was going to ask for a TypeScript suggestion, thanks! I wonder how far off the VS Studio setup is from Visual Studio Code as I've been using the latter lately.

lhorie 11y ago

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)

dcwca 11y ago
It keeps simplicity low for large and complex projects, but isn't simple to get started with.
- mooseburger 11y ago
  You mean complexity low, not simplicity low, yes?
acemarke 11y ago
There's varying aspects of complexity involved: * Both React and Redux have very small API surfaces, but do involve very different ways of thinking for someone coming from a jQuery or Backbone background * While the "Javascript Fatigue" argument is a bit worn out by now, there _is_ validity in the point that there can be lots of moving pieces to set up * There are some significant nuances with both libraries once you get past the "Hello World" stage. State shape, performance optimization, managing more complex use cases, etc. Beyond that, there's a _lot_ of articles and tutorials out there, and the quality of the information varies considerably. I did a lot of bookmarking while I was learning these things last year, and have found myself answering many of the same questions over and over on Reddit and Reactiflux. I wanted to put together a consolidated reference of good information that I could point people to. So no, you probably don't need to read "dozens" of articles to get started, but one person might find a certain 3 or 4 articles more useful than someone else (kind of along the lines of how "everyone uses 20% of MS Word's features... but everyone uses a different 20%").
switz 11y ago
No matter how simple a piece of technology is at face value, people often use its simplicity to solve complex problems. Sure, building a TODO list with react and redux is easy enough, but once you start building a large or complex application you need to establish patterns and design decisions in order to scale the codebase well. I can't speak to the quality of this list, but I gather that, rather than a defacto list of how to go from 0 to expert on react and redux, the author intended to curate a list of tutorials that they found insightful so you don't have to go digging around Google.

andrewvijay 11y ago

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

jbmorgado 11y ago

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