React Naming Conventions You should follow as a Junior Developer - clean-code

Summary

This video script offers essential React naming conventions for developers, focusing on clean, readable, and maintainable code. It covers directory and file structure, naming for pages, components, hooks, variables, and more. The script emphasizes using PascalCase for pages and components, camelCase for files and variables, and underscores for constants. It also advises on descriptive function and hook names, and leveraging linters to enforce consistent naming conventions, ensuring a harmonious codebase for team collaboration.

Takeaways

• 📂 The script emphasizes the importance of a well-structured directory for React projects, with main folders like 'src', 'public', and specific files for configurations.
• 🔍 Inside the 'src' folder, there should be organized sub-folders such as 'assets', 'pages', 'components', 'hooks', 'services', 'store', 'typings', and 'utils' for better code maintenance and readability.
• 📝 For 'pages', use PascalCase for folder and file names to highlight their importance as the main entry points of the application.
• 📦 Components should be reusable and kept in their respective folders, with an 'index' file as the main entry point for each component.
• 🔑 Hooks should be named descriptively and prefixed with 'use' to indicate their purpose and to follow React's naming convention.
• 🛠 Functions and variables should have descriptive names to convey their functionality at a glance, using camelCase for file names and variables outside of the 'pages' folder.
• 📈 For props, use PascalCase and define them using interfaces for clarity and reusability across components.
• 📝 When naming interfaces or types, avoid starting with an 'I' prefix as it is no longer necessary with TypeScript, and use PascalCase instead.
• 🔠 Constants or global variables should be in ALL_UPPERCASE with underscores to indicate their unchanging nature.
• 👮‍♂️ Use linters with specific rules like 'camelcase' and 'typescript-eslint' to enforce naming conventions and maintain code quality.
• 🔄 The script suggests that following these naming conventions contributes to cleaner, more readable, and maintainable React code.

Q & A

What are the essential React naming conventions discussed in the video?

The video discusses several React naming conventions, including using PascalCase for pages and components, camelCase for file names and variables, and specific hooks naming with 'use' prefix. It also covers the structure of folders and files within a React project.

Why is the 'src' folder important in a React project?

The 'src' folder is important as it contains all the source code for the application. It is the main directory where developers write and organize their code.

What is the purpose of the 'public' folder in a React project?

The 'public' folder contains assets that are publicly available throughout the web server, such as images, fonts, and other static files that can be accessed by users or other websites.

What are the main folders typically found inside the 'src' directory of a React project?

The main folders inside the 'src' directory include 'assets', 'pages', 'components', 'hooks', 'services', 'store', 'typings', and 'utils'.

Why should pages be named using PascalCase in a React project?

Pages should be named using PascalCase because they are very important and serve as the main entry points for the application. PascalCase makes it clear and easy for developers to identify these key files.

What is the recommended naming convention for file names outside the 'pages' folder?

For file names outside the 'pages' folder, camelCase is recommended as it is easier to read and write, and it is the conventional standard in JavaScript and React projects.

How should components be organized within a React project?

Components should be organized in folders, with each folder representing a single component. Inside each component folder, there can be multiple files related to that component, including an 'index' file that serves as the main entry point.

What is the naming convention for functions in a React project?

Functions should be named using camelCase and should be descriptive to indicate their purpose. For example, 'calculateTotalWithVat' clearly indicates that the function calculates a total including VAT.

Why is it important to use interfaces for props in a React component?

Using interfaces for props is important because it enforces a contract for the data that components expect to receive, making the code more maintainable and less prone to errors.

What is the recommended naming convention for TypeScript interfaces?

TypeScript interfaces should be named using PascalCase, without the traditional 'I' prefix, as it is no longer necessary and can make the interface name too specific.

How can a linter help enforce good naming conventions in a React project?

A linter can enforce good naming conventions by setting rules that check for correct case usage, such as camelCase for variables and PascalCase for interfaces and components. It can prevent code from being committed if it does not adhere to these standards.

Outlines

00:00

📂 Essential React Naming Conventions and Project Structure

