DEV Community: Akash Shyam

The Ultimate Cheatsheet To Mongoose Query Methods

Akash Shyam — Wed, 22 Sep 2021 12:39:23 +0000

Good morning folks,

Today, I have a compiled a cheatsheet of mongoose query methods. It contains several performance related tips and data fetching patterns like filtering, pagination etc.

This cheatsheet contains all the tips and tricks I've picked up over the last one year I've spent working with mongoose and mongodb.

You can checkout the repo here.

Feel free to create a PR containing your own tips and tricks you known and want to share with the community.

Also, follow me on twitter where I post about web development stuff like JavaScript, React, NodeJS and Crypto. Bye for now 🤟

Features To Look Out For In Future JS Versions

Akash Shyam — Sun, 08 Aug 2021 07:03:38 +0000

I'm am sooooo excited... some of my favourite typescript features are on the horizon. So without further ado, let's get started

Class Fields

Class fields include private methods and accessors(like get & set), public and private instance fields, static class fields and private static methods. Let's look at them:

Private Methods & Fields

class Man {
  // Private Field
  #name = '';

  // Private Getter
  get #x() {
    return #xValue; 
  }

  // Private Setter
  set #x(value) {
    this.#xValue = value;
  }

  // Private Method
  #clicked() {
    this.#x++;
  }

  constructor(name) {
    this.name = name;
  }

}

Static Private Methods & Fields Just like we have saw private instance fields and methods earlier, we can do the same for static fields & methods.

class ColorFinder {
  static #red = "#ff0000";
  static #green = "#00ff00";
  static #blue = "#0000ff";

  static colorName(name) {
    switch (name) {
      case "red": return ColorFinder.#red;
      case "blue": return ColorFinder.#blue;
      case "green": return ColorFinder.#green;
      default: throw new RangeError("unknown color");
    }
  }

}

Top Level Await

I bet most of us have used async IIFEs(Immediately Invoked Function Expression) a.k.a IIAFEs for using async/await in the top level of a module in this fashion:

(async () => {
  // Async code
  await axios.post('https://xyz.com');
})()

Using this, we can simplify this code to:

// That's it... no catch!
await axios.post('https://xyz.com');

That's it for this post! I hope you liked it. Checkout my twitter where I post tips, tricks and memes for developers. Bye for now 🤘

Level Up Your Commit Messages With These Tips!

Akash Shyam — Sat, 31 Jul 2021 04:52:59 +0000

At some point, we’ve all come across a commit message we don’t understand. Let’s rectify that commit by commit:

1. Specify the type of comment

feat: for feature addition
fix: for bug fixes
refactor: for changing the way a code block is written without changing the final result
style: for style changes(CSS/Sass etc)
test: anything and everything about testing
docs: documentation addition/updates
chore: code maintenance

Do not restrict yourself to these types, feel free to add more types of comments but be consistent across the code base.

2. Never assume another developer understands the original problem i.e. the reason for the commit

I recently started working on an existing codebase along with 3 developers. Me and another dev just started working on the codebase. On the second day, when I woke up to pull the latest code to my database I see this:

fix: bug inside the StudentList screen regarding the list
// … some irrelevant details about the new solution

When I looked at it, I had no idea what the problem was. After about 15 minutes of chatting back and forth, I finally understood the original problem.

Just a single paragraph, that’s all I ask. One paragraph describing the problem containing 2–3 lines. It will help you too in the future, when you come back later trying to fix a bug.

3. Limit the subject line to 50 characters

50 characters is not a hard limit, just a rule of thumb. Keeping subject lines at this length ensures that they are readable, and forces the author to think for a moment about the most concise way to explain what’s going on.

Github will truncate commit messages over 72 characters

Checkout the remaining article here. I've saved the best for the last!

To Typescript Or Not To?

Akash Shyam — Tue, 27 Jul 2021 10:14:57 +0000

In my previous post, one of my readers, said some very good points against typescript and is resulting in a pretty long conversion in the comments. So, I'd like to do have a final comparison.

Advantages of Typescript

Strict Typing

Once declared, a variable can take only one type and can take only certain values. The compiler alerts developers to type-related mistakes, so they have no opportunity to hit the production phase. This results in less error-prone code and increase in developer productivity.

For example, we call a string specific method on an argument, we can do this without need to add an if check because typescript will through an error if a different type of value is passed.

But static typing is not only about catching bugs. It also gives the code more structure, makes it self-documenting and more readable, speeds up debugging and refactoring.

It’s important to note that TS doesn’t force declaring types everywhere. Developers are free to change the level of type strictness in different parts of the project. This approach distinguishes TS from other statically typed languages and allows you to find the right balance between flexibility and correctness. This also makes it easy to migrate javascript code to typescript because we don't need to convert the entire code base to compile the code.

With TypeScript, everything stays the way it was initially defined. If a variable is declared as a string, it will always be a string and won’t turn into a Boolean. This enhances the likelihood of functions working the way initially intended.

Early spotted bugs

Researchers found that TypeScript detects 15 percent of common bugs at the compile stage. Far from a 100 percent result, this amount is still significant enough to save developers time and let them focus on correcting mistakes in the logic — rather than catching common bugs. Pushing the code through a compiler also decreases the volume of quality assurance and testing activities.

