DEV Community: Christian Montero

What to/not to test when building an App with MERN stack? 👨🏻‍💻

Christian Montero — Sat, 26 Sep 2020 21:10:54 +0000

Hi guys, I'm trying to keep learning testing, but I'm not sure what to test and what not to test, I been reading posts, seeing tutorials and everybody agree that you should avoid testing implementation details...

but if you guys have some more experience, what should I focus on when it comes to testing either in the backend and the frontend, and what libraries/frameworks do you recommend?

Also if you want to recommend any book, articles, video-tutorial or any other source that you consider useful, go ahead , if not, it's ok, I'll look into the docs and search for examples and articles by myself.

thank you guys! enjoy your weekend 👍

React Router

Christian Montero — Tue, 01 Sep 2020 02:55:04 +0000

react-router 🔀

Hi, how are you guys? hope you are doing good, today we'll be talking about React Router.

react-router is a library that allows us to handle routes in our Web application.

Why do we need routes? 🤷‍♂️

You might be wondering why do we need routes, if we are developing SPA, it's very likely that you have been using conditional rendering based on the state to change the components that you want show, and it works, but... what happens when our application becomes bigger and more complex?

this conditional rendering might become difficult to understand, manage and maintain.

From the documentation:

Components are the heart of React's powerful, declarative programming model. React Router is a collection of navigational components that compose declaratively with your application.

With react-router, we'll be able to:

1.- Define which component/components to render based on a path.
2.- Use the back and forward buttons of our browser.

Main components of react-router

1.- BrowserRouter: This component is used for applications which have a dynamic server that knows how to handle any type of url. This means that our server has to be configured correctly. Specifically, our web server needs to serve the same page at all URLs that are managed client-side by react-router.

History 📍

Something important that we need to know is that our router will create a history object which is used to keep track of the current location.

2.- Route: This is a key piece of react-router, it's main responsibility is to render something when a location matches the route's path. the route expects this 3 arguments:

Argument	Description
exact	Is a boolean property, it means that the specified path must be exactly, for render the specified component
path	Is a string that’s equal to the path of the current place where we are
component*	The component that we want to render

*There are other ways to specify what do we want to render if the route's path matches, but we'll talk about it later.

3.- Link: Provides declarative, accessible, navigation around our Application.

Link takes 2 attributes, to and replace.

Argument	Description
To	Can be a string, object or function which tells the app which path to redirect to
Replace	Is an optional boolean, is it's true will replace the current entry in the history stack instead of adding a new one

4.- Redirect: Rendering a will navigate to a new location. The new location will override the current location in the history stack, we can use this for example, when a user is already logged in and he try to navigate to the Login Page, there' s no point on doing that, so if he try to do it, we can redirect him to the Home Page.

5.- Switch: We can use the component to wrap our routes/redirects and it will render/redirect the first child that matches the location.

How's different than just using a bunch of routes?

is unique in that renders a route exclusively.

Installation 🔧

npm install --save react-router

Setup ⚙️

Lets start coding, first lets create a couple of components to start playing with our Router, lets create a components folder and inside 3 components, Login, Home and Dashboard:

In the last picture you can see the components folder and inside a folder for each component, right now I haven't created files for the styles, we'll do it later, and I like to name my component files as .component.jsx but you can name them however you like.

The components will be very simple, we just want to render the name of the component.

import React from 'react';

const Login = () => {
  return(
    <div>This is Login Page</div>
  )
}

export default Login;

Now lets go to our App.js where we'll import our components and our router components. First lets wrap everything with our BrowserRouter and first we will create a couple of links to navigate through our components, then lets specify our routes and lets test it, here is the code of our App.js.

import React from 'react';
import { 
  BrowserRouter as Router,
  Route,
  Link
} from 'react-router-dom'
import './App.css';

import Login from './components/login/login.component';
import Home from './components/home/home.component';
import Dashboard from './components/dashboard/dashboard.component';

