DEV Community: Vaibhav Mehta

Getting Started with JavaScript Fetch API

Vaibhav Mehta — Mon, 05 Dec 2022 06:07:09 +0000

Prelude

Have you ever used XMLHttpRequest object in JavaScript to send a request to the backend to fetch or post some data? If not, then lucky you, as it was pretty chaotic and complicated.

Here's a quick example of what it takes to fetch a file from a given URL using XMLHttpRequest object vs $.ajax() in jQuery vs newly introduced native fetch API.

Fetching Data using `XMLHttpRequest`

var xhr = new XMLHttpRequest();

xhr.onreadystatechange = function() {
  if (xhr.readyState == XMLHttpRequest.DONE) {
    console.log(xhr.responseText);
  }
}

xhr.open('GET', 'https://api.jsonbin.io/v3/b/6360e54a65b57a31e6a94a42', true);
xhr.send(null);

Looks tedious right? That's not it, the above is mostly a minimal example of how to send a request using XMLHttpRequest() object. Next, jQuery comes to the rescue by introducing $.ajax(), a simplified version of the XMLHttpRequest() as a cherry on top, introducing additional functionalities.

Fetching Data using `$.get()`

$.get(
  'https://api.jsonbin.io/v3/b/6360e54a65b57a31e6a94a42',
  (res) => {
    console.log(res);
  }
);

jQuery simplified fetching the data to a great extent, compared to the native XMLHttpRequest() object. Though it was easy, it came at some cost, as the jQuery lib weighed ~100kb (vague estimation) where even if you built the lib with ajax only module, it still weighed roughly ~50kb which is pretty high to do something as basic as fetching some JSON data.

Before we dive into using fetch() API, here's something important to take a note of:

The fetch specification differs from jQuery.ajax() in the following significant ways:

The Promise returned from fetch() won't reject on HTTP error status even if the response is an HTTP 404 or 500. Instead, as soon as the server responds with headers, the Promise will resolve normally (with the ok property of the response set to false if the response isn't in the range 200–299), and it will only reject on network failure or if anything prevented the request from completing. ^[1]

Unless fetch() is called with the credentials option set to include, fetch() ^{Quoting from MDN}:

Won't send cookies in cross-origin requests.

Won't set any cookies sent back in cross-origin responses.

Introducing the fetch() API

fetch API is supported by most of the modern browsers today. It makes it easier for the devs to make asynchronous network requests as it's promise based, thus, avoids callback hell.

Here's a simple example of making a GET request using fetch API.

fetch('https://api.jsonbin.io/v3/b/6360e54a65b57a31e6a94a42')
  .then((res) => res.json())
  .then((data) => console.log(data));

You could also use async ... await instead of promises, like:

(async () => {
  const res = await fetch('https://api.jsonbin.io/v3/b/6360e54a65b57a31e6a94a42');
  const data = await res.json();
  console.log(data);
})();

In the above examples, fetch() takes one argument which is the path to the resource you wish to fetch. An important thing to note here, the response does not return the JSON response body but it instead a representation of the entire HTTP response where you could use .json() to fetch the actual response JSON data.

fetch also provides various options which you could use for the response object, like, text() which returns raw text, formData(), blob(), etc.

Error Handling

When I first tried fetch, I used .catch() assuming that my code would end up in the .catch() statement if the request was a non 200. To my surprise, .catch() never ran, even if the request failed with a response code of 4xx or 5xx. As mentioned previously in this post.

For eg, the following URL would throw a 404 error.

fetch('https://api.jsonbin.io/v3/b/6360e54a65b57a31e6a94a4a')
  .then((res) => res.json())
  .then((data) => console.log(data))
  .catch((err) => console.log('Something went wrong'));

Here, my code didn't print Something went wrong. Later, referring to the official documentation, it turns out that fetch doesn't throw an error if the server returns an error (4xx or 5xx).

The only time my code would end up in the catch statement is when there's no internet connection, or similar issues. Here's where response.ok comes to the rescue. Using response.ok would return true if the response status code is between 200-299 else false.

In the above example, using response.ok to check the request state would return false as the response code was 404.

(async () => {
  const res = await fetch('https://api.jsonbin.io/v3/b/6360e54a65b57a31e6a94a42');
  if(!res.ok) {
    throw new Error(`'Request failed with status code: ${res.status}`);
  }

  const data = await res.json();
  console.log(data);
})();

