6 ms·

Why would you even pay to learn React? The official doc is free and takes only few hours of reading.

benbristow 8y ago
I learned most of it myself but bought a Udemy course for Black Friday. I find the docs to be quite confusing to be honest. I know it's not React but Redux's docs aren't great either. Concepts quite hard to understand at first.
- acemarke 8y ago
  Hi, I'm a Redux maintainer. FWIW, a lot of people tell us Redux's docs are "great", but we've also had people tell us they aren't helpful. Kinda hard to figure out how to make improvements based on that kind of conflicting feedback :) We are actually looking at revamping the Redux docs in the near future [0]. If you've got any specific concerns or suggestions on how we can improve things, please let me know directly, or comment on that issue. Also, besides the docs, you may be interested in my suggested resources for learning Redux [1], including my own Redux workshop slides [2]. [0] https://github.com/reduxjs/redux/issues/2590 https://github.com/reduxjs/redux/issues/2590 [1] http://blog.isquaredsoftware.com/2017/12/blogged-answers-learn-redux/ http://blog.isquaredsoftware.com/2017/12/blogged-answers-lea... [2] https://blog.isquaredsoftware.com/2018/06/redux-fundamentals-workshop-slides/ https://blog.isquaredsoftware.com/2018/06/redux-fundamentals...
  - benbristow 8y ago
    The Udemy course that I saw gives an anology to how Redux is meant to work in the form of an Insurance Company and how Action Creators, Actions, Reducers, Stores etc. map to a real world scenario. That really helped my understanding of the 'Redux' model.
    - acemarke 8y ago
      Gotcha. Any aspects of the Redux docs that you felt didn't explain things well enough?
  - jsgo 8y ago
    not saying you're taking offense to the critique, but I wouldn't. While I don't use Redux nor have experience with the docs for it, there have been some concepts that I didn't grasp from reading the docs for a topic where others had a better understanding of it coming out where after someone broke it down in a blog, it allowed me to understand it as well (at which point the docs were beneficial as a resource to come back to later). Different mediums will probably be better suited for getting more nuanced than the docs can, generally. So I can totally see where conflicting feedback could appear and why you shouldn't take the "negative" feedback as a slight against the work on the docs (but fielding concerns/questions/suggestions as you are is completely a great thing). From the outside looking in, if I were looking at Redux and I heard from a few "man, the docs are a bit hard to grasp" and others "I love the docs. They allowed me to get up and running" I wouldn't be scared off; it'd seem to be pretty par for the course.
    - acemarke 8y ago
      Right, not taking offense - just saying that it's hard to come up with actionable ways to improve things when most people say they're good, and a few people say they're not helpful, and neither group really gives much in the way of specifics :)
      - geezerjay 8y ago
        > when most people say they're good One size doesn't fit all, and some people don't speak for all.
  - munchbunny 8y ago
    Maybe I can help on this one. I'm midway through learning Redux - enough to have stuff working, but not enough to write complex UI code with it. The problem for me is that Redux uses a set of higher order constructs, which requires a set of functional abstractions that are pretty unique to Redux and Redux-likes. There isn't remotely enough documentation to explain why the boilerplate is put where it is or named the way it is, so I have working code, but no real understanding of why the boilerplate is this way vs. any other way. So what happens in the docs is that I follow the tutorial along, and it's great about setting up the problems to show why Redux is useful, but then it goes "ok so to solve the problem you use this magical incantation in Redux." Yes, I can adapt the magical incantation, but that doesn't really help me grok who owns which callback that makes which modifications or transformations to be consumed by which objects.
    - acemarke 8y ago
      Can you point to some specific "boilerplate" examples you're having trouble with, and possibly also docs pages showing those items?