function App() {
  return (
    <Router>
      <div>
      <Link to="/login">Login</Link><br/>
      <Link to="/home">Home</Link><br/>
      <Link to="/dashboard">Dashboard</Link><br/>
      </div>
      <Route exact path='/login' component={Login}/>
      <Route exact path='/home' component={Home}/>
      <Route exact path='/dashboard' component={Dashboard}/>
    </Router>
  );
}

export default App;

As you can see, after saving our changes, we will see in the browser our links to navigate through our components, but nothing else, notice that when we click in the login link our URL will change as well as the content in the page, under our links we will see our Login component.

We expect the same behavior when we click in the rest of our links, the URL will change as well as the component being rendered.

Great our router is working as we expect, lets see how the exact argument of the route works, first lets change the path of the route for our Home component, also lets change the Link for our Home component and lets remove the exact argument from our Routes, this is the new code:

function App() {
  return (
    <Router>
      <div>
        <Link to="/">Home</Link><br/>
        <Link to="/login">Login</Link><br/>
        <Link to="/dashboard">Dashboard</Link><br/>
      </div>
      <Route exact path='/' component={Home}/>
      <Route exact path='/login' component={Login}/>
      <Route exact path='/dashboard' component={Dashboard}/>
    </Router>
  );
}

As we can see now, our Home component is always visible and the reason of this is because it's path ('/') matches with the URL in the browser in all scenarios.

Arguments passed to the rendered component.

Something important is that any component that gets rendered by a route get passed 3 arguments, History, location and Match.

Here is a description of the most used properties of our arguments.

Argument	Description
match	⬇️
url	is the url until our component matches, so if the path associated to our component is ‘/’ but we navigate to http://localhost:3000/ or to http://localhost:3000/topics/details/something our url inside the match object will be ‘/’ because is the url until it match.
path	Is the pattern that our route is looking to match, it means, the path that we specify in our route.
isExact	Becomes true if the entire url match the pattern to match
params	Is an object of url parameters. Lets say that we have a route with this path ='/topics/:topicId' notice that after ‘/topics/’ we have “:topicId” this means that after this point we can dynamically change our url. And we can use those params for fetch data from a database or if it’s a title for some item, we can use it to display that title in the Component.
history	⬇️
push	There are 2 ways to navigate with react-router the first one is using the Link component, where we can specify a parameter called to and we specify the route where when want it to takes us to. For example: to='/topics'. Just remember that React is SPA, so what we are actually doing is hijacking the url and determine with Javascript what component to replace, there’s no navigation at all (we are not re-rendering the whole application). The other way to do this is: props.history.push('/topics')
location	⬇️
pathname	It tells us where we are in the application. So if we navigate to: http://localhost:3000/topics/15/something/props that url is exactly what pathname will return. And this is useful because our component is aware what the full url looks like.

Nested Routing

Lets create an quickly example of nested routing, Lets add a TopicsList component a Topic component to our project.

This is the code of our TopicsList component:

import React from 'react';
import { Link } from 'react-router-dom'

const TopicsList = (props) => {

  React.useEffect(() => {
    console.log(props.match.url);
  }, []);

  return(
    <div>
      <h1>Topics List Page</h1>
      <Link to={`${props.match.url}/A`} >To topic A</Link><br/>
      <Link to={`${props.match.url}/B`} >To topic B</Link><br/>
      <Link to={`${props.match.url}/C`} >To topic C</Link><br/>
    </div>
  )
}

export default TopicsList;

As you can see we are using Links inside our TopicsList component. and the "to" argument is being created with a string template so we can use our props.match.url + the topic we want to see. The props.match.url at this point is '/topics' because that is the path specified to render the TopicsList component, we can see that if we console.log that value.

And after that we specify which Topic we want to see

This is the code of our Topic component:

import React from 'react';

const Topic = (props) => {

  React.useEffect(() => {
    console.log(props);
  }, []);

  return(
    <div>
      <h1>Topic {props.match.params.topicId}</h1>
    </div>
  )
}

export default Topic;