Attaching Request Headers & Payload

In the above examples, we tried to fetch these records using the default GET method.

But what if you wish to send a POST or a PUT request along with some Headers attached to it?

You could pass headers and attach a payload to your fetch request either by using Headers() object or you could simply pass these in an object as a second parameter to the fetch API like:

(async () => {
  const res = await fetch('https://api.jsonbin.io/v3/b/6360e54a65b57a31e6a94a42', 
  {
    method: 'POST', // *GET, POST, PUT, DELETE, etc.
    mode: 'cors', // no-cors, *cors, same-origin
    headers: { // Request headers
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({"sample": "json"}) // Request payload
  });

  if(!res.ok) {
    throw new Error(`'Request failed with status code: ${res.status}`);
  }

  const data = await res.json();
  console.log(data);
})();

`fetch()` vs. XHR

There are a few differences between the fetch API and XHR request. I didn't want to repeat or copy these since I myself got to know about these differences from a Stackoverflow answer.

Browser Support

fetch() API now has a decent Browser Support. Here's a quick Browser Support overview from MDN:

You could also use fetch in NodeJS using --experimental-fetch flag, or use the node-fetch package if needed.

Resources

Getting started with Deno.js

Vaibhav Mehta — Thu, 17 Nov 2022 16:30:49 +0000

I've been spending a lot of time exploring new tech, trying to make out the most of the Lockdown. From Vue & VueX to Service workers & IndexedDB, it has been a great journey so far. For a few days, there has been a lot of buzz in the engineering community around Deno (I pronounce it as Dee-no), a secure JavaScript & Typescript runtime developed by Ryan Dahl, who previously developed Node.js back in May 2009.

I am working on Node.js for over three years now, and hence, I wanted to explore Deno since it's very similar to Node and wanted to understand how is it different from Node, and is it any better? At the time of writing this article, Deno announced the 1.0.0 release.

So what is Deno?

Deno is a new runtime for Typescript (and Javascript), a part of it is written in Rust. As Ryan Dahl said in one of his interviews, that Deno acts more like a web browser for command-line scripts. Its security model is that to a browser where websites ask for permission to access the camera, location, etc.

Deno aims to replace utility scripts that were historically written with Bash or Python.

Similarly, Deno scripts run in a secure sandbox without access to the operating system, where users can selectively grant access to the files to provide further functionality. Furthermore, it explicitly takes on the role of both runtime and the package manager.

Features of Deno and how are they different from Node.js

If you've worked with Node.js previously, you'll find Deno quite similar to it but with some significant enhancements around security and the way we import the modules.

Here are some of the features I tried out using Deno and I am highlighting some of them below:

Deno is written in Rust as compared to its predecessor, Node.js, which is written in C++.
Unlike Node.js, it does not use npm and instead uses modules that are referenced as URLs or file paths. It also embraces the use of ES6 Modules over require statements. For example:

//The Node.js way
const package = require('mypackage');

//The Deno 🦕 way
import package from "https://deno.land/std/SOME_MODULE.ts";

Does not use package.json in its module resolution algorithm.
All async actions in Deno return a promise. Thus Deno provides different APIs than Node.
Support for top-level await unlike Node.js where you need to define async before you can use await. For example:

//The Node.js way
async () => {
  let getData = await fetch('URL');
  ...
}

//The Deno 🦕 way
let getData = await fetch('URL');
...

Requires explicit permissions for files, network, and environment access. Think of a file requesting data from an external resource, and you need to pass a flag like --allow-net to allow the file to fetch the data from an external resource. We will discuss more on this as we write a basic app.
It exits if any uncaught errors are encountered. (😨 rip my code, seems like I'll be spending a lot of time on error handling 😂)
Typescript by default. It also eliminates the need for other tools like Babel to compile JavaScript and instead has built-in support.
Deno provides a standard library that does not have any external dependencies and is reviewed by the Deno core team. This consists of core modules like DateTime, File System handling, HTTP, etc.
Lastly, it has built-in support for necessary testing.

Up & Running

There are numerous ways using which you can install Deno on your system. I'll share a few examples here:\

Using CURL (for macOS & Linux)

curl -fsSL https://deno.land/x/install/install.sh | sh

Powershell (for Windows)

iwr https://deno.land/x/install/install.ps1 -useb | iex

or you can use Homebrew on macOS

brew install deno

For more information, you can refer to the Deno Installation.

Is there a Deno Versioning Manager?

As of now, there's no official documentation around the version manager. While searching further on this, I came across an open issue on the Deno repo for the same.

In the above, a couple of developers have suggested version managers like asdf-deno and DVM.

Hello World in Deno Land

Let's take a quick look at a simple example that will highlight some critical features of Deno. You can type the commands directly in the REPL(Read-Execute-Print-Loop) mode, or we can write the code in the .ts or a .js file.

Type deno in the terminal, which will enable the Deno REPL mode.

We can run any JavaScript or TypeScript code (no need of a compiler for TypeScript as Deno natively supports TypeScript).

In the above example, I've done some simple math operations like adding two integers and assigning an integer to a constant, which is further used to add to another number.

Lastly, you can exit the REPL mode by typing Deno.exit() or close().

REPL mode is not that useful when running large programs or code snippets, and this is where a file comes handy. We can write our code in a .ts or .js file and execute it using Deno. Let's create a simple HelloWorld.ts file which will output a simple string.

touch HelloWorld.ts //create a file

Add some code to it. Just a simple console statement for now.

console.log('Hello World');

Note: Writing vanilla JavaScript in the TypeScript file is absolutely fine as mentioned on TypeScript's website: All valid JavaScript code is also TypeScript code.

And now, let's run the above file by typing the following command in the terminal.

deno run filepath.ts //outputs Hello World

Deno also allows you to run the remote files directly in the terminal like:

deno run https://deno.land/std/examples/welcome.ts

The above file is one of the examples available in Deno's Standard Library. You can find more examples at https://deno.land/std/examples.

Our first Deno app

Now that we have some fair idea on how to execute code using REPL or a .ts file, we will now move to a little more complex program where we will explore additional features of Deno.

In the below app, we are merely fetching some data from the third-party website and printing it in the terminal.

We will create a new file for the program, say Request.ts.

touch Request.ts

Add the below code to Request.ts

//fetch the data from JSONBin.io - JSON Storage website (public record)
const getRecords = await fetch('https://api.jsonbin.io/v3/b/5ec136d747a2266b1479ecc7');

//proceed once the promise is resolved from the previous statement, fetch the response body and parse it to json
const getData = await getRecords.json();

//prints the retrieved data
console.log(getData); //[ 1,2,3,4,5 ]

In the above code, we request the JSON data from JSONBin.io (a free JSON hosting website) and later we parse the response using .json() and then we print the response using console.log() statement.

Now, we will run the above code using the following command.

deno run Request.ts

Fair. When we run the file, we expect the file to output the contents we just retrieved, but instead, it errors out.

😖 Why is it erroring out? As we discussed earlier, unlike Node.js, Deno provides a secure runtime for JavaScript, and hence, since your script file is trying to access an external resource, you need to grant the permission to the script to do so. Try rerunning the following command, but this time, we will pass the necessary permission for the script to fetch the data.

deno run --allow-net Request.ts

# script will now output the contents of the file like 
# [ 1, 2, 3, 4, 5 ]

These are some key takeaways from the above app we just created.

We didn't install any third-party modules like axios, request or node-fetch to request the data as Deno provides us with native fetch API support.
No need to wrap the request with an async function. We can use await directly as it's available as a top-level function.
We cannot run the program unless the third-party website is granted explicit permission. Hence, we need to pass --allow-net flag explicitly.

Final thoughts

It's been a couple of days since I started exploring Deno, and I must say, it's too early to use it in production apps. In the near future, security will be a massive concern for the developers as we've already seen malicious packages sneaking in on the NPM registry. There's also a lack of third-party support, modules that further makes the development difficult as you need to write a lot of modules by yourself instead of focusing on the core functionality of your app.

Deno is not going to replace Node.js any time soon, but in the coming years, you might see Deno community growing, and you'll see a lot of third-party support like frameworks, modules that will extend the core functionality of the system.

Relevant Resources

I'm sharing a few resources which will help you get started with Deno assuming you already know Node.js.

Deno Repository
Deno Documentation
Deno Examples
Deno Manual
Deno Standard Library
Deno - Third-Party Modules (more or less like NPM library)
Top Level fetch
Rust Introduction
TypeScript for beginners

How to Configure PM2 the right way

Vaibhav Mehta — Tue, 08 Nov 2022 08:25:54 +0000

Prelude

While developing apps on NodeJS, you must have used packages like Nodemon, which monitors your code for changes and restarts your Node App. Though Nodemon is super useful in development, it's not recommended to use it in Production. Nodemon is not something you use if you wish to keep your app alive on Production if it crashes.

Here's where PM2 comes in handy. I've been hosting my NodeJS apps using PM2 on production as well I use PM2 for Development.

Quoting from PM2:

PM2 is a production process manager for Node.js applications with a built-in load balancer. It allows you to keep applications alive forever, to reload them without downtime, and to facilitate common system admin tasks.

Before we go ahead and configure the PM2, yes, PM2 does support the auto-reload feature like Nodemon using the watch feature. More on this later in the article.

Configuring PM2

PM2 simplifies the way you could define the configuration for your app using PM2 ecosystem configuration file. You could use a PM2 configuration file for configuring multiple envs, logging, etc.

Here's a snippet for configuring your PM2 envs and I'll brief each of these later in the article.

ecosystem.config.js

module.exports = {
  apps: [
    {
      name: "PROJECT_NAME",
      script: "./server.js",
      instances: 2,
      max_memory_restart: "300M",

      // Logging
      out_file: "./out.log",
      error_file: "./error.log",
      merge_logs: true,
      log_date_format: "DD-MM HH:mm:ss Z",
      log_type: "json",

      // Env Specific Config
      env_production: {
        NODE_ENV: "production",
        PORT: 8080,
        exec_mode: "cluster_mode",
      },
      env_development: {
        NODE_ENV: "development",
        PORT: 8080,
        watch: true,
        watch_delay: 3000,
        ignore_watch: [
          "./node_modules",
          "./app/views",
          "./public",
          "./.DS_Store",
          "./package.json",
          "./yarn.lock",
          "./samples",
          "./src"
        ],
      },
    },
  ],
};

You can put the configuration file at the root level of your project.

Basic Configuration

name

This could be your project name and PM2 will use this name to name your workers.
script

The entry point of your app, mostly it's the server.js. Make sure you set the right path, the above configuration assumes that you've the ecosystem.config.js and the server.js file at the root level of your project.
instances

This is the number of workers you wish to spawn.
max_memory_restart

PM2 allows you to reload your application based on the memory limit you specify using the max_memory_restart.

Logging Configuration

out_file

Generic logging, all your console.log() statements are logging in this file along with other information.
error_file

Similar to out_file but error files only log the errors of your application.
merge_logs

This is not needed if you are fine with PM2 storing a unique log file for each of its PID - Process ID). Using this config will merge all your app logs into a single file. merge_logs will merge your log files of various PIDs and it doesn't merge the output and error logs into one.
log_date_format

The above is self-explanatory. You could define a date/time format you wish to print your logs in.
log_type

Specify the output style, it's raw by default but we are using JSON here.

Logs Path & Disabling Logs
By default, your Logs are stored under $HOME/.pm2/logs/<app name>-(out||error)-<pid>.log. You could disable logging by pointing the log path to out_file: "/dev/null" and the same is applicable for error_file

Environment specific Configuration

env_production && env_development
These are nothing but different environments you wish to run your apps in, using PM2. You could create config for multiple staging env if your setup requires to do so.
- NODE_ENV
  The above set the env variable value to Production / Development for your app.
- PORT
  Port at which you would like to initiate your app at.
exec_mode
You could use cluster or fork, where the latter is the default mode. It is recommended to use the cluster mode on production and you could use a single instance locally. Number specified in the instances creates child processes (workers) and distributes the incoming connections across the worker processes. You could set the value to 0 or max to specify how many workers you wish the PM2 should launch (max will spawn as many workers as the number of available cores). From PM2 Docs
The worker processes are spawned using the child_process.fork() method, so that they can communicate with the parent via IPC and pass server handles back and forth.
watch
We need to use this only on the dev envs. The use case is exactly what nodemon does. The watch monitors the file changes in your app and restarts your app as soon as a file change is detected.
watch_delay
You don't want to end up restarting your app as soon as you save your file. So if you try to save your file multiple times in under three seconds, it will only restart your app once as it will clear the watch timer every time you save your files under three seconds.
ignore_watch
There will your app will end up restarting even if you install an NPM package, add or move a file in your app dir, or as simple as add an img in your public dir. Hence, any folder or file paths added to the ignore_watch array will not trigger a restart of your app as they are not relevant and don't require your app to be restarted in the first place.

Useful PM2 commands

Starting your App in Dev & Production mode

You could add the following commands to package.json

"scripts": {
  "start_dev": "pm2 start ecosystem.config.js --env development",
  "start_prod": "pm2 start ecosystem.config.js --env production"
},

You could execute the above commands like npm run start_dev and npm run start_prod which starts your app in dev and production mode with the given config.

Start, Stop, Restart & Kill your App

Kill your App

pm2 kill #kills all pm2 workers

Reloading your App

pm2 reload all

Restarting your App

pm2 restart all

Alternatively, you could pass the PID instead of using all keyword which will end up running the same operation on all the processes.

Restarting a process will kill and restart it as opposed to reloading which achieves a 0-second-downtime reload.

Logs

Delete all Logs

pm2 flush

Read Logs

pm2 logs

Processes

List Processes

pm2 list

Monitor Processes

pm2 monit

References

You could also configure the deployment process using the PM2 but I've not covered it in the above tutorial as I've never used it personally.

Here are some resources which will help you understand PM2 configuration in detail.

Folder Structure for NodeJS & ExpressJS project

Vaibhav Mehta — Mon, 31 Oct 2022 09:30:17 +0000

Prelude

I've worked over several backend technologies, starting from PHP, then moving to RoR before getting my hands on NodeJS. I love how NodeJS simplifies backend development for Frontend developers; and not only this, the NPM ecosystem helps devs get up and running with complex projects with ease, without the need of re-inventing the wheel by developing core packages.

Over these years, I've tried and tested various folder structures for my projects (confession: I've never referred to any folder structure on the web as I wanted to design something of my own which I find comfortable working with rather than being biased upfront - how ironic as I am drafting this tutorial 🙂) and I've finally reached a stage where I feel confident enough to share something which works for a majority of my NodeJS projects.