- ergothus 8y ago
  I found their docs to be quite good, but I teach the topic and students vary in their responses, so I think it comes down to your approach and previous experience. React is best to approach the same way you approach functions: You want to have small components, that do one job, that don't interact with outside state (see below for exception), and are largely ignorant of how your app works. The slight exception is container components, where interacting with outside state should be their sole job, encapsulating the application state interactions and passing the info to the contained components so that they don't have to have that knowledge. I find a top-down approach works well: Break your page into parts (boxes of content), and then break those down, and so forth. Each box of content will be a component - most will contain others, and the smallest will just have on job. Move all logic except for simple "show/don't show" into outside functions that you import in to your components - React is the View and you don't want it doing nearly as much as it CAN do. Keep it simple, keep it small. Remember the key rule: You can pass values DOWN (into contained components) but not UP (into your wrapping components). So if you need to send data "up", you need to pass callbacks down and use those callbacks to pass any data "up". This can feel weird, but it helps keep those contained components ignorant of your larger application, which in turn makes them more reliable overtime, as they aren't impacted by changes outside of themselves. If you have had limited experience with function best practices, or if you've only worked in deeply OOP systems (that have similar best practices but different concepts for passing data), this can be a bit of a struggle to adjust to, but it's actually a very common pattern, and the reason I use React to teach web dev (after teaching basic vanilla JS) - even after React is obsolete these practices will be useful to follow. I also recommend learning React BEFORE taking on Redux (or any other application state management lib) - even a simple TODO app (don't copy what is out there, write it without hints, then compare) can help clear up the root concepts, and after that application state management is easier to keep distinct in your mind. I took it all on (React + Flux) at once when I started and it took months to grasp because I wasn't keeping them clear from one another. Redux mapXXXXToProps() functions are in fact quite hard to grasp unless you comfortable with how you use React props in practice, at which point they become straightforward. And lastly, the switching between class-based components and function-based components can be really confusing. I personally prefer to use almost exclusively function-based components, because React is not expecting you to use an OOP approach to the components. I only use class-based components where I need component state (often only the top-level component for small apps) or if I need to use the lifecycle methods (and I rarely do - many examples use didComponentMount to fire off service calls, but I tend to put those into event handlers, though that gets a lot easier when you are using an application state management lib). but if you prefer class-based components, that's fine - just don't think React is using classes for anything more than providing inheritance of the component methods. No OOP-approach to your components. Hope this helps!
- crooked-v 8y ago
  Redux has the problem that (a) the read-only reducer concept is totally at odds with how a bunch of JS builtins work and so conceptually hard to understand for a newbie, (b) it has just so much boilerplate for "best practices" for even the simplest use case, and (c) it's not immediately clear what the benefits of wrapping your head around all that are. For me, it took me a while of working on a web app with derived data everywhere (~15 KB raw JSON that gets updated with diffs and recombobulated into different output formats and different intersections of data with live updates), and endless debugging of data transformations by stepping back and forth through the reducer history, before I really "got" it. On the note of (b), I really like the redux-actions project (https://redux-actions.js.org https://redux-actions.js.org) for the way its helpers that get rid of most of that. A simple example: const setValueA = createAction('SET_VALUE_A'); const setValueB = createAction('SET_VALUE_B'); const setValueAB = createAction('SET_VALUE_AB', (a, b) => ({ a, b })); export const reducer = combineReducers({ valueA: handleActions({ [setValueA]: (state, action) => action.payload [setValueAB]: (state, action) => action.payload.a }, null), valueB: handleActions({ [setValueB]: (state, action) => action.payload [setValueAB]: (state, action) => action.payload.b }, null) });
  - acemarke 8y ago
    We've actually got a new `redux-starter-kit` package which includes some reducer utilities similar to `redux-actions`, but using the Immer library internally. That allows you to write simpler immutable updates that look like "mutation". There's also some helpers for common use cases like simplifying store setup, and generating entire "slices" of state at once (including generating action creators and action types automatically). I put together an example of using this the other day: https://www.reddit.com/r/reactjs/comments/a0b1sa/frustrated_with_redux_so_i_created_abredux_vs/eagqit6/ https://www.reddit.com/r/reactjs/comments/a0b1sa/frustrated_... Please try it out and let us know what you think! https://github.com/reduxjs/redux-starter-kit https://github.com/reduxjs/redux-starter-kit
    - crooked-v 8y ago
      createSlice is an interesting approach, though it feels like it's missing the use case of being able to set multiple keys in the same reducer from one action, as with my valueAB example above. It might be worth putting some thought into how to make a variant of it that can produce multiple reducers (one per key to be affected), not just one.
danellis 8y ago
There seems to be a culture of collecting Udemy courses among fledgeling web developers.
- narwally 8y ago
  Do people actually put that kind of stuff on resumes? I've done a good handful of MOOC courses (usually not all the way through to be fair), but I can't imagine actually paying for a certificate so I can put it on my resume. If I want to show that I know React I'd rather just build something with it, throw it on github, and list it as a side-project.
  - ep103 8y ago
    yes, yes they do.
  - jammygit 8y ago
    Doesn't matter if you put it on your resume. You can use what you learn to build a portfolio project
  - danellis 8y ago
    I don't think Udemy has any kind of completion certificates, and I can't imagine would put "Watched video about X" on their resume.
    - geezerjay 8y ago
      Truth be told, putting MOOCs on a resume is not good either. Some employers actually consider MOOCs on CVs as red flags.
- thrower123 8y ago
  Young web developers certainly seem to love video courses for some reason. Maybe I'm just old and crotchety, (well, one of those is certainly true), but I would much rather get my fix textually and go along at my own pace. Flipping pages or scrolling is still superior to trying to scrub through a video timeline.
aczerepinski 8y ago
Imagine a brand new developer who started learning JavaScript as their first programming language one month ago. A nice hand-holds video might be perfect for them. Also, not going to judge a super experienced developer if they just prefer videos for whatever reason.
projectramo 8y ago
I think you learn a lot from watching people code that you don't get from their docs. Here are some examples: 1. Which files do I spend time on and which ones can I ignore? The first time I tried npm I felt like I had to understand all those files that kept popping up. 2. What is a good workflow? None of those documents tell you to open up dev tools and constantly console.log out values, but in a video (I assume) this will come up. These are two examples but they mostly they show you what you should focus on. There are dozens of little things that you won't pick up from text.
munchbunny 8y ago
For programming veterans who have at least some frontend experience and just want to pick up React (i.e. me) the React docs and scattered tutorials/stack overflow sites was sufficient. But I wouldn't remotely recommend this path for someone relatively new to programming.
- k_vi 8y ago
  I wouldn't remotely recommend react for someone relatively new to programming.
  - pageandrew 8y ago
    Why not? It’s simple enough.
    - lsiunsuex 8y ago
      React itself is simple enough. To build a proper, functioning app, React is not enough. You need a dozen other packages to build even the most basic of data driven sites. I'm an experienced developer and I could not wrap my head around React with free tutorials. This tutorial uses React, Flux, blah blah blah. This other tutorial uses a whole different set of packages. It's not transferable. I need to build X. Show me a tutorial on how to build X. People give Angular 2+ a lot of crap but at least every.single.tutorial I've ever read on it are discussing the same basic set of tools and system. I pay for Pluralsight and while I've been focused on learning Angular from it, paid tutorials "generally" are much better quality then free ones IMO.
- vmware505 8y ago
  You can do the same with Ember.js also. There is a free detailed tutorial for absolute begginers. You build a full featured web app. It is so much fun: https://yoember.com https://yoember.com
doanguyen 8y ago
I would say we are all human. Some are lazy, some want shortcuts, some have difficulty in reading, all sort of things, that's why there are a lot of non-free React (framework X/ Library Y...) courses
oh-kumudo 8y ago
My thought exactly. They are more than enough resources to learn React... Literally everywhere...

I learned most of it myself but bought a Udemy course for Black Friday. I find the docs to be quite confusing to be honest. I know it's not React but Redux's docs aren't great either. Concepts quite hard to understand at first.

acemarke 8y ago
Hi, I'm a Redux maintainer. FWIW, a lot of people tell us Redux's docs are "great", but we've also had people tell us they aren't helpful. Kinda hard to figure out how to make improvements based on that kind of conflicting feedback :) We are actually looking at revamping the Redux docs in the near future [0]. If you've got any specific concerns or suggestions on how we can improve things, please let me know directly, or comment on that issue. Also, besides the docs, you may be interested in my suggested resources for learning Redux [1], including my own Redux workshop slides [2]. [0] https://github.com/reduxjs/redux/issues/2590 https://github.com/reduxjs/redux/issues/2590 [1] http://blog.isquaredsoftware.com/2017/12/blogged-answers-learn-redux/ http://blog.isquaredsoftware.com/2017/12/blogged-answers-lea... [2] https://blog.isquaredsoftware.com/2018/06/redux-fundamentals-workshop-slides/ https://blog.isquaredsoftware.com/2018/06/redux-fundamentals...
- benbristow 8y ago
  The Udemy course that I saw gives an anology to how Redux is meant to work in the form of an Insurance Company and how Action Creators, Actions, Reducers, Stores etc. map to a real world scenario. That really helped my understanding of the 'Redux' model.
  - acemarke 8y ago
    Gotcha. Any aspects of the Redux docs that you felt didn't explain things well enough?
