React Naming Conventions You should follow as a Junior Developer - clean-code
Summary
TLDRThis 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
📂 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.
📝 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.
🔍 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.
Mindmap
Keywords
💡React
💡Naming Conventions
💡PascalCase
💡camelCase
💡Components
💡Hooks
💡Services
💡Store
💡Props
💡Linter
💡TypeScript
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
5.0 / 5 (0 votes)