Forem: Jalu Pujo Rumekso

How to close Bootstrap 5's modal with back button on Vue project

Jalu Pujo Rumekso — Wed, 25 Aug 2021 03:27:48 +0000

Say you are building a spa using Bootstrap 5 and Vue. And one of its functionality is displaying a list of product through a modal. And you want the modal to get closed when the user press the back button, just like how most mobile app behave.

How do you do that? Let me tell you.

Before we dive into the technical implementation, let's understand the logic first.

The logic is simple. When the user press back button while the modal is open, we want to tell Vue to close the modal instead of navigating back to the previous route.

From that simple logic now we know that we need to know four things:

First, when the user press back button.
Second, the Bootstrap modal's state (open/close).
Third, how to prevent Vue from going away to previous route.
Finally, how to close Bootstrap's modal programmatically.

Alright, let's get into it.

Project Setup

First, let's open the terminal and run vue create modal-demo to create a new Vue project. After the setup is complete, install Bootstrap using npm install bootstrap command. To include Boostrap's css add this line inside the style block of App.vue: @import "~bootstrap/dist/css/bootstrap.min.css".

Now let's add a bare bone component to work with. I'll name it ModalDemo and place it in the views folder since it's a page-level component.



<template>
  <button
    data-bs-toggle="modal"
    data-bs-target="#theModal"
    class="btn btn-primary"
  >
    Open Modal
  </button>
  <div id="theModal" class="modal" tabindex="-1">
    <div class="modal-dialog">
      <div class="modal-content">
        <div class="modal-header">
          <h5 class="modal-title">Modal title</h5>
          <button
            type="button"
            class="btn-close"
            data-bs-dismiss="modal"
            aria-label="Close"
          ></button>
        </div>
        <div class="modal-body">
          <p>Modal body text goes here.</p>
        </div>
        <div class="modal-footer">
          <button
            type="button"
            class="btn btn-secondary"
            data-bs-dismiss="modal"
          >
            Close
          </button>
          <button type="button" class="btn btn-primary">Save changes</button>
        </div>
      </div>
    </div>
  </div>
</template>



export default {
  name: 'ModalDemo',
};



import { createRouter, createWebHistory } from 'vue-router';

const routes = [
  {
    path: '/',
    name: 'Home',
    component: Home,
  },
  {
    path: '/modal-demo',
    name: 'ModalDemo',
    component: () => import('@/views/ModalDemo.vue'),
  },
  {
    path: '/about',
    name: 'About',
    // route level code-splitting
    // this generates a separate chunk (about.[hash].js) for this route
    // which is lazy-loaded when the route is visited.
    component: () => import(/* webpackChunkName: "about" */ '../views/About.vue'),
  },
];

const router = createRouter({
  history: createWebHistory(process.env.BASE_URL),
  routes,
});

As you can see, our component consist of a modal and a button to toggle it. The button has data-bs-toggle and data-bs-target to activate the modal on button click.

Then, we registered the component to Vue Router's routes. So now we have three components. The ModalDemo and the Home and About which is included by default when we create our project using vue create command. Now let's open the App.vue to add a link to our ModalDemo component.



// App.vue

<template>
  <div id="nav">
    <router-link to="/">Home</router-link> |
    <router-link to="/about">About</router-link> |
    <router-link to="/modal-demo">Modal Demo</router-link>
  </div>
  <router-view />
</template>

So here's what we gonna do to test the 'close bootstrap modal on back button' functionality. First we want to visit the home route (/). Then click the 'Modal Demo' link. Then click the button to open up the modal. Then, while the modal is open, we'll click the back button.

As you can see, by default Vue Router will take us to the previous route when we press the back button while the modal is open. Also it leaves the modal overlay open. And those are not what we want, right?

Alright, let's tackle our first task.

Detecting Back Button event on Vue

Well, honestly we can't detect when the user press the back button since there is no such an event. However, thanks to Vue Router's beforeRouteLeave navigation guard, we can execute code at the time when the user is about to navigate away from the currently rendered component. Whether the user wants to go back, forward, or to completely another route, the beforeRouteLeave got you covered.

So let's add the beforeRouteLeave navigation guard to our ModalDemo component definition.



beforeRouteLeave(to, from, next) {
  // check modal state and prevent navigation here
  next()
}

The beforeRouteLeave takes three argument: to, from, and next. The first twos give us information about the route that we are going to navigate to and from respectively. The next is a function that we need to execute to tell Vue whether we are allowing the navigation to occur. And it need to be executed once.

Alright, at this point that's all what we need to know about the role of beforeRouteLeave. For more information just check the official doc.

Identifying the state of Bootstrap 5's modal.

Lucky for us, Bootstrap 5 offers an out of the box functionality to check the modal's state via the Modal instance.

Here's how you want to instantiate a Bootstrap 5's Modal in Vue's component:



import { Modal } from 'bootstrap';

export default {

  ...

  data() {
    return {
      theModal: null
    }
  },

  ...

  mounted() {
   this.theModal = new Modal(document.getElementById('theModal'));
  }

}

We begin with importing the Modal and instantiate it at the mounted hook. Why the mounted? Because at the mounted we can access the DOM required for Modal instantiation.

Here we instantiate the modal by providing the Modal constructor with a modal element by an id of theModal (so make sure that at the template definition you have a valid modal markup with an id of 'theModal' or named it anything you want). Then we assign it to theModal data's prop so now our modal's props and methods is accessible from any place in the component code via this.theModal.