Inside our topic component we are using the props.match.params.topicId because we want to know which Topic we need to render, we are using the same component to render all the topics, we just need to change the content and we get it from the params:

Now we just need to update our App.js with this code:

import React from 'react';
import { 
  BrowserRouter as Router,
  Route,
  Link
} from 'react-router-dom'
import './App.css';

import Home from './components/home/home.component';
import TopicsList from './components/topicsList/topicsList.component';
import Topic from './components/topic/topic.component';

function App() {
  return (
    <Router>
      <div>
        <Link to="/">Home</Link><br/>
        <Link to="/topics">TopicsList</Link><br/>
      </div>
      <Route exact path='/' component={Home}/>
      <Route exact path='/topics' component={TopicsList}/>
      <Route exact path='/topics/:topicId' component={Topic}/>
    </Router>
  );
}

export default App;

Notice our Route for the Topic Component, we are using a new syntax:

<Route exact path='/topics/:topicId' component={Topic}/>

After /topics/ we use :topicId as we said before in our table, this means that after this point we can dynamically change our url, and it will be passed as a parameter.

Lets save our changes and test our App.

As you can see everything is working as expected, now you know how everything works together, how we can used the props that are being passed to the components rendered by the Route and by the Link components.

I hope you enjoyed this post and found it useful, if you like it, feel free to share, also if you have any thoughts about this post, feel free to comment here or contact me, any feedback would be appreciated.

Have a nice day! ✌️

GitLab CI/CD example with a dockerized ReactJS App 🚀

Christian Montero — Wed, 26 Aug 2020 05:11:22 +0000

Good afternoon!
Today we'll be creating a CI/CD pipeline using GitLab to automate a dockerized ReactJS deployment 🚀

Introduction

So today We're going to use Create-react-app in order to generate a simple ReactJS project, then we are going to dockerized that project in our local environment just to test it, Then we are going to upload our code to a GitLab repository in order to use it's CI/CD pipeline functionality and then deploy our dockerized app into a Digital Ocean droplet.

So, to follow this tutorial you should have:

1.- create-react-app installed ⚛️
2.- docker installed 🐳
3.- Good understanding about docker 🐳
4.- Good understanding about nginx 🆖
5.- GitLab account 🦊
6.- Digital Ocean account 🌊

Let's get started 💪

1.- Let's generate a react project using create-react-app

I'm gonna create a project called Budgefy 🐖 (an old project that I never finished), we just need to type:



npx create-react-app budgefy

and we'll see something like this:

After the project was successfully created, let' s verify that we can start the project typing this:



cd budgefy
npm start

And it will open a new tab in our browser with the project running, you'll see this:

Let's check if the tests are passing as well, by typing this:
(first ctrl + c to stop the project)



npm test

and it will prompt this in the console:

and then just type 'a' to run all tests, and we expect this output:

2.- Let's dockerize our application

This is not an article about docker, so I'm assuming that you have a good understanding of docker, I'm planning to write an article about docker in a couple of days or maybe weeks, I'll do it as soon as possible. Anyways this is our docker file (this file will be in the root folder of our project):



# Set the base image to node:12-alpine
FROM node:12-alpine as build

# Specify where our app will live in the container
WORKDIR /app

# Copy the React App to the container
COPY . /app/

# Prepare the container for building React
RUN npm install
RUN npm install react-scripts@3.0.1 -g
# We want the production version
RUN npm run build

# Prepare nginx
FROM nginx:1.16.0-alpine
COPY --from=build /app/build /usr/share/nginx/html
RUN rm /etc/nginx/conf.d/default.conf
COPY nginx/nginx.conf /etc/nginx/conf.d

# Fire up nginx
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

We need to create a .dockerignore file (this file will be in the root folder of our project) to ignore the node_modules folder in our dockerized app, so, the content of our .dockerignore is this:



node_modules

Also, since we will be using nginx (I will write about nginx in another article) we need to create the nginx folder in the root folder of our application, and inside we need to create the nginx.conf file with this content:



