How to learn React Native (and have fun)

There are many ways to learn new things, and having dedicated time to do it is an opportunity.

At Cantiere Creativo, we invest part of our working hours in training in several ways: courses, pairing between colleagues, code reviews.

But also on our own, experimenting with new technologies and unexplored topics.

Recently, I had the chance to tackle React Native on my own.

I had already used this framework, contributing small parts to a few projects, but I had never tried creating a new project by myself.

For a first approach, it's always best to start with a modest project so you don't get lost in the logic of something too complex.

A bigger project has to stay flexible, so it definitely requires well-organized content, careful attention to how it's built and readable code that stays maintainable.

In a small project with a few simple features, you can proceed step by step and, once it reaches a certain complexity and there's room to optimize, you don't need to overhaul too much.

This gives you the chance to really understand the basic logic and how responsibilities are assigned to individual components.

And that's what I did: I started with the smallest element, studied its requirements and the logic needed to build it, then moved on to the higher-level component that would include the first.

But already at this point I found myself wondering who should be responsible for managing the "state": which one owns it? The first or the second?

Through several refactors, I was able to understand how to optimize my code with just two fairly small components.

I'm sure that with time and some experience, these processes, slow for now, will become faster and more natural in the way I build, so I can invest more time in the overall vision of the project.

This was the method I tried to apply while building my first app, called Figu!

The typical beginner "exercise" is the classic TODO app, which in its simplicity covers all the basics: creating, reading, updating and deleting data, known as CRUD (Create, Read, Update and Delete).

I decided to give it a different spin and change the path slightly by creating a sticker album manager instead.

So I started by creating the first component: the single sticker.

It might seem like the simplest piece, but it actually captures most of my app's purpose: showing whether I've already found that "number" and how many copies I have.

The parent component, then, is the Album, the sticker binder: the truly essential element, to which I decided to assign the state management of all the stickers.

Just to make these two components interact, I made several optimizations over multiple sessions to get the best possible result with clean code.

I thought a summary of how much is left to complete my collection would come in handy, shown as a percentage and a progress bar.

Then a panel showing how many stickers I've found, how many I'm missing and how many "duplicates" there are.

Why not share it all with friends? I added a button for sharing individual subgroups.

The last cog in this machine is the system for creating an album with a name and number of stickers.

A simple modal that opens when you click the dedicated button on the main screen.

Finally, when the app opens, it shows a list of all my albums, with links to their details and the option to delete them from the list.

So my app boils down to two simple "pages": a list and a detail view.

In React (or React Native, as in this case), passing "properties" from one component to another is everyday business, so I wouldn't have had much trouble getting all of an album's details across my 4-5 components through "props", even if it's a bit clunky.

But since I'm focusing on learning, why not dig deeper into managing an application's state?

When I started studying React, I always heard it mentioned together with Redux (a well-known library created for exactly this purpose): I confess it intimidated me a bit from the start, just at the thought of having to manage at least three files.

I probably wasn't the only one to feel this way, to the point that Context has become increasingly popular.

Context provides a way to share information between components without having to pass props through every level of the tree, simply (and manageable even in a single file). It's mainly used when data needs to be accessible to many components, even deeply nested ones.

src/MyContext.js

In practice, the createContext function creates an initial state that can be accessed from the files where it's used, thanks to the corresponding Context.Provider.

The Provider is used to "wrap" the components that will use that state, whether that's just a small group or every component in our application.

src/App.js

This way, both the <Main /> and <Sidebar> components will have access to the {theme} value we make available.

You can create several different contexts to share a centralized state specific to the components included in each Provider.

I believe this was the right path for my exercise, knowing that even if my app were to scale, I could keep using Context without any problems.

After all, I'm in a learning phase, and as Dan Abramov says in the article "You Might Not Need Redux":

And who am I to contradict its creator?!

It may seem obvious, but you might think that in a small project you can write code without paying attention to form, just "making it work".

Nothing could be more wrong!

I tried to pay attention to how I wrote my code, but a check to see whether I had kept to the necessary standards was a must.

Once I added a linter to flag the errors to fix, I found myself having to fix about 800 errors and warnings.

Admittedly, most of them were minor, but as I've said all along, these are details you shouldn't overlook.

The upside is that I learned two key things: first, in my next project I'll run this check from the start to keep an eye on my code right away; second, and just as important, all the fixes I made, which I hope to remember while I write.

After this review, I had the chance to do a code review with our CTO, to whom I explained my intent and with whom I went over some parts of the logic I'd applied.

Our CTO also suggested other best practices to apply and keep in mind to ensure quality. So when I work on even small parts of a large project, the rest of the team will know the section I built meets the quality bar.

You can see Figu in action in this short video, if you're curious!

To get the satisfaction of completing a big project, it's worth remembering all the small parts it's made of. Taking care of each one, with attention to detail, is key to the success of the end result, and an opportunity to improve your skills and gain greater awareness.

Even the longest journey is made of many small steps.