- jsgo 8y ago
  not saying you're taking offense to the critique, but I wouldn't. While I don't use Redux nor have experience with the docs for it, there have been some concepts that I didn't grasp from reading the docs for a topic where others had a better understanding of it coming out where after someone broke it down in a blog, it allowed me to understand it as well (at which point the docs were beneficial as a resource to come back to later). Different mediums will probably be better suited for getting more nuanced than the docs can, generally. So I can totally see where conflicting feedback could appear and why you shouldn't take the "negative" feedback as a slight against the work on the docs (but fielding concerns/questions/suggestions as you are is completely a great thing). From the outside looking in, if I were looking at Redux and I heard from a few "man, the docs are a bit hard to grasp" and others "I love the docs. They allowed me to get up and running" I wouldn't be scared off; it'd seem to be pretty par for the course.
  - acemarke 8y ago
    Right, not taking offense - just saying that it's hard to come up with actionable ways to improve things when most people say they're good, and a few people say they're not helpful, and neither group really gives much in the way of specifics :)
    - geezerjay 8y ago
      > when most people say they're good One size doesn't fit all, and some people don't speak for all.
- munchbunny 8y ago
  Maybe I can help on this one. I'm midway through learning Redux - enough to have stuff working, but not enough to write complex UI code with it. The problem for me is that Redux uses a set of higher order constructs, which requires a set of functional abstractions that are pretty unique to Redux and Redux-likes. There isn't remotely enough documentation to explain why the boilerplate is put where it is or named the way it is, so I have working code, but no real understanding of why the boilerplate is this way vs. any other way. So what happens in the docs is that I follow the tutorial along, and it's great about setting up the problems to show why Redux is useful, but then it goes "ok so to solve the problem you use this magical incantation in Redux." Yes, I can adapt the magical incantation, but that doesn't really help me grok who owns which callback that makes which modifications or transformations to be consumed by which objects.
  - acemarke 8y ago
    Can you point to some specific "boilerplate" examples you're having trouble with, and possibly also docs pages showing those items?