As an example for this article, we will try to structure an App assuming there's a:

Website with a Landing Page
Basic Authentication
A Dashboard
You are using Express like framework
Build tools for Frontend like Gulp, Webpack.
Applicable if you are using Frontend frameworks/libs like React, Angular, Vue.js, etc.
Applicable if you wish to build API only App.

That's a pretty standard scenario for any application out there.

Last but not the least, the structure is more or less a Monorepo. You could take some good parts and apply them to your apps if your Node Apps are intended to serve as an API only or as a Website.

NodeJS Project Folder Structure

The folder structure I usually follow is inspired massively by RoR as I was working with Ruby & RoR before switching to NodeJS.

Here's how I structure my NodeJS App. I'll be explaining some of the reasoning behind the file structure and will also share some snippets on how do I expose some of the configs at a global level or how do I initiate a Database Connection across the app.

/app
├── config/
│   ├── db.conf.js
│   ├── app.conf.js
│   ├── app.keys.js
│   ├── db.keys.js
│   ├── init.js
├── database/
│   ├── Redis.database.js
│   ├── Mongo.database.js
│   ├── init.js
├── routes/
│   ├── App.routes.js
│   ├── Auth.routes.js
│   ├── Dashboard.routes.js
├── utils/
│   ├── Logger.util.js
├── middleware/
│   ├── App.middleware.js
│   ├── ErrorHandler.middleware.js
│   ├── init.js
├── models/
│   ├── User.model.js
├── controllers/
│   ├── App.controller.js
│   ├── User.controller.js
├── helpers/
│   ├── App.helper.js
├── views/
│   ├── layouts/
│   ├── partials/
│   ├── support/
│   │   ├── index.ejs
│   ├── documentation/
│   │   ├── index.ejs
│   ├── index.ejs
│   ├── about.ejs
│   ├── contact.ejs
/public
├── dist/
├── images/
│   ├── dashboard/
│   ├── auth/
│   ├── documentation/      
├── sitemap.xml
/samples
├── .env.sample
├── db.conf.sample
├── app.conf.sample
├── app.keys.sample
/src
├── javascript/
├── css/
/node_modules
/server.js
/package.json
/.env