Note: you can optionally pass the second argument to the Modal constructor, which is modal's option object. Check here for further information about modal's option object.

Alright, now if you check theModal from Vue devtools we know that it has several properties and the one we're interested with is the _isShown prop. Its value is true when the modal is shown and vice versa.

Alright, now let's use it as a condition at our beforeRouteLeave navigation guard.



beforeRouteLeave(to, from, next) {

  if(this.theModal._isShown) {
    // cancel navigation here
  } else {
    // allow to navigate away as usual
    next()
  }

}

Note: The line of theModal._isShown will likely cause the eslint to throw 'no-dangle-underscore' error. To fix it we need to add an exception for the _isShown. We can do so by adding this rule: 'no-underscore-dangle': ["error", { "allow": ["_isShown"] }] to the rules prop of eslintrc.js.



// eslintrc.js

rules: {
    'no-console': process.env.NODE_ENV === 'production' ? 'warn' : 'off',
    'no-debugger': process.env.NODE_ENV === 'production' ? 'warn' : 'off',
    'no-underscore-dangle': ["error", { "allow": ["_isShown"] }]
  },

Alright, now can execute the real route cancelation!

Preventing Vue from Navigating Away

To prevent the app from navigating away we need to pass false to the next() method.



beforeRouteLeave(to, from, next) {

  // When the modal is shown
  if(this.theModal._isShown) {
    // cancel navigation
    next(false);
  } else {
    // allow to navigate away as usual
    next();
  }

}

Next, we just need to close the modal!

Close Bootstrap 5's Modal Programmatically

Now in Bootstrap 5, you want to call the hide() method on the modal instance to hide the modal.



beforeRouteLeave() {

  // When the modal is shown
  if(this.theModal._isShown) {
    // cancel navigation
    next(false);
    this.theModal.hide();
  } else {
    // allow to navigate away as usual
    next();
  }

}

Alright, now try to open the modal and click the back button. As you can see, the app won't going anywhere except to close down the modal. It works!

That's it! Thanks for reading

Note: Sorry for poor gif. I create it using Peek on Ubuntu laptop. If you know a better way to do this task, feel free to leave your comment out. Thank you.

Data Validation in Hapi

Jalu Pujo Rumekso — Mon, 22 Feb 2021 01:39:55 +0000

Today Joe wants to enhance his app with a layer of validation. He thinks validation is a basic requirement to prevent nonsensical inputs.

Joi

Thankfully, there is a wonderful library that can help him achieve this goal easily. The library is Joi (funny enough, it has a similar name to Joe). On its site, Joi describes himself as "the most powerful schema description language and data validator for JavaScript". Awesome!

Without further ado, Joe begins adding Joi to his project by running npm install joi. Then as usual, before he can do amazing things with the library, he needs to require it and store it in a variable: const Joi = require("joi").

The documentation says that he can start using Joi by defining his data first. Then that data definition will be used to validate the incoming input. Defining data is done by calling the available methods on Joi instance. At Joi's official documentation he finds a comprehensive list of the available methods. Here are some that picks Joe's interest:

string() which means it must be a string,
min() chained after string() to define the minimum string characters,
max() chained after string() to define the maximum string characters,
required() which means it is required,
integer() which means it must be an integer, etc.

Joe finds the methods are self-explanatory so he thought it must be easy to learn the others as well for a more complex use case later.

Joe reviews his store data. It has three properties: id, name, and address. The id will be generated automatically by the database so he doesn't need to worry about it. For the name, it's obviously must be a string. And since it's the main descriptor of a store, he wants it to be classified as required. Also, he wants its length to be 30 characters at max. For the address, he only wants it to be a string. So here is his code:

const storeSchema = Joi.object({
  name: Joi.string()
    .max(30)
    .required(),
  address: Joi.string(),
});

Using Joi with Hapi

Now the question is how to use this schema to validate the request payload in Hapi? Fortunately, Joi integrates very well with Hapi. All Joe needs to do is assigning the schema to options.validate.payload or options.validate.query or options.validate.params of a route, depends on what input he wants to validate. In this case, Joe wants to validate the payload at the create and update store route.

Here is how he implements it at the create store route:

server.route({
  method: "POST",
  path: "/api/stores",
  handler(req) {
    const newStore = {
      id: stores.length + 1,
      name: req.payload.name,
      address: req.payload.address ?? null,
    };

    stores.push(newStore);

    return newStore;
  },
  options: {
    validate: {
      payload: storeSchema,
    },
  },
});

And here is how he implements it at the update store route (which is identical):

server.route({
  method: "PUT",
  path: "/api/stores/{id}",
  handler(req) {
    const { id } = req.params;

    const theStore = stores.find((store) => store.id === parseInt(id));

    theStore.name = req.payload.name ?? null;
    theStore.address = req.payload.address ?? null;

    return theStore;
  },
  options: {
    validate: {
      payload: storeSchema,
    },
  },
});

Then he tests the create store route by sending this request:

POST http://localhost:3000/api/stores HTTP/1.1
content-type: application/json

{
  "name": 1
}

He intentionally assigns an integer to the name property. So how does the app respond?

Here is what he gets back from the app:

HTTP/1.1 400 Bad Request
content-type: application/json; charset=utf-8
cache-control: no-cache
content-length: 82
Date: Sun, 21 Feb 2021 06:44:56 GMT
Connection: close