server {

  listen 80;

  location / {
    root   /usr/share/nginx/html;
    index  index.html index.htm;
    try_files $uri $uri/ /index.html;
  }

  error_page 500 502 503 504 /50x.html;

  location = /50x.html {
      root /usr/share/nginx/html;
  }

}

Now that we have our files in place, make sure that in your terminal you are in the same folder where the Dockerfile is and let's run this command to create our image:



docker build --tag budgefy:1.0 .

docker will log a lot of messages during the build process and at the end we can verify that our image was created by typing docker images and we should see our budgefy image, like this:

and now we can run our image with this command:



docker run -p 4250:80 -d --name bugefycontainer budgefy:1.0

After running our image, we will see an output like this one, where we'll see that we have a container running with our application

so now, if you are using ubuntu, you can go to localhost:4250 and you will see our dockerized app running, in my case since I' m using Docker in windows, I have to access to the app through an IP that docker provides me, and this is our result:

Great everything is working!!!😎💪

What's next? Let's upload our code to GitLab!

3.- Creating a project on GitLab 🦊

To create a Project on GitLab it's super easy, just login into your account and click on the "New Project" Button:

then just fill the name field, let's leave it as a private repository and click on "Create Project":

Great! we have our project, let's upload our code, in our GitLab we'll see the instructions, in my case I need to follow this instructions:

And after following those instructions we will see our code in our GitLab repository as you can see in this image:

4.- Let's create our Pipeline

In order to create our pipeline we need to add a new file in the root folder of our project whit the name: .gitlab-ci.yml

Once we added the .gitlab-ci.yml file and push it to our GitLab repository, GitLab will detect this file and a GitLab runner will go through the file and run all the jobs that we specify there. By default GitLab provides us with "shared runners" that will run the pipeline automatically unless we specify something else in our file. We can also use "specific runner" which basically means to install the GitLab runner service on a machine that allows you to customize your runner as you need, but for this scenario, we will use the shared runners.

In this file we can define the scripts that we want to run, we can run commands in sequence or in parallel, we can define where we want to deploy our app and specify whether we want to run the scripts automatically or trigger any of them manually.

We need to organize our scripts in a sequence that suits our application and in accordance with the test we want to perform

Let's see the next example:



stages:
  - build
  - test

build:
  stage: build
  image: node
  script: 
    - echo "Start building App"
    - npm install
    - npm build
    - echo "Build successfully!"

test:
  stage: test
  image: node
  script:
    - echo "Testing App"
    - npm install
    - CI=true npm test
    - echo "Test successfully!"

let's include this code in our .gitlab-ci.yml file and commit those changes to our repo.

If we go to our repo we will see that our pipeline is running, let's take a look to our pipeline, we need to go to CI/CD and then to pipelines in our sidebar:

and then click in our status button:

then we will see the progress/status of our jobs as you can see here:

And since we test our App locally, everything should work as expected, and eventually we will see the successful message.

So, this was a very simple example to see how the pipeline works, we have two stages, and in the first one we just build the application and in the second one we run our tests. You might be asking you why are we running "npm install" 2 times, surely there's a better way to do it.

This is because each job runs in a new empty instance and we don't have any data from previous jobs, in order to share data we need to use artifacts or cache, what's the difference?

Artifacts:

1.- I usually the output of a build tool.
2.- In GitLab CI, are designed to save some compiled/generated paths of the build.
3.- Artifacts can be used to pass data between stages/jobs.

Cache:

1.- Caches are not to be used to store build results
2.- Cache should only be used as a temporary storage for project dependencies.

So, let's improve our pipeline:



stages:
  - build
  - test

build:
  stage: build
  image: node
  script: 
    - echo "Start building App"
    - npm install
    - npm build
    - echo "Build successfully!"
    artifacts:
      expire_in: 1 hour
      paths:
        - build
        - node_modules/

test:
  stage: test
  image: node
  script:
    - echo "Testing App"
    - CI=true npm test
    - echo "Test successfully!"

