Learn React for free (opens in new tab)

I wouldn't remotely recommend react for someone relatively new to programming.

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

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.

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.

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

[1] http://blog.isquaredsoftware.com/2017/12/blogged-answers-lea...

[2] https://blog.isquaredsoftware.com/2018/06/redux-fundamentals...

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) 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)
    });

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!

But how, how? I wouldn't be able to bring myself to say something that I knew to be strictly inaccurate. Even if you are talking to beginners, don't you owe it to them to say only things that you believe to be true? There are lots of ways to put it differently so that it wouldn't be so outrageously inaccurate and so that, if you are a beginner, more senior developers don't laugh at you if you repeat those things.

I find this ^^ to be one of the main selling points. All online courses are in danger of falling into the "Tutorial Hell" category, where they spend all their time teaching you without the student actually being more capable afterword. The Scrimba platform significantly lowers the barrier for students to get their hands on the code and actually obtain new skills. I have yet to find another platform that lowers that barrier as efficiently/well as Scrimba.

Thank you for the information. I am however not an investor but a developer. When 'a free tutorial' is advertised i am always afraid i'll be forced into later payments or becoming the product myself, especially when professional investors are willing to support the company financially.

Giving information on your website about the user do's and don'ts are always appreciated without having to file a request in triplet to the board of directors. Still I highly appreciate the links to the company information.