{
  "statusCode": 400,
  "error": "Bad Request",
  "message": "Invalid request payload input"
}

He was greeted by Bad Request error with a message of invalid request payload input. The message clearly indicates that his code works. But he isn't satisfied with the generic error message. Yes, it's true that the payload is invalid, but what's the reason? He wants to know it too.

Throwing Joi's Original Error

As usual, then he goes to his friend asking about "joi hapi validation error". And as usual, his friend does a good job finding the information that he needs.

So here is what he finds. It turned out that since version 17, the Hapi team decided to not send Joi's input validation errors to the client. Hapi will send a generic 400 error instead such as what he saw above. They explain that it's a security consideration. He finds the answer from this interesting discussion.

Fortunately, Hapi provides a workaround for people like Joe who want to get the original Joi's validation error. It's done by configuring the routes.validate.failAction() on the server configuration object.

The failAction() method is an async function. It has three parameters: req, h, and err. The last parameter is where Joi's original error resides. So throwing it will send the error back to the user when the validation fails.

Now here is how Joe's server object looks:

const server = Hapi.server({
  port: 3000,
  host: "localhost",
  routes: {
    validate: {
      async failAction(req, h, err) {
        console.error(err);
        throw err;
      },
    },
  },
});

He throws the error back to the requester also console.log() it so he can inspect it from the terminal as well.

Then when he sends the same request as before, he gets this:

HTTP/1.1 400 Bad Request
content-type: application/json; charset=utf-8
cache-control: no-cache
content-length: 128
Date: Sun, 21 Feb 2021 07:04:48 GMT
Connection: close

{
  "statusCode": 400,
  "error": "Bad Request",
  "message": "\"name\" must be a string",
  "validation": {
    "source": "payload",
    "keys": [
      "name"
    ]
  }
}

And when he sends an empty name, he gets this:

HTTP/1.1 400 Bad Request
content-type: application/json; charset=utf-8
cache-control: no-cache
content-length: 123
Date: Sun, 21 Feb 2021 10:31:52 GMT
Connection: close

{
  "statusCode": 400,
  "error": "Bad Request",
  "message": "\"name\" is required",
  "validation": {
    "source": "payload",
    "keys": [
      "name"
    ]
  }
}

Now Joe feels happier because he receives a more meaningful message. Although Hapi suggests to him not to throw the detailed error, he wants to keep it this way for the development purpose.

Then he realizes something that's not quite right.

Since he tells Joi that the required property is only the name property, then there'll be a case where the user doesn't send the address. If the user doesn't send the address then Javascript will assign undefined to the address property. Joe doesn't want that. He wants Javascript to assign null instead. So he modifies his code to implement that functionality. Here is how his code looks:

server.route({
  method: "POST",
  path: "/api/stores",
  handler(req) {
    const newStore = {
      id: stores.length + 1,
      name: req.payload.name,
      address: req.payload.address ?? null,
    };

    stores.push(newStore);

    return newStore;
  },
  options: {
    validate: {
      payload: storeSchema,
    },
  },
});

server.route({
  method: "PUT",
  path: "/api/stores/{id}",
  handler(req) {
    const { id } = req.params;

    const theStore = stores.find((store) => store.id === parseInt(id));

    theStore.name = req.payload.name;
    theStore.address = req.payload.address ?? null;

    return theStore;
  },
  options: {
    validate: {
      payload: storeSchema,
    },
  },
});

Joe uses the nullish coalescing operator which basically says: is req.payload.address has a value other than undefined or null? If it has, then uses that value, otherwise assign null.

With this new modification, then his create/update store route will always return three properties: id, name, and address that can be a string of address or null.

The modification also concludes Joe's learning session today. He feels satisfied with the new enhancement on his app. Now he doesn't have to worry about his user sending a number or even an empty string to name his store.

Next time he wants to learn about the response toolkit.

Defining Routes in Hapi

Jalu Pujo Rumekso — Fri, 19 Feb 2021 14:05:03 +0000

Today Joe has plenty of time to learn more about Hapi. His target is learning how to add routes to his server so it can accept requests for creating and modifying data. And obviously, he also wants to be able to respond to the request back.

Before going straight to the documentation, Joe tries to guess it. He has a strong feeling that routing in Hapi has something to do with the server object. Because from the last learning session, he knew that the server object is the main application container. And if it has a bunch of properties such as server.info, then it should also have a bunch of methods and one of them must be a route-related method. That what's Joe thinking about.

Then he checks his hypothesis by visiting the documentation, especially the server object API section. And yes he is right. Indeed Hapi has server.route() which responsible for defining route endpoints. Finding his hypothesis get validated, he intends to use that educated guess more often in the future.

Creating Endpoints

The server.route() accepts an object as the only parameter with a format of {METHOD, PATH, HANDLER}, which is self-explanatory.

method is a string that refers to the name of the HTTP method Joe wants to respond. It accepts any valid HTTP method.
path is a string that refers to the actual path that the user will type in the browser (following the hostname).
handler is a function where he puts his code for that particular route

Given that new knowledge, Joe creates a test route that accepts GET request. Inside the handler, he returns a string that said 'OK'.

server.route({
  method: "GET",
  path: "/test",
  handler() {
    return "OK";
  },
});

He starts his server and the terminal greets him with the server info which means his code from the previous coding session is still work. Then he opens his favorite web browser and types out the http://localhost:3000 followed by the route path /test at the address bar. When he hits enter, the browser shows 'OK'. Great!

