In early 2016, I got so fatigued while trying to learn React that I almost gave up on being a developer. Impostor syndrome consumed me. Now, I am a full-time React developer and author of React.js for the Visual Learner.
How did I overcome impostor syndrome and finally learn React? There are a few reasons but one of the most significant ones was learning how to make pure CSS images.
Sinking Into Impostor Syndrome
In December of 2015, I graduated with a degree in Computer Science and wasn’t quite sure what in the world of development to focus on. After some exposure to entrepreneurial podcasts, I was fascinated by the fresh aroma of startups that had created revenue streams by making web applications. For that reason, I finally set a goal for myself to become a web developer.
As I researched modern web development, I realized that it was totally different than what I was taught in my formal education. My brief knowledge of HTML, CSS, JavaScript, and PHP looked totally different than all of these JavaScript frameworks that people were talking about. I saw a lot of buzz around React and decided to give it a shot.
Here’s a made-up conversation with myself that is accurate to the struggles I was experiencing in this pursuit:
Online Resources: React is what you want to focus on for creating user interfaces for modern web applications.
Me: Sounds great! What do I need to do to start a new React project?
Online Resources: Yeah. We can initialize our project with npm. Then, we just need to install and configure Webpack and Babel so we can write in ES6 instead of ES5. Then, we can install React and ReactDOM so we can start coding with React.
Me: Um. What’s ES6? Why do we need to use Webpack and Babel? Also, React and ReactDOM to use React? Is that a typo?
Online Resources: ES6 is a newer release of ECMAScript. It’s not well implemented in browsers but has some cool features that we can use. Babel processes the ES6 code and makes it compatible with browsers that support ES5. We can use Webpack to bundle our code and apply Babel. React is one library but you need to also include the ReactDOM library to make things work.
Me: _ECMAScrip_t? I thought we were talking about JavaScript. I’m not sure what bundling your code refers to. You know…this seems like a lot of work just to get started. What’s the benefit of React after all?
Online Resources: You can construct a user interface out of components that encapsulate JSX and data. It’s really modular.
Me: JSX?
Online Resources: Yeah it’s just JavaScript syntax for defining what you want your component to ultimately render as. It looks a lot like HTML…just use className instead of class.
Me: That kinda makes sense. Let’s carry on then.
Online Resources: Sweet. Let’s start by me showing you the code for a Hello World component.
Me: Looks kinda awkward at first but these components do seem like a cool concept. I mean that Hello World component wasn’t bad at all.
Online Resources: Great! I know you seemed a bit confused about creating a new React project. Don’t worry. There’s an awesome starter kit on GitHub that comes loaded with Webpack, Babel, and Webpack Dev Server. Go ahead and clone it.
Me: Woah. I have no idea what half of this code does. However, these components look familiar. I get the basic components, but why is their nesting of components going on?
Online Resources: Oh! That’s just because we can break up a view of a user interface into parent and child components. Then, we can pass data down between them.
Me: But there’s way more than a parent and child! There’s like a great great grandparent and great great grandchildren and the whole ancestral line in-between. What gives?
Me: You know what…don’t answer that. React is popular so it must be simple. I’m probably just dumb for asking so many questions. Clearly, I’m not fit to be a developer. I’ll give up on this attempt to learn modern web development.
The point of this made-up conversation is to highlight the struggle that a beginner to React can go through. In particular, one of the main struggles is understanding the concept of components. Unfortunately, there can be a lot of fatigue before you even get to that issue. At that point, there needs to be a super practical explanation and not something that just throws out more buzz words.
I truly believe that I accidentally discovered a wonderful way to explain React components after messing around with pure CSS images.
It’s a really good story. Grab a drink if you want.
Discovering Pure CSS Images
As I was trying to learn React, I had taken a job as an IT Support Specialist. After my first day when I had to screw in light bulbs on the third floor, I knew I couldn’t wait to get out.
One day, I had to make a flyer for a broken printer or a broken door (you know since IT and maintenance are the same thing). I came across a vector graphic tool called Inkscape which I used to make the flyer. I had never been exposed to vector graphics but found it delightful to create shapes, manipulate shapes, and color shapes in order to make a final graphic.
In order to burn some built up frustration in my IT role, I decided to play with Inkscape for an hour during my lunch breaks. I eventually discovered Dribbble (show and tell for designers) and Affinity Designer (an awesome upgrade to Inkscape) which fueled me to work even more with vector graphics.
The more practice I got with vector graphics, the more I realized that the key to success was to look at a final graphic, break it down into smaller shapes, create those smaller shapes, and apply good colors.
I started to get really good. With this newly found confidence, I decided to give web development another shot.
Before I got into React, I came across Codepen which I loved because it was like Dribbble for frontend developers. I kept checking their homepage to see all the cool things people were making. One of the things that caught my attention was pure CSS images. I thought to myself: “Woah! These are just like the vector graphics I’ve been making but they replace Affinity Designer with CSS!”
I eventually learned how to make pure CSS images and got good with them.
Zelda | A Link to the Past | Pure CSS
The workflow was just like with making vector graphics.
- I would either look at an existing graphic that I wanted to recreate. Or, I would imagine a final graphic using Dribbble as inspiration.
- I would break that graphic down into smaller components that I needed to create.
- I’d create those shapes using CSS and position them in the appropriate place.
- I’d use Dribbble, Coolors, and/or Colorzilla to get colors.
Step 2 in the list above was really the most difficult part. As I made more complex graphics, the more I realized that I had to have a better definition for components that would explain their hierarchy.
Understanding Component Hierarchy
What do I mean by explaining the hierarchy of components in a pure CSS image? Well, let’s look at an example.
Take a look at this vector graphic of a koala that I made:
Now, if I asked you to tell me what components make up this koala, there are two possible answers I suspect you would give.
On on hand, you could say that the koala’s components are ears, eyes, a nose, a head, and hair.
On the other hand, you could be even more specific and say that the koala’s components are 3 light gray circles, 2 dark gray circles, 2 white circles, 2 navy blue circles, a brown rounded rectangle, and two light gray triangles.
Both of these answers aren’t wrong. The former explanation is broader and categorized while the latter explanation is very precise and particular.
What this shows is that there is a hierarchy when it comes to describing components of pure CSS images.
A more complex pure CSS image, like the Zelda dungeon show below, would have even more levels to a component hierarchy.
While pure CSS images may look incredibly difficult, it becomes quite easy if you can look at a graphic you want to create and break it down into it’s smallest pieces then work your way up the component hierarchy.
Using the Koala shown above as an example, we could break it down into its individual shapes and then combine some of those shapes to form the more complex body parts (i.e. an eye and ear).
The individual shapes are the lowest level of the component hierarchy and the next level up is the body parts where some contain multiple shapes. If you put all the body parts together, you form the final koala graphic.
To summarize, the ability to break down a final graphic that I wanted to create into an organized component hierarchy greatly simplified the process. I could start at the bottom of the component hierarchy and work my way up. The final graphic could be put together piece by piece.
Flash forward to when I got back into learning React, the benefits of React being component-based now made perfect sense. However, I found the explanations of the hierarchy/organization of components to be very impractical (even though I now understood what they were trying to get at).
For this reason, I’ve developed a way of explaining the hierarchy of React components, which I call React Village Design.
React Village Design
I will be making the comparison between the hierarchy of components in a React application and the hierarchy of a village/town.
There are 4 major levels of a village hierarchy (going from broadest to most specific):
- Village
- Neighborhoods
- Blocks
- Houses
Village
Let’s start with village since it is the easiest to grasp.
A village is the equivalent of a view such as a home page.
This is the broadest part of a village hierarchy. Now, what if I asked you to tell me the components that make up a village?
Just like our koala, there are different ways in which we could describe this.
Houses
Let’s start at the most specific level (the lowest level of the hierarchy). At the most basic level, we could say that a village is a collection of houses. Houses are the building blocks of a village.
In a similar way, houses can be used to describe the building blocks of a view. They cannot be broken down any further.
In our koala example, a dark gray circle is a house.
In the example of the Airtable home page show below, the title, paragraph, sign up button are examples of houses that make up the view.
Blocks
At the next level of the village hierarchy is blocks.
Blocks are a collection of houses. So in a broader sense, we could say a village is a collection of blocks.
In our koala example, we could say that the eyes are an example of a block:
Eye Block
The eyes are the next level up above the houses which contain a white circle and a navy blue circle. While we can categorize the eyes into a block, they do not form a final image on their own.
Blocks in a user interface are collections of houses that work together to form a specific functionality/purpose to the view. However, like our eyes in the Koala, they can’t stand on their own.
For example, the following title, paragraph, input form, and button in the Airtable home page are working together to get a visitor to “opt-in”.
For this reason, we can call it a block made up of individual houses. Or, an opt-in section made up of a title, paragraph, input form, and button. Again, it cannot stand on its own as a view.
Neighborhoods
In our village hierarchy, we could go another level up and describe a village as a collection of neighborhoods.
A neighborhood is a collection of blocks. In terms of a user interface, I like to think of neighborhoods as the sections of the interface.
For example, this is the header of the Airtable home page which is a neighborhood:
This header neighborhood is a collection of three blocks. There is the navigation bar at the top. Then, we have the video and the surrounding pattern forming another block on the left. On the right, we have the opt-in block which we previously described. These blocks form our header section, or again, our header neighborhood. All of the blocks in this neighborhood can be broken down into houses (i.e. Sign up button).
Let’s go from the top of the Airtable site and point out the different neighborhoods.
At the top, we have the H_eader_ neighborhood:
Next, we have a content section neighborhood. Let’s call this Content Section A:
Content Section A Neighborhood
There is another content section neighborhood which we can call Content Section B:
Content Section B Neighborhood
We then have a neighborhood for testimonials which can call Content Section C.
Content Section C Neighborhood
Following that, there is another neighborhood which we can call Content Section D:
Content Section D
Note: I’ve highlighted the graphic above in green so you can see that it is a section despite only possessing one block which we described earlier as the opt-in block.
Lastly, there is a Footer neighborhood:
Footer Neighborhood
If you put all these neighborhoods together, we have a village (or a view).
Once you have broken down a user interface, you can create the React components for each one at a time. Like I discovered with pure CSS images, this greatly simplifies what can seem to be quite overwhelming from a bird’s eye view.
Concluding Thoughts
I acknowledge that React Village Design is not always going to be a perfect analogy. However, I think it serves its purpose to communicate the idea that with React we can create user interfaces consisting of views that contain a hierarchy of components. Like pure CSS images, there is a tremendous value to be able to create things piece by piece. This is where React shines.
Hopefully, you can better understand React components and why React components are helpful.
As I alluded to earlier, there are multiple reasons why React can be challenging for a beginner. If you enjoyed this post, you will certainly enjoy a new ebook I created called React.js for the Visual Learner. In this ebook, I teach the absolute basics of React.js through design principles, visual-friendly examples, and super practical teaching methodologies like I have done in this post.
You can [read it for free or pay to support me](http://absolute basics of React.js through design principles, visual-friendly examples, and super practical teaching methodologies.) to create more content.
Cheers,Mike MangialardiFounder of Coding Artist