Let's commit our code, and we'll see that everything it's still working, thats good! 🌟

5.- Let's build our image in the Pipeline

Now let's create another stage to dockerize our App. Take a look in our "docker-build" stage, our file will look like this:



stages:
  - build
  - test
  - docker-build

build:
  stage: build
  image: node
  script: 
    - echo "Start building App"
    - npm install
    - npm build
    - echo "Build successfully!"
  artifacts:
    expire_in: 1 hour
    paths:
      - build
      - node_modules/

test:
  stage: test
  image: node
  script:
    - echo "Testing App"
    - CI=true npm test
    - echo "Test successfully!"

docker-build:
  stage: docker-build
  image: docker:latest
  services: 
    - name: docker:19.03.8-dind
  before_script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
  script:
    - docker build --pull -t "$CI_REGISTRY_IMAGE" .
    - docker push "$CI_REGISTRY_IMAGE"

After committing and pushing our code, it will take a few minutes for the pipeline to finish the jobs, and if everything goes well, you'll see that all jobs passed, like this:

Also if you go to our sidebar in the GitLab dashboard, to "Packages and Registries" then to "Container Registry"

You will see the image that we just built 😎

Amazing job! 👌

So, what is happening in our "docker-build" stage? 🐳
Basically the same that we did in our local environment to build our docker image, we are using a docker image for this because we will need to run some docker commands, also we need to use the docker-dind service, in this case I'm using this specific version (docker:19.03.8-dind) because I had a couple of problems with other versions, and after that we are just login in to our GitLab account and build and push the image to the GitLab registry.

Also we are using some predefined GitLab variables, what is that?

Predefined Environment Variables:

GitLab offers a set of predefined variables that we can see and use if some of them are useful for our particular needs, you can see the full list here (https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) In our particular case we are using this ones:

1.- CI_REGISTRY_USER: The username to use to push containers to the GitLab Container Registry, for the current project. 🤵

2.- CI_REGISTRY_PASSWORD: The password to use to push containers to the GitLab Container Registry, for the current project. 🙈

3.- CI_REGISTRY: If the Container Registry is enabled it returns the address of GitLab’s Container Registry. This variable includes a :port value if one has been specified in the registry configuration. 🔗

4.- CI_REGISTRY_IMAGE: If the Container Registry is enabled for the project it returns the address of the registry tied to the specific project 🔗

So, what's next? We need to deploy our App to our server!!! so first, let's

6.- Adding the Deploy stage 🔨

Again we need to do what we did in our local environment, we need to pull our image from the GitLab registry and then we need to run it, and that's it! our App will be available in our server. So first let's add some commands to our .gitlab-ci.yml file, our last version of this file will be this one:



stages:
  - build
  - test
  - docker-build
  - deploy

build:
  stage: build
  image: node
  script: 
    - echo "Start building App"
    - npm install
    - npm build
    - echo "Build successfully!"
  artifacts:
    expire_in: 1 hour
    paths:
      - build
      - node_modules/

test:
  stage: test
  image: node
  script:
    - echo "Testing App"
    - CI=true npm test
    - echo "Test successfully!"

docker-build:
  stage: docker-build
  image: docker:latest
  services: 
    - name: docker:19.03.8-dind
  before_script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
  script:
    - docker build --pull -t "$CI_REGISTRY_IMAGE" .
    - docker push "$CI_REGISTRY_IMAGE"
    - echo "Registry image:" $CI_REGISTRY_IMAGE

deploy:
  stage: deploy
  image: kroniak/ssh-client
  before_script:
    - echo "deploying app"
  script:
    - chmod 400 $SSH_PRIVATE_KEY
    - ssh -o StrictHostKeyChecking=no -i $SSH_PRIVATE_KEY root@$PROD_SERVER_IP "docker pull registry.gitlab.com/alfredomartinezzz/budgefy"
    - ssh -o StrictHostKeyChecking=no -i $SSH_PRIVATE_KEY root@$PROD_SERVER_IP "docker stop budgefycontainer || true && docker rm budgefycontainer || true"
    - ssh -o StrictHostKeyChecking=no -i $SSH_PRIVATE_KEY root@$PROD_SERVER_IP "docker run -p 3001:80 -d --name budgefycontainer registry.gitlab.com/alfredomartinezzz/budgefy"