Project Structure Brief

Config & Sample

Configuration could be categorised into three major categories:

System Configuration
App Configuration
App Keys

Store the configuration variables in .env (dotenv) which are necessary for configuring your application like App Port, Environment (Production, Staging, etc.). .env configuration will be available across your app as they are set globally as ENV variables.

You could then create multiple app-relevant configuration files like:

Database Connection: Database-specific configurations like Host, Port & Name.
App Configuration: Acceptable Request Payload Size, Blacklisting IPs or Regions, etc.
Auth Configuration: OAuth Callback URLs, etc.

And last but not the least, you could create multiple files and store relevant keys, like OAuth Client & Secret Keys, Database Keys, Mailer Keys etc.

Important: Do not commit any of these configuration files to Git. Copy the configuration structure with dummy values and commit to git using sample files under the /sample folder.

Database

This is where you could create connections to your database(s) like Redis, MySQL, MongoDB etc.

You could then require the necessary configuration & keys to initiate a connection here. This will also make it easier for you manage everything related to your Database connection in one file, like adding listeners around successful connections, errors and disconnects, etc.

Later, these connectors could be loaded under initialization files as needed.

Routes

Usually, you could create a single Route file here to manage all your app related routes but it is recommended to create multiple route files which could be categorised like:

Website Routes
API Routes
Authentication Routes
Documentation Routes