Now Joe is ready to replicate the successful test to his initial mission. What is his mission anyway? The point of sale app! After reviewing his mission brief, Joe decides that he'll start with the store resource.

He wants the GET stores route to return an array of store objects. However, since he doesn't want to work with the database yet, he will just hardcoded it.

So here is Joe's simple pseudo database:

const stores = [
  {
    id: 1,
    name: "JoeTech Store 1",
    address: "East Java, Indonesia",
  },
  {
    id: 2,
    name: "JoeTech Store 2",
    address: "Lombok, Indonesia",
  },
  {
    id: 3,
    name: "JoeTech Store 3",
    address: "Bali, Indonesia",
  },
];

And for the GET store route his code looks like this:

server.route({
  method: "GET",
  path: "/api/stores",
  handler() {
    return stores;
  },
});

As we can see, he prefixes the stores path with api and uses a plural form for the resource name. Where does he get that information? His best friend, Google. And for the handler, he writes it in the shorthand syntax which is introduced in ES6.

One more question, where does he put that code? At first, he puts it inside the init function following the example at Hapi documentation. But when he found that his code still works even if it placed outside the init function, he chooses to place it there. He thinks that it's cleaner that way.

So now his app.js code looks like this:

const Hapi = require("@hapi/hapi");

const server = Hapi.server({
  port: 3000,
  host: "localhost",
});

const stores = [
  {
    id: 1,
    name: "JoeTech Store 1",
    address: "East Java, Indonesia",
  },
  {
    id: 2,
    name: "JoeTech Store 2",
    address: "Lombok, Indonesia",
  },
];

server.route({
  method: "GET",
  path: "/test",
  handler() {
    console.log("it works...");
    return "OK";
  },
});

server.route({
  method: "GET",
  path: "/api/stores",
  handler() {
    return stores;
  },
});

const init = async () => {
  try {
    await server.start();
    console.log("Server started...");
    console.log(server.info);
  } catch (error) {
    console.log(error);
  }
};

init();

Then he opens his browser again and going to http://localhost:3000/api/stores. When he hits enter, the browser gives him this beautiful response, which is the exact same stores array he created before:

[
  {
    id: 1,
    name: "JoeTech Store 1",
    address: "East Java, Indonesia",
  },
  {
    id: 2,
    name: "JoeTech Store 2",
    address: "Lombok, Indonesia",
  }
]

Testing API using REST Client Plugin

Joe realizes that testing his api using a browser will only work for GET endpoint. How about the other endpoints? From a lot of tutorials on Youtube, he knew that the most common way to test API is using Postman. But he wonders if there is a more simple approach to accomplish this task. Then he remembers something...

From his frontend development experience, he found that his favorite code editor, the VS Code, has many plugins available (thanks to the wonderful community). So he thought maybe there is a plugin for this particular task. So he goes to his best friend asking this matter. Here is what he asks Google: "how to make api call from vscode". Without much thinking, his friend gives him a lot of information. But there is one particular piece of info that Joe thinks would work for him, the REST Client plugin by Huachao Mao.

How to use REST Client plugin to test api?

The documentation says that first, he needs to create a file with .http extension. Joe names it ApiTest.http. Then he needs to write the request with a format like this METHOD URI HTTP/1.1. So here is what he writes for testing the test route:

GET http://localhost:3000/test HTTP/1.1

And to send a payload we write the request like this:

POST http://localhost:3000/test HTTP/1.1
content-type: application/json

{
    "message": "Hello"
}

Then to execute the request he needs to click the Send Request link at the top of the file.

Joe thinks that this plugin is surprisingly easy and intuitive. Thanks to this plugin, now Joe doesn't need to go back and forth between his code editor and Postman.

Query Parameter

Joe wants the user of his app to be able to search stores by name. He thinks this feature is important when his user has many stores. Also, it's pretty common by the way.

In this case, Joe needs to know how to get the value of the query parameter so when he types .../stores?name=something he can catch that 'something' and use it to filters the stores data.

The documentation says that Joe can access the query parameter's value from the request parameter object. It's available as the first parameter of the route handler function. It can be named anything, however, the common one is request or req for short.

Then Joe tries to implement it. Here is his code:

server.route({
  method: "GET",
  path: "/api/stores",
  handler(req) {
    const { name } = req.query;

    if (name) {
      return stores.filter((store) => store.name === name);
    }

    return stores;
  },
});

Now he wants to test this new capability as well as testing the REST Client plugin for "a real use case". Here is what he writes at ApiTest.http:

GET http://localhost:3000/api/stores?name=JoeTech Store 1 HTTP/1.1

And here is the result after he clicks the Send Request:

HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
cache-control: no-cache
content-length: 68
accept-ranges: bytes
connection: close
Date: Wed, 17 Feb 2021 21:48:37 GMT

[
  {
    "id": 1,
    "name": "JoeTech Store 1",
    "address": "East Java, Indonesia"
  }
]

This way, his GET stores route is capable of filtering the stores based on the name specified by the user via the query parameter. Awesome!

Defining Path Parameter

Listing all stores is only half useful if the user can't see each store's details. So now Joe wants to create a route for retrieving a single store by its id.

What does he need to know to achieve this goal? He needs to know how to define and access a path parameter in Hapi.