Sweet VS-Code Autocomplete
Vs code already has great javascript autocomplete but typescript gives it an enormous boost. Also, if we use external 3rd-party libraries, we can check the type definitions which will be faster than checking the docs(some libraries don't have great documentation)
Extra Features
Over and above the normal javascript features, typescript has several features which are not in javascript. For example, public, private and protected fields, Generics which helps us to create quite complex dynamic typings, Nullish Coalescing (??) etc], abstract classes.
Popularity

Typescript has over 19 Million weekly downloads on NPM:

Next, let's look at the 2020 survey from the state of js, one of the most popular Javascript surveys.

Popularities of Various JS flavours over the years:
![Screenshot

Percent of people who like/dislike typescript:

Experience Over time:

According to the [2020 SO survey], typescript is the second most loved language, surpassing python too! (https://insights.stackoverflow.com/survey/2020):

Of course, these are just numbers. Popularity doesn’t necessarily mean that something is of high quality and should be trusted. Fortunately, TypeScript also enjoys support from some truly formidable players in the tech world.

The language is widely used in software products such as Slack, Medium, Asana, or Visual Studio Code. What’s more, many great JavaScript tools are written in TypeScript, including frameworks (Angular, Ionic etc) and libraries (ZoomCharts, yWorks, or GoJS).

As if that wasn’t enough, tech giants like Microsoft (duh!), JetBrains, eBay, Ericsson, airbnb or Ubisoft are all open about using TypeScript—and who knows how many other enterprise-level companies have included it in their tech stack.

Disadvantages Of Typescript

Extra Stage - Transpiling
One of the major argument against TypeScript is that it requires compilation, while JavaScript doesn't. But, let’s be honest, most of JavaScript applications these days require a build step. Whether it’s Gulp, Grunt, Webpack, Rollup, Babel, or Closure—a build step is a necessity and nothing really prevents you from expanding it.
Extra code
To leverage the features of typescript properly, we need to create types, interfaces etc and under a time constraint or a tight deadline, this may cause unnecessary delay. However, in the long run, it will save us a lot of time because a new developer will need a lot less time to understand the codebase.
Learning curve
Even though typescript is similar to javascript, there is still some learning that needs to be done to understand the code properly.

Conclusion

I think that this is subjective, and as person who loves autocomplete, code readability and syntactic sugar (and a person who introduces a lot of bugs 😅) typescript is the obvious choice for me. However, while working on a tight deadline, vanilla javascript would be better

If you liked this post don't forget to leave a like and follow me here on dev.to and twitter where I will (try) to post javascript/typescript tips and tricks regularly. Bye 🤟

7 Tips For Clean Code

Akash Shyam — Mon, 26 Jul 2021 09:33:47 +0000

It's all about maintaining clean and readable code(which works of course). So, I wanted to share a few tips with you guys. Feel free to correct me or share more tips of your own in the comments to create a learning experience for all of us. Let's get to it then:

1. Comments, Comments and More Comments

I'm not the ideal developer whose code is understood by everyone and I'm betting you aren't either. Instead of explaining what exactly to do, I'm going to tell you what not to do. Let's look at some sample code:

// Created a constant variable "foo" and assigned a value of "bar"
const foo = "bar";

2. Meaningful Names

You want to use those kinds of names where the reader goes, "Yes! I know exactly what this does".

// NEVER DO THIS
const abc = validateEmail('writecleancode@gmail.com')

// Good Job!
const isEmailValidated = validateEmail('writecleancode@gmail.com');

3. Console Warns/Errors

This is a huge problem, so many times I've seen developers commit code with eslint warnings. Infact, a couple of months ago, I started working on an existing project. When I compiled the frontend, there were over 100 warnings by jsx-ally, eslint etc.

We can use husky along with lint-staged which will not let you commit code until you clear all the warnings and errors.

4. `as unknown` in Typescript

Typescript is smart, but sometimes, it just isn't smart enough! I've seen a lot of // @ts-ignores or as unknowns in typescript code. So instead of doing this:

const user = dog as unknown;

do this:

const user dog as IUser

Even though doing this is not advisable, at least you get some type safety.

5. Use Babel Instead of tsc

From version 7, Babel added support for TypeScript, which means you no longer need to use the TypeScript compiler i.e. tsc to build your project, but instead can just use Babel which simply strips your types from all TypeScript files and then emits the result as JavaScript.

This is not only much faster than tsc, especially in bigger projects, but also allows you to use the whole Babel ecosystem within your project. For example, it's great when you want to use react or javascript features which are still in stage 3.

For back-end projects, this means you can simplify your clunky file-watching scripts and just use babel-node to watch for changes.

6. Use SonarJS and Eslint

Eslint has many rules that enforce best practises and conventions and will also help to prevent bugs.

(TSLint is being deprecated in favor of typescript-eslint; the TSLint plugin SonarTS has been adopted and is now part of SonarJS).

In addition to ESLint’s features, SonarJS adds some complexity checks to your code, which are helpful to just code away and then break your methods into smaller pieces.

7. Opaque Types

I'm not going to explain, I'll just demonstrate this to you.

Imagine we are building a banking API.

// Account.ts

export type PaymentAmt = number;
export type Balance = number;
export type AccountNumberType = number;

function spend(accountNo: AccountNumberType, amount: PaymentAmt) {
  const account = getAccount(accountNo);
  account.balance -= amount;
}

// controller.ts
import {spend} from "./accounting";

type Request = {
  body: {
    accountNumber: number,
    amount: number
  }
};

export function withdrawAmt(req: Request) {
  const {accountNumber, amount} = req.body;

  spend(amount, accountNumber);
}

Did you spot the bug? If you didn't, look at the place where we are calling the spend() function. I've (intentionally) passed the amount before the accountNumber but typescript does not complain.

If you are wondering why this happens, this is because AccountNumberType and PaymentAmt are assignable to each other because both of them are of type number.

There is a long standing issue in the typescript repo about this. Until the typescript team does something about this, we can use the following hack

// Can be used with any type
type Opaque<K, T> = T & { __TYPE__: K };

type Uuid = Opaque<"Uuid", string>;

The utility function Opaque simply defines a new type that, aside from a variable’s value, also stores a (unique) key, such as Uuid.

Conclusion

Thanks for reading! Check out my twitter where I (try) to post tips & tricks daily. Bye 🤟

What's new in React 18?

Akash Shyam — Wed, 16 Jun 2021 01:37:02 +0000

React 18 has a lot of new features but they are all possible thanks to "concurrent rendering". It lets React prepare multiple versions of the UI at the same time. This change is mostly behind-the-scenes, but it introduces so many cool features to improve our apps.

Suspense

Suspense is the feature that pretty much everyone has been waiting for. We have been hearing about Suspense since a long time and it is now finally coming to React 18. Before we get into the code around Suspense we first need to talk about what Suspense does.

Imagine you have a website like this:

<Container>
  <Nav />      {/*  50ms */}
  <Sidebar />  {/* 150ms */}
  <Blog />     {/* 100ms */}
  <Comments /> {/* 200ms */}
</Container>

We have 4 components with their respective loading times. This time includes the time to fetch items from an API, render the JSX etc.

Now, when a person opens a blog article, he/she does not care about the comments, the sidebar etc, the blog is important. So, the other components can load later in the background while only the most important component i.e. the Blog is loaded.

Before Suspense there was no way to delay the loading of these components when doing server side rendering since all the HTML must be sent at once which means all the data must be loaded. With Suspense, though, you can tell React to only load the data for the important components and delay the loading of less important or slow components.

<Container>
  <Navbar />
  <Suspense fallback={Loader}>
    <Sidebar />
  </Suspense>
  <BlogArticle />
  <Suspense fallback={Loader}>
    <Comments />
  </Suspense>
</Container>

The server will send all the HTML/data for components that are not wrapped in a Suspense component. The client will then start hydrating those components as soon as it gets the HTML so that the page is usable as soon as possible. While that is happening the data inside the Suspense components will be sent down to the client in the background as soon as it is ready. The components will then begin the hydration process before finally being ready to use.

React will also prioritize hydrating components that the user is actively trying to interact with which makes your app feel even quicker for users since the parts they care about the most will load the quickest.

Automatic Render Batching

Most new React developers are confused when you have multiple setState calls one after another. This is a bit of a complicated question to answer since in React 17 it depended on where the state was set. Sometimes it would batch the updates together and do only one rerender, but other times it would re render the entire component once for each setState call. In React 18 this has been greatly simplified since now all changes to state are batched together if they are near each other.

Transition

It is very common in React to do lots of complex calculations when state changes. React 18 adds in the idea of urgent updates and transition updates. An urgent update is just like the normal React update you are used to. It is an update that happens immediately and blocks the application. Something like a button click, or selecting items from a dropdown are great use cases for urgent updates.

A transition update on the other hand is an update that is not urgent and is something a user does not expect to happen instantly. A good example of this is filtering a list of items. Most state updates you do that aren’t directly tied to interacting with an input are most likely transition updates. With React 17, though, everything is considered an urgent update since transition updates don't exist. In React 18 all updates are by default urgent unless you specifically mark them as transition updates.

import { startTransition } from 'react'

// Urgent
setInputValue(input);


// Transition
startTransition(() => {
  setSearchQuery(input)
})

Using React 18

React 18 is currently in alpha and can be downloaded like this:

npm install react@alpha react-dom@alpha

We are all used to rendering our components like so:

ReactDOM.render(<App />, document.getElementById('root'));

However, to utilize some of the new features, our components need to be rendered like this:

const root = ReactDOM.createRoot(document.getElementById('root'))
root.render(<App />)

Conclusion

I am really excited to see what the full release of React 18 looks like and can't wait for the production ready version! Like the post and follow me for more content on Fullstack Web Development.

Going 3 Dimensional With Three.JS

Akash Shyam — Mon, 17 May 2021 08:01:09 +0000

We've all wanted to create those cool websites with those amazing moving shapes which look 3 dimensional. The technology used for this is called WebGL. It's great and gives us a lot of freedom and flexibility.

However, with this, comes a price. WebGL is complex and we need to write a lot of code for something as simple as a cube. Here's where three.js comes into play. Three.js adds a layer above WebGL while allowing almost the same amount of flexibility.

This is a the first post in a series of Three JS posts. Today, I'll show you how to create some basic shapes in three JS.

We can use Three JS through NPM or by a CDN.

npm i three

We use the canvas element for our 3d figures. Canvas is used for drawing, it's in the name.

<canvas width="800" height="600" id="threejs-canvas"></canvas>

Let's select this canvas through javascript.

const canvas = document.querySelector('#threejs-canvas');

Scene

Firstly, let's begin by creating a Scene. A scene can be understood as the container for our 3d figures.

import { Scene } from 'three';

const scene = new Scene();

Parts of Objects

A basic object in Three JS has 3 fundamental parts:

Geometry

It is the shape/outline of an object. Now, we'll create a geometry of a cube.

// Params are width & height
const geometry = new BoxGeometry(1, 1);

Material

It is the color/texture of the object. We can add unique looks and appearances by combining colors and textures. I'll create a detailed post on this very soon.

const material = new MeshBasicMaterial({ color: 'cyan' });

We can use various color formats like hexadecimal, rgb, hsl etc.

Mesh

It is used to combine the geometry and the material. We can also use it for rotations, scaling, transformations etc.

const cube = new Mesh(geometry, material);

If you run the code, you'll see a black background but no cube. We may have created the cube but we have not added the cube to the scene.

scene.add(cube);

After running that again, there's still no cube:

This is because we need to render our scene.

const renderer = new WebGLRenderer({ canvas });

// Dimensions of the canvas
renderer.setSize(800, 600);

There are various renders but WebGLRenderer is what we need. Finally, we can see our cube:

Controls

I think it be great if we could look around the cube i.e. view it from other angles. We can do this by changing the position of the camera. We could implement this on our own but three JS gives us a class we can use.

const controls = new OrbitControls(camera, canvas);

// Adding easing for better UX
controls.enableDamping = true;

Now, let's try some other shapes:

Sphere

// The first argument is the radius
const geometry = new SphereGeometry(1);
const material = new MeshBasicMaterial({ color: 'cyan' });
const sphere = new Mesh(geometry, material);

scene.add(sphere);

If we run the code, we get something like this:

As you can see, the edges are jagged. People who have used 3d software tools like blender, 3d max etc will know why this happens. This is because we lack detail on the sphere which is necessary for creating a smooth sphere. In fact, everything we create in three JS is made of triangles. So, we want to increase the number of triangles(or segments according to the docs).

It's important that we don't go overboard with this because the amount the GPU has to compute is directly proportional to the number of segments. I'd recommend increasing the value slightly until most of the sharp edges disappear. The controls in most cases are used for debugging and the user will probably have a fixed camera angle.

const geometry = new SphereGeometry(1, 32, 32);
const material = new MeshBasicMaterial({ color: 'cyan' });
const sphere = new Mesh(geometry, material);

scene.add(sphere);

Now, we get a nice and smooth sphere:

Torus

Most of the code is the same, we just need to change the class:

// Params is the radius of the torus, radius of inner circle
const geometry = new TorusGeometry(1, 0.2);
const material = new MeshBasicMaterial({ color: 'cyan' });
const torus = new Mesh(geometry, material);

scene.add(torus);

If we execute the code, we can see that the torus is lacking some detail(same issue we had with the sphere). So, let's add some more segments to this.

const geometry = new TorusGeometry(1, 0.2, 32, 32);
const material = new MeshBasicMaterial({ color: 'cyan' });
const torus = new Mesh(geometry, material);

scene.add(torus);

There, it looks much better:

Cone

// Radius of bottom, height
// I've added segments to give it a smooth texture
const geometry = new ConeGeometry(1, 2);
const material = new MeshBasicMaterial({ color: 'cyan' });
const cone = new Mesh(geometry, material);

scene.add(cone);

Here's how it looks:

As you can see, we have the segment problem again. Let's fix that:

const geometry = new ConeGeometry(1, 2, 32, 32);
const material = new MeshBasicMaterial({ color: 'cyan' });
const cone = new Mesh(geometry, material);

scene.add(cone);

And our nice looking cone:

TorusKnot

This is an interesting shape and I think it's cool and unique.

const geometry = new TorusKnotGeometry(1, 0.2, 128, 128);
const material = new MeshBasicMaterial({ color: 'cyan' });
const torusKnot = new Mesh(geometry, material);

scene.add(torusKnot);

There are many more geometries that are available here in three JS.

Debug Panels

These come real handy when we want to make little changes to test out colors, positions, angles etc. I like using dat.gui for this. Let's install it:

npm i dat.gui

Next, we need to initialize the GUI:

import { GUI } from 'dat.gui';

const gui = new GUI();

Now we can see a panel at the top right:

We have a property called wireframe on our object. It removes the color/texture i.e. is the material and exposes the geometry(the outline of the object).

const geometry = new TorusGeometry(1, 0.2, 16, 16);
const material = new MeshBasicMaterial({});
const torus = new Mesh(geometry, material);

material.wireframe = true;

scene.add(torus);

Here's how it looks:

As you can see, there are a lot of criss-crossing lines. These are the segments(the triangles) of the shape.

Let's use this property in our debug GUI.

gui.add(material, 'wireframe');

gui.add() takes in an object and wireframe is the property we want to toggle. The gui.add() method can take in various types of properties(the second argument which needs to be changed). We can use functions, booleans, numbers, ranges etc. One thing to note is that we have decided to change the wireframe property, if we specify something else(like jdfkdfjkd instead of wireframe), it won't work.

Here's how our GUI looks:

As you can see, the label for the property is the property itself(we gave the second argument as wireframe and that is also used as the label).

// Set the label to "Name1"
gui.add(material, 'wireframe').name('Name1');

After changing our label, here's how our GUI looks:

Conclusion

Three JS is super interesting and I think this could be the way to go in the future! Thanks for reading until here. Next, I'll be writing about animating our figures by transformations, rotations etc. Bye for now 🤟

Selector Nesting Has Come to CSS 🤯🤯🤯 !!!

Akash Shyam — Sun, 02 May 2021 06:33:40 +0000

First we had variables and now nesting in css! It seems that the functionality we get with pre-processors like Sass and Less are slowly being introduced in CSS. It's similar to what's happening between javascript and typescript. If you have noticed, a few years ago, some of the current javascript features did not exist in javascript but were implemented in typescript.

I'm not saying this is a bad thing, it's actually great! This decreases the need for pre-proccessors which need to be compiled into CSS/Javascript

That being said, selector nesting is still in the future. No browsers support it yet, but I expect this to improve. For more information, checkout the draft.

What Really Is nesting???

To explain this effectlively, I'm going to compare two code samples.

Without Nesting

button.btn {
  color: blue;
  background: white;
  transition: .2s all ease-in;
  /* More styles for the button */
}

button.btn:hover {
  color: white;
  background: blue;
}

button.btn:focus {
   /* Add more styles */
}

button.btn-group {
  /* Some styles */ 
}

button.btn-primary {
  /* I promise, this is the last. */ 
}

Now let me show the same code with nesting.

.btn {
  color: blue;
  background: white;
  transition: .2s all ease-in;

  &:hover {
    color: white;
    background: blue;
  }

  &:focus {
   /* Add more styles */
  }

  &-group {
    /* Some styles */ 
  }

  &-primary {
    /* You get the point right??? */ 
  }
}

Just like in Sass, The & is used to refer to the parent selector(in this case, .btn). That's not all, we can also nest multiple levels deep.

.btn {
  color: white;
  background: cyan;

  &-container {
    margin: 10px 20px;

    &:hover {
      /* Some fancy animation */ 
    }

    & .overlay {
       /* There should always be an "&" in a nested selectors */
    }
  }
}

@nest

This is a new at-rule that helps us overcome some of the limitations of nesting using the &. Look at the following code:

.section {
    /* etc ... */
}

.section {
    /* etc ... */

    .blog {
        /* We want to reference the blog container which is inside the .section. */
    }
}

For this, we can use the @nest rule. This rule shifts the reference of the & to another selector we specify.

.main {
    /* etc ... */

    .blog {
        @nest .section & {
                        /* The "&" refers to ".section" */
            background: red;
        }
    }
}

Nesting Media Queries

For people who are familiar with Sass, the "normal" code looks like this:

.section {
  @media(/* some media query */) {
    /* styles... */
  }

}

However, this is slightly different. In css, the styles must be enclosed in "&".

  @media(/* some media query */) {
    & {
      /* styles... */
    }
  }

Normal code

.table.xyz > th.y > p.abc {
  font-size: 1rem;
  color: white;
}

.table.xyz > th.y > p.abc-primary {
  font-size: 1.4rem;
}

The Power of nesting 💪 💪 💪

.table.xyz > th.y > p.abc {
  font-size: 1rem;
  color: white;

  &-primary {
    font-size: 1.4rem
  }
}

Makes code more readable

As soon as you look the code, you can go "Aha, anything between those outer curly braces is related to buttons or .btn! Not my business!"

A gotcha

One thing to keep in mind is that any css which is after nested selectors is flat out ignored. However, any nesting that is followed is completely valid.

.x {
  &-y {
    /* styles... */
  }

  a {
    /* invalid */
  }

  &-z {
    /* valid */
  }
}

That's it guys! Thank you for reading this post. Please give it a like and follow me on dev.to for more content based on HTML & CSS, Javascript, React and NodeJS. To my dear regular readers, I'm sorry about not writing any articles in the past few weeks, I was quite busy. Bye guys 🤟

Why I stopped using Redux and Used Recoil Instead

Akash Shyam — Wed, 31 Mar 2021 05:27:18 +0000

What's wrong with Redux?

Redux is not perfect, but it is by far the most popular state management library used with React. Let's look at what's not so great in redux:

Giant Learning Curve
There are so many concepts to learn like actions, action creator, reducers... and when we throw class based and functional components in the mix along with a different way of dispatching while using thunk etc, It can really scare a beginner
Huge Amount of Boilerplate
Everytime we want to setup a redux app, we have to create reducers, combine them, create a store, add middleware, link to devtools, computed values etc. We need to add so many 3rd party libraries which have a config of their own and introduce another layer of complexity.
Restructuring Folder Structure
The react component based approach does not align itself very well with the redux way of splitting business logic. If we want to introduce redux into an existing react app, then we need to change the file structure and a lot of code has to be changed.

Context API

The context API is not really a solution for this. It solves the prop drilling problem... not global application state. You cannot pass data across siblings using context. The child will have to update the parent which will update another child(the sibling).

Terminology with Recoil

Unlike redux where we have so many concepts to understand... there are only a few in Recoil

Atom

This is the easiest part of the terminology.... an atom is basically a piece of state

Selector

A piece of state that is calculated on the basis of another atom(s) or selector(s)

Recoil

Let's begin by installing recoil

npm i recoil

Whenever we want to use recoil, we need to have the RecoilRoot component somewhere in our component tree.

import React from 'react';
import {RecoilRoot} from 'root';

export default function App() {
  return (
    <RecoilRoot>
      <h1>Recoil Demo</h1>
    </RecoilRoot>
  )
}

When we want to create an atom, we use the atom function.

import React from 'react';
import { RecoilRoot, atom } from 'recoil';

const counter = atom({
  key: "counter",
  default: "0"
});

export default function App() {
  return (
    <RecoilRoot>
      <h1>Recoil Demo</h1>
    </RecoilRoot>
  )
}

Each atom() takes in 2 fields:

Key
The key is the name our atom. It must be unique in our application and we use it to get the value of the atom.
Default
The default is the initial value of our atom

We've created an atom but we'll also need to access it. We use the useRecoilState hook

import React from 'react';
import {RecoilRoot, useRecoilState, atom} from 'root';

const counter = atom({
  key: "counter",
  default: "0"
});

export default function App() {
  const [number, setNumber] = useRecoilState(counter);

  return (
    <RecoilRoot>
      <h1>Recoil Demo</h1>
      <button onClick={() => setNumber(number + 1)}>{number}</button>
    </RecoilRoot>
  )
}

We pass in the counter atom to the useRecoilState. Very similar to the useState hook in react, useRecoilState also returns the value of the state and a function to set the state.

I've added a simple button that shows the value of number. When we click on it, we increment the number state using the setNumber() function.

This atom can be used in another component too. In case we only want to access the value of the number atom, we can use the useRecoilHook.

function Display() {
  const number = useRecoilValue(counter);
  return <p>{number}</p>
}

Derived State

Let's begin by understanding what derived state actually is. It's a piece of state that is calculated on the basis of another state.

It's very easy to do this in recoil. We can use the selector() function. A selector is a pure function that takes in atoms or other selectors. We'll cube the value of our counter.

const cubed = selector({
  key: "cube",
  get: ({ get }) => get(counter) ** 3
})

The key field is nothing new... it specifies the name of our state, as I mentioned earlier, It must always be unique. The get field is where things get interesting. I agree it the syntax is complicated but this gives us a lot of power and expands the possibilities. Whenever an atom which the selector uses changes, the selector is recalculated Let's go through the code line by line.

We are giving a function to the get field. Recoil passes an object into that, from this object we are destructuring the get field. The get field is a function that allows use to pass in the key of an atom or selector and access it's value. Then we are raising it to the power of 3. Here we have used only one atom but we can use multiple atoms for computations.

import {selector} from 'recoil';

const cubed = selector({
  key: "totalPrice",
  get: ({ get }) => {
    get(numState) ** 3
  }
})

Folder Structure

Let's say the we have 2 broad categories of state in our app: users and todos. All the atoms go in /atoms and the selectors go in /selectors. The atoms related to users will go in /atoms/users.js, the atoms related to todos will go in /atoms/todos.js and so on.

That's all for now, thank you for reading until here. I hope you guys liked this post, if you did please like the post and follow me. Bye 👋

Use Multiple Threads in Node like a PRO

Akash Shyam — Fri, 26 Mar 2021 17:04:37 +0000

Time consuming and software intensive programs cannot be run on the main thread. With Piscina, create new threads with absolute ease.

Why Should You Care?

While building APIs, most of us have hashed passwords before storing it in our database(if you haven't... please do it). We often tend to go lightly on our hashing so that it does not affect performance. With multiple threads, this can be done separately without blocking the main thread and leaving the user hanging.

Example

Let's setup an NPM project:

npm init -y

Install piscina:

npm i piscina

Create an index.js file and add the following code:

const path = require('path');
const Piscina = require('piscina');

const piscina = new Piscina({
  filename: path.resolve(__dirname, 'worker.js')
});

(async function() {
  const result = await piscina.runTask({ a: 4, b: 6 });
  console.log(result);  // Prints 10
})();

We've created a new piscina worker and passed in the absolute path to the worker. Then, in an async function, we've allotted a task to our worker.

Now, for our worker.... let's create a worker.js file:

module.exports = ({ a, b }) => {
  return a * b;
};

Our workers can also be a promise.

const { promisify } = require('util');
// Make setTimeout() a promise
const timer = promisify(setTimeout);

module.exports = async ({ a, b }) => {
  // Fake some async code
  await timer(() => {
    console.log('1 second later');
  } ,1000);

  return a * b;
};

What we've seen is pretty straightforward and not very difficult to implement on our own.... here's where piscina start's to shine:

Efficient Communication Between threads
Task Cancellation
Delaying Availability
Custom Task Queues
Statics for run and wait times
Async Tracking
Support for Typescript(yay!), common JS and ESM

We'll look at most of this throughout the post.

Cancellation

For this, we'll need use the events package.... this comes by default so no need to install anything. The event package gives us an EventEmitter which we can use to send events. Our worker listens to the abort event, stops executing and throws an error to let us know that it was successfully cancelled.

const path = require('path');
const Piscina = require('piscina');
const EventEmitter = require('events');

const piscina = new Piscina({
    filename: path.resolve(__dirname, './worker.js'),
});

(async function () {
    const eventEmitter = new EventEmitter();

    try {
        const task = piscina.runTask({ a: 4, b: 5 });

        eventEmitter.emit('abort');
        await task;
    } catch (error) {
        console.log('Task cancelled');
    }
})();

If you look carefully, you will find that we haven't immediately awaited our task. If we don't do this, then by the time the abort event is emitted, the task would have finished executing.

This is by no means a complete list of what piscina can do.... checkout the official docs here.

That's it for now, I hope you guys liked this post. If you did please like it and follow me. Bye 👋

An Introduction to React Portals

Akash Shyam — Thu, 18 Mar 2021 14:08:18 +0000

The first thing that comes to my mind when thinking about the word portals is teleporting. We are able to teleport outside our parent-child hierarchy and create a sibling element. Today I'll be talking about React Portals. Before actually explaining what a portal is, let me tell you what do portals solve.

The Problem

Any basic react app has a div in the HTML file and a javascript file has the following code:

import React from 'react';
import ReactDOM from 'react-dom';
import App from './App.jsx';

ReactDOM.render(<App />, document.getElementById('root'));

ReactDOM converts the App component into HTML, CSS and Javascript and injects it into the selected element.

By default, most react apps have the following hierarchy:

We all embed our components into the <App /> component. When we try to build a modal component, we want it to cover the whole page and nothing else should be clickable. In normal HTML pages, we would do something like this:

<div class="content">
  <!-- button to open modal -->
  <button class="modal-activate">Open Modal</button>

  <!-- content of page goes here -->
</div>

<div class="modal hidden">
  <!-- Modal goes here -->
</div>

Through Javascript, we can do something like this:

const modal = document.querySelector('.modal');
const modalActivateButton = document.querySelector('.modal-activate');

modal.classList.remove('.hidden');

We can add some CSS to set the display to none in the hidden class... you get the idea.

As you can see, we have to sibling divs, one for the modal and the other for the rest of the content. Now, let's see how to do the same in React.

Portals

Portals basically allow us to add a component to a sibling div of the root div. First, we need to add another div in our index.html file.

<div id="root"></div>
<div id="modal"></div>

Let's create a new component called Modal:

import React from 'react';
import ReactDOM from 'react-dom';

export default function Modal({ title, content, actions, onDismiss }) {
    return ReactDOM.createPortal(
        <div>
                  // Content for modal goes here
                </div>,
        document.querySelector('#modal')
    );
}

Now we can add any buttons/content into the div.

That's it, we're done. A sibling div is created! That's all for now. I hoped you like this simple post, if you did please like it and follow me. Bye 👋

A Guide to Github Actions and CI/CD Workflows

Akash Shyam — Sat, 13 Mar 2021 15:13:38 +0000

Hey guys 🖐, Today I'm going to tell you all about github actions and we'll setup a CI/CD workflow

Github Actions

This is tool made by Github that helps us to automate tasks.

Before github actions, we had to push the code, run the tests manually, fix the bugs, test again, fix more bugs.... you know the drill. Github actions help us to automate this workflow. Let's look at CI/CD in detail:

Continous Integration

This involves merging code with existing codebase.
The developers push to a git repo and test suites are run automatically. If there is an error, then the next stage won't start. However, if all goes well, we move on to the next stage(you guessed it.... continuous deployment).

Continous Deployment

This involves sending code to hosting provider.
The pushed code(already tested and hopefully bug free) is pushed to the deployment server which reflects the changes in the live site. For example, after the CI stage, the code is pushed to heroku(hosting service in this example).

Terminology and Concepts

Workflows are automated procedures that live in your GitHub repository. This is the configuration for specifying how the automation works and it’s done with a YAML file.

name: Deploy to Firebase Hosting
on: push
jobs:
  build_and_preview:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - run: npm ci && npm run build
      - uses: FirebaseExtended/action-hosting-deploy@v0

This is a sample of a configuration file. Don't worry, we'll go through everything in detail later.

Actions
Actions are standalone commands like npm run test or npm run build. Actions are the building blocks of a workflow
Steps
Running an action is called a Step. An action is a single step. One step is to install dependencies, the next is to build app, then the last step could be to deploy to hosting provider.
Jobs & Runners
All of these steps create a Job. Jobs execute on a server called a runner. For most cases the runner is hosted on GitHub. You can host your own, but I have no idea how that works, so this blog post only refers to using GitHub hosted runners. When configuring the workflow YAML file you’ll see a spot for Jobs.
Steps
Steps are tasks that can be can be executed by a job.
Job
A job is made up of multiple steps and runs in an instance of the virtual environment. Jobs can run independently of each other or sequential if the current job depends on the previous job to be successful.

That's a lot of terminology... let's get our hands dirty with some code.

First Github Action

Github actions are created in .github/workflows folder in your root directory. If you want, you can follow along with your own project and we'll automate the hell out of it. You're free to call it anything you want. The actions will show up in the actions tab in github.

Each action has 3 compulsory properties:

name - name of the action()
on - when to run this action(eg. on pushing to repo)
jobs - work to be done when action is called(eg run test suite)

YAML/YML

If you don't know about yaml, yaml is basically JSON with brackets. Yaml relies heavily on indentation, make sure you have the right number of spaces/tabs. Let me give you a quick rundown of yaml syntax.

Indentation

example: 'lorem-ipsum'
example-object: 
  x: 'y',
  abc: 'pqr'

Arrays/Lists

array:
  - a: a
  - b: b

Let's create a new file deployment.yml. For the purpose of this demo, we will be creating an action that deploys to firebase hosting when code is pushed to master branch.

name: learn-github-actions
on: [push]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - run: echo 'PUSH'

We have added the following code into our deployment.yml file. Let's walk through each line step by step.

name: The name of the workflow as it will appear in the Actions tab of the GitHub repo.
on: The event to listen to(eg push, pull request etc)
jobs: An array of all the jobs
deploy: Name of 1st job, can add more jobs in similar fashion
runs-on: Configures the job to run on an Ubuntu Linux runner of the given version.
steps: Array of steps that run in the deploy job. Each item in this array is an action or a command

To push the changes, run the following commands in your terminal(after setting up remote origin):

git add .
git commit -m "Adding deployment workflow"
git push origin master

After pushing the changes, go to the actions tab of your repo

In the actions tab, if you have done everything correctly, you will find a workflow(It will have a title of the commit message) with a name of learn-github-actions(name of the workflow in yml file). Click on it.

Once you click on the workflow, you should see our yml file name and the deploy job in the workflow.

Now, click on the deploy job. After doing this, you will be able to see the various steps in our job. If you click on one of the steps you can see how it was run in the terminal

Continuous Integration and Testing

Let's implement a workflow that runs tests everytime code is pushed.

name: NodeJS Tests
on: ['push']
jobs:
  test_node:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [12.x, 14.x]
    steps:
      - uses: actions/checkout@v2
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm install
      - run: npm run build --if-present
      - run: npm run coverage

      - name: Coveralls
        uses: coverallsapp/github-action@master
        env:
          COVERALLS_REPO_TOKEN: ${{ secrets.COVERALLS_REPO_TOKEN }}
          COVERALLS_GIT_BRANCH: ${{ github.ref }}
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}

I've called it Node Tests and it runs on pull requests. I've created a job called test_node which runs on the latest version of ubuntu. Since we need our source code in our VM, we will use the actions/checkout@v2 community action to bring the code into the current working directory. We'll need node to execute our apps so we'll use another community action called actions/setup-node@v1 and specify our node version.

We're ready to start running our own commands. I've started with installing my dependencies using npm ci. Then, I'm running my test suite and building the application to make sure the build compiles properly.

If you have a more complex test suite like cypress, there's probably a community action for this.

Adding Continuous Deployment

Let's implement deployment to firebase hosting on merge and pull requests. The basic concepts of actions are the same, these can be used along with various hosting providers.

Most of these providers will have specific does on how to use github actions along with their product. For example, firebase has it's docs about here. There probably is a community action for every popular hosting service.

After running the following command, agree to the options. In the build command section, add a build command if required. Check out the files generated by firebase for me and we'll walk through the code.

firebase init hosting:github

In firebase-hosting-merge.yml:

name: Deploy to Firebase Hosting on merge
'on':
  push:
    branches:
      - master
jobs:
  build_and_deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - run: npm ci && npm run build
      - uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: '${{ secrets.GITHUB_TOKEN }}'
          firebaseServiceAccount: '${{ secrets.auto_generated }}'
          channelId: live
          projectId: auto_generated_variable
        env:
          FIREBASE_CLI_PREVIEWS: auto_generated_variable

In places where I've written auto_generated those are private variables given by firebase which I cannot disclose(otherwise you could access my app).

name is nothing new... we've looked at this before. on is set to push. Here we have added a branches array with the master branch.

Then we have the jobs, in which there's a build_and_deploy job. We've specified runs-on which is set to ubuntu-latest. Again, nothing new here.

The uses keyword tells the job to get v2 of the community action named actions/checkout@v2. This is an action that checks our repository and downloads it into the runner, allowing you to run actions against your code (such as testing tools).

The with provides input arguments that are needed by the action and env provides environmental variables.

The other file firebase-hosting-pull-request has almost identical code. Checkout various community developed actions
here.

Github actions does not stop here. There are a lot more things we can do with actions. Like AI based pull request reviewing, auto code fixing for starters.

Uses for actions

Publish NPM package
As soon as code is pushed to a branch, we can deploy our package to NPM
Push to master branch
Run test/deployment on pushing to the master/main branch
Scheduled background jobs
Used to backup database data(mostly firebase as it is not built-in) to cloud storage buckets

That's all for now, I hope you guys liked this post. Like the post and follow me if you did. Bye 👋

DEV Community: Akash Shyam

The Ultimate Cheatsheet To Mongoose Query Methods

Features To Look Out For In Future JS Versions

Class Fields

Top Level Await

Level Up Your Commit Messages With These Tips!

1. Specify the type of comment

2. Never assume another developer understands the original problem i.e. the reason for the commit

3. Limit the subject line to 50 characters

To Typescript Or Not To?

Advantages of Typescript

Disadvantages Of Typescript

Conclusion

7 Tips For Clean Code

1. Comments, Comments and More Comments

2. Meaningful Names

3. Console Warns/Errors

4. as unknown in Typescript

5. Use Babel Instead of tsc

6. Use SonarJS and Eslint

7. Opaque Types

Conclusion

What's new in React 18?

Suspense

Automatic Render Batching

Transition

Using React 18

Conclusion

Going 3 Dimensional With Three.JS

Scene

Parts of Objects

Geometry

Material

Mesh

Controls

Sphere

Torus

Cone

TorusKnot

Debug Panels

Conclusion

Selector Nesting Has Come to CSS 🤯🤯🤯 !!!

What Really Is nesting???

Without Nesting

@nest

Nesting Media Queries

Makes code more readable

A gotcha

Why I stopped using Redux and Used Recoil Instead

What's wrong with Redux?

Context API

Terminology with Recoil

Atom

Selector

Recoil

Derived State

Folder Structure

Use Multiple Threads in Node like a PRO

Why Should You Care?

Example

Cancellation

An Introduction to React Portals

The Problem

Portals

A Guide to Github Actions and CI/CD Workflows

Github Actions

Continous Integration

Continous Deployment

Terminology and Concepts

First Github Action

YAML/YML

Continuous Integration and Testing

Adding Continuous Deployment

Uses for actions

4. `as unknown` in Typescript