Forem: Aisha A.

React props - A beginner's guide

Aisha A. — Tue, 16 May 2023 04:25:10 +0000

This concept is when you're passing the data from the parent down to its direct children.

Take for example the image above where the App component has 2 children, the Modal component and the Form component. The App component has the following data.

How do we then pass the data down from App to Form component? That's when we're going to use "props". Props consists of all attributes that we pass the component to. What do I mean by that? Let's have a look at the example below:

Props is a shortened version for properties, quite similar to objects, each component have their own properties "IF" given any. If we were to convert the code above to a vanilla Javascript object, it will look like this:

Now let's have a look at our JSX code and identify the attributes.

As you've noticed, we have an attribute property and a value assigned to each attribute. Quite similar to how objects are.

React useState() - A guide for beginners

Aisha A. — Sun, 14 May 2023 12:17:27 +0000

As a beginner, you need to know why we use useState, how its executed and why do we need it. These sections will be discussed as we deep dive into useState hook.

For a start, we need to understand why we need useState. Using vanilla Javascript code doesn't trigger component re-render. Take for example the code below:

Examining the code above, you'll probably think that the title should change because we're re-assigning it a value, right?

However, that's not what is happening. Rather, you can see that the title has a new value called "Updated" in the console but the DOM did NOT change. Why is that you ask? That is because when React renders the component a second time, the local variables don't persist, and the second reason is that, local variables don't trigger re-render/renders.

By default, the DOM only gets mounted ONCE and will never re-evaluate even if a change occurred. To update a component, 2 things need to happen, 1, for the data between render to be retained and 2, for React to render the component with the new data. Now let's try to understand that visually.

This entire process is the mounting phase of the React Component Lifecycle which only happens ONCE when the components are first evaluated and rendered for the first time

Now, we're faced with an issue where React will never repeat the same process. As soon as it's rendered for the first time, it's done. However, most of the time, we want to be able to change the values rendered on the page when a change occurs. That's when we're going to need states.

As mentioned above, React ignores any normal/vanilla variables even if a change occured. It doesn't trigger the component to re-render and even if it does, it will just re-create the variable with the same value. Even if there's a click or any other event listener, it doesn't trigger the component to run again.

In useState however, any changes to its values should result in the component function being called again.

useState returns two values, a pointer to the managed state, and the second value is a setter function that can be called later to set a new value, you can access access these values using an array destructuring.

When the setter function is called and re-renders the component, it will compare the virtual dom and the actual dom to check if there’s a change in the data or the component itself, if there is then it will replace the actual dom with the new values.

To be accurate, it's comparing the current evaluation to the previous evaluation. If there's any change, those changes is handed over to the ReactDOM which makes necessary changes in the real DOM.

This phase or state is called the Updating phase in the React component lifecycle.

Another thing to note is that the console log doesn’t print the updated value straight away, rather, it prints the value BEFORE it was updated. The reason for that is because useState doesn’t change the value right away, rather, it schedules the update.

On top of that, states are per component instance basis, meaning, if you change the state in one component, the other component state isn't affected. Think of it as a modular state, separated from the other component.

State snapshots

How do we then get the latest state snapshot? Meaning, how do we get the latest value? Well, think of it this way, imagine depositing your money in the bank, they now manage your money for you, as days go by, the interest in your account accumulates. A year later, you withdraw your money which now has interest on top.

Likewise, in React, it's like telling React to give you the latest snapshot that you asked to be managed, hence, you have an access to its previous change and manipulate it like so:

 const [detectChange, setDetectedChange] = useState(false);

 setDetectedChange((previousState) => !previousState);

App.js, what should be in it?

Aisha A. — Tue, 06 Sep 2022 03:19:13 +0000

Now that we’ve tackled the concepts, let’s visualise how they are intertwined.

To explain the image above. When the user first triggers the /users end point, it will trigger the route through the server application which is the file that holds the server.

In my case, the server resides in the app.js file. How do I know that it is my server? Because it is where the instance of the server is declared:

const app = express();

On top of that, app.js holds the database connection as well as the grouping routes. Since app.js is like the centre point of everything, it is in our best interest to understand what should be included within it.

First, we must declare ALL the required modules such as the express and mongoose at this point, like so:

//! Required Modules
const express = require('express');

//* This allows us to connect in our mongoDB

const mongoose = require('mongoose');

//! Port
const port = 4000;

//! Server
const app = express();