What are we doing?

In order to make this happens, we need to establish a ssh connection between our pipeline and our server, to do that we will need to store the IP of our server as a environment variable and also our private key.

So, for this stage we will use an image with a ssh client (kroniak/ssh-client) and we will run our commands 1 by 1 like this:



ssh -o StrictHostKeyChecking=no -i <private_key> <user_in_server>@<server_ip> "<command>"

But if we want to test our last stage, we need to let our server ready!

Do not commit/push this changes (it will throw an error) we'll do it later

6.- Creating our server in Digital Ocean 🌊

You don't need to use Digital Ocean but I think that it's a very fast and easy option to get our server up an running! you just need to create an account, most of the time they give 100 dlls that you can use in the next 60 days, the server that we'll be using costs 5 dlls per month, so I found digital ocean very useful to practice and learn.

So just go ahead and create your account it will ask you for a payment method, you need to introduce your credit card but it won't charge you a cent.

Once you have your account, go to your dashboard and create a Droplet

Then you need to choose your droplet requirements, we need a very basic one, choose the one of 5 dlls per month as you can see in this image:

You can leave the rest of the options as they are, just need to type a password and give your server a cool name 😎

And that's it, then it will take around 55 seconds to get your server up and running, pretty simple isn't? 👌

Now you can see your server and it's IP!