The documentation says that to define a path parameter Joe needs to wrap the name of the parameter with curly braces and simply include it in the path. In this case, what Joe wants to do is writing the route's path in this fashion: /api/stores/{id}. Then he can access that 'id' from the same request object above, specifically from the params property.

After understanding that explanation, Joe writes the GET single store route. His code looks like this:

server.route({
  method: "GET",
  path: "/api/stores/{id}",
  handler(req) {
    const { id } = req.params;
    return stores.find((store) => store.id === id);
  },
});

His code looks good. He uses the req.params to access the id. Or more precisely, he uses ES6 destructuring to extract the id from req.params.

However, when he runs it, he gets this instead of the data of store with id 1:

HTTP/1.1 500 Internal Server Error
content-type: application/json; charset=utf-8
cache-control: no-cache
content-length: 46
Date: Wed, 17 Feb 2021 06:56:29 GMT
Connection: close

{
  "statusCode": 500,
  "error": "Internal Server Error",
  "message": "An internal server error occurred"
}

And when he checks the terminal, it says:

Debug: internal, implementation, error
    Error: handler method did not return a value, a promise, or throw an error
    ...

When he checks whether the id is obtained successfully using console.log(), it is. But why it still gives him an error? What's wrong?

Then he realizes that the path parameter is a string and he uses a strict equality operator to compare it with the store's id which is an integer, of course, he gets an error. So he fixes his code by parsing the path parameter's id to an integer. His code looks like this now.

server.route({
  method: "GET",
  path: "/api/stores/{id}",
  handler(req) {
    const { id } = req.params;
    return stores.find((store) => store.id === parseInt(id));
  },
});

Now GET request to http://localhost:3000/api/stores/1 returns:

HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
cache-control: no-cache
content-length: 46
Date: Wed, 17 Feb 2021 16:56:29 GMT
Connection: close

{
  "id": 1,
  "name": "JoeTech Store 1",
  "address": "East Java, Indonesia"
}

It works!

Capturing Payload

Now Joe wants to work on the create store route. For this task, Joe needs to know how to capture the payload. So how does Hapi handling this matter?

Like the path parameter, the payload is also accessible via request object. For example, if Joe wants to echo out the user's payload at his POST /api/stores, then the code will look like this:

server.route({
  method: "POST",
  path: "/api/stores",
  handler(req) {
    return req.payload;
  },
});

After understanding the method of getting the user's payload then Joe implements the "real" logic for the create new store route.

server.route({
  method: "POST",
  path: "/api/stores",
  handler(req) {
    const newStore = {
      id: stores.length + 1,
      name: req.payload.name,
      address: req.payload.address,
    };

    stores.push(newStore);

    return newStore;
  },
});

Since he uses an array as dummy data, he only needs to catch the incoming store data and push it into the stores array. The data from the payload is passed unchanged except for the id which he manually adds by incrementing the array length by one. Of course, when he uses a database later the code will be more complex than this. After the store is added, he is returning the newly created store.

Now it's time to test it. Joe opens the ApiTest.http file and writes the following to create a post request to his new endpoint:

POST http://localhost:3000/api/stores HTTP/1.1
content-type: application/json

{
  "name": "Amalina",
  "address": "Jakarta, Indonesia"
}

When he clicks Send Request, he gets the following response:

HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
cache-control: no-cache
content-length: 46
Date: Thu, 18 Feb 2021 14:06:29 GMT
Connection: close

[
  {
    "id": 3,
    "name": "Amalina",
    "address": "Indonesia"
  }
]

It means his code is working! Good job Joe!

There is only one route left, the edit store route which accepts a PUT request. Joe thinks that all of his routes, this is the most complex one. This route requires him to catch the path parameter as well as the payload. Thankfully, since he already nails the concept into his head, this complex task becomes easy for him. So here is his code:

server.route({
  method: "PUT",
  path: "/api/stores/{id}",
  handler(req) {
    const { id } = req.params;

    const theStore = stores.find((store) => store.id === parseInt(id));

    theStore.name = req.payload.name;
    theStore.address = req.payload.address;

    return theStore;
  },
});

At the handler function, Joe grab the store's id from the path parameter. Then he uses that id to find the store. Then he updates the store data with the incoming payload.

He told by the internet that the PUT request should send a full resource. So even if he only wants to update certain property, he still need to send the full resource. So he needs to provide all the neccessary means to edit all store's properties: theStore.id, theStore.name and theStore.address. Surely he needs to find a more elegant way in the future when the store's details is not just name and address anymore.

Also he found many warnings to think that POST is exclusively for creating resource and PUT is exclusively for editing resource. Many people said that that's wrong! In fact, both POST and PUT can be used to create and edit a resource. Even though, in practice, he found many tutorials that simply map POST for create operation and PUT for edit operation.

Being a good beginner, who doesn't have much experiences yet, he tries to follow what the community said as well as what is make sense for him.

Then Joe tries his new route by sending a PUT request to modify the name of the store with id 1.

PUT http://localhost:3000/api/stores/1 HTTP/1.1
content-type: application/json

{
  "id": 1,
  "name": "J-Tech",
  "address": Indonesia
}

And here is what he gets:

HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
cache-control: no-cache
content-length: 46
Date: Fri, 19 Feb 2021 06:56:29 GMT
Connection: close

{
  "id": 1,
  "name": "J-Tech",
  "address": "Indonesia"
}

Thank God, it works!

Having all store routes completed, Joe decides to call it a day. Joe feels happy as he has learned the skill to create routes in Hapi. For the next session, he wants to learn about validation in Hapi so he can make his app more stable.