ergothus 8y ago
I found their docs to be quite good, but I teach the topic and students vary in their responses, so I think it comes down to your approach and previous experience. React is best to approach the same way you approach functions: You want to have small components, that do one job, that don't interact with outside state (see below for exception), and are largely ignorant of how your app works. The slight exception is container components, where interacting with outside state should be their sole job, encapsulating the application state interactions and passing the info to the contained components so that they don't have to have that knowledge. I find a top-down approach works well: Break your page into parts (boxes of content), and then break those down, and so forth. Each box of content will be a component - most will contain others, and the smallest will just have on job. Move all logic except for simple "show/don't show" into outside functions that you import in to your components - React is the View and you don't want it doing nearly as much as it CAN do. Keep it simple, keep it small. Remember the key rule: You can pass values DOWN (into contained components) but not UP (into your wrapping components). So if you need to send data "up", you need to pass callbacks down and use those callbacks to pass any data "up". This can feel weird, but it helps keep those contained components ignorant of your larger application, which in turn makes them more reliable overtime, as they aren't impacted by changes outside of themselves. If you have had limited experience with function best practices, or if you've only worked in deeply OOP systems (that have similar best practices but different concepts for passing data), this can be a bit of a struggle to adjust to, but it's actually a very common pattern, and the reason I use React to teach web dev (after teaching basic vanilla JS) - even after React is obsolete these practices will be useful to follow. I also recommend learning React BEFORE taking on Redux (or any other application state management lib) - even a simple TODO app (don't copy what is out there, write it without hints, then compare) can help clear up the root concepts, and after that application state management is easier to keep distinct in your mind. I took it all on (React + Flux) at once when I started and it took months to grasp because I wasn't keeping them clear from one another. Redux mapXXXXToProps() functions are in fact quite hard to grasp unless you comfortable with how you use React props in practice, at which point they become straightforward. And lastly, the switching between class-based components and function-based components can be really confusing. I personally prefer to use almost exclusively function-based components, because React is not expecting you to use an OOP approach to the components. I only use class-based components where I need component state (often only the top-level component for small apps) or if I need to use the lifecycle methods (and I rarely do - many examples use didComponentMount to fire off service calls, but I tend to put those into event handlers, though that gets a lot easier when you are using an application state management lib). but if you prefer class-based components, that's fine - just don't think React is using classes for anything more than providing inheritance of the component methods. No OOP-approach to your components. Hope this helps!
crooked-v 8y ago
Redux has the problem that (a) the read-only reducer concept is totally at odds with how a bunch of JS builtins work and so conceptually hard to understand for a newbie, (b) it has just so much boilerplate for "best practices" for even the simplest use case, and (c) it's not immediately clear what the benefits of wrapping your head around all that are. For me, it took me a while of working on a web app with derived data everywhere (~15 KB raw JSON that gets updated with diffs and recombobulated into different output formats and different intersections of data with live updates), and endless debugging of data transformations by stepping back and forth through the reducer history, before I really "got" it. On the note of (b), I really like the redux-actions project (https://redux-actions.js.org https://redux-actions.js.org) for the way its helpers that get rid of most of that. A simple example: const setValueA = createAction('SET_VALUE_A'); const setValueB = createAction('SET_VALUE_B'); const setValueAB = createAction('SET_VALUE_AB', (a, b) => ({ a, b })); export const reducer = combineReducers({ valueA: handleActions({ [setValueA]: (state, action) => action.payload [setValueAB]: (state, action) => action.payload.a }, null), valueB: handleActions({ [setValueB]: (state, action) => action.payload [setValueAB]: (state, action) => action.payload.b }, null) });
- acemarke 8y ago
  We've actually got a new `redux-starter-kit` package which includes some reducer utilities similar to `redux-actions`, but using the Immer library internally. That allows you to write simpler immutable updates that look like "mutation". There's also some helpers for common use cases like simplifying store setup, and generating entire "slices" of state at once (including generating action creators and action types automatically). I put together an example of using this the other day: https://www.reddit.com/r/reactjs/comments/a0b1sa/frustrated_with_redux_so_i_created_abredux_vs/eagqit6/ https://www.reddit.com/r/reactjs/comments/a0b1sa/frustrated_... Please try it out and let us know what you think! https://github.com/reduxjs/redux-starter-kit https://github.com/reduxjs/redux-starter-kit
  - crooked-v 8y ago
    createSlice is an interesting approach, though it feels like it's missing the use case of being able to set multiple keys in the same reducer from one action, as with my valueAB example above. It might be worth putting some thought into how to make a variant of it that can produce multiple reducers (one per key to be affected), not just one.

danellis 8y ago

There seems to be a culture of collecting Udemy courses among fledgeling web developers.

narwally 8y ago
Do people actually put that kind of stuff on resumes? I've done a good handful of MOOC courses (usually not all the way through to be fair), but I can't imagine actually paying for a certificate so I can put it on my resume. If I want to show that I know React I'd rather just build something with it, throw it on github, and list it as a side-project.
- ep103 8y ago
  yes, yes they do.
- jammygit 8y ago
  Doesn't matter if you put it on your resume. You can use what you learn to build a portfolio project
- danellis 8y ago
  I don't think Udemy has any kind of completion certificates, and I can't imagine would put "Watched video about X" on their resume.
  - geezerjay 8y ago
    Truth be told, putting MOOCs on a resume is not good either. Some employers actually consider MOOCs on CVs as red flags.
thrower123 8y ago
Young web developers certainly seem to love video courses for some reason. Maybe I'm just old and crotchety, (well, one of those is certainly true), but I would much rather get my fix textually and go along at my own pace. Flipping pages or scrolling is still superior to trying to scrub through a video timeline.

aczerepinski 8y ago

Imagine a brand new developer who started learning JavaScript as their first programming language one month ago. A nice hand-holds video might be perfect for them. Also, not going to judge a super experienced developer if they just prefer videos for whatever reason.

projectramo 8y ago

I think you learn a lot from watching people code that you don't get from their docs. Here are some examples: 1. Which files do I spend time on and which ones can I ignore? The first time I tried npm I felt like I had to understand all those files that kept popping up. 2. What is a good workflow? None of those documents tell you to open up dev tools and constantly console.log out values, but in a video (I assume) this will come up. These are two examples but they mostly they show you what you should focus on. There are dozens of little things that you won't pick up from text.

munchbunny 8y ago

For programming veterans who have at least some frontend experience and just want to pick up React (i.e. me) the React docs and scattered tutorials/stack overflow sites was sufficient. But I wouldn't remotely recommend this path for someone relatively new to programming.

k_vi 8y ago
I wouldn't remotely recommend react for someone relatively new to programming.
- pageandrew 8y ago
  Why not? It’s simple enough.
  - lsiunsuex 8y ago
    React itself is simple enough. To build a proper, functioning app, React is not enough. You need a dozen other packages to build even the most basic of data driven sites. I'm an experienced developer and I could not wrap my head around React with free tutorials. This tutorial uses React, Flux, blah blah blah. This other tutorial uses a whole different set of packages. It's not transferable. I need to build X. Show me a tutorial on how to build X. People give Angular 2+ a lot of crap but at least every.single.tutorial I've ever read on it are discussing the same basic set of tools and system. I pay for Pluralsight and while I've been focused on learning Angular from it, paid tutorials "generally" are much better quality then free ones IMO.
vmware505 8y ago
You can do the same with Ember.js also. There is a free detailed tutorial for absolute begginers. You build a full featured web app. It is so much fun: https://yoember.com https://yoember.com

doanguyen 8y ago

I would say we are all human. Some are lazy, some want shortcuts, some have difficulty in reading, all sort of things, that's why there are a lot of non-free React (framework X/ Library Y...) courses

oh-kumudo 8y ago

My thought exactly. They are more than enough resources to learn React... Literally everywhere...