I'm always surprised that reading source code is such a rare occurrence or suggestion in this world. If you consider yourself even in the vicinity of "advanced", I think you're capable of learning great stuff by looking at anything on github. Something big, but well organized. Lo-dash, Node, Mocha, etc.
Of course you won't understand everything on first read. But you will learn really good things if you know how to look at something confusing and identify what it is you don't understand; then you can go find didactic materials to fill in the gaps.
This is an amazing way to learn. You get to see how some of the most used, or cutting-edge tools are implemented (for free!). You learn about the tools themselves and thus gain expertise in them. And, you gain the meta-skill of working in unfamiliar territory, which I think is a fundamental key to being considered "advanced".
Totally fine, so long as you know that makes you an "advanced user".
I can't imagine you'll find a sane place to work where senior people are only capable of learning something after consuming a tutorial or a manual. The nature of the work is to drill down one layer below what you're working on. Do you need to know how to smelt steel in order to be a good car mechanic? No, of course not, but it sure helps to have taken an engine apart. And if you're trying to build the next, better engine, it's really great to see the internals (and the commented motivations!) of previous implementations.
Kyle Simpson and the "You Don't Know JS" series. Can't speak highly enough about them.
Also he has a good recent book on Functional Programming, which if you plan on tackling Redux later will be helpful.
I got the physical editions because that's how I prefer books (easier to note / annotate), but all the books mentioned here are available free online / on Simpson's Github.
The Road to learn React [0] is an open source book that gets continuously improved because it was self-published and the community contributes as well. You will build a React.js application along the way and transition smoothly from JavaScript ES5 to JavaScript ES6. It teaches the fundamentals of React without any tooling or Redux. Afterward, you are ready to go to build your own React applications. I would love to get your feedback on the book! :)
Otherwise, I can recommend to checkout this repository [1] by Mark Erikson to find out more about React and its ecosystem. I am sure you will find plenty of starter tutorials to get into learning React.
I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics. It includes links for learning core Javascript (ES5), modern Javascript (ES6+), React, Redux, and much more.
Finally, the Reactiflux chat channels on Discord are a great place to hang out, ask questions, and learn. The invite link is at https://www.reactiflux.com .
I know these are great resources, but I don't think redux should be taught with react. Most of the React projects I've seen using Redux didn't need it - all they needed was for their developers to have a deeper understanding of how React handles state.
Learn React first. When you have complex data management problems, consider learning Redux, but master Reacts own state management first.
Trust me, I agree. In fact, my standard copy-paste "advice on learning React" includes:
> Definitely don't over-complicate the learning process by trying to learn many different things at once. Some people will say you should use a "boilerplate" to learn React, and they're wrong - boilerplate projects almost always come with too many pieces configured, and are confusing for beginners.
> Instead, the best advice is to focus on learning React itself first. Once you have a good understanding of how React works, you will better appreciate why a state management library like Redux can be useful, and you can learn about other tools later.
That said, my rough estimates are that around 55-60% of React apps are using Redux, and it's also frequently used with Angular, Ember, and Vue, albeit sometimes in different forms (ngrx/store, vuex, etc). So, while I totally agree that most people should not try to learn Redux right away, it _is_ a very relevant topic to cover.
Which reminds me, if you can get an employer to pay for an Egghead subscription and/or a Frontend Masters subscription as part of a training budget, both are great. Also probably worth buying on your own if work won't cover it.
I'm improving my JS skills by learning how to read and understand the source code of mithril.js.org (I'm doing write ups at: https://gist.github.com/CarlMungazi).
It's what we use internally at work so it made sense for me to actually understand how it uses JS to tackle all the problems a framework is supposed to solve. I've only been doing it a short while but I've learnt a ton already.
I casually glanced at the source for Ember and React over the weekend and I could understand much better what was going on because I had a reference point based upon the source as opposed to just knowing the APIs.
I'm working my way through these and love them. I'd bought books and followed tutorials so I'd completed 3-4 "hello world" apps. With Stephen's videos, I thought, "oh, great, another hello world" but the way he explains things, sudden I understand what it all actually meant instead of just bashing together code and hoping it worked.
I would say pair programming with others and reading code as a group together is the best way to level up. While reading open source projects will fill in some knowledge gaps and teach you to write cleaner code. You may miss the subtle aspects that makes the code one step better then others. When I pair program with seniors I get to see how they come at a problem, make design decisions, and find out why they do something some way. Pairing with a less senior developer causes you to reflect on yourself. If you can't explain something to someone else in simple terms then you might need to revisit that idea. Also a good way to remind yourself how much you have grown as a developer, and how much farther you still need to go. Pair programming in a group is a great for a team to understand how each other thinks. It also confirms styling techniques for the code base and also allows people to fill in random knowledge gaps they may not know they have. Finally it has been proven over and over again the more a team communicates with one another the better they work as a team even though our codes and docs suppose to be the best way to convey our thoughts to other programmers. Spending some time every day talking and working together is the fastest path to bring entry level and junior level developers to a senior level.
The idea is to get a small dose of React every day.
I'm also always looking for what else to include in the course - so I'd love to hear what you find most difficult, or what you think is lacking from current learning resources.
React-Redux complements React in some great ways. It has been my state storage of choice from the beginning. IMO, it would be better to start react with it rather than changing habits later. The go-to tutorial series is here: https://egghead.io/courses/getting-started-with-redux
And definitely use typescript if you value good code quality (and your sanity). The advanced type system and compile time type checking is really a boon to the JS ecosystem. https://www.typescriptlang.org
Most popular libraries these days either include their own typescript definitions, or the definitions are available vie @types (it is as easy as npm install --save-dev @types/library-name)
If on the off chance that no typings are available, you just write a simple namespace declaration (usually a one liner) and start using the library right away, albeit without smart code sensing / completion. See https://stackoverflow.com/questions/22842389/how-to-import-a...
React is full of declarative code. Something I'd recommend whole-heartedly is Michael Fogus' Functional Javascript book. It shares a lot in common with POODR in that it's conscious of why functional techniques are useful and how to think in a data-oriented way. The book is self-aware of the beginner's mindset in absorbing that information and is very well-layered.
Personally, I feel the best way to learn is by experience and by exposure. By seeing similar code in different contexts, you can learn why React programs tend to rely on certain patterns. To that end, working through something like How To Design Worlds (http://world.cs.brown.edu/1/) or the Elm guide (https://guide.elm-lang.org/) will give you points of comparison that will help you better articulate what you decide to do in React.
If you want to get good at JavaScript, do learn about closures and lexical scope. Example assignment: Make a function that loads a list of images and then show the average width of the images. Then make three versions of the function, one that loads the images in serial, one that loads the images in parallel and one that loads max three images at a time.
A number of people have mentioned Dan Abramov's Redux tutorials on Egghead, which I recently went through and got a lot out of. As a supplement/alternative I also found this series of LearnCode tutorials (https://www.youtube.com/watch?v=1w-oQ-i1XB8&index=1&list=PLo...) to be really useful and informative. Where Abramov's series was great for seeing how to start with the most simple integration of Redux and building up to an advanced one, these start out advanced, allowing it to cover a few more topics (like middleware). Just figured I'd throw that in.
Shameless plug: I did a free open source video series called "Building products with javascript" [1] that covers building CRUD webapp using javascript (including es6+), node, express, react, redux, rxjs and all that kind of stuff.
Will be happy to answer any questions :)
I just spoke @ JSChannel 2017 & published a book on this very topic (https://github.com/FarhadG/ui-react). It has reached the weekly best seller's list, so I hope it can be of some use for your goals.
This course (offered at my University) has some good material on React, not to mention the fact that you can even download the starter code for the assignments and work through it.
It seems everyone is recommending books/courses/similar. I'll go the other way around. This is difficult for me to say, but I think I am an expert in CSS+JS. I know the inner workings and really advanced things of CSS, and while JS API is quite broader I know some in-depth JS APIs that your average developer doesn't even know exists.
I got to this point first in CSS and then with JS by making side projects and focus each one on a different advanced concept. I will also say it in 1st person as I experienced it as it might sound insulting otherwise:
- Don't get attached to my code. My code is crap. My 6+ months old code is a lot more crap. Always think ways of improving it. Sidenote: try to make it as standard of possible. Initially I did things my way until my open source started to get some traction and it was a mess.
- Once I got past the basics and mid-level, what I did to keep up learning was to try to focus each small side project around a technology I wanted to learn in-depth. Examples: Umbrella JS[1] is about a modular codebase, Superdom [2] is about Proxy, drive-db [3] is about talking with external APIs and DB design, etc.
- Push the limits on the technology on each project. Don't just do the basics and call it a day, try to find what is possible and what is not. Examples: Umbrella JS'[1] performance is similar to jQuery thanks to using the prototype properly, Superdom's [2] Proxies are recursive-ly, drive-db [3] is cached for maximum performance, etc.
- If I don't use it no one will. Publish it for feedback after it is polished from feedback from different projects. Focus on the positive comments to keep going and on the negative ones to keep improving. Because I know my code is crap, when someone says X is quite bad I agree on principle and find a way to fix it or prove to myself that it _was_ the right approach. Examples: Umbrella JS initial code wasn't good for the different ways of importing it, so I added a UMD-ish kind of thing. Superdom was really buggy so I had to write a few tests all around it. drive-db was not good for promises-based code so I converted it to ES7.
There is something I haven't made which I am trying now that it's reading and understanding large, public projects such as Ghost. I have done something similar while contracting, but those closed-source project's code is IMHO generally messier and you are normally trying to go for business requirements, not really focusing on pleasure/learning so much.
Of course you won't understand everything on first read. But you will learn really good things if you know how to look at something confusing and identify what it is you don't understand; then you can go find didactic materials to fill in the gaps.
This is an amazing way to learn. You get to see how some of the most used, or cutting-edge tools are implemented (for free!). You learn about the tools themselves and thus gain expertise in them. And, you gain the meta-skill of working in unfamiliar territory, which I think is a fundamental key to being considered "advanced".