Creating a Server in Hapi

Jalu Pujo Rumekso — Sun, 14 Feb 2021 13:32:47 +0000

It's Sunday, which for Joe it means that he has much time to continue his business on learning Hapi. In his pajamas, he opens his laptop, turns it on, and then navigates to Hapi documentation to learn about how to create a server.

From the documentation, Joe found that to create a server in Hapi, he needs to do the following.

First, the most obvious one, he needs to import Hapi and store it inside a variable.

To execute this step, he creates his first file and names it app.js. Then, he imports Hapi and assigning to a variable named Hapi. Actually, he can name it anything, but he chooses the most typical one.

const Hapi = require("@hapi/hapi");

Second, he needs to create a server object by calling Hapi.server() and assigning it into a variable. Again, he can name it anything, he chooses the most common one: 'server'.

const server = Hapi.server();

"That's it? Wow, super easy! He said.

After having the server object, Joe wanted to start it. After all, what's the purpose of a server if it just sits there and serves nothing, right?

Then, Joe call server.start() to start the server.

That alone will work, however, the documentation mentions that server.start() is actually a promise that returns no value. And a promise is still a promise even if it returns no value, right? So he needs to treat it properly either by using .then() or async/await. He opted for the async/await since it makes his code concise.

It means Joe needs to create an async function that wraps the await server.start(). Also, it would be nice if he caught its error too, in case something gone wrong.

Now his code looks like this:

const init = async () => {
  try {
    await server.start();
    console.log("Server started....");
  } catch (error) {
    console.log(error);
  }
};

So, now to really start the server, Joe calls init() instead of calling server.start() directly.

Finally, Joe's app.js file looks like this:

const Hapi = require("@hapi/hapi");
const server = Hapi.server();

const init = async () => {
  try {
    await server.start();
    console.log("Server started....");
  } catch (error) {
    console.log(error);
  }
};

init();

Then he opens up his terminal, navigating to his project folder, and runs node app.js. Instantly, he sees the terminal shows the Server started... log message. It means his server is working. Yay!

Server Properties

After successfully started the server. Joe dives deeper into the documentation to find out more about the server object. He finds that the server has several properties. Most of them are read-only and seem too advanced for him right now.

One particular property that picks his interest is server.info. It's an object that describes the server about its id, server creation and starts time, port, host, address, protocol, and uri.

Joe wants to see server.info in action, so he adds it into his init function.

const init = async () => {
  try {
    await server.start();
    console.log("Server started....");
    console.log(server.info);
  } catch (error) {
    console.log(error);
  }
};

When he spins up the server, here is what he sees on his terminal:

Server started...
{
  created: 1613264249044,
  started: 1613264249059,
  host: 'L645',
  port: 40549,
  protocol: 'http',
  id: 'L645:6956:kl4fvpas',
  uri: 'http://L645:40549',
  address: '0.0.0.0'
}

At this point, Joe feels happy because he was able to know about his server information. But then he gets curious, "How to modify some of those properties?"

Server Options

After doing a quick search at the Server API documentation, he finds that he can configure the server by providing a server configuration object. Basically, it's just another server property like server.info above.

The documentation shows a bunch of the available configurations. However, as a Hapi beginner, here are some options that he familiar with:

host: refers to the operating system hostname, which is set at the time when the operating system is installed. If the machine has no hostname specified, it will default to 'localhost'.
port: the TCP port the server will listen to. If not specified, it'll be assigned with the available port at the time the server started.
tls: an option object to create https. It consists of key and cert properties which are identical to the option object passed into raw Node https.createServer().
address: the hostname or IP address. Its default value is 0.0.0.0. However, if Joe set the host option to localhost then its value will be 127.0.0.1

Then Joe tries to configure his server to listen to port 3000 and set host to localhost, which is a common setup he found on the internet.

const server = Hapi.server({
  port: 3000,
  host: "localhost",
});

Now when he spins up the server, the terminal shows something like this:

Server started...
{
  created: 1613264576969,
  started: 1613264576983,
  host: 'localhost',
  port: 3000,
  protocol: 'http',
  id: 'L645:7011:kl4g2qbt',
  uri: 'http://localhost:3000',
  address: '127.0.0.1'
}

Testing for Error

Up until now, Joe finds his code always works. While it's good, he wonders if the code inside the catch block of the init function actually can do his job. So he tries to cause an error by mistyping the hostname.

const server = Hapi.server({
  port: 3000,
  host: "loclhst",
});

Now when he run his server he sees:

Error: getaddrinfo EAI_AGAIN loclhst
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:67:26) {
  errno: -3001,
  code: 'EAI_AGAIN',
  syscall: 'getaddrinfo',
  hostname: 'loclhst'
}

Then he removes the catch block to see the difference, so his init function looks like this:

const init = async () => {
  await server.start();
  console.log("Server started....");
  console.log(server.info);
};

Now when he runs the server, he gets UnhandledPromiseRejectionWarning like this:

(node:10184) UnhandledPromiseRejectionWarning: Error: getaddrinfo EAI_AGAIN loclhst
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:67:26)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:10184) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:10184) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Now Joe knew that when there is an error, the server stopped and the catch block inside the init function is doing its job. Without it, Node will spit out the UnhandledPromiseRejectionWarning. With it, he got a more friendly error message.

Watching for Changes