So now, let's get inside of our server via SSH from our local environment, let's go to our terminal (I'm using the cmder terminal for windows, if you are using the regular one, maybe you need to download putty or probably you can establish a ssh connection from the powershell, if you are on Mac or Linux you can do it from the regular terminal), so we just need to type:



ssh root@<server_ip>

it will prompt you a message if you want to establish the connection:

and then it will ask you for the password that you established when you created your droplet, just type it in and then you'll be in!

So now that we are in, we have a clean ubuntu server, we need to install docker, and let's login to our GitLab account, pull our project image and run it.

Here's a very simple guide to install docker in our ubuntu server: https://www.digitalocean.com/community/tutorials/how-to-install-and-use-docker-on-ubuntu-20-04

We can verify that docker was successfully installed by typing docker -v or/and docker ps to list our containers:

so, lets go to our Container Registry in GitLab, we will find a blue button that says "CLI commands":

We'll need the login into our GitLab account, and then we need to pull and run the image manually in our server, so let's do it.

Let's login:

Then let's pull our image:

And then let's run it with this command, make sure that you change your image name if it's different and if you want to use another port, just change it, in my case I'll run it with this command:



docker run -p 3005:80 -d --name budgefycontainer registry.gitlab.com/alfredomartinezzz/budgefy

We can run the docker ps command to see our containers:

And then let's go to our browser and go to our SERVER_IP:PORT

In my case I will access to the app on port 3005 and the IP of my server is: 138.68.254.184

And now we can see our App up and running in our server! as simple as that! 👍

So, now that we verify that our server is running perfectly and we can run our app there, we need to store our server's private key as an environment variable in our GitLab Project and also we need to store the IP address, so let's do it.

Let's go to our sidebar in our GitLab dashboard, and let's click on settings and then CI/CD we will see a lot of options, let's expand the variables section:

Then click on the "Add variable" button and a modal will pop up, our variable key will be "PROD_SERVER_IP" and the value will be our server IP, leave the rest of the options as they are and click on "Add variable".

Now we need to add our private key, but first let's create one in our server. Go to your server, open the terminal and type this:



ssh-keygen -m PEM -t rsa -b 4096 -C "your_email@example.com"

it will ask you for a file to save the key, just type enter to use the default one, then it will ask you for a passphrase, for this example let's leave it empty and press enter a couple of times, and then you will see a successful message, then we need to copy our private key add it to our project on GitLab, we can run this command to see the our private key:

then let's copy our private key

let's type cat ~/.ssh/id_rsa and copy the output, create a new variable, the key will be SSH_PRIVATE_KEY and the value will be our private key:



cat ~/.ssh/id_rsa

so, let's copy the content and paste it.

Then we need to go to our server and run this command:



cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

Now that everything is ready, let's commit and push our code to see the result.

That's all, now every time that we push our code into our repo, our pipeline will build our app, then it will run our tests, it will dockerize our app and push it into the GitLab Registry and finally it will deploy our App into our server!

Have a nice day! ✌️

Create React App

Christian Montero — Wed, 19 Aug 2020 05:08:08 +0000

What is create-react-app and Why are we going to use it?

From its website, they define create-react-app as a comfortable environment for learning React, and is the best way to start building a new single-page application in React.

It sets up our development environment so we can use the latest JavaScript features, provides a nice developer experience, and optimizes our App for production. We'll need to have node >= 8.10 and npm >= 5.6 in our machine.

What does it includes?

1.- Webpack: A static module bundler for modern JavaScript applications.
2.- Webpack Dev Server: To run a local environment.
3.- Babel: For transpiling our files to work on the targets we choose.
4.- ESLint: For error checking and help you to format code.
5.- Jest: A testing library!

How to create a Project?

npx create-react-app my-app
cd my-app
npm start

Folder Stucture

So as a result, create-react-app will create a project with the next structure:

1.- node_modules: This is the folder in which all the dependencies are installed, it's generated when we run the create-react-app or the npm install command.
2.- public: contains 3 files, usually we would only make a few changes in the index.html file
3.- src: The folder in which we will be working, the starting point of our react application is the index.js where we specify the root component which is App.js.
4.- .gitignore: a list of folders/files that don't want to include in our repo when we push our code.
5.- package-lock.json: ensure consistent installation in our dependencies.
6.- package.json: Contains the dependencies and scripts requried for the project.
7.- README.md: We include information related to the project, sometimes the steps to run it, test it, etc.

That was a pretty short introduction to our structure, we will come back to them in next lessons.

JS fundamentals: const vs var vs let?

Christian Montero — Tue, 04 Aug 2020 05:55:16 +0000

A lot of features came out with ES6 (ECMAScript 6. ES2015, Harmony, ESNext), many of these features are already supported by the newest features.

One of these features is the incorporation of new ways to declare variables, but you might be wondering what's the difference? what makes them better than our friendly var?

In the next posts we are going to be discussing the Javascript fundamental concepts so we can switch to the latest syntax if we haven't yet. In this post we will discuss about the differences between var, let and const in relation to their use, hoisting and scope.

Terminology 📕

Scope: In Javascript the scope refers to the current context of code that determines the accessibility (visibility) of a variable. There are 2 types of scope:

-Global Scope: Variables declared outside of a block.
-Local Scope: Variables declared inside of a block.
Hoisting: Is a Javascript mechanism that moves the declaration of variables and functions to the top of their scope before code execution.

We will talk more about this concepts later on this post.

Const ❗️

Const doesn't mean "constant" it means one time assignment

Const cannot be updated or re-declared

Const keyword is a litttle tricky especially if you have used them in other languages. A constant is a variable with an inmutable reference. When we declare a primitive type as const we cannot change its value, if we try, we will see an error in the console, as you can see here:

const PI = 3.1415926535;
console.log(PI);
PI = 3.1416;
console.log(PI);

The same way if we try to re-declare a const variable we will see this error:

const PI = 3.1415926535;
const PI = 3.1416;

This means that when we want to declare a variable using the const keyword, we must initialize them at the time of the declaration or we will see another error message:

const PI;
PI = 3.1415926535

However this behavior changes when it comes to non-primitive types (objects, arrays, etc) as const. The way the const keyword works with objects is this:

We cannot re-declare the object but we can update the value of its properties and we can add more properties without returning errors.

const user =  {
  name: 'Obi-Wan',
  age: 30
};

console.log(user);

user.name = 'Luke';
user.lastname = 'Skywalker';
user.age = 25;

console.log(user);
};

