Something similar to "Practical Object-Oriented Design in Ruby"
Right now I'm a junior/mid js developer, but I want improve my skills/code/tests etc...
Any help is welcome.
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".
I don't break apart an engine to figure out how to use it, I read the manual about inputs and outputs.
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.
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.
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.
In addition, my "Practical Redux" tutorial series ( http://blog.isquaredsoftware.com/series/practical-redux) shows how to use a variety of intermediate to advanced React and Redux techniques in the context of a sample app, and my "Idiomatic Redux" series (http://blog.isquaredsoftware.com/series/idiomatic-redux ) discusses important aspects of good Redux usage, including why common patterns exist.
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 .
Learn React first. When you have complex data management problems, consider learning Redux, but master Reacts own state management first.
> 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.
It is how I finally grokked JS and it is the same tutorial that I put all new additions to my team through...
https://drboolean.gitbooks.io/mostly-adequate-guide/content/
And the related video series on Egghead (which I think requires a subscription)
https://egghead.io/courses/professor-frisby-introduces-compo...
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.
A dedicated section for React can be found here: https://scrimba.com/topic-react
And here is a playlist which takes you through building your first React app: https://scrimba.com/playlist/playlist-1
It's based upon an article I wrote here: https://scrimba.com/playlist/playlist-1
It's all free. Hope it helps!
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.
https://learn-anything.xyz/programming/programming-languages...
And here is one for learning React :
https://learn-anything.xyz/web-development/javascript-librar...
Both maps are community curated so if anyone thinks there is a more efficient path for learning them, you can submit pull requests. :)
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.
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
You'd like to get comfortable with the latest tools that compile, transpile and pack the code for you (you might be familiar with that already.) Here might be a good start: https://medium.com/@fay_jai/getting-started-with-reactjs-typ...
Have fun!
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...
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.
http://shop.oreilly.com/product/9780596517748.do
Very useful day-to-day and first place I go:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
There are gaps/things that have changed since the book came out, but this is a really great resource for understanding the core JS language.
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.
http://www.mattgreer.org/articles/react-internals-part-one-b...
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.