This paragraph introduces the importance of adhering to essential React naming conventions for cleaner, more readable, and maintainable code. It covers the standard project structure, including the SRC folder for source code, public folder for assets, and key files like index.html. The SRC folder is emphasized with its main components: assets, pages, components, hooks, services, store, types, and utils. Each component's role within the project is briefly explained, setting the stage for further discussion on naming conventions.

05:01

📝 React Component and File Naming Conventions

The second paragraph delves into the specifics of naming conventions for React components, files, and other elements. It advocates for PascalCase for pages and components to signify their importance and as a convention among developers. The paragraph also discusses the organization of components within folders, the use of interfaces for props, and the importance of descriptive function names. It highlights the use of camelCase for file names outside the pages folder and underscores the significance of using linters to enforce consistent naming conventions across a project.

10:02

🔍 Advanced Naming Conventions for Hooks, Interfaces, and Constants

The final paragraph focuses on advanced naming conventions for hooks, TypeScript interfaces, and constants within a React project. It explains the React Hook naming convention, which requires the 'use' prefix followed by camelCase for clarity and consistency. For TypeScript interfaces, it advises against starting with an 'I' prefix, instead suggesting more descriptive names using PascalCase. The paragraph also touches on the naming of constants, recommending uppercase with underscores for immediate recognition. It concludes with the use of ESLint to enforce these conventions, ensuring a clean and uniform codebase.

Keywords

💡React

React is a popular JavaScript library for building user interfaces, particularly single-page applications. It is maintained by Facebook and a community of individual developers and companies. In the video, React is the central theme as the speaker discusses naming conventions for developers working with React to write cleaner and more maintainable code.

💡Naming Conventions

Naming conventions are the rules and guidelines for choosing the character sequence in identifiers which denote variables, types, functions, and other entities in source code. In the script, the speaker emphasizes the importance of following naming conventions in React to enhance code readability and maintainability, providing examples of both good and bad practices.

💡PascalCase

PascalCase, also known as UpperCamelCase, is a naming convention where the first letter of each word is capitalized, with no spaces or underscores between words. In the video, the speaker recommends using PascalCase for naming pages and components in React, as it signifies the importance of these files as entry points in the application.

💡camelCase

camelCase is a naming convention that is similar to PascalCase, but with the first letter of the first word in lowercase. It is widely used in programming for variable names, function names, and method names. The speaker in the video suggests using camelCase for file names outside the pages folder and for variables and functions within the React code.

💡Components

In React, a component is a piece of code that is reusable and can be included in other parts of the application. Components can be thought of as the building blocks of a React application. The script discusses how to structure and name components, emphasizing the use of PascalCase for their names and the importance of making them reusable.

💡Hooks

Hooks are a feature in React that allows you to use state and other React features without writing a class. They are functions that let you “hook into” React state and lifecycle features from function components. The speaker explains the importance of naming hooks with a descriptive term and starting with 'use' to indicate that it is a hook.

💡Services

In the context of the video, services refer to a layer of the application that handles data fetching and communication with APIs or databases. The speaker mentions that services should be encapsulated with methods for fetching and submitting data, making the code more modular and easier to manage.

💡Store

Store in React, particularly when using Redux or similar state management libraries, refers to a central repository that holds the application's state. The speaker discusses the 'store' folder as a place where all the state-related configurations and store logic should reside.

💡Props

Props, short for properties, are a way to pass data from a parent component to a child component in React. The speaker advises using PascalCase for naming props and emphasizes the use of interfaces to define the structure of props for better code predictability and reusability.

💡Linter

A linter is a tool that analyzes source code to flag programming errors, bugs, stylistic errors, and suspicious constructs. In the video, the speaker recommends using a linter to enforce good naming conventions across a project, ensuring consistency and reducing the likelihood of errors.

💡TypeScript

TypeScript is a superset of JavaScript that adds optional static typing, classes, and interfaces to the language. The speaker mentions TypeScript in the context of using interfaces for defining the structure of props and other data types, which helps in catching errors during development and improving code quality.

Highlights

Essential React naming conventions are crucial for writing cleaner, more readable, and maintainable code.