After declaring them, we then need to create a database connection first and foremost by utilising mongoose and use the dot notation to access the method called connect which allows us to connect to MongoDB Atlas remotely.

The first parameter should have the URI string taken from their site (https://cloud.mongodb.com/) after logging in. Locate the Database under the Deployment and click Connect and then click the Connect your application option from the given tools, then copy the URI string displayed.

The second parameter is optional, but it is ideal to add it in order to prevent the web application from crashing when MongoDB updates. See the full code below:

mongoose.connect(
    //mongodb+srv://CG:admin@cluster0.322.mongodb.net/tasks182?retryWrites=true&w=majority
    'mongodb+srv://admin:admin@233-course-booking.g54.mongodb.net/tasks182?retryWrites=true&w=majority', {
        useNewUrlParser: true,
        useUnifiedTopology: true,
    }
);

After creating the connection, the programmer has to know if a connection has been established successfully or not, right? In order to do that, we need to access the .connection method that is made available for us by mongoose and declare it in a variable like so:

//This will create a notification if the db connection is successful or not.
let db = mongoose.connection;

We can then tap the variable declared and check if the connection is successful or not by using the .on and the .once methods. What exactly are they?
.on signifies that the event will be called every time the specified event occurs.
.once signifies that the event will be called only ONCE the first event is triggered.

Let us first have a look at the .on code below:

db.on('error', console.error.bind(console, 'DB Connection Error'));

Notice that we’re constantly checking for any error that may occur whilst the server is on as its first parameter. The second parameter is binding the error to both the console and the terminal.

Let us now have a look at the .once code below:

db.once('open', () => console.log('Successfully connected to MongoDB'));

In the code above, we’re checking if the connection is successful or open then we’re logging a message to the console which notifies the programmer that a connection has been established.

The next thing we’re tackling are the middleware that we need in order for our application to run smoothly. The first middleware is the express.json(), its sole purpose is to convert the request body into a JSON object. The next middleware is the express.urlencoded which enables the server to accept any data type on top of the string and array data types that it’s already accepting. Let’s have a look at their code snippets:

app.use(express.json());
app.use(express.urlencoded({ extended: true }));

Now, all we need to add to complete our app.js is to add the grouping routes which will allow us to connect our routes to the server. As shown in the image previously, by visiting the /users, we’re triggering our routes.

Now, what do they look like and how does it work? Let’s have a look at the code snippet below and then dissect what each of them do.

First, we’re declaring a variable that will hold the route (green box above). Next, we’re requiring the routes that we want to trigger (beige colour) which resides in a different file path which is relative to the root file (app.js).

We’re now going to use the routes as a middleware which will run after the request is received and before the response is triggered (app.use). The first parameter is the endpoint (orange box) that we want to trigger our route (yellow box).
Lastly, all we need in our app.js is to add the port:
app.listen(port, () => console.log(Listening to port: ${port}));

Route file
The route file is where we are going to trigger the business logic which resides in the controller. In this file, we first need to declare the required modules just like what we did in the app.js. The first module we need is the express.
const express = require('express');

The next module that we need is the router which will allow us to access HTTP methods without directly connecting to the server which is declared in our app.js.
const router = express.Router();

But why do we need it instead of just declaring another server you say? Well, it’s because by doing so, we’re not really separating the concerns that we’re trying to achieve.
After declaring the router, we now need to declare the controller that we need to execute which resides in a relative folder; accessed through the relative path using “../”.
const usersController = require('../controllers/usersController');

Now need to execute the controller that holds the business logic for the /users endpoint. However, let us first understand what’s happening with the code below:
router.post('/', usersController.createUsers);

MVC, why do we need it.

Aisha A. — Tue, 06 Sep 2022 03:02:06 +0000

Why do we need to separate the concerns?

Imagine if you have to do your groceries inside a bank, wouldn’t that be chaotic? Or imagine if your groceries aren’t categorized where you’ll have to scour through the entire cupboard just to find the ingredient you need?

Likewise, programming works the same way. We separate our concerns for code readability and code maintainability. How so? Let’s first understand what a model, controller and routes is.

Model

Model is where your structure resides, it is where your data blueprint is. It contains the properties as well as the data type that we’re expecting from the user. This is where the schema and the model should be, like so:

const mongoose = require('mongoose');
const taskSchema = new mongoose.Schema({
name: String,
status: String,
});

module.exports = mongoose.model('Task', taskSchema);

Controller

Controller is where our business logic resides. This is where the brain of the program is. Previously, we’d put all the business logic inside the route like so:

app.post('/items', (req, res) => {
let newItems = {
name: req.body.name,
price: req.body.price,
isActive: req.body.isActive,
};

items.push(newItems);
res.send(items);
});

Our business logic can be quite convoluted if there are hundreds or thousands of them. Hence, we separate it in a different file called “Controller.js” under a folder called “controllers” where all our controllers will reside.

On that note, please bear in mind that a controller goes side by side with the route.

Route

Route is where the routes reside. This is where the **endpoints **should be defined. As mentioned above, the route, work side by side with the controller, like so:

const express = require('express');
const router = express.Router();

const taskControllers = require('../controllers/taskControllers');

console.log(taskControllers);

router.post('/', taskControllers.createTaskController);

module.exports = router;

Mongoose Router

Mongoose router allows us to use HTTP methods without having direct access to our server. What do I mean by that? In order to have access to the HTTP methods, we need to have access to the server which is defined by calling the server instance declared using the variable **app **and directly access the HTTP methods directly like so (see line number 3):

const express = require('express');
const app = express();

app.get('/items/getSingleItem/:item', (req, res) => {
res.send(items[+req.params.item]);
});

However, since the route file does NOT have access to the HTTP methods as it is NOT a server, we need a way to access it in order to define the routes and its function that needs to be performed.

const express = require('express');
const router = express.Router();
//Router method - allows access to HTTP methods

const taskControllers = require('../controllers/taskControllers');

console.log(taskControllers);

//create task route. At the moment, we don't have direct accessto the server, hence, we NEED to use router in order to have access to the HTTP methods
router.post('/', taskControllers.createTaskController);

module.exports = router;

Runtime Environment and the Javascript Engine

Aisha A. — Mon, 04 Oct 2021 19:50:25 +0000

Beginners often jump into coding without fully/partially understanding how the internet works or the runtime environment and the javascript engine.

It may or may not be beneficial to you depending on your goal.

However, if you aim to understand how things are connected and their process under the hood then you've come to the right place.

First of all, let's understand how the internet works from the moment you visit a site. In this example, we'll be using aifolio-journal.herokuapp.com.

When you visit "aifolio-journal.herokuapp.com", it will request your ISP (Internet Service Provider) which will then conduct a DNS lookup on the URL entered. DNS lookup is basically like yellow pages where every person has a designated name, address, and phone number. The name in this instance will be the URL, your ISP will check what is the address for the name provided (which is aifolio-journal.herokuapp.com, you can check the IP address by opening your command prompt and run the syntax "ping google.com").

Upon finding the address, the ISP will send it back to the user which in turn will make a direct request to the server with the IP provided.

The response will depend on how the route is handled. In this instance, the response will have an HTML file, CSS, and JS.

The Javascript will run in the runtime environment; but what exactly is a runtime environment? Think of it as a container that has all the necessary components to run your code. It will have the Javascript Engine, Web API, and a Callback queue.

The engine comprises 2 components, the Callstack where the codes are executed, and the Heap memory where all the objects are stored.

When the code first enters the engine, the engine will read it and then parse it into an AST (Abstract Syntax Tree) where the codes are de-structured in a meaningful way. For instance, if you have a code as const x = 10, it will be converted into AST (See image below)

The parsed codes (AST Objects) are the ones that are compiled into machine language (0's and 1's). Before we delve deeper, let's first take into consideration the difference between compilation and interpretation, which is the step the comes after the Parsing step.

An example of the compilation are programs that you've installed on your machine, you may execute them at any time but they are not compiled before execution, rather, they are compiled and bundled long before you even execute it. If you're familiar with Java then to illustrate that, when you compile your code, it provides you with a .class file; a file that is compiled into a machine code.

An interpreted language is what Javascript historically used. Where the codes are executed after compilation on a line-by-line basis. This is way slower than compilation as it needs to read each line of code before executing it. Imagine using Google Maps; whenever you pan around, there will be a second or more delay as it needs to calculate your location and the image that needs to be displayed.

JIT or Just-in-time compilation is a mixture of both compilation and interpreted language. It will read the code, compile it and then execute it; whilst the code is still running, it will fire up the optimization, optimizing the compiled code, recompiling it and then executing it. The latter process will enter a loop until the compiled code is fully optimized. The reason for this process is for faster and more efficient code execution, the faster it spits out compiled codes, the faster it can be executed.