Thursday, 17 October, 2019 UTC
Summary
Have you heard that old saying… “How do you eat an elephant?”
…
One bite at a time!
…
This article is off to a great start, I can tell.
But really, though: breaking up big problems into tiny bite-sized ones is the only way to really get anything done in this world.
It’s how I taught myself React, and it’s how I approach a lot of problems in software.
Rule #0: One thing at a time, if you can It’s a lot easier to learn a thing if you can isolate it.
For an instrument like the piano, that’d be “learn to play one note”, then “learn to play an easy chord, with one hand”. Then later, two hands.
That’s very different from saying “I’m gonna learn this complex song and play every note, hands together, from the very start.”
So when it comes to learning React (or any programming thing), try to make a checklist of the things you need to learn, and their dependencies, and then start at the bottom and work your way up.
Choosing to learn a whole cluster of skills simultaneously (e.g. build an app with React, having barely used JS before) is like playing the game on hard mode. You can do it, you absolutely can, but it’s probably gonna be harder.
I’m not trying to say “you MUST learn JS before touching React”. I don’t think it’s absolute like that. Everyone has a different set of experience coming in, and everything is a gradient.
You don’t need to be a Jedi Master at each of these skills before moving on to the next, either. Learn enough to where you feel a bit of confidence, then continue.
It’s a bit like juggling. Add one ball at a time. Soon you’ll be juggling the whole set.
Rule #1: Get it working, and keep it working Errors are the worst. Especially when you’re first learning a thing. They feel like a big setback and can be tough to diagnose.
So I try to avoid causing errors by making small, cautious changes. In React, this looked like writing a small simple “Hello World” component, and expanding on it, bit by bit.
I had gone through the official tutorial and I went forward with the assumption that React was “pretty much HTML inside functions”. (I already knew HTML well at this point, and I knew JavaScript, since I’d been working with AngularJS for a while.)
So I started with Hello World.
function HelloWorld() { return <div>Hello World!</div> } Then what if I try to render more stuff inside that div, does that work?
function HelloWorld() { return <div>Hello World! <p>More stuff and <strong>bolded</strong></p></div> } Cool, ok. Can I put it on multiple lines so it doesn’t look like a travesty?
function HelloWorld() { return ( <div> Hello World! <p> More stuff and <strong>bolded</strong>! </p> </div> ); } Yep, nice.
How about inserting the value of a variable with curly braces?
function HelloWorld() { const name = 'Dave' return <div>Hello {name}!</div> } Sweet, I can make it say “Hello Dave”.
Ok, now if I make a second component… and try to render that inside of HelloWorld?
function Name() { return <span>Dave</span> } function HelloWorld() { return <div>Hello <Name/></div> } Nice, I can nest components like HTML tags. Makes sense.
Let’s pass a “prop” into Name to tell it the name to display…
function Name({ name }) { return <span>{name}</span> } function HelloWorld() { return <div>Hello <Name name="Dave"/></div> } Hey that worked too!
…
I poked around like this, making small changes, seeing what was possible.
Personally I have more fun learning things when I treat it like a fun exploratory experiment. Can I do X? Oh nice. What about X+Y? Awesome. Pushing the bounds a little each time, and aiming for “tiny wins” along the way.
Rule #2: Cause errors on purpose You’ve gotta know what syntax is valid and what isn’t. To build up that intuition, it can be helpful to break the code on purpose, and learn where the boundaries are.
Can I put the JSX on a separate line from the return?
function HelloWorld() { return <div>Hello World</div> } Nope, that breaks. Right, because in JS
return<newline> is the same as return; and that returns undefined.Ok, what about a tag like
<br>… do I have to close it?function HelloWorld() { return <div>Hello <br> World</div> } Huh, that broke. Guess I have to close the br tag then. That’s different from HTML.
Ooh, does that mean I can write a self-closing div? I always hated having to write <div></div> in HTML…
function HelloWorld() { return <div>Hello <div/> World</div> } Nice! That’s awesome. Ok, so tags have to be closed, and they can all be self-closing.
…
This is similar to Rule 1, but here you’re testing the limits in the other direction. Intentionally causing errors, reading the errors, learning how they work.
This way the errors aren’t so scary, and they don’t catch you off guard. And because you’re making small changes, it’s easy to revert them back to a working state.
Plus, you’re building up an inventory of a bunch of different potential errors, so you’ll know how to fix them if you hit a snag when you’re building a real thing.
Rule #3: Start small, and build from there If Rule 1 was all about taking tiny risks that will almost definitely work, Rule 3 is more about the bigger risks.
If I can write HelloWorld, and I can nest components… could I design a whole page this way? (probably!)
After building a few small things, I had the idea of building a Slack clone.
This was a bit more risky. I had only used state a little bit, but building a chat app seemed like a good leap forward, so I gave it a shot.
I kept Rule 0 in mind - one thing at a time. I would focus on JUST the React app and use static data for chat messages. At first it was literally a static webpage that looked a lot like Slack.
Once that worked, I implemented “sending messages” by updating the app’s local state. There was no server in the picture yet, so I couldn’t actually CHAT with anyone, but it was fun because it felt like React was making sense.
And I started to run into the pain of “prop drilling”, so I looked into Redux as a solution.
Teach Others I was feeling pretty happy with React, and having a fun time building little things.
But looking around at forums, Twitter, Reddit… it seemed others weren’t faring so well. Lots of folks were having trouble getting started with React, often because of all the tooling (this was before Create React App existed), and then because of trying to learn everything at once.
So I started writing about React on my blog, and a while later wrote a book, Pure React. My goal was to teach React to others in the way that had worked for me: with one new thing at a time, small examples, and practice exercises to build confidence.
Almost 2,000 people have used Pure React at this point, and I now feel pretty safe saying “it works” :) I get a lot of happy emails from folks saying how React finally clicked for them, or that the book helped them “get it” in a way that a 35-hour course hadn’t. Emails like that make my day.
Over the last few months I’ve been working hard on expanding Pure React beyond just a book, and I’m almost ready to share it with the world. In about two weeks, on November 1, I’ll be opening the doors for early access.
Sign up below to hear when it’s ready and get an early access discount.
How I Learned React was originally published by Dave Ceddia at Dave Ceddia on October 17, 2019.
CodeProject