Joe feels like he ready to move on to the next topic. However, he feels that stopping and restarting the server every time he made changes is bothersome. He believes there must be a solution to this problem. And yes there is, nodemon. It's a simple program that will watch for changes on his node app and restart it accordingly.

Without further ado, he installs nodemon by issuing npm install -g nodemon command to his terminal. He adds the -g flag because he want it available globally to all of his project.

So now instead of starting the server with node app.js, he uses nodemon app.js. This way, the server will restart automatically every time he made modifications to app.js (as long as not an error, which will stop the server).

Joe decides to call it a day and rewards himself with a cone of ice cream. Among all other places in his house, he chooses the living room to enjoy the ice cream. He sits there facing the open door. He likes this spot because he can rest his eyes by looking at the dancing trees across his house. His mouth busy with the tasty ice cream while his mind happily recalls what he had accomplished today. Now he knows how to include Hapi in his project, how to create a server, and how to access the server's info. He also knows how to configure the server and successfully caught its error.

But he realizes that all of those things are only the beginning. His server still does nothing even if it's active. No users except him can interact with it yet. So he decides that tomorrow he needs to learn how to make his server does something more useful than simply outputting 'Server started...'. He wants his server capable of accepting and responding to requests.

Barebone Hapi Project Setup

Jalu Pujo Rumekso — Fri, 12 Feb 2021 09:04:19 +0000

It's a quiet night. No tv sound, no traffic sound, just a group of the cricket singing. Joe can't wait to open his laptop. He's been busy helping his wife running a multi-branch store all day long. Now he has the time, he feels happy and wants to jump directly into his own business. What business do you ask? The business of starting a Hapi project.

Initialization

Joe began his project with git init and npm init. After filling out the details, he installed HapiJS by running npm install @hapi/hapi. He sees the terminal showing an installation progress bar. When the process is completed, he checks the size of his project folder. To his surprise, it's only 1.9 MB.

Project Structure

After Hapi got installed, Joe begins to wonder about how to structure his project. Then he does a quick search for the best practices online. He finds people ask the same question at Stack Overflow and Hapi Github's issue. From those two sources, he finds many recommendations.

Then he decided that his project structure was like this:

assets (folder): contains static files such as images;
config (folder): contains app configurations
models (folder): contains data models
routes (folder): contains routes handlers
app.js: the app's main file or the entry point
package.json: a file created from npm init command
.gitignore: a file containing a list of files that need to be ignored by git

That structure is just his personal preference and he is happy with it.

Joe looks at the clock, it's 23:00, which is quite late for him since he has to wake up at 03:30 tomorrow. So he decides to call it a night and close his laptop.

Before he goes to sleep, he writes his target for learning Hapi tomorrow: creating my first Hapi server.

References

Here are the references that Joe use to set up his project:

Hapi.js - Project Structure and Best Practices (Part 2)
Best Practice Project Structure
.gitignore template was taken from here.

Introduction to Learn Hapi/MySQL Series

Jalu Pujo Rumekso — Fri, 12 Feb 2021 02:02:49 +0000

I'm learning Hapi/MySQL now and I thought it would be fun to share what I learned through a series here.

Alos, to make this series even more interesting, fun, and easy to read, I will present it through a story of a person learning HapiJS. The person is Joe — an ambitious man who determined to build a software as a service app.

Disclaimer

Obviously, since I'm still learning it, I am not a Hapi/MySQL expert. So, please do understand that whatever I tell you in this series comes from a fellow learner's perspective, not as a Hapi or MySQL expert.

Prerequisites

In order to be able to follow this series easily, at least you've got Javascript fundamental covered and getting comfortable at using terminal and NPM. Prior experience with Node development or other Node frameworks is beneficial but is not required.

So If you are totally new to Javascript, understand the basics first and come back later.

And technically, you should have the following programs installed:

Node
NPM
MySQL

Alright, I think it's enough for the introduction. Let's start Joe's story.

Background Story

After getting comfortable with writing Javascript for the frontend, Joe decided that he should learn Node backend development too so he could become a full-stack Javascript developer. That way, he can independently create an API to power his frontend app.

Fortunately, Joe already has some familiarity with a particular database, namely MySQL. He learned it a long time ago from a course Intro to SQL: Querying and Managing Data that is available for free at Khan Academy. Yes, he knew that, from his research, the Javascript community actually prefers MongoDB, however, he wants to use his existing knowledge so he could get up and running as soon as possible. So for now, he will stick to MySQL until he finds a good reason to switch to others.

And for the Node framework, he chose HapiJS.

What and Why Hapi?

So what is Hapi and why Joe chose it?

Here is what Joe found in his research.

On Hapi's official site. Joe found these:

"The Simple, Secure Framework Developers Trust"
"Build powerful, scalable applications, with minimal overhead and full out-of-the-box functionality"
"Originally developed to handle Walmart’s Black Friday scale."

"If it's simple then I'll be able to understand it easily. If it's secure then it would save me a lot of trouble on a security matter that I am clueless about. If it's full out-of-the-box functionality then I don't need to deal with much third-party library. And if it can handle Walmart's Black Friday, then surely it can handle my simple app!", John said to himself.

Joe also found these convincing pieces of information from DWYL's Learn Hapi repo:

