Sara Vieira - The Opinionated Guide To React

This book is not supposed to ever serve as a teaching mechanism for React, but more of a way to see React from the eyes of someone who has been using it for years and got sick of the "it depends".All I will show you here are things that either I use(d) or things developers I trust have used.

Also, opinions will be shared that you may agree with or not, but my objective with this book is to show the options and my point of view.

I hope you enjoy this book and have some fun writing web apps and making some amazing buttons.

I am never the best person to talk about myself, so I asked twitter, some of the answers were good, some bad and some just funny.

One of them was just amazing, and so it will be the one I use here:

It's my great honor to introduce you to my (spiritual) little sister, Sara Vieira. While I cannot paint a complete portrait of her in precious few words, I will attempt to highlight what I admire most about her.

Despite her insistence otherwise, she's one of the smartest people you are ever going to meet. Sara possesses a profoundly unique talent to take difficult or mundane topics and infuse them with clarity and humor. When you meet her, you cannot help but be inspired and delighted by her affable demeanor and sharp wit. Sara is a fierce advocate for the underrepresented, the undervalued, and those would otherwise lack the same opportunities as her. She speaks English better than most Americans (present company included.) And while Sara quick to make fun of her native Portugal, she's even quicker to tell you to **** off for disparaging her ptria. She's a rare and respected voice for mental health in the tech industry that advocates for mental health and inclusivity. During the day, Sara works at https://codesandbox.io where she's a Berlin-base frontend engineer. When not saving the world one clever meme at a time, Sara is a renowned public speaker, an accomplished conference organizer, and an amazing spouse to her wife.

And I'm lucky enough to call her my friend. I hope you enjoy her book; I know I will. You are supporting one of my favorite humans and doing yourself a huge favor by absorbing a bit of her wisdom. I hope you get to meet her some day; you too can see she's pretty indescribable.

Brian Holt

Senior Program Manager

Visual Studio Code & JavaScript on Azure

Microsoft

Probably not how to use React from the basics but a clearer picture of how bigger React apps work, a bit of the tools they use, the ups and downs, their structure, also some knowledge on how to use these tools yourself and a lot of hooks.We will start with some things like folder and name structure and then go into packages, starter kits and much more.

What I hope is not that you follow everything I say blindly but that you consider these options and these packages as something to make use of in the future, my hope is that by the end the React world becomes easier to navigate.

In this chapter, we will be talking about how I usually structure applications in terms of folder position, file exports, and some other small tidbits.

In apps and websites I have built with React, I tend to have a similar structure that seems to work and that looks like so:

In the core, I have four main folders:

• components - This is where components used by more than one page or module get placed. These things usually don't quite belong in a design system. One example could be a SaveButton: this will be an extension of the Button with some differences that will be used in a lot of places, but unlike the Button it doesn't quite belong in a design system.If no design system is in place, basically anything that's used by more than one page or component like an Alert should go here.

• pages- This is where your main pages will be. This folder will have an index.js, the place from which your routes file will import all the pages in your app. Usually, within a page you can have multiple sections like a hero. This hero component won't be used anywhere else, but it's a crucial part of this particular page. It should have both its own index.js and a styles file so we can put this in a separate folder to minimize the size of our files, while also making it easier to find things.

• assets - The assets folder will contain all your images and icons. I usually have both, so I find it easier to divide the folders: most of the time, my icons will be in SVG, and these get translated into JSX, so end up also being JavaScript files at their core. I did that so many times in random websites I even made a desktop application for it that you can download at svg-jsx.netlify.com and a Figma plugin to do the exact same thing and if you use Figma the plugin can be found in the figma community

• utils - This is where your overly complicated functions go. Making a utils folder is kind of like hiding the shame, but in a calculated way. Let's say you need to transform dates in a component, and it's a pretty heavy function. In my opinion, this should be its file, maybe generalized to dates so it can export several functions for date manipulation - trust me, there will always be date manipulation.In this folder, I would also include any hooks you may create for this particular project.

This structure assumes I don't have a global state management solution, and in case I do, there are usually two options: Using just context and using Overmind(we will get into overmind later).

In case I am only using context, I would have a folder like:

The idea is to separate your concerns and make each different context it's own file so you can easily change any of them and they are isolated.

I will not go through Overmind because it won't make much sense until we talk about it. Trust me it's great! It powers all of CodeSandbox.

I always try to name my files index.js and let the folder name do the talking. This will allow me to have more freedom in the composition of that component or page, as more files may be added, and that way they all stay concise in that folder. So I may have something like:

Even though it's the index file, the way module resolution works in JavaScript is that you don't need to specify index.js so you can just import like you would a file:

This will look for the file Alert.js, and then if it doesn't find that it looks for the folder and an index file within it, so don't worry about more typing.

Let's say this Alert component is weirdly complicated for an alert; it can also have components of itself. In many cases I see myself having a components folder inside a component like so:

As everything in this book it's a preference I have, smaller files over less folders.

For many years, I used the good old export default