Project structure typically includes an 'src' folder for source code, a 'public' folder for assets, and key configuration files.

The 'src' folder should be well-organized with main folders such as 'assets', 'pages', 'components', 'hooks', 'services', 'store', 'typings', and 'utils'.

'Pages' folder contains the main entry point files for the application, representing the core pages.

Use PascalCase for naming pages to signify their importance and as the starting point of the application.

Components in the 'components' folder should be reusable and named using PascalCase to indicate they are React components.

Hooks in the 'hooks' folder should be named descriptively and follow the 'use' prefix convention for immediate recognition.

Services in the 'services' folder handle data fetching and API communication, encapsulating actions within them.

'Store' folder is for state management configurations, especially when using tools like Redux or Recoil.

Typings in the 'typings' folder define interfaces and types, crucial for TypeScript projects.

Utility functions in the 'utils' folder should be named descriptively to indicate their purpose clearly.

CamelCase should be used for file names outside the 'pages' folder for better readability.

Props should be defined using interfaces with PascalCase to maintain consistency and clarity.

Function names should be descriptive, indicating their action and purpose for better code understanding.

Variables, especially those holding values, should have descriptive names using camelCase to reflect their content.

Constants or global variables should be in uppercase with underscores to denote their unchanging nature.

Using a linter enforces good naming conventions across the project, ensuring consistency among team members.

ESLint rules like 'camelcase' can be customized to enforce naming conventions for variables and interfaces.

The video concludes with the importance of adhering to naming conventions for better code quality and team collaboration.

Transcripts

so if your Junior react developer or

you're just getting a new start with

react probably right in your react code

wrong so in this video we're going to

see the essential react naming

conventions you should follow as a

general react developer to write cleaner

and easier to read and easier to

maintain code

so I'm going to see all different

varieties stuff like following how to

write Pages components hooks variables

process so much more alright so let's

get started with Fuller structures and

folders naming conventions particularly

so here most of them like a lot of

JavaScript and reacts projects in here

have sort of the same like I mean

aspects in here or hold the structure so

you're always going to have like an SRC

in here where all your you know source

code is like living inside of that one

there's a public folder in here which

has the assets that are publicly

available throughout the web server and

like users or other websites or other

tools can it be easy accessing that one

and here you have some couple files like

the index.html have like the

configuration for Tailwind for example

post CS has the TS config.js in here

maybe these config in here now let's go

inside the SRC and this is actually the

main important part so the SRC in here

has all of our code and we need to make

sure we structure our code the right way

so for our setup in here we have like

eight main folders starting with the

assets and Assets in here are anything

related to like images funds uh specific

stuff that you you're just going to be

represented as an asset like an svgs or

something like that now we come to a

most important folder here which is

Pages now the pages in here is actually

where the main Pages for our application

actually live and what I mean by the

main page is for example let's take this

application is a multi-page application

that means you have like a home page and

you have another page that just allows

you to render products we have another

page that allows you to see like the top

rated products so this is what it looks

like for example we've gone to the home

page in here and if we try for example

go to products this actually we see oh

the all the list of products in here be

fetch from the database and see all of

that so if you go to like you know top

rated products or something the third

folder here is actually the components

and from the name in here you know

that's actually where all of our reacts

components actually live inside and

mainly those components are reusable so

we can have any component for example

have the cards or a product and we can

reuse those components across different

pages for example I can use the power

skin here on the top rated product and

you can use it at the same time on the

product we have other folders like hooks

this is actually where all our herx

lives we have the services it's actually

where all of our services relates and

service is what I mean by server is

actually like you Gateway your main

point to communicate with the data base

or something or with an API so the

service in here is going to like be

responsible fetching data submitting

there to the API so all of the actions

are going to be just like encapsulated

inside of the service in here and you

can like use that service as a function

or as a class or just like an object

that has a bunch of methods inside of it

and you can just right use it here we go

the store so if you're using redox or

Zoo standard any other store management

for example I'm using black redox

toolkit in here the stores folders

actually where all your stores should be

living and all the configuration related

to stores for typings in here you have

all the typing for example all the type

interface like the cards how a product

should look like and everything this is

