Show HN: Fullstack React: The Complete Book on ReactJS and Friends
fullstackreact.com
fullstackreact.com
I've been here at HN long enough to know that a few of you might take issue at our pitch of learning React "The Right Way". Obviously there are many, many opinions on how to write React apps and there are many good ways to approach React.
But I think a large part of so-called Javascript fatigue comes from the fear of being wrong.
Because React is so modular there are tons of different modules for every idea. "Awesome" lists are egalitarian and often put libraries of vastly different popularity and stability right next to each other. In most cases the community has already gathered behind one or two libraries, but it takes a lot of research to figure out which one (and it's especially hard if you're a beginner).
What we're offering here is a well-researched, coherent, code-packed resource. We'll tell you which libraries to use and how to use them and you won't have to piece together hundreds of blog posts. We've kept our books on Angular up-to-date for years now and we're planning on doing the same for this React book.
I have one problem though:
Why do you only introduce unit tests in part 12 out of 13? When I "Imagine how quickly I can get all of your work done with the right tools and best practices", it involves me being able to write solid automated tests for everything. Not only that, but if you introduce the proper way to set up testing early and carry it through the rest of the book, it helps the student keep themselves on track. When they get stuck, having a failing test helps them focus and have a clearer idea of how to move forward.
I strenuously urge you to introduce testing earlier.
That chapter will be an in-depth guide to unit testing React generally, but we'll introduce testing some of the example code in other chapters earlier in the book.