Const is block scoped

Before ES6 we had local/function scope and global scope.
function-scoped variables were only available inside the function where they were declared. Now with ES6 and with the addition of the let and const keywords, we have the block scope where block code means the code bounded by {}, anything within curly braces is a block. We will this explain in the next example:

const PI = 3.1415926535;

function cirleArea( radius ){
  const PI = 3.1416;
  console.log('PI inside circleArea function: ', PI);
  return radius*radius*PI;
};

console.log('PI outside circleArea function: ', PI);

var area = cirleArea(1);
console.log("The area is: ", area);

As you can see, we define a PI constant outside our circleArea function, and we define another constant with the same name inside our function, since they have different scope, we won't run into a re-declaration error, also if we console log both of this variables in their respective scope, we will see the different values.

Hoisting of const

const delcarations are hoisted to the top but is not initialized. so if we try to use a const variable before its declarations, we'll get a Reference error.

console.log("The value of PI is: ", PI);
const PI = 3.1415926535;

Let ✅

Javascript now has lexical variable scoping, we create code blocks with curly backets. With functions, these curly brackets block off the scope of variables, but if we think about if-else statements, we might assume that these blocks would also block variable scope, before the addition of the let keywork this wasn't the case as we can see in the next example:

var name = 'Peter Griffin';

if(true){
  var name = 'Homer Simpson';
  console.log(name);
}

console.log(name);

The name variable inside the if block resets the value of the global name variable.

Fortunately with the let keyword, we can scope a variable to any code block. Using let protects the value of the global variable and that's why let is now the preferred for variable declaration.
We can see the same example here:

var name = 'Peter Griffin';

if(true){
  let name = 'Homer Simpson';
  console.log(name);
}

console.log(name);

Unlike const, let can be updated but not re-declared

Any variable declared with the let keyword can be updated, but if we try to re-declare it, we will get an error as we can see in the next example:

let name = 'Peter Griffin';
console.log(name);
name = 'Homer Simpson'
console.log(name);

let name = 'Peter Griffin';
console.log(name);
let name = 'Bart Simpson';
console.log(name);

Let is block scoped

A variabled declared in a code block using the let keyword will be only available within that block.

Hoisting of let

The same way that const, let delcarations are hoisted to the top but they are not initialized, so if we try to use a const variable before its declarations, we'll get a Reference error.

What about our old friend var? 👨‍🦳

Most of the time we can replace let with var and vice-versa and expect things to work, but there are some important points that we have to know.

var has no block scope

When we declare a variable using the var keyword they are either function-wide or global. They are visible through blocks:

if(true){
   var name = 'Peter Griffin';
}
console.log(name);

As we can see, even when we declare the variable inside the if block, the variable lives outside. We will see the same behavior with for loops blocks. The only different scenario is if the code block is inside a function, in that case the variable becomes a function-level variable.

if(true){
   var name = 'Peter Griffin';
}
console.log(name);

var can be re-declared

var can be declare below their use (This is possible because declarations are hoisted, but assignments are not)

function add(a, b){
  result = a + b;
  console.log(result);
  var result;
};
add(5, 2);

💡 Summary 💡

Scope means the code context where variables are available for use. 👀
Hoisting is a Javascript mechanism that moves the declaration of variables and functions to the top of their scope before code execution. 🔺
Const doesn't necessarily means that holds an immutable value, it means that holds an immutable reference and it behaves different depending the type of variable that we assign to. But even though our code can be more meaningful if we use the const keyword. 👍
Let is similar to var, but let is block scoped. 💪 5.- Reading across many articles I found that many authors recommend to avoid the use of var, there's no need to use it anymore. 👎

I believe that there's always something to learn from everyone, hopefully this post will be useful for somebody, I'm still learning, so any feedback would be appreciated. Have a nice day! ✌️