etc. Above is more scalable as well as manageable. Here's a code sample for the above:

const express = require("express");
...
const websiteRoutes = require("@routes/Website.routes");
const apiRoutes = require("@routes/Api.routes");

...

app.use("/", websiteRoutes);
app.use("/api", apiRoutes);

As you see, moving the routes to separate files also simplifies how your app would consume these routes.

Utils

Your app may have several utility functions, like Logging important information, or something which are static and have no relevance to other classes/files, as opposed to Helpers (defined later in this post) which may help other classes or modules in your app.

Middleware

Your app will have several middleware functions which could be separated and initiated in a single file. These helpers could range from critical middleware like Body Parser, Global Error Handlers, Authentication Middleware, enabling CORS, Attaching Custom Headers or setting a View Engine in ExpressJS.

Models

Every Collection (if MongoDB) or a Table (if MySQL) will have a standalone model file. For eg: A collection of Users will have it's own User.model.js file which could be extended further for defining a Schema Structure for the collection, Setting Default Values in the DB or Validating the User Inputs before storing the values to Database.

Controllers

Controllers will be responsible to handle all the incoming requests to your application which will either render a page in response, may send a JSON payload or will handle other critical API related actions like POST, PUT, DELETE etc.

Controllers will further consume Models, say a User model to Create Users while registering on your website or will render the view files if static pages are requested.

Helpers

Unlike utility methods, helpers could be dynamic in nature and related to specific controllers when needed. Helpers may contain methods to parse some user posted payload, modify it before storing it to the Database, etc.

Views

You may not need this folder if you are developing an API only app or using a separate SSR library like Next or Nuxt. This may be useful when you are using Express View Engine like Pug or EJS.

You can further divide your views into Layouts, Pages & Partials. Where, Layouts could be shared between similar pages and a website could have multiple layouts. Lastly, partials will hold common components like Header, Footer, Sidebar etc which are needed across your web pages.

Public

As the name suggests, anything under this folder will be publicly accessible by your website users. CSS, JavaScript and Images will be a part of this folder.

Your app may use tools like Webpack and Gulp which will compile(minify, pre-process) your (S)CSS & JS files and move under the public folder which will later be linked on web pages.

You could also build and output your React (or similar lib/framework) app under the dist/ folder.

Src

As App folder is responsible for handling all of the backend logic, Src folder will hold your JavaScript & CSS files if you are using SASS, ES 6 / Next which needs to be transpiled, compiled, minified and uglified before these could be served to the end users.

Src folder will further hold directories like CSS and JavaScript which could be customized as per your needs.

A simple explanation for init.js files before I close this article, init.js files will require rest of the files and export them to other files of your application, so that you need not have to require multiple files every time if you wish to consume them all.

Conclusion

I follow the above folder structure more or less in all the projects I build on Node. It works well for me and I would love to hear from you if it helps you in some way.

Eventually, you should try and modify the folder structure as per your needs and something which you find comfortable managing and scaling it in the long run.

Useful Resources

Lastly, I would love to share some packages which I use to manage configuration, simplifying the process of requiring files at various nested levels, as well as some Linting packages to standardise your code to a great extent..

@use & @forward in SASS

Vaibhav Mehta — Wed, 12 May 2021 11:50:19 +0000

I have been working with CSS over the years and love it. I have tried various libraries, toolsets like Bourbon (yes, I am that old), and pre-processors like SASS & Less.

Talking about the CSS pre-processors, lately, I was reading about how node-sass will be deprecated soon, and hence, I checked out the dart-sass documentation.

While reading the documentation, I came across an exciting way of importing the SASS files instead of the traditional way of importing the stylesheets using @import statements.

Yes, just like me, you must have thought the same, that what would be better than using @import statements to import the Stylesheets? Well, dart-sass has to offer two new ways of importing them, namely @use and @forward.

Important: Make sure that you have sass installed, and NOT node-sass

Before we try out the new ways to handle the imports using SCSS, we will first define the Files & the Folder structure.

/project
|-- /vars
|---- _colors.scss
|---- _fonts.scss
|-- app.scss

Let's try out @use

As you know, we can import the files in SCSS using the @import statement. @use pretty much does the same thing, EXCEPT, that it namespaces your variables, thus, preventing the name collisions.

Starting with some simple code here, we will create a file to hold some variables, and then we will require this in our App file.

// _colors.scss
$h1-color: #f00;
$component-color: #0f0;

And then, we will use @import first, in app.scss to test if everything's in place.

// app.scss
@import 'vars/colors';

h1 {
  color: $h1-color;
}

The above should work as expected. Now, without any further ado, we will go ahead and modify the @import statement to @use.

// app.scss
@use 'vars/colors';

h1 {
  color: $h1-color;
}

@use helps you namespace your SCSS files

Now that we are using @use it to import the stylesheet will result in an error. Reason? Remember, in the beginning; I mentioned that @use helps us namespace our variable names, thus preventing collisions if any. Hence, we need to modify the above code like:

// app.scss
@use 'vars/colors';

h1 {
  color: colors.$h1-color;
}

Viola, the SCSS is now compiled. All we did was, prefixed the $h1-color variable using colors that are nothing but the file name.

@use(ing) Alias

Now, what if we have a file name of _colors_for_theme_blue.scss (not pretty at all but assuming some worst-case scenario), and then writing it like colors_for_theme_blue.$h1-color will be super annoying.

To cut short the filename, you can use the keyword as that will help you create an alias for the _colors.scss file. E.g.:

// app.scss
@use 'vars/colors' as c;

h1 {
  color: c.$h1-color; //note that now we are using only c here
}

as helps you define an alias for the file name you are importing using the @use keyword.

Alternatively, you could also use an * as an alias which will result in behavior similar to the one which @import provides. For, e.g.:

// app.scss
@use 'vars/colors' as *;

h1 {
  color: $h1-color; // note, you need not have to specify
                       colors prefix before you use $h1-
                       color variable.
}

I would not recommend you doing the above since it misses the point in having name-spaced variables.

Scope using @use vs. @import

There is another benefit of using @use instead of the @import is the scope. When we use @import statement to import certain files, then this file has access to the declared variables before importing the component file. For, e.g.: (we will introduce a new folder here, say components, and create a sample component file like _my_component.scss)

/project
|-- /components
|---- _my_component.scss
|-- /vars
|---- _colors.scss
|---- _fonts.scss
|-- app.scss

Here, we will try to import _my_component.scss using the @import statement and then using the @use and see the difference.

// app.scss
// using @import
@import 'vars/colors';
@import 'components/_my_component';

h1 {
  color: $h1-color;
}

And here we have some code in the _my_component.scss file

// _my_component.scss
.my-component {
  color: $component-color;
}

In the above example, the code will be compiled as expected, where even the _my_component.scss has access to the variables declared in the app.scss file, create issues as the codebase grows.

The above results in the following compiled CSS

// compiled output
.my-component {
  color: #0f0;
}

h1 {
  color: #aaa;
}

If you notice, the .my-component can access the colors defined in a separate file imported before importing the component file.

If we make use of @use instead of the @import, here's what will happen.

// app.scss
// using @use
@use 'vars/colors' as c;
@use 'components/_my_component';

h1 {
  color: c.$h1-color;
}

Tweaking the component file a bit:

// _my_component.scss
.my-component {
  color: c.$component-color;
}

The above will result in an error:

Error: There is no module with the namespace "c".

Say if we remove the namespace, which is c, then the error which we will get is

Error: Undefined variable.

Hence, using @use helps you control the scope of your variables instead of @import which makes the variables globally accessible to the files which are imported post the variable file. Still, if you wish to use the same variable file in the _my_components.scss then you need to require the variables in the components file as well.

// _my_component.scss
@use '../vars/colors' as c; //note the filepath here,
                              have added ../

.my-component {
  color: c.$component-color;
}

.my-component {
  color: c.$component-color;
}

Using @forward

You must be having multiple helper files, say for variables, mixins, fonts, extends, etc. Having to require them in every single file (since using @use, it will not make these files globally available) required in components and other SASS files will be tedious.

Hence, we could use @forward which acts like a pipe. It takes many files and makes the contents of those files available where this file is required. Let us take an example:

/project
|-- /components
|---- _my_component.scss
|-- /vars
|---- _colors.scss
|---- _fonts.scss
|---- helpers.scss // we will add this file here, which 
                      will contain forwards of 
                      _colors.scss & _fonts.scss
|-- app.scss

And now we will add the @forward to the helpers.scss file.

// helpers.scss
@forward 'colors';
@forward 'fonts';

Now instead of requiring every helper file in app.scss you would instead import the helper.scss which will make the other files like _colors.scss & _fonts.scss available.

// app.scss
@use "vars/helpers";
@use "components/my_component";

h1 {
  color: helpers.$h1-color; // note that you need to modify
                               the namespace, or use * and 
                               you could simply use $h1- 
                               color
}

and subsequently, we can now modify the _my_component.scss file as well.

// _my_component.scss
@use "../vars/helpers";

.my-component {
  color: helpers.$component-color;
}

Using @forward will make it simple for you to import multiple files without specifying them separately and instead use the common file.

The above is a basic intro for using @use and @forward. There is much more to it, like Private Members, Index Files, Visibility Control, etc. I'll be attaching a few references where you could refer to these features in detail.

References

Documentation for @use
Documentation for @forward
Dart SASS
SASS NPM

DEV Community: Vaibhav Mehta

Getting Started with JavaScript Fetch API

Prelude

Fetching Data using XMLHttpRequest

Fetching Data using $.get()

Introducing the fetch() API

Error Handling

Attaching Request Headers & Payload

fetch() vs. XHR

Browser Support

Resources

Getting started with Deno.js

So what is Deno?

Features of Deno and how are they different from Node.js

Up & Running

Using CURL (for macOS & Linux)

Powershell (for Windows)

Is there a Deno Versioning Manager?

Hello World in Deno Land

Our first Deno app

Final thoughts

Relevant Resources

How to Configure PM2 the right way

Prelude

Configuring PM2

ecosystem.config.js

Basic Configuration

name

script

instances

max_memory_restart

Logging Configuration

out_file

error_file

merge_logs

log_date_format

log_type

Environment specific Configuration

env_production && env_development

NODE_ENV

PORT

exec_mode

watch

watch_delay

ignore_watch

Useful PM2 commands

Starting your App in Dev & Production mode

Start, Stop, Restart & Kill your App

Kill your App

Reloading your App

Restarting your App

Logs

Delete all Logs

Read Logs

Processes

List Processes

Monitor Processes

References

Folder Structure for NodeJS & ExpressJS project

Prelude

NodeJS Project Folder Structure

Project Structure Brief

Config & Sample

Database

Routes

Utils

Middleware

Models

Controllers

Helpers

Views

Public

Src

Conclusion

Useful Resources

@use & @forward in SASS

Let's try out @use

@use(ing) Alias

Scope using @use vs. @import

Using @forward

Fetching Data using `XMLHttpRequest`

Fetching Data using `$.get()`

`fetch()` vs. XHR