WalmartLabs are the guys who found/solved the Node.js CORE Memory Leak; they have developed Hapi following Benchmark Driven Development and the result is a high-performance framework
The Lead Developer of Hapi is Eran Hammer who was one of the original authors of the OAuth (Secure Authentication) Spec. He has built a security-focussed mindset into Hapi and reviews all code included in Hapi. Several members of the Node Security Project are core contributors to Hapi which means there are many security-minded eyes on the code.

So that's Hapi and why Joe chose it.

The Mission

Joe decided that he should build a point of sale app. The reason is that he wanted to modernize his wife's retail store. Until now, the store's transaction was still recorded using pen and paper. For some basic usage, it's pretty convenient. However, when it comes to searching and analyzing the transaction, it's a nightmare!

In order to be useful to power his wife's store digitally, Joe thought that the app should have the following features:

Recording sales (obviously)
Ability to sell on credit
Applying discount
Creating multiple stores
Tracking inventory
Transfer order
Purchase order
Stock Adjustment
Multiple roles: owner & employee

Also, Joe wanted his app to have the following features so he can offer the app to other store owner and make money from it:

Offering subscription plan
Accepting payment

Then Joe began his research on how to make that kind of app. Soon he realized that the app is not trivial. It requires comprehensive learning of backend development. At least he should be able to do the following tasks to turn his idea into reality:

Creating server
Defining endpoints of various HTTP methods
Handling user request
Defining model
Working with database
Authentication with JWT
Authorization

After defining the goals, now Joe is ready to embark on his first journey on learning HapiJS.

How To Show a Background Overlay and The Content of a Column on Hover in Elementor

Jalu Pujo Rumekso — Fri, 21 Aug 2020 22:48:53 +0000

In this post, I am going to show you how to display a background overlay of a column and the headline widget on top of it when the user hovers over the image. The final product would be like this:

Cool, isn’t it? So let's get started!

Set Up The Image and The Content

Add a new section and choose the two-column structure. Then click Edit Column.

In Style > Background > Background Type choose Classic. Then under Image click the + sign to add the Image you want to display.

For now, you'll only see a very small portion of the image. No worries, it happens because our column doesn’t have any content yet. So let's add a Headline Widget on it.

Why is it still the same? Since our Headline widget is only a one-line content, then the column doesn't get much additional height.

However, by adding this content now we can adjust the column padding and see the change. If you do it before adding the content, you won't see the result until you place the content. Do you get it?

Now let's adjust the padding.

Click Edit Column and go to Advanced tab. Before we add the padding, let's turn off the Link Values Together button so we can set each padding value individually.

Now set the padding for the top and bottom value to make the column stretched vertically. You can play around with the number, but for the purpose of this tutorial let's set it to 300 hundred since I know it'll look good.

Please note that we make the top and bottom padding identical because we want the content to be vertically centered.

Alright, now we've successfully made our image visible, but it only shows us a small part of it. We don't want that right? Let me show you how to fix it.

Go to Style > Background and set the Position to Center Center. Next, change the Repeat to No Repeat. Lastly, set Size to Cover.

Voila, now we have a beautiful image that takes half of our screen.

Set The Overlay

Now we've our image set up, then our next step would be setting up the background overlay. Let's proceed.

Go to _Style > Background > Hover. Next, choose Classic for the Background Type and set the color.

If you do it right, now you should have a column filled with an image that shows a background overlay on hover. And that's it for the image.

Adjusting the Text

Before we move on, let's change the content of our Headline widget into something more meaningful. I'll change it to "A Cozy House with Sea View".

Now let's edit the color so it goes well with our background overlay.

Look good?

I think yes, except for one thing: the text is too close to the edge of the image. Let's add some padding to it so it has more room to breathe.

And that's it. Now we have text on top of an image with an overlay on hover.

Our next step would be to hide the text on the normal view before we can reveal it on hover.

The CSS Code

To hide our text, we need to set the opacity to 0. For this task, we need to set it manually using CSS since there is no such an option in the Elementor editor.

There are two steps in using CSS to customize the Elementor widget. First, we need to give the widget a CSS Class or ID name. Second, we need to write the CSS code itself.

Let's do it.

Go to Advanced tab and give the CSS Classes a name. I'll name it 'my-hidden-headline'.

Then, we need to give our column a CSS Class name too so we can target it when the user hovers on it.

Go to Advanced tab and fill the CSS Class with a name, let's name it 'my-bg-overlay'.

Why we use CSS Class instead of ID? I prefer to use class than id because it opens up the possibility to use it more than once on the same page. In our case, it means that we can use the 'my-hidden-headline' again for other Headline widgets somewhere on this page. If we use ID, that will be only for that specific widget.

Now, before we add our CSS code in the theme customizer, let’s save our changes first. So, click UPDATE and view your page.

Then click Customize and copy the following code:

After that, paste that code into Additional CSS setting panel and click Publish.

What we are doing here is targeting the my-hidden-headline class and set its opacity to 0 so it becomes hidden on the normal view.

Finally, copy this code:

and paste it below the previous code. This final code set the headline widget opacity back to 1 when the my-background has hovered.

Please note that we use the transition property so the Headline reveals smoothly.

Conclusion

That's it, now when your user hovers over the image, it will display the background overlay and the text.

To sum up, here's what we've learned in this tutorial:

Adding image to a page via column background image setting
Adjusting the padding to control the size of a column
Adding background overlay on hover
Giving an element a unique CSS class name.
Hiding text via CSS
Finally, showing text on hover.

If you found this tutorial helpful please leave a comment and feel free to request another Elementor or WordPress customization tutorial as well.