actually where you should live aside

insiders and last but not least you got

the utils in here so the utility is in

here are going to be like you know

whatever utility you have for example

some calculations you're doing something

not really into component rendering or

not really into the UI itself now when

it comes to name conventions let's go

and get started with the pages because

that's the main important folder in here

so for pages in here what you want to do

always use passcode case and that's just

simply because pages are very important

so you just like using Pascal case

you're starting with an uppercase letter

in here and you combine it with like

other words are always going to be

stunning with an uppercase letter so

that will tell the actual developers are

working on the same code base in here

that Pages here and those files are

actually an important files like they

are the main entry point files for our

code base in here because those are the

main Pages that's all the components all

the launch is going to flow from so

those are actually like the starting

point so you don't want to use something

like about Dash Us in here you want to

always use Pascal case in here so

something like this you know home page

inside of it there's a component starts

with an age like you know best case as

well so instead of just using about us

in here because that's a bad practice

now for file names actually depends on

what time file as for example here we

got the up in here because he uses the

Pascal key so he starts with an

uppercase letter that's because the up

in here is actually kind of sort of like

very important like the entry point for

our application where they have a router

we have the provider we have like you

know you know there's actually where the

routing starts so that's basically an

uppercase uses basketball case but other

than that most of the times like 90 of

the times you want to use camel casing

like this one main.tsx in here so like

this is actually camel casing so I would

always suggest using camel casing file

names and particularly file names are

outside the pages folder now for our

components and reusable components in

general I love to put my components

inside of folders each folder represents

a single component and like any

components folder in here you can have

multiple sort of files and components

related to that components itself so for

example in here you got the card drawing

here and you have the index like the

index in here tells you like this is the

main entry point for the card so there's

actually where the main component lives

inside of the index but if you need to

you know split into multiple components

just to make it easier and readable so

you can just put a multiple component

here you can just going to use the

current drawing here and you're done you

can put it inside of the same folder now

for naming components you always always

want to use Pascal case naming in here

and you always want to export like a

function I don't like exporting that you

know const something like it looks like

a variable I love to export like a

function that immediately tells you oh

this is a function component like a

reacts an actual functional reacts

components so easy you know that and of

course you want to use Pascal casing so

you don't want to use you know something

like this you don't want to use a dash

or you don't want to use snake casing

all right when it comes to props you

don't want to use any type of like

naming convention for props in here you

always want to use an interface and you

want to like maybe you want to export

that because it could be used by another

components that depends on your code

base but for naming convention you would

want to always use a pascal case for

props in here because you know you just

do like products pops you don't include

the i in here that's outdated and you

just provide like all props product

props now for functions for example in

here we have utl we have Carter

typescript this particular file here we

have a function that allows us to

calculate the total price of our cards

items and whatever items you have inside

our card we can just use this function

to basically get the total now there's

actually two things first one in here is

actually the bad approach where there's

actually it all depends on the name of a

function because the more descriptive

name you put the easier it's going to

get and the easier it's going to be you

know it's going to make your code

cleaner and easier to read for example

when you take for instance this function

in here does the calculate and what it

does as well is actually includes a vat

rate so it calculates some taxes as well

before checkout so from the function

name in here by just looking at the name

in here if you're just like another in

another file or something and using or

just looking at the function name in

here you don't know exactly what it's

doing you know that oh you're getting

the total from a cards but you know

exactly what's happening if you're doing

get maybe you're a fetch it from

somewhere or what what is what do you

mean by exactly in our case and also

we're not specifically telling it we're

including the vat rating here or the

taxes by instead for the good like the

good name in here for the function what

you should do for example oh you give it

a verb like oh calculate and that means

oh we did this function is going to do

the calculation for us and we know this

is cards when it's going to calculate

the total with vat so the name in here

is very descriptive just by looking at

the name in here I can easily tell like

what the function does and I just know

that's going to calculate something for

our cart items and from the parameters

you know I know it takes cards and it

takes products and as simple as that now

if you go to variables which are

basically the same thing as functions so

they need to be as descriptive as

possible of what the variable has now

they are a little bit different from

functions because functions has a like

something to do whether they get you

something they return something or they

do an action but a variable is just for

holding a value so it should be like a

noun something so here from this we got

two things so we got the first bad

approach in here we're using use memo

what we're doing we're filtering through

products and we just like filtering

products in here by the rating so we're

getting like top rated products for our

web page in here which is called top

ratedproducts.tsx and we just simply

returning that but now we're putting

inside of a variable called filtered I

mean from the variables do you know

exactly what the variable holds it holds

a filter it but filtered what I don't

know what the type of value it has I

don't know what is what is it to do with

that I mean just by looking at the

variable I don't exactly know what's

happening but the good approach in here

you should like include you know have a

pretty decent variable name in here at

least so you can do oh filtrated

products by rate and that tells you

immediately oh this will include the

products array that are filtered by rate

just like that and of course for

variable names you always want to use

camel casing the same thing as functions

all right now when it comes to hooks the

same thing all of them actually play a

major role in the naming convention so

make sure always to use like a

descriptive name for your hook in here

and the thing in here for herx because

react high is actually a very specific

naming convention for hooks you always

need to prepend a use before The Hook

name so just by following that

immediately you know or any other

developer routes on the same code base

in your ear knows that by just looking

at this oh this is a hook immediately

and it should be used inside of a

functional component and the same thing

naming conversion is always camel casing

just to make it easier to read and very

simple and last but not least which are

typescript interfaces because the reason

we're covering this in reacts because 99

of the times use an interfacing here

you're going to be using for props or

something and interfaces are actually a

very important thing whether interfaces

or types they are basically the same

thing so the same naming convention here

applies to both of them so for example

in here the bad approach for naming

interfaces you always started with an

eye I used to do that a lot in the

previously but now like everything

changes typescripts you no longer need

to do that because that actually makes

it very specific and interface actually

very Broad and they have a lot of things

they can do so for example of doing eye

products you can just name it store

products and yes for interfaces you

would want to use password case because

interface represents a type and when it

comes to constants variables or constant

Global variables you always want to name

them as an uppercase like o uppercase

with an underscore instead of doing like

a camel casing or something you know the

whole Community actually agrees on that

so just always using an uppercase for a

constant variable make you immediately

know oh this is a constant sort of

variable in here it just has a value in

here and that's it to better enforce

actually having a good naming convention

across the project and just to make sure

you know all the team members actually

following the same in conventions you

want to use something like a linter

because I have like two rules I always

love to use for ES links in here to kind

of like enforce a good naming convention

across my projects and the first one is

called like camel case which is kind of

like a rule that allows you to enforce

camel casing for variable names in here

has a bunch of options in here but this

one just allows you to have camo casing

for variables so there's actually pretty

good one it doesn't have a lot of like

you know flexibility and there's the

other one which I really like but

there's actually needs from you to use

typescript ESPN plug it in here so you

can just go in like serious typescript

instant in here and see how you can set

up this one and this is actually very

very customizable you can have a bunch

of stuff in here like exclusively the

different options so for example inside

of my ears links what I'm using I'm

using camel case ER so that just gonna

tell all my variables to be camel cases

in here although I'm just going to throw

an error in here and here for the naming

conventions of like the TF timescript is

the name convention I'm using an error

and I mean giving it actually a

different options in it for example for

a variable I want to make sure it's

actually a camel case and I can just

like lead in underscore allowing to add

any underscore at the beginning of the

variable like something like that

modifiers in here should be like

exported variables should be camel cased

and so much more so for example if he's

trying to do your own links in here to

see exactly what we have if you see the

errors in here for example people there

is a expected empty option in here for

example there is an identifier which is

is open he uses snake case and he tells

you oh this is not a camel case I can't

accept that so that just immediately

warns you about that so it doesn't allow

you to like commit your code that is

looking pretty bad in here or for

example you go oh interface name eye

product must not match the reject so you

should not start with an i in here so

that makes it a little bit more you know

easier for you to know and find the

issues across by just using those rules

so anyway thanks for watching hope you

guys enjoyed the naming conventions and

catch you all hopefully in the next ones