DEV Community: Anurag Hazra

Understanding Tech: Looking Beyond the Surface

Anurag Hazra — Sat, 21 Oct 2023 18:15:54 +0000

Photo by Sebastian Bill on Unsplash

Let's talk about abstractions.

Today, I was browsing twitter while I found this amazing article, it talks about how too many layers of abstractions have caused developers to only think in terms of tools instead of understanding the underlying systems of a tech.

This article also advices people to, And I quote:

Never just follow hype or trends.
Be curious. Don't just learn tools, try to understand how the underlying technology works.
If possible, try at least once to manually do what e.g. a configuration tool does for you.
If possible, try to look at the code for the tool. Even a basic understanding of the code can be very valuable. Stay curious. Keep learning. Experiment. Dive deeper into the technology that interests you. If possible, set up a homelab and use it as a playground for learning and breaking things.

The 2nd and the 4th point is what I want to highlight because previously I've attempted to write my thoughts on this topic but it was a terrible attempt, I wasn't able to convey my thoughts clearly on that article and ended up comparing react vs vue.

So after almost 3 years I want to take a second jab at this, where I want to write about the importance of "using a tool vs understanding a tool".

Don't just learn tools

Let's talk about design, I'm not a very good designer but like designing in my free time.
I also love to create abstract 3D designs in blender.

But the thing is, sure I do "designing" but do I actually "understand" designing?
Absolutely not.

Designing is not just about using a tool like figma, blender or photoshop and pressing few combinations of buttons until you get something which "looks" good. It's a process.

A good designer can design regardless of the tool that you give them, be it a figma board, photoshop canvas or a piece of paper.
A good designer embraces and understands the fundamental principles of design and applies them whenever they see fit.

Now coming back to tech, A good engineer is not someone who knows X framework nor it is someone who knows Y language. A good engineer is someone who has a certain level of understanding of the underlying systems.

For example, If you are an UI Engineer,

Learn about Immediate Mode vs Retained Mode UI models
Learn how browsers work
Learn how your framework works under the hood, even build your own clone of the framework.
Learn how your favourite programming language works under the hood, even build your own toy programming language.

The point is, it's fine if you are starting with a higher level of abstraction and getting things done or shipping things to production, But at some point slow down, hit the brake paddle and try to get a deeper understanding of the tools that you are using.

A good photographer is not someone who can just operate a camera (the tool), A good photographer is someone who can operate a camera AND understands/applies the fundamental principles of photography.

Curiosity Helped The Cat

Be curious.

They say curiosity killed the cat, but if you are reading this you are probably not a cat.

if you are a curious engineer that means you ask questions, explore new ideas, solve complex problems with simple solutions, and always find ways to get a deeper understanding of things.

If you are a curious engineer:

Wonder about this scary regex #([1-9fA-F]{2,})! Wonder how regexes work under the hood. Research and try to build your own regex engine from scratch.
Wonder how to build your own programming language. Research about compilers, Learn about compiler design, Write a simple parser or even build a toy language.
Get fascinated by physics engines like Box2D/Toxiclibs and wonder about how these physics engines work under the hood. Research, learn & build your own rigid body physics engine.
Wonder about how operating systems work, learn how to write a bootloader, you don't need to succeed at every step just have a general idea.
Wonder how complex & scary looking TypeScript code works. Ask questions, learn about it & get a deeper intuition.

In the long run the more curious you are the deeper your overall understanding of tech gets.

The End Goal

In conclusion, it's okay to use a higher level of abstraction but dive deeper into the tech and try to understand the fundamentals. Aim to become a "T" shaped engineer, have the breadth but also have the depth.

In the long run it will be extremely beneficial to you,
From being able to easily debug React code because you know how React works under the hood to writing efficient Regexes because you know ins and out of how regex engines work or even preventing your entire company to go down because of an evil regex.

Byte sized TypeScript #1 - Filter type

Anurag Hazra — Sat, 28 May 2022 11:27:27 +0000

Hiya! Welcome to the first post of my new TypeScript blogpost series.

In this series I'll demonstrate & deconstruct byte sized TypeScript snippets to help you understand how to write type-level code.

Let's start shall we?

Filter Type

In TypeScript we have a notion of tuple types which are basically directly comparable to Arrays in js. It looks something like this:

type MyTuple = [1, 2, string, boolean, null];

Now let's say we want to implement a Filter method similar to JavaScript's native Array.Filter in Type Level, how do we do this?

Here's the full implementation:
As we go forward I'll explain this type line by line.

type Filter<Arr extends unknown[], FilterBy> = Arr extends [
  infer FirstElement,
  ...infer Rest
]
  ? FirstElement extends FilterBy
    ? [FirstElement, ...Filter<Rest, FilterBy>]
    : Filter<Rest, FilterBy>
  : Arr;

type Demo = Filter<[1, 2, string, boolean], number>
// -> [1, 2]

Open on playground

Line 1:

In line 1 we have Arr extends [ infer FirstElement, ...infer Rest]

In here we are saying:
If Arr is equal to [infer FirstElement, ...infer Rest] then go into the true branch of the conditional type. This line will also ensure that the passed Arr is actually a Tuple. If not, the false branch will be taken which is returning the Arr in the last line.

The important part is the infer keyword, infer keyword is the inspection glass of TypeScript, it can extract what the value of the type is at a particular place.

Basically we are asking the TypeScript compiler "Hey! whatever is in this place assign it to this variable called FirstElement"

Then we can access this FirstElement type's value in the conditional branch.

Let's see an example:

type GetFirstElementOfArray<Arr extends any[]> = 
  Arr extends [infer FirstElement, ...infer Rest] 
    ? FirstElement 
    : never

type Demo = GetFirstElementOfArray<[1, 2, 3]> // 1

You'll also notice the ...infer Rest part, It is similar to JavaScript's rest syntax. This part will infer the rest of the elements in the array and save it in the variable called Rest which you can also access in the conditional branch, in this case it will have the values [2, 3].

Line 5, 6, 7:

Now we are inside the true branch of the conditional type

At FirstElement extends FilterBy we are checking if the FirstElement is equal to FilterBy

If the above condition passes we are going to return a new tuple type [FirstElement, ...Filter<Rest, FilterBy>], here we are including the FirstElement & then recursively calling the Filter generic again with the Rest of the elements.

Notice that we are also using the spread syntax ...Filter<Rest, FilterBy>, since the Filter generic returns a tuple we can spread it's value in this new tuple we are returning.

And if FirstElement extends FilterBy fails we are going to call the Filter recursively again but skipping the FirstElement this time, Filter<Rest, FilterBy>.

Now let's step through the code on each recursive call to understand better what's happening:

// Initial state
type D = Filter<[1, 'hello', 'world'], number>

Recursion #1:

// input <[1, 'hello', 'world'], number>
type Filter<Arr extends unknown[], FilterBy> = Arr extends [
  infer FirstElement, // 1
  ...infer Rest // ['hello', 'world']
]
  ? FirstElement extends FilterBy // 1 == number -> true
    ? [FirstElement, ...Filter<Rest, FilterBy>] // [1, ...Filter<['hello', 'world'], FilterBy>]
    : Filter<Rest, FilterBy>
  : Arr;

Recursion #2:

// input <['hello', 'world'], number>
type Filter<Arr extends unknown[], FilterBy> = Arr extends [
  infer FirstElement, // 'hello'
  ...infer Rest // ['world']
]
  ? FirstElement extends FilterBy // 'hello' == number -> false
    ? [FirstElement, ...Filter<Rest, FilterBy>]
    : Filter<Rest, FilterBy>  // Filter<['world'], FilterBy>
  : Arr;

Recursion #3:

// input <['world'], number>
type Filter<Arr extends unknown[], FilterBy> = Arr extends [
  infer FirstElement, // 'world'
  ...infer Rest // []
]
  ? FirstElement extends FilterBy // 'world' == number -> false
    ? [FirstElement, ...Filter<Rest, FilterBy>]
    : Filter<Rest, FilterBy>  // Filter<[], FilterBy>
  : Arr;

Recursion #4:

// input <[], number>
type Filter<Arr extends unknown[], FilterBy> = Arr extends [
  infer FirstElement, // unknown
  ...infer Rest // unknown
]
  ? FirstElement extends FilterBy
    ? [FirstElement, ...Filter<Rest, FilterBy>]
    : Filter<Rest, FilterBy>
  : Arr;
  // ^ false branch is taken since `Arr extends [infer FirstElement, ...infer Rest]` failed,
 //   thus empty Arr is returned.

That's about it, I hope you understood how the Filter type works now. At it's core the type is simple enough but understanding how each piece works is the important part.

In case you still couldn't understand the type level code, how about we rewrite the type level code to runtime javascript code?

You'll be surprised how similar it looks:

function Filter(Arr, FilterBy) {
    if (Arr.length < 1) return Arr;
    const [FirstElement, ...Rest] = Arr;
    if (typeof FirstElement === FilterBy) {
        return [FirstElement, ...Filter(Rest, FilterBy)];
    } else {
        return Filter(Rest, FilterBy)
    }
}

Filter([1, 2, 3, 'hello', true], 'number')
// [1, 2, 3]

Cool isn't it?

Anyways I think that's about it, I hope you learned something new & enjoyed the post.

I'll be continuing this blogpost series, so make sure to follow me on twitter or dev.to to get updated.

Thoughts on find-in-page with custom accordion elements.

Anurag Hazra — Sat, 08 Jan 2022 17:47:32 +0000

Today while scrolling the twitter timelines I stumble upon this interesting tweet by one of the google chrome engineer who is working on a pretty interesting problem on the internet which is being able to de-collapse accordions when user triggers a find-in-page action.

// Detect dark theme var iframe = document.getElementById('tweet-1479525286211248128-641'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1479525286211248128&theme=dark" }

While as developers we sometimes miss these small details but after glancing over these problem you will realize how impactful these small things can be for better accessibility, discoverability & usability of a web app.

The Problem

The general problem is easy to understand,

Say you might want to search something on a page but you couldn't because the content which you are searching for is inside a collapsed accordion.

I've built and seen many accordion components but each and every one of them lacked this feature, and there's a good reason for it which we will get into later.

Research & implementation on the userland

After trying out few of the well known component libraries like Radix, ChakraUI.
I decided "well whatever, let's just implement this. How hard could it be?"

Oh boi, I was in for a interesting ride of 50+ browser tabs searching for solution.

So to implement this on userland, we need to do few things

Detect if user in find-in-page mode by detecting keypresses of CTRL+F
Record the user's search keyword
Match that keyword against all the accordion contents and de-collapse ones which matches the keyword.

Pretty simple right? Well NO!

Just even detecting if user is in find-in-page mode or the user closed the search modal is tricky.

To properly detect the event, we have to record and save all the events which is happening in a eventQueue

See, when user presses CTRL+F first thing what happens is window gets out of focus or in other words the blur event is triggered, With this we can detect if find-in-page modal is open if CTRL+F event and BLUR event happened subsequently.

Let's look at the code quickly:




const usePageFind = () => {
  const [isFinding, setIsFinding] = React.useState(false);
  const [eventQueue, setEventQueue] = React.useState<string[]>([]);

  React.useEffect(() => {
    window.addEventListener("keydown", (e) => {
      // detect CTRL+F if it passes then push to events queue.
      if (e.key.toLowerCase() === "f" && e.ctrlKey) {
        setEventQueue((p) => [...p, "CTRL+F"]);
      }
    });
    window.addEventListener("blur", () => {
      // push blur event to queue
      setEventQueue((p) => [...p, "BLUR"]);
    });
    window.addEventListener("focus", (e) => {
      // push blur event to queue
      setEventQueue((p) => [...p, "FOCUS"]);
    });
  }, []);

  React.useEffect(() => {
    const openSlice = eventQueue.slice(-2);
    const closeSlice = eventQueue.slice(-3);
    // if eventQueue's last 2 elements are CTRL+F & BLUR then we know the find modal is open
    if (arrayCompare(openSlice, ["CTRL+F", "BLUR"])) {
      setIsFinding(true);
      console.log("Finding open");
    }
    // if eventQueue's last 3 elements are CTRL+F, BLUR & FOCUS then we know the find modal is closed
    // We are checking for FOCUS because if user closes the find modal the page will be refocused again.
    if (arrayCompare(closeSlice, ["CTRL+F", "BLUR", "FOCUS"])) {
      setEventQueue([]);
      setIsFinding(false);
      console.log("Finding closed");
    }
  }, [eventQueue]);

  return { isFinding };
};

And this is not even a perfect solution mind you.

Retrieving search keyword

But the real challenge here is detecting what user typed in the search field, because the window is blurred while user is searching we cannot hook into onKeyDown or any event handlers to know what user is typing.

But there is a very very very hacky trick which we can use to detect this, which I found while researching about this topic.

This article from Milan Laslop explained how the method works pretty well with implementation:
https://www.milanlaslop.dev/post/2020-01-11-javascript-detecting-what-the-user-searches-on-the-page/

I just implemented this on our code and lets see what the final code looks like:

NOTE: THIS IS VERY VERY BUGGY, AND ONLY A POC. DO NOT TRY THIS AT HOME.
Open this URL https://u8rtx.csb.app on a newtab for better experience

Thoughts

Now the above implementation which I created is not something I created to use in production nor it's a great solution, it's buggy, fragile, easy to break.

I solely created the example to show you how nearly impossible it is to build this without proper platform APIs.

Better Solutions

Next we will talk about possible naive solutions to this problem which you can use today & what new features are coming in HTML spec to improve & solve this problem.

Solution 1: De-collapse all the accordions on find-in-page trigger

A simple yet elegant solution would be to de-collapsing all the accordions in the page when we detect find-in-page event with our previously discussed usePageFind hook.

Solution 2: Use the platform

As mentioned in the original tweet which Joey Arhar is working on chrome 97 now supports auto expanding of the elements which you can use.

See live demo: https://auto-expanding-details.glitch.me/#target

With New APIs

Along with having built in support for this, since here we are talking about custom accordion elements we can also leverage new APIs which has been worked on namely:

hidden=until-found HTML attribute
and the beforematch event

These two together will enable us to build custom accordions with the same capability of text search in collapsed items.

Read hidden content spec to know how it works.

Conclusion

And that concludes my today's research on this interesting problem, I hope you learned something along the way.

It's amazing to see that browser are working on these type of features to improve the UX and the overall experience we have building websites which are generally more accessible.
Hope to see more features like this to land.

Without the new hidden content feature it's nearly impossible to build something like this.

Generally I would like to see all modern component libraries adopt these new platform patters to improve their components.

Links & glosarry

2021 In Review, Huge milestones! 🥳

Anurag Hazra — Fri, 31 Dec 2021 08:28:11 +0000

This year was probably the most impactful year so far, from Open Source to Career every aspect of my life got improved one way or another.
As the year ends I want to look back at my achievements and celebrate the end of the year with this blogpost.

Milestones of 2021

Got an amazing job at Razorpay
Selected for GitHub India Open Source grants program
github-readme-stats
- hit 10million requests per month
- hit 35k stars on github
Speaking
- Talked about Advanced TypeScript at Tech Talks With Santosh
- Spoke at React Summit 2021 with some of the wonderful panelist
- Spoke at ReactFinland about building flexible component libraries
Got a lot of support from people via GitHub Sponsors
Bought a new phone
Graduated from college
Donated to to people who are in need via TeamSeas, GiveIndia.
Made few beautiful 3D artworks & started voxel modelling
Learned about advanced GLSL Shaders
Learned and deep dived into building compilers & parsers
Leveled up my TypeScript skills & tweeted a ton of things
Participated in GitHub Actions Hackathon 2021
Wrote a blogpost about my interview experience at Razorpay
Took my first ever interview of a candidate at razorpay
Connected with lots of amazing people on twitter & made new friends. <3

Other Random Stuff I Did

Bought anuraghazra.dev domain
Learned more about web accessibility
Started writing a card builder for github-readme-stats
Bought my first ever book planning on starting a reading habit.
Bought a lot of house appliances :)
Built few small experimental projects
Built a toy programming language

Aaaaandddd... That's a wrap!

This year was full of great achievements & learning.
But one of my greatest achievement is the smile which I was able to put in my mom's face, it's just a wonderful achievement which is above every other thing and I thrive to continue keeping that smile always.

I also wanted to thanks few of the notable people who impacted my year in a positive year.
Huge Thanks to Santosh, Kamlesh, Divyanshu, Saurabh for supporting & encouraging me.

Happy New Year! Cheers! 🥂

Explain Like I'm Five: TypeScript UnionToIntersection type

Anurag Hazra — Tue, 07 Dec 2021 15:36:00 +0000

Few moths ago while playing around with TypeScript types, I found myself wanting to convert an union to intersection type.

When I realized that I literally have no idea on how to do it,
As any other 10x developer, I googled it - "Union to intersection in typescript".

Immediately I found this amazing post by @ddprrt, after going through the post, I had no idea how that UnionToIntersection type worked, It looked like magic to me and didn't even understood the concept of contra-variant/co-variant so I just copy pasted the utility and moved away pondering how it works.

Couple months later when I got better at TypeScript I dived deeper into type variance and got a general idea about it.
This video from @titiancernicova helped me a lot to understand about variance in typescript along with this post, but still I sometimes get confused about variance.

Now, today with this post my aim is to make you understand the UnionToIntersection type without even knowing about variance.
I will explain the type step by step in simple terms so that you can understand it.

Anatomy Of UnionToIntersection

Let's first on a very high level visualize the anatomy of the UnionToIntersection type and see a demo of how it works.

As we go deeper unpacking the type we will discuss more details about each part.

let's say you have an union like this, which you want to convert to an intersection.

type ContactMethods =
    | { email: string }
    | { phone: number }
    | { address: string }

type User = {
    // Need intersection of ContactMethod here :(
    // something like this { email: string } & { phone: number }
    contact: DoSomeMagic<ContactMethods>
}

Let's drop in the UnionToIntersection type.
As you can see the type is now converted to an intersection.

TS Playground link

type UnionToIntersection<T> = 
  (T extends any ? (x: T) => any : never) extends 
  (x: infer R) => any ? R : never

type User = {
    contact: UnionToIntersection<ContactMethods>
//  ^? { email: string } & { phone: number } & { address: string }
}

Let's Unpack

Naked type & distributive conditional type

So first the type takes an generic parameter T.
type UnionToIntersection<T> =

Then on the second line, we are doing this
(T extends any ? (x: T) => any : never)

Here the T extends any is a naked type, which means that it isn't wrapped in anything.
TypeScript conditional types have a special property that if you pass an union then the conditional type will be applied to each member of that union, given the type is a naked type.

Refer to @ddprrt's article to learn more about this section of the code, I'm skipping the detailed examples here since I don't want to repeat the same.

Learn more about distributive conditional types

Extracting out

Let's extract out the first part of the type to a different utility type for easier understanding,
And go step by step of how the compiler will evaluate the type.

type ToUnionOfFunction<T> = T extends any ? (x: T) => any : never

// Phase 0
type Demo0 = ToUnionOfFunction<
  { a: string } | { b: string }
>
// ↓
// Phase 1 - Union gets distributed to each of it's member
type Demo1 = 
  | ToUnionOfFunction<{ a: string }> 
  | ToUnionOfFunction<{ b: string }>
// ↓
// Phase 2 - `{ a: string }` becomes `(x: { a: string }) => any`
type Demo2 =
    | ((x: { a: string }) => any)
    | ((x: { b: string }) => any)

TS Playground Link

Simple enough right? Basically it converts the passed union to an union of functions.

The key thing here is the distributive conditional type (T extends any,
if we just used (x: T) => any then the type would resolve to:
(x: { a: string } | { b: string }) => any

type ToUnionOfFunction<T> = (x: T) => any;
type Demo = ToUnionOfFunction<{ a: string } | { b: string }>
//   (x: { a: string } | { b: string }) => any

Understanding how the intersection will happen

Now that we have this union of function.

type UnionOfFunctions =
    | ((x: { a: string }) => any)
    | ((x: { b: string }) => any)

let's assign this to a function and see what happens

type UnionOfFunctions =
  | ((x: { a: string }) => any)
  | ((x: { b: string }) => any);

const foo: UnionOfFunctions = () => {};

// 'b' is missing
foo({ a: "hello" });

// 'a' is missing
foo({ b: "world" });

// Works
foo({ a: "hello", b: "world" });

What's happening here is that, to safely call the function foo which has a type of UnionOfFunction we have to pass a type which will satisfy both of the function's requirement. In other words the argument must be { a: string, b: string }

Voila! we get an intersection type in the param.

TS Playground Link

Now all that is left is to get the type of the parameter, which covers the second part of the type.

Second Part

Let's move to the second and final part.
extends (x: infer R) => any ? R : never

In this part we are first checking if the result of ToUnionOfFunction is equal to this (x: infer R) => any, but instead of passing T into the arg we are inferring the argument with the keyword infer

Let's inline all of it:

// Result of ToUnionOfFunction<T>
type UnionOfFunctions =
  | ((x: { a: string }) => any)
  | ((x: { b: string }) => any);

type Demo = UnionOfFunctions extends (x: infer R) => any ? R : never;

Infer keyword is like a magnifying glass of TypeScript which lets us inspect any certain type from the eye of compiler & extract it to a type variable, in this case R

And that's it! 🎉

Let's look at the whole thing at once.

TS Playground link

type ToUnionOfFunction<T> = T extends any ? (x: T) => any : never;

type UnionToIntersection<T> = 
    ToUnionOfFunction<T> extends (x: infer R) => any ? R : never;

type ContactMethods =
  | { email: string }
  | { phone: number }
  | { address: string };

type User = {
  contact: UnionToIntersection<ContactMethods>;
  // ^?
};

Conclusion

I hope you got a basic understanding of how this handy type works.

Now as I said my aim with this post was to explain and breakdown the type without going into the topic of variance, So I oversimplified some things and how the intersection on the param actually happens so,

If you want to learn more about exactly how it works and go digging deeper into this topic here are few resources:

Follow me on twitter for more TS related posts. :) Thanks for reading.

Using GitHub actions to enhance profile readmes

Anurag Hazra — Fri, 26 Nov 2021 14:19:48 +0000

My Workflow

One of the coolest features of GitHub is profile readmes, It helps developers present their work in a cohesive manner and works as a gateway to showcase skill and dedication.

From the start I was always intrigued by making the profile readmes more dynamic so that's why I built github-readme-stats It's been used by thousands of people and gives insights on their progress in open source.

That's why I decided to create this github action, peerlist-profile-action.

You might ask what is peerlist?
Peerlist.io is a modern platform for developers to showcase their work, achievements and resume all at once place. It's a great platform it's currently in beta and shows great potential.

peerlist-profile-action is a simple action which uses puppeteer to automate and generate dynamic resumes which you can embed in your profile readme as an image.

It works by simply installing the action on your github profile readme, see usage guide

After the action is finished running, it will automatically upload and commit the dynamically generated profile readme png file to your repository which you can embed like so

[![](./images/peerlist-profile.png)](https://peerlist.io/your_username)

Features

Easy to setup
Multiple themes
Different sizes
Options to customize

Themes

Simply pass theme_name option to the action inputs and you can change the theme of the card as you like.
Here's the list of all available themes.

Multiple Sizes

Passing the card_size argument you can change the size of the card, currently we support "sm", "md", "lg" or any number.

Customizations

If you want to customize the colors and build your own theme you can also do so by passing these inputs:

output_path - Output path to upload the image
title_color - Card's title color (without #)
text_color - Body text color (without #)
bg_color - Card's background color (without #)
branch - Branch which you want to upload the image, change it depending on your main branch (default: main)

Submission Category:

Wacky Wildcards

Yaml File or Link to Code

Usage:
Inside .github/workflows folder create a new workflow called peerlist-overview.yml and copy paste this content:

name: 'peerlist-overview'
on:
  schedule:
    # run every day at 12
    - cron: "0 0 * * *"

jobs:
  peerlist-run:
    name: Generate peerlist overview
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: browser-actions/setup-chrome@latest
      - uses: 'anuraghazra/peerlist-profile-action@master'
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          username: 'anuraghazra' # your peerlist username

anuraghazra / peerlist-profile-action

Peerlist Profile Action

Get dynamically generated peerlist.io profile overview on your readmes!

View Demo · Report Bug · Request Feature

Love the project? Please consider sponsoring to help it improve

A GitHub action to get peerlist.io profile overview on your readmes.

Usage

see action.yml

Inside .github/workflows folder create a new workflow called peerlist-overview.yml and copy paste this content:

name: 'peerlist-overview'
on:
  schedule:
    # run every day at 12
    - cron: "0 0 * * *"
  
jobs:
  peerlist-run:
    name: Generate peerlist overview
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: browser-actions/setup-chrome@latest
      - uses: 'anuraghazra/peerlist-profile-action@master'
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          username: 'anuraghazra' # your peerlist username

After running the action, it will automatically create a commit and upload it to the repo. And you can import that image to…

View on GitHub

Additional Resources / Info

Open source libraries & action used in this project:

Since I used puppeteer, to install chrome in github action ci, I used browser-actions/setup-chrome action from https://github.com/browser-actions/setup-chrome

My FrontEnd Interview Experience At Razorpay

Anurag Hazra — Wed, 25 Aug 2021 16:53:29 +0000

Hey Folks! I hope you are doing great.

As you know from the announcements that I've recently joined Razorpay as a FrontEnd Engineer.

So this is a writeup about my interview experience at razorpay and how I
cleared the interview and got the offer!

After over 1k LinkedIn likes & 600 twitter hearts, and 50+ DMs about
"what is the interview process at razorpay?" I'm finally writing this.

// Detect dark theme var iframe = document.getElementById('tweet-1427348086188232739-587'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1427348086188232739&theme=dark" }

Let's get started. First thing first I've got a lot of questions in one week and the most frequent one is:

"How did you get this opportunity?"

Simple one liner answer to this question would be
"I built my personal brand, showcased my skills publicly and connected with friends in the community who work at razorpay"

My story of getting the opportunity is bit interesting, so there was a twitter post from the Razorpay engineering handle and I posted a meme as a reply to that post,

Then Kamlesh DM'd asking if I was ready to explore the opportunity, even though that tweet was totally a joke from my side and I had no plans to join razorpay atm 😂, I still took the opportunity and moved forward with the interviews. (And boi I'm glad I did)

https://twitter.com/anuraghazru/status/1413166291821600770

And there goes my sweet 🥰 twitter friends creating "HIRE ANURAG CAMPAIGNS".

Thank you Sid, Vish, Saurabh it was very wholesome :)

Now the interesting story out of the way, let's talk about the interview experience.
So there was a lot of queries about the interview process at razorpay from folks.

So the first thing which I really liked about the interview process is that you will immediately be given a "Interview Preparation Guide - FE Engineer" document which will have everything you need to know about the whole process,
I cannot say enough how useful that document was.

It had information about the Razorpay's Philosophy, the interview rounds and what to expect from the each round and evaluation criteria for each round, also few handy interview tips.

First I had a catch-up call with Kamlesh it wasn't part of the interview but just to give me a general idea of what I'm going into we decided to have a call and Kamlesh discussed with me about the structure and the business model and what they are doing at Razorpay, It was a great insight and after that I decided to move forward with the real interviews.

First I got a call from the recruiter about the schedule and you will get daily reminders before each interview from the recruiter.
And after clearing every round you will get call from the recruiter for the next one.

He scheduled the first interview.

Let's start with the rounds then. In total there was 4 interview rounds:

Round 1 (1 Hour) Technical Deep Dive
Round 2 (1.5 Hour) Coding Round
Round 3 (1 Hour) Web Fundamentals
Round 4 (1 Hour) Hiring Manager Round

Round 1 (1 Hour) Technical Deep Dive

This round heavily focuses on discussions about your own projects (any project) and your work experience.

I was asked about my work experience at timelessco and what projects I worked on, we talked a lot about the design system & component library I was building at timeless.

It was like a discussion about the project on how it works, what challenges I faced building it, what things I liked about the projects.

We also talked about my open source projects, we talked about github-readme-stats and BugVilla.

Interviwer asked me "What are the challenges you faced building BugVilla"

I answered, and discussed about how I had to rewrite the whole redux state management code to add optimistic updates and to fix the laggy behaviour because of wrongly structured state of the application.

it was a pretty chilling experience and discussion.

Tips to clear this round:

Study your past projects to get a refresher on your memory before going into this round
Brag a lot about your projects
Don't hesitate to say you wrote a bad piece of code
Justify your answers/approach to solving the problem clearly

Round 2 (1.5 Hour) Coding Round

This round is a typical coding round it will be on codesandbox.io and you can choose any framework/language to solve the given problem.

Unlike other companies where you will be given to revert a binary tree, at razorpay you will only get real-world problems to solve. Which is :chefkiss:

For me this round was more like "pair-programming" than "coding-test",

Interviewer will not just sit around watch you type code, interviewer will also give you hints, tips and discuss the problem with you.

My question statement was a medium difficulty task, it was carefully created to test your understanding of basic to advanced concepts in FrontEnd development.

Although it was pretty straightforward (spoiler, but I messed it up) I started explaining what I will do and took some time to plan my approach.

After that I started implementing one of the core part of the logic where I kinda mess things up, I decided to go with a typical old school approach to the problem but not to mention It did not worked very well, it was kinda broken and I could not deliver the whole thing, but I wasn't too afraid or nervous because it was a fun learning experience for me.

After finishing the half-baked demo my interviewer asked "Anurag, how else can you solve this problem?"

Just after hearing that question my mind blowed and I got the idea which I totally missed.

I proposed my solution but since we did not had time I could not implement it.

Now you might say "Woooww Anurag you totally messed this up!"

Yes I did, but the cool thing about this interview is that they aren't looking for solid solutions from you, they just want to test out your thought process and approach to solving the problem by thinking it in logical way.

Even though I could not deliver the solution I was able to come up with the solution and approached the problem in a logical manner.

Tips to clear this round:

Think out loud, convey all your thought process to the interviewer so that they know you are solving it in a logical way.
Ask questions about the problem statement.
Plan before you write the code, don't jump into it directly.
If you are stuck discuss with the interviewer about the problem and explain it to him.
If you could not deliver the solution at least think of few different approaches to the problem and propose that to interviewer.

Round 3 (1 Hour) Web Fundamentals

This is also a discussion based round where you will be asked various open-ended questions like "How to build X feature", "How X works in Y"

I just loved this session!! It was like two engineers discussing on how something works. You won't believe how much I learned from this one interview, it was very insightful and learned a lot.

I got asked about 4 or 5 questions all of which were interconnected to one another.

First question was pretty straight forward and I had experience with it so I explained it pretty well.

Then the second question was bit more tricky, there was a few more interconnected questions about web fundamentals and how the web works.

It was a such a information packed session that I felt knowledgeable after leaving that interview session. 🤯

Tips to clear this round:

Just discuss your thoughts clearly.
You are also the interviewer, so ask questions.
Focus and study fundamentals of how web works.
break down problems into smaller chunks and explain them

Round 4 (1 Hour) Hiring Manager Round

This round was also a discussion based one, but it was more like a culture fitment round, there was lots of small questions about my own work experience in my previous firm, the teams, how we worked and my day to day work at timeless.

This round mostly focuses on my:

Ability to resolve conflicts in the team
Decision making ability
Which time management method I like most (I like macro management)

There were specific questions like

"If a team member proposed a solution which you don't agree with (vice versa) in that case what will you do"

There were also behavioural questions

"What motivates you most and what is the one feature which you built you are not proud of?"

Interviewer will also explain to you about how the work happens and various things about razorpay.
This is the best chance to clear up any org specific questions if you have.

Tips to clear this round:

Be honest and be "you" because you have to work with a team seamlessly in day-to-day life.
Be rational about your thought process and answer the questions correctly.
if you don't have the experience to answer the question, just say "I don't have the experience but If i was in that situation I will do...this that and that..".
Ask lot of questions.

And that's it folks! Thanks for reading all the way through.

My interview experience at razorpay was super smooth and I felt like I could give another 5 rounds without any issue. It was relaxing and a fun learning experience.

In Conclusion

You will not be the only person learning from the interview, It is a both side interview.

If interviewer asks you 10 questions, you should also ask 10 questions. Do reverse interview!

Ask questions.
Think out loud.
Plan your approach.
Make sure you have projects to showcase and brag about.
Don't be nervous, take the interviews as a fun learning experience :).

I hope this writeup will help you pass your next interview at Razorpay (hope to see you soon in the team)

I would like to thank you the wonderful onboarding and interview team at razorpay and especially Kamlesh, he guided me through the whole process and even gave me personal guidance on career.

Finally also like to thank you timeless.co for being so nice and respecting my decision.

Thanks! Bye!

A Successful Year For Me, 2020 In Review.

Anurag Hazra — Wed, 30 Dec 2020 17:27:39 +0000

Phew! 2020 was a crazy year!

For most people 2020 was tragic and probably you wish that no year should be as worst as 2020, which I agree too!

But... 2020 was one of THE most successful year for me

Highlights of 2020!

GOT AN AMAZING JOB AT @timelessco as a FrontEnd Engineer! 😍
Bought my mom a saree from my own salary which was my mom's dream.
Bought a shiny new laptop ❤️
Launched github-readme-stats which was a huge success
github-readme-stats hit 10k stars on github (now 16k)
github-readme-stats got sponsored by Vercel
github-readme-stats become one of the rising stars of 2020
Released my project BugVilla
Gave my first ever conference talk on typescript
Participated in Official GitHub Actions Hackathon and got merchs!
Got lots of OSS donations for github-readme-stats largest was $100 from Robert Hofmann (Thanks Robert!)
Finished #DesignPatternsEveryday challenge and wrote blog which got lots of attention.
Started working on ConvoyChat
Started working on renderlesskit at work
@realtoughcandy reviewed my portfolio site
Started learning Rust
Learned some advanced TypeScript patterns
Got my Gatsby swag!
Forgot to claim my github action hackathon prize 😂 (but thankfully got it after contacting Nat Friedman)
Finished yet another hacktoberfest
Stopped using facebook
Gained a bit fat :p
Made lot of new friends on discord & twitter

Other Random Stuff I Did

Started Learning GraphQL
Made few creative coding projects
Learned a lot about testing
Learned a lot about making a11y react components
Learned Design Patterns
Did lot of open source stuff
Created few UI Designs
Wrote few blogs
Learned a bit of XSS
Started doing some leetcode (but eventually left it)
Learned a few neat js animation tricks
Tried out few libraries like MobX, Recoil, XState, ThemeUI, Svelte
Learned some advanced Typescript patterns

2020 might be a bad year but still 2020 was full of success, learnings & happiness for me and my family!

We all lost lot of things this year, learned lot of stuff, and I hope at the end of the year we overcome all our difficulties and hope for the best in 2021!

Happy New Year! Cheers! 🥂

Dynamically Generated Github Stats For Your Profile ReadMe

Anurag Hazra — Fri, 10 Jul 2020 07:44:35 +0000

Hey guys! i hope you are doing well.

Yesterday after seeing that lot of people on twitter are creating their Github profile Readmes i thought i should do something cool & unique, so i created this ->

Github Readme Stats

Features

anuraghazra / github-readme-stats

⚡ Dynamically generated stats for your github readmes

GitHub Readme Stats

Get dynamically generated GitHub stats on your READMEs!

View Demo · Report Bug · Request Feature · Ask Question

Français · 简体中文 · Español · Deutsch · 日本語 · Português Brasileiro · Italiano · 한국어 Nederlands नेपाली . Türkçe

Love the project? Please consider donating to help it improve!

Are you considering supporting the project by donating? Please DON'T!!

Instead, Help India fight the 2nd deadly wave of COVID-19.
Thousands of people are dying in India for lack of Oxygen & COVID related infrastructure.

Visit https://indiafightscorona.giveindia.org and make a small donation to help us fight COVID and overcome this crisis.
A small donation goes a long way. ❤️

Features

GitHub Stats

…

View on GitHub

Github readme stats allows you to simply add a markdown image link and it will show you realtime stats for your github account.

![Anurag's github stats](https://github-readme-stats.vercel.app/api?username=anuraghazra)

And the cool thing is since it's just an image you can embed it anywhere even on Dev.to posts!

Live Demo:

Pretty neat isn't it? Try it out right now on your profile readme too! :D

After seeing that people liked the Github Stats Card idea i created Github Extra Pins

Github Extra Pins

Github extra pins allows you to pin more than 6 repositories in your profile by using github readme profile.

Yey! you are no longer limited to 6 pinned repos

[![Dev.to](https://github-readme-stats.vercel.app/api/pin/?username=thepracticaldev&repo=dev.to)](https://github.com/thepracticaldev/dev.to)

Live demo:

Top Languages Card

[![Top Langs](https://github-readme-stats.vercel.app/api/top-langs/?username=anuraghazra)](https://github.com/anuraghazra/github-readme-stats)

Live demo:

Check out the docs to learn more

That's it :D
I hope you guys liked the project. And make sure to give it a star on Github

Featured By Github!

GitHub

@github

Did you notice that we quietly launched GitHub Profile READMEs? This post over on @thepracticaldev highlights ten, and shares how you can enable yours: dev.to/github/10-stan…

18:05 PM - 24 Jul 2020

Tweets

Github Stat Card

Anurag Hazra ⚛

@anuraghazru

Hello guys. I thought i should do something unique and dynamic with @github's new readme resumes. 👇

Introducing Github Readme Stats! dynamically generated stats for your github readmes 🎉

You can also use this on your own readme! check the docs!
github.com/anuraghazra/gi…

10:49 AM - 09 Jul 2020

Github Extra Pins

Anurag Hazra ⚛

@anuraghazru

Hello guys. after seeing that you guys liked the Github Status Card, i'm happy to announce..

Github Extra Pins! 🎉 You can now pin more than 6 github repos in your account!!

Try it out right now! 👇👇 github.com/anuraghazra/gi…

@github

17:35 PM - 09 Jul 2020

Using a tool vs. knowing how a tool works internally.

Anurag Hazra — Tue, 26 May 2020 17:16:20 +0000

My thoughts about using a tool vs. understanding how a tool works internally.

Photo by Todd Quackenbush on Unsplash

Before we start let me tell you that this post isn't about which tool is better vue or react, my intentions are to express my thoughts about "Using a tool vs knowing how it works" & "If the tool is easier to work with, does that means it's easier to understand how it works?"
Also note that i'm not an Vuejs expert.

Here's an important thing,

People say react is hard but it's not, they think it's hard because they don't know how it works.

People say redux is hard but it's not, they think it's hard because they don't know how it works,

People say Vue is amazing and easy to use (of course it is) but most people don't know how it works internally, but still they love it and find it easier than react.

The point to be noted here is that Vuejs is magic, and Reactjs is JavaScript just plain simple JavaScript.

Most people find react hard because they lack the fundamental understanding of the language (js).

But they don't find vuejs hard because vue does magical stuff to abstract away all the things which you have to do in order to get the app running.

Now if I ask someone
"How does vuejs works"
"How vuejs handles the template"
"How v-if v-for works?"

Well Vuejs parses the template in 3 stages.

Compilation stage.
Optimization stage.
CodeGen stage.

Vuejs firstly parses the template and creates an AST representation of the template and parses all the directives, elements, tags, childrens, and then it runs the second stage of optimization stage where it sets a "static" flag on the nodes which are not gonna be dynamic, and then finally it generates a render function (an hierarchical representation of VirtualDOM).

Vue needs to hide these implementations away from the end users in order to make it a breeze to work with. (which is in my opinion is amazing)

But knowing how vuejs internally works requires knowledge of AST, compilation, optimization, codegen etc etc. which in my opinion is not an easy task.
And we haven't even talk about Reactivity in vuejs.

Now, let's talk about React.

If I ask someone
"How react works?"
"How conditional rendering works?"

Well in case of react, the internals are far far more simpler than Vuejs.
and yes modern react uses JSX compilation but you need to know how React.createElement works not how compilation works in order to understand how react works.

React has a React.createElement method which takes 3 parameters (tagName, props, childrens) in order to create a virtual dom node.

basically ->

<p>hello</p> 
// converts to
React.createElement("p", null, "hello");

Now with this simple factory function we can compose the whole virtual dom tree like this

React.createElement(
  'div', 
  null,
  React.createElement('p', null, "hello")
)

After composing the dom tree ReactDOM.render will recursively mount the vdom to the actual dom.

And that's basically it. and the cool thing is because Reactjs is just plain simple javascript it answers all the questions like

How conditional rendering works.
How loops will be handled.

Because React.createElement is just a function call you can just pass an array of childrens

let arr = ['one','two', 'three'];

React.createElement(
  'div',
  null,
  arr.map(v => React.createElement('p', null, v))
)

In my opinion for an average person to understand "How React works" is far easier than "How Vue works"

Because in case of vue you need to know about compilers, AST, optimizers, codegeneration.
but to understand React you just need to understand how vdom (for vue too) works and how recursion works.

Now i know some people might disagree but its just my personal opinions.

React is javascript.
Vue is magic (not magic, CS actually).
Vue is easier to work with.
React is easier to understand.

People like Vuejs because of its simplicity.
I heard from lot of Vuejs devs that React is hard, and they say that because vuejs is easier to work with and does all the magic as i said earlier.

But React is much more simpler to understand.

The point of this whole post is not about "React is better" or "Vue is better" it's about as a developer we should know how our tools works because knowing that is beneficial.

"Don't just use it, understand how it works"

Design Patterns Everyday

Anurag Hazra — Thu, 21 May 2020 09:33:18 +0000

Photo by Flo P on Unsplash

Originally posted on my site

Hey folks! few weeks ago i started a new challenge to learn about one design pattern everyday i called it
"#DesignPatternsEveryday".

Since i completed the challenge i thought i should share briefly what i learned about design patterns, let's get
started.

I will be going over most of the patterns and going to explain them in my own words, so if you find any mistakes or
misinformation please let me know. i'm not a design patterns expert.

Table of Contents

What are Design Patterns?
Day 1 - Abstract Factory Pattern
Day 2 - Builder Pattern
Day 3 - Factory Method
Day 4 - Singleton
Day 5 - Adapter Pattern
Day 6 - Bridge Pattern
Day 7 - Composite Design Pattern
Day 8 - Decorator Pattern
Day 9 - Facade Pattern
Day 10 - Proxy Design Pattern
Day 11 - Chain of Responsibility
Day 12 - Command pattern
Day 13 - Iterator pattern
Day 14 - Mediator Design Pattern
Day 15 - Observer Design Pattern
Day 16 - State Pattern
Day 17 - Strategy Design Pattern
Day 18 - Template Method
Day 19 - Visitor Pattern

What are Design Patterns?

"Design patterns are typical solutions to common problems in software design. Each pattern is like a blueprint that you
can customize to solve a particular design problem in your code." - refactoring.guru

There are 3 categories of design patterns, we are going to cover them one by one.

Creational
Provides a way to create new objects which increases the flexibility and reusability.
Structural
Helps to structure & assemble objects and classes while making them flexible.
Behavioural
Helps to communicate between objects and concerned with responsiblities between objects.

Also note that, One thing is really important for utilizing design patterns in your project.

Never start with the mindset of "okay I'm going to use {this pattern} in the codebase"

Judge & analyze the code base, plan the logic and implementation first then apply design patterns to solve any
particular problem only IF NECESSARY.

Design patterns are solution to problems, not solution finding problems.

Day 1

Abstract Factory Pattern

Abstract factory is a creational design pattern which allows us to produce families of objects without specifying their
concrete classes.

Suppose you are creating a drawing app where you'll have tools like "draw box", "draw circle" but you also need rounded
variants of box & circle, in that case you can create a factory for "ShapeFactory" and "RoundedShapeFactory" which will
return respective shapes.

Use Cases

Abstract factory pattern could be helpful in scenarios while you need to have a framework work cross platform, for
example "Electronjs". i dont know how electronjs handles that probably not with factory pattern but it can be
implemented with factory pattern.

Example

code on github

class Button {
  render() {}
}

class Factory {
  createButton() {}
}

class WinButton extends Button {
  render() {
    return "<button class='windows'></button>";
  }
}

class LinuxButton extends Button {
  render() {
    return "<button class='linux'></button>";
  }
}

class WinFactory extends Factory {
  createButton() {
    return new WinButton();
  }
}
class LinuxFactory extends Factory {
  createButton() {
    return new LinuxButton();
  }
}

class AbstractFactory {
  static factory(type) {
    switch (type) {
      case 'windows':
        return new WinFactory();
      case 'linux':
        return new LinuxFactory();

      default:
        break;
    }
  }
}

let guiFactory = AbstractFactory.factory('linux');
let button = guiFactory.createButton();
console.log(button.render());

Day 2

Builder Pattern

Builder pattern is creational design pattern which allows us to create complex objects in a step by step manner. It
allows us to create different type of objects with same code.

Real World Analogy

Think of it as car assembly line. The car will be assembled with parts gradually step by step, firstly its chassis will
be setup then the engine, radiator, wheels, seats, doors. and by modifying these steps in the assembly line we can
create different types of car models with the same assembly line.

Use Cases

Builder pattern is useful when you want to create various objects with different representation without creation
subclasses for each of them.

I implemented builder pattern in one of my previous project
Evolution Aquarium to build different kind of Boids with different
behaviours and traits.

Example

code on github

class Car {
  constructor(engine, fuelTank, seats) {
    this.engine = engine;
    this.fuelTank = fuelTank;
    this.seats = seats;
  }

  printSpecs() {
    console.log(this.engine, this.fuelTank, this.seats);
  }
}
class CarBuilder {
  constructor() {
    this.engine = '';
    this.seats = '';
    this.fuelTank = '';
  }

  addSeats(name) {
    this.seats = name;
    return this;
  }
  addEngine(value) {
    this.engine = value;
    return this;
  }
  addFuelTank(value) {
    this.fuelTank = value;
    return this;
  }

  build() {
    return new Car(this.engine, this.fuelTank, this.seats);
  }
}

let truck = new CarBuilder()
  .addSeats(8)
  .addEngine('v12')
  .addFuelTank('200liters')
  .build();

let sedan = new CarBuilder()
  .addSeats(4)
  .addEngine('v6')
  .addFuelTank('100liters')
  .build();

Day 3

Factory Method

Factory Method Pattern, its similar to abstract factory method but has some subtle differences. In Abstract factory
pattern it creates Factories & Sub Factories depending on the type. (which i think is a little bit verbose) but Factory
method is pretty straight forward it has only one factory.

Use Cases

DOM API's document.createElement method is a Factory method. which creates different type of HTML elements depending
on the passed type.

Example

code on github

class Document {
  render() {
    return null;
  }
}
class Div extends Document {
  render() {
    return '<div />';
  }
}
class Section extends Document {
  render() {
    return '<section />';
  }
}
class DOMFactory {
  createElement(type) {
    switch (type) {
      case 'div':
        return new Div();
      case 'section':
        return new Section();
      default:
        break;
    }
  }
}

let domFactory = new DOMFactory();
let div = domFactory.createElement('div');
let section = domFactory.createElement('section');

Day 4

Singleton

Singleton design pattern is a creational design pattern that ensures that a class will only have one instance.

Real World Analogy

A good real world analogy for singleton is Government, a country can only have one government regardless of how many
person it consists of it be always titled as "Government of {Country}"

Example

code on github

class Singleton {
  static instance = new Singleton();
  static getInstance() {
    return this.instance;
  }

  showMessage() {
    console.log('Hello singleton');
  }
}

let instance1 = Singleton.getInstance();
let instance2 = Singleton.getInstance();
console.log(instance1 === instance2); // true

instance2.showMessage();

Starting Structural Design Patterns

Day 5

Adapter Pattern

Adapter pattern is a structural design pattern which acts like a translator between two different interfaces/apis.

Use Cases

This pattern could be useful in cases where you have two different APIs and you want an universal interface to handle
them both.

let's take an example. suppose you are building a 2D Renderer for web which supports both WebGL & CanvasAPI you can make
an universal rendering api and use adapter pattern to fill the gaps between them.

Example

Code on github

class Python {
  print(msg: string) {
    return console.log(msg);
  }
}
class Javascript {
  console(msg: string) {
    return console.log(msg);
  }
}

class LoggerAdapter {
  adapter: any;
  constructor(type: string) {
    if (type === 'py') {
      this.adapter = new Python();
    } else if (type === 'js') {
      this.adapter = new Javascript();
    }
  }

  log(type: string, msg: string) {
    if (type === 'py') {
      this.adapter.print(msg);
    } else if (type === 'js') {
      this.adapter.console(msg);
    }
  }
}

class Logger {
  adapter: any;
  log(type: string, msg: string) {
    this.adapter = new LoggerAdapter(type);
    this.adapter.log(type, msg);
  }
}

const logger = new Logger();

logger.log('js', 'Hello world js');
logger.log('py', 'Hello world py');

Day 6

Bridge pattern

""Decouple an abstraction from its implementation so that the two can vary independently"" what?

Well, it's confusing but it's interesting to see how useful this pattern could be.

Basically Bridge pattern allows us to separate the platform depended logic from platform independent logic.

This could be useful for building User Interfaces where you want to make different views depending on different
resources and doing that in traditional manner will force you to implement each and every view and their resource
implementation separately and will exponentially grow the number of complex coupled classes.

but with bridge we can solve this issue by having a Uniform Resource Interface to talk with an abstract view class.

Example

code on github

interface IResource {
  title: "() => string;"
  body: () => string;
  link: () => string;
  image: () => string;
}

abstract class View {
  resource: IResource;
  constructor(resource: IResource) {
    this.resource = resource;
  }

  render(): string {
    return '';
  }
}

class DetailedView extends View {
  render() {
    return `
    <div>
      <h2>${this.resource.title()}</h2>
      <img src="${this.resource.image()}" />  
      <div>${this.resource.body()}</div>
      <a href="${this.resource.link()}">readmore</a>
    </div>
    `;
  }
}
class MinimalView extends View {
  render() {
    return `
    <div>
      <h2>${this.resource.title()}</h2>
      <a href="${this.resource.link()}">readmore</a>
    </div>
    `;
  }
}

class ArtistResource implements IResource {
  artist: any;
  constructor(artist: any) {
    this.artist = artist;
  }

  title() {
    return this.artist.name;
  }
  body() {
    return this.artist.bio;
  }
  image() {
    return this.artist.image;
  }
  link() {
    return this.artist.slug;
  }
}

class SongResource implements IResource {
  song: any;
  constructor(song: any) {
    this.song = song;
  }

  title() {
    return this.song.name;
  }
  body() {
    return this.song.lyrics;
  }
  image() {
    return this.song.coverImage;
  }
  link() {
    return this.song.spotifyLink;
  }
}

const artist = new ArtistResource({
  name: 'Anurag',
  bio: '404 not found',
  image: '/img/mypic.png',
  slug: '/u/anuraghazra',
});
const song = new SongResource({
  name: 'Cant belive i can fly',
  lyrics: 'la la la la la',
  coverImage: '/img/cover.png',
  spotifyLink: '/s/song/132894',
});

const artist_detail_view = new DetailedView(artist);
const artist_minimal_view = new MinimalView(artist);

const song_detail_view = new DetailedView(song);
const song_minimal_view = new MinimalView(song);

console.log(artist_detail_view.render());
console.log(song_detail_view.render());
console.log(artist_minimal_view.render());
console.log(song_minimal_view.render());

Day 7

Composite Design Pattern

Composite patterns allows us to compose objects which have hierarchical tree structure.

Use Cases

Nice use cases of this pattern i can see is that you can easily make composable Layering & Grouping System, like
photoshop where you have a Layer() class you'll push Circle/Shape classes to the Layer and those shapes will get
relatively positioned and parented to that Layer.

CodeSandbox example

const rootLayer = new Layer('rootlayer');
const shapesLayer = new Layer('my layer');
const circle = new Shape(100, 100, 'red');
const box = new Shape(200, 100, 'red');

layer.add(circle);
layer.add(box);
rootLayer.add(shapesLayer);

Example

code on github

As you can see i have a FileNode, FolderNode if i were to implement this without composite pattern then i have to do
extra checks to see if the type of the passed component is Folder and then recursively go through the childs and make
the whole tree.

interface Component {
  remove?: (c: Component) => void;
  add?: (c: Component) => void;
  ls: () => string;
}

class FolderNode implements Component {
  name: string;
  childrens: Component[];
  constructor(name: string) {
    this.name = name;
    this.childrens = [];
  }

  add(component: Component) {
    this.childrens.push(component);
  }

  remove(component: Component) {
    this.childrens = this.childrens.filter((c: Component) => c !== component);
  }

  ls() {
    let str = '\n---' + this.name;
    this.childrens.forEach(child => {
      str += child.ls();
    });
    return str;
  }
}

class FileNode implements Component {
  name: string;
  constructor(name: string) {
    this.name = '\n------' + name;
  }

  ls() {
    return this.name;
  }
}

let root = new FolderNode('root');
let src = new FolderNode('src');
let lib = new FolderNode('lib');

let jsFile = new FileNode('app.js');
let htmlFile = new FileNode('index.html');
let cssFile = new FileNode('style.css');
let mainFile = new FileNode('index.js');

src.add(jsFile);
src.add(htmlFile);
src.add(cssFile);
lib.add(mainFile);

root.add(src);
root.add(lib);

console.log(root.ls());

Day 8

Decorator Pattern

Decorator pattern allows us to enhance any class/object with extra behaviour without having to define any subclasses. I
really like the flexibility and composability powers which decorators provide me.

Use Cases

Decorator pattern is extremely useful and we have already used it in many places. Angular devs uses @Decorator syntax
very often. and React also make use of HigherOrder Functions (decorators), and libraries like MobX take advantage of
decorator patterns very cleverly.

Javascript will also have native @Decorators support some point in future the @Decorator proposal is right now on 'Stage
2' so we might see some changes, i'm excited for it. but we can use typescript/babel to compile down those to todays js and use them right now.

Example

more examples on github

// simplified example
function loggerDecorator(wrapped) {
  return function(...args) {
    console.log('******');
    console.log(wrapped.apply(this, args));
    console.log('******');
  };
}
function mapper(arr: any[], add: number) {
  return arr.map(i => i + add);
}

loggerDecorator(mapper)([1, 2, 3], 10);

Day 9

Facade Pattern

Facade pattern provides a consistent and unified API for any complicated API/Subsystem, making it easier to use for the
client.

It basically works as a bootstrapper where it abstracts away all the complicated setups and provides a straight forward
simple interface.

Example

Example is a little big so check it out on github

Day 10

Proxy Design Pattern

Proxy is an object which works as a placeholder or substitute to any other object. proxy provides a similar interface to
original object but extends the behaviour of how the object will react to changes.

There are mainly 5 types of proxies.

Remote Proxy
Virtual Proxy
Cache Proxy
Protection Proxy
Smart Proxy

▶️ Remote proxy acts as a translator between two remote origins and you can do stuff like logging the requests.

▶️ Cache proxy improves performance by caching any long running operation's results and serving the cached results
instead of request the data every time from the original source.

▶️ Virtual proxy object is a default placeholder proxy that can be lazily initiated, we can think of it as a skeleton
object which acts as the original object until the data loads.

▶️ Protection proxies mainly acts as a authentication layer for the original object. restricting unauthorized access to
the object.

▶️ Smart proxies adds extra behaviours to the original object, for example sending the data to any third-party API or
logging the data

Example

more examples on gihtub

// EXAMPLE OF PROTECTION PROXY
interface IServer {
  request(url: string): void;
}
class Server implements IServer {
  request(url: string) {
    console.log('------');
    console.log('loading:    ', url);
    console.log('completed:  ', url);
    console.log('------');
  }
}

class ProtectedServer implements IServer {
  api: IServer;
  bannedWebsites: string[];
  constructor() {
    this.api = new Server();
    this.bannedWebsites = ['https://fakesite.com', 'https://spamming.com', 'https://harmfulsiteyoushouldvisit.com'];
  }
  request(url: string) {
    if (this.bannedWebsites.includes(url)) {
      console.log('------');
      console.log('BANNED:    ', url);
      console.log('------');
    } else {
      this.api.request(url);
    }
  }
}

const server = new ProtectedServer();
console.log('EXAMPLE-1 Protected Proxy');
server.request('https://google.com');
server.request('https://fakesite.com');
server.request('https://facebook.com');

Starting Behavioural Design Pattern

Day 11

Chain of Responsibility. (CoR)

CoR is a behavioural design pattern which we know of as middlewares. CoR lets us delegate the individual logic as a
handler and passing it onto the next handler.

Real World Analogy

A good real world analogy would be call centers or tech support channels.. when you call them, firstly you are prompted
with an automated voice asking you to do some steps in order to talk to a real person, then they pass your call to a
real person and if they can't help you they will again pass your call to a technician.

Use Cases

Express.js heavily make use of CoR or Middleware pattern, it passed the next() handler to the next middleware performing
some checks and doing some operation in between.

CoR can be beneficial when you wanted to your logic to be reusable delegate the logic to multiple handlers. CoR also
helps minimizing the complexity of a tightly coupled system by making sure that every chunk of handler does some
specific work and passes the data to the next handler.

Example

code on github

// Chain of responsibility
import { consoleColor } from '../utils';

interface IHandler {
  addMiddleware(h: IHandler): IHandler;
  get(url: string, callback: (data: any) => void): void;
}

abstract class AbstractHandler implements IHandler {
  next: IHandler;
  addMiddleware(h: IHandler) {
    this.next = h;
    return this.next;
  }

  get(url: string, callback: (data: any) => void) {
    if (this.next) {
      return this.next.get(url, callback);
    }
  }
}

class Auth extends AbstractHandler {
  isAuthenticated: boolean;
  constructor(username: string, password: string) {
    super();

    this.isAuthenticated = false;
    if (username === 'anuraghazra' && password === 'password123') {
      this.isAuthenticated = true;
    }
  }

  get(url: string, callback: (data: any) => void) {
    if (this.isAuthenticated) {
      return super.get(url, callback);
    } else {
      throw new Error('Not Authorized');
    }
  }
}

class Logger extends AbstractHandler {
  get(url: string, callback: (data: any) => void) {
    consoleColor('green', '/GET Request to: ', url);
    return super.get(url, callback);
  }
}

class Route extends AbstractHandler {
  url: string;
  URLMaps: {};
  constructor() {
    super();
    this.URLMaps = {
      '/api/todos': [{ title: 'hello' }, { title: 'world' }],
      '/api/random': Math.random(),
    };
  }

  get(url: string, callback: (data: any) => void) {
    super.get(url, callback);

    if (this.URLMaps.hasOwnProperty(url)) {
      callback(this.URLMaps[url]);
    }
  }
}

const route = new Route();
route.addMiddleware(new Auth('anuraghazra', 'password123')).addMiddleware(new Logger());

route.get('/api/todos', data => {
  consoleColor('blue', JSON.stringify({ data }, null, 2));
});
route.get('/api/random', data => {
  console.log(data);
});

Day 12

Command pattern

Command pattern is a behavioural design pattern which lets us decouple the business logic from the client
implementation.

Real World Analogy

Think of it like when you go to a restaurant you, call the waiter and command him to place your order and waiter passes
that command to the chief, and after chief completed the order it gets back to you.

Use Cases

Command pattern also lets you do undo and redo operations. Suppose you are making a text editor and you wanted to
implement undo, redo feature, it is can advantageous. And Command pattern also provides a nice interface to implement
modular GUI Actions allowing us to seperate the UI Layer from the logic of the code.

Traditionally if you have a CopyText feature, you might face scenarios like when you want to allow users to trigger that
CopyText function from the ContextMenu and the Toolbar both, in this scenario Command Pattern can be very useful.

Example

check out the code on github

interface ICommand {
  undo?(payload?: any): any;
  execute(payload?: any): any;
}

abstract class Command implements ICommand {
  calc: Calculator;
  constructor(calc?: Calculator) {
    this.calc = calc;
  }
  execute() {}
}

class Calculator {
  currentValue: number;
  history: CommandHistory;
  constructor() {
    this.history = new CommandHistory();
    this.currentValue = 0;
  }

  getValue(): number {
    return this.currentValue;
  }

  execute(command: ICommand) {
    this.currentValue = command.execute(this.currentValue);
    this.history.add(command);
  }

  undo() {
    let lastCommand = this.history.remove();
    if (lastCommand) {
      this.currentValue = lastCommand.undo(this.currentValue);
    }
  }
}

class CommandHistory {
  commands: ICommand[];
  constructor() {
    this.commands = [];
  }

  add(command: ICommand) {
    this.commands.push(command);
  }

  remove() {
    return this.commands.pop();
  }
}

class AddCommand {
  value: number;
  constructor(value: number) {
    this.value = value;
  }
  execute(value: number) {
    return value + this.value;
  }
  undo(value: number) {
    return value - this.value;
  }
}

const calc = new Calculator();
calc.execute(new AddCommand(50));
calc.undo(); // undo last command

Day 13

Iterator pattern

Iterator pattern is a behavioural design pattern which lets us traverse any complex data structure without exposing the
underlying implementation to the client.

Use Cases

We can traverse graphs, lists, trees with iterator pattern easily. Javascript internally uses Iterator Protocol to
implement [...spread] spread operators and loops.

Example

code on github

interface IIterator {
  next(): any;
  hasMore(): any;
}

interface ICounter {
  getIterator(): IIterator;
}

class Counter implements ICounter {
  collection: any;
  constructor(data: any) {
    this.collection = data;
  }
  getIterator() {
    return new CounterIterator(this.collection);
  }
}

class CounterIterator implements IIterator {
  current: number;
  collection: any;
  constructor(data: any) {
    this.collection = data;
    this.current = 0;
  }

  next() {
    return this.collection[this.current++];
  }

  prev() {
    return this.collection[this.current - 1];
  }

  hasMore() {
    return this.collection.length > this.current;
  }
}

let iterator = new Counter([1, 2, 3, 4, 5]).getIterator();
while (iterator.hasMore()) {
  console.log(iterator.next());
}

Day 14

Mediator Design Pattern

Mediator design is a behavioural design pattern which determines how set of objects will interact with each other.
mediator pattern encourages loose coupling between components because it prevents objects from directly referencing each
other. thus reducing the overall complexity.

Mediator acts as an middle-man between different objects and all other objects will communicate through the mediator
only.

Real World Analogy

A nice real world analogy would be Air Traffic Controller. While landing and taking off airplanes does not talk to each
other directly instead they talk to the air traffic controllers to get information about other airplanes and the control
tower tell them when to land/takeoff.

Use Cases

I think this pattern has some use cases, for example when building ChatRooms you can implement mediator pattern to
simplify the relation between different members of the chatroom and send them messages though the Mediator.

You can also use Mediator pattern as a global event manager in front end applications where components talk to each
other by the mediator instead of passing callbacks/props.

Example

code on github

// mediator pattern
import { consoleColor } from '../utils';

interface IMediator {
  sendMessage(msg: string, from: any, to?: any): void;
}

class Chatroom implements IMediator {
  members: { [x: string]: Member };
  constructor() {
    this.members = {};
  }

  addMember(member: Member) {
    member.chatroom = this;
    this.members[member.name] = member;
  }

  sendMessage(msg: string, from: Member, to?: Member) {
    Object.keys(this.members).forEach(name => {
      if (!to && name !== from.name) {
        this.members[name].receive(msg, from);
        return;
      }
      if (to && name == to.name) {
        this.members[name].receive(msg, from);
      }
    });
  }
}

class Member {
  name: string;
  chatroom: Chatroom;
  constructor(name: string) {
    this.name = name;
    this.chatroom = null;
  }

  send(msg: string, to?: any) {
    this.chatroom.sendMessage(msg, this, to);
  }

  receive(msg: string, from: Member) {
    consoleColor('magenta', `-------`);
    consoleColor('cyan', `${from.name} says to ${this.name} : `);
    consoleColor('green', `${msg}`);
    consoleColor('magenta', `-------`);
  }
}

const chatroom = new Chatroom();

let anurag = new Member('Anurag');
let hitman = new Member('hitman');
let jonathan = new Member('John Wick');
chatroom.addMember(anurag);
chatroom.addMember(hitman);
chatroom.addMember(jonathan);

anurag.send("I'm more dangerous than you hitman");
hitman.send('Sorry brother forgive me! pls', anurag);
jonathan.send('Hey hey hey hitman, nerver ever mess with Anurag', hitman);

Day 15

Observer Design Pattern

Observer design pattern is a behavioural design pattern which is a subscription system which notifies multiple objects
about any changes to the object they are observing.

▶️ The cool thing about observer pattern is that it decouples the State from the actual business logic. in terms of UIs
you can separate the State from the actual rendering of the UI and if that State updates the UI will automatically react
to it.

Suppose you have a some Todos in your state you can decouple the data from the Ui and implement the render logic
entirely differently. You can have a DOMRenderer and a ConsoleRenderer and both will react and update to the changes
made to the Todos. Heres a good example https://github.com/anuraghazra/VanillaMVC

Real world Analogy

You can compare Observer pattern with daily newspaper subscriptions, If you subscribe to any newspaper you don't need to
go to the store everyday and get the newspaper instead the Publisher sends the newspaper to your home.

Another analogy would be Youtube, well you might know pretty well that subscribing to youtube channels means you will
get notification about new videos. Observer pattern also works the same. you as a user will subscribe to events you
choose to get notifications.

Use Cases

Observer pattern has lot of use cases. (a lot) Vuejs's Reactivity system relies on Observer pattern. The whole idea of
RxJs is based upon observers. MobX also uses Observer design pattern effectively.

From User Interfaces to Data Reactivity, Observer pattern is really handy when some changes/events in a particular
object has to be reflected on other objects

Example

code on github

import { consoleColor } from '../utils';

interface IPublisher {
  addSubscriber(subscriber: any): void;
  removeSubscriber(subscriber: any): void;
  notifyObservers(): void;
}
interface IObserver {
  notify(payload: any): void;
}

class Publisher implements IPublisher {
  subscribers: IObserver[];
  state: any;
  constructor(state: any = {}) {
    this.subscribers = [];
    this.state = state;
  }

  addSubscriber(subscriber: IObserver) {
    if (this.subscribers.includes(subscriber)) return;
    this.subscribers.push(subscriber);
  }

  removeSubscriber(subscriber: IObserver) {
    if (!this.subscribers.includes(subscriber)) return;
    let index = this.subscribers.indexOf(subscriber);
    this.subscribers.splice(index, 1);
  }

  notifyObservers() {
    this.subscribers.forEach(subs => {
      subs.notify(this.state);
    });
  }

  setState(newState: any) {
    this.state = newState;
    this.notifyObservers();
  }
}

class UserInterface implements IObserver {
  renderTodos(todos) {
    console.clear();
    todos.forEach(todo => {
      consoleColor('cyan', '-----');
      consoleColor(todo.isCompleted ? 'green' : 'red', `${todo.title} ${todo.isCompleted ? '[DONE]' : '[PENDING]'}`);
      consoleColor('cyan', '-----');
    });
  }

  notify(state: any) {
    this.renderTodos(state.todos);
  }
}

const store = new Publisher({
  todos: [
    { title: 'hello', isCompleted: false, id: 1 },
    { title: 'world', isCompleted: false, id: 2 },
  ],
});

const userInterface = new UserInterface();
store.addSubscriber(userInterface);

// add todo
store.setState({
  todos: [...store.state.todos, { title: 'new item', id: Math.random() }],
});

// remove todo
store.setState({
  todos: store.state.todos.filter(t => t.id !== 2),
});

Day 16

State Pattern

State pattern is a behavioural design pattern which lets objects change its behaviour based on its internal state.

If you wanted to see the code, i have three examples on state-pattern in my github repo:
https://github.com/anuraghazra/design-patterns-everyday

▶️ State pattern can be correlated with State-Machines where at certain point of time an application can only be in one
state or in a limited finite number of states.

Where State-Machines heavily relays on if statements and switch cases which leads to Complex logic and unmaintainable
code when codebase gets larger. State pattern changes behaviour methods based on the current state.

Real World Analogy

Suppose you have a Music Player and that music player has 2 buttons "UP" & "DOWN"

When you are playing a song those "UP" & "DOWN" button will change the song volume.
And when you are on a playlist menu the Up and Down buttons will scroll up and down in the list.

Use Cases

A good real world use case would be a any drawing app / text editor or anything where you have some class which changes
its behaviour based on some state.

for example: if are building a drawing app the app will have a pain brush tool which would draw in different color/size
based on the selected color/size.

Another example would be text editor, where you have a class for writing the text on screen but depending on the
Uppercase/bold/lowercase buttons you write appropriate character to the screen

Example

code on github

/* SIMPLE TOGGLE */
interface IToggleState {
  toggle(state: IToggleState): void;
}

class ToggleContext {
  currentState: any;
  constructor() {
    this.currentState = new Off();
  }

  setState(state: IToggleState) {
    this.currentState = state;
  }

  toggle() {
    this.currentState.toggle(this);
  }
}

class Off implements IToggleState {
  toggle(ctx: ToggleContext) {
    console.log('OFF');
    ctx.setState(new On());
  }
}
class On implements IToggleState {
  toggle(ctx: ToggleContext) {
    console.log('ON');
    ctx.setState(new Off());
  }
}

let button = new ToggleContext();
button.toggle();
button.toggle();

Day 17

Strategy Design Pattern

Strategy design pattern is behavioural design pattern which lets us define different algorithms for doing a particular
action and interchange them as we wish. basically means you can switch between different types of behaviour and
implementation.

Strategy design pattern is very similar to state design pattern. strategy pattern is an extension to state pattern, but
strategy pattern completely makes the subclasses independent from each other.

Real World Analogy

I think a good real world analogy would be a match of football. the coach (context) decides a

strategy every situation the game flows through and switch between them depending on the situation. for example if the
opposition is playing defensive then coach changes the strategy to playing aggressive. and when the team is leading 1
goal coach changes the strategy to semi-defensive.

Use cases

If you every used passportjs then you already used Strategy design pattern. passportjs uses strategy pattern to easily
change/add new Authentication providers and the system becomes more flexible to use and extend on.

Example

code on github

// Strategy pattern
interface IStrategy {
  authenticate(...args: any): any;
}

class Authenticator {
  strategy: any;
  constructor() {
    this.strategy = null;
  }

  setStrategy(strategy: any) {
    this.strategy = strategy;
  }

  authenticate(...args: any) {
    if (!this.strategy) {
      console.log('No Authentication strategy provided');
      return;
    }
    return this.strategy.authenticate(...args);
  }
}

class GoogleStrategy implements IStrategy {
  authenticate(googleToken: string) {
    if (googleToken !== '12345') {
      console.log('Invalid Google User');
      return;
    }
    console.log('Authenticated with Google');
  }
}

class LocalStrategy implements IStrategy {
  authenticate(username: string, password: string) {
    if (username !== 'johnwick' && password !== 'gunslotsofguns') {
      console.log('Invalid user. you are `Excommunicado`');
      return;
    }
    console.log('Authenticated as Baba Yaga');
  }
}

const auth = new Authenticator();

auth.setStrategy(new GoogleStrategy());
auth.authenticate('invalidpass');

auth.setStrategy(new GoogleStrategy());
auth.authenticate('12345');

auth.setStrategy(new LocalStrategy());
auth.authenticate('anurag', '12345');

auth.setStrategy(new LocalStrategy());
auth.authenticate('johnwick', 'gunslotsofguns');

Day 18

Template Method

Template method is a behavioural design pattern which defines skeleton of an algorithm in a step by step manner and lets
subclasses override them.

Basically what template method does is that it requires you to split an algorithm into a smaller chunks and make
separate methods for them, and then call each of the methods sequentially in a series. that way you can override any
step of an algorithm in a subclass.

Real World Analogy

A good real world analogy would be the concept of house construction, while making a house it requires some steps such
as building the roof, floor, walls electricity supply etc etc. and the client (or the owner) can customize these
components and get different type of house.

Use Cases

Template method is widely used in frameworks, lets take Reactjs

React's Class Component is a implements template method where it has placeholder methods of componentDidMount,
componentWillUnmount etc etc and the client will override and customize these methods as per their needs.

Btw fun fact, these kind of inversion of control is called "the Hollywood principle" ("don't call us, we'll call you".)

Example

code on github

// template method
import fs from 'fs';

abstract class DataParser {
  data: string;
  out: any;
  constructor() {
    this.data = '';
    this.out = null;
  }

  parse(pathUrl: string) {
    this.readFile(pathUrl);
    this.doParsing();
    this.postCalculations();
    this.printData();
  }

  readFile(pathUrl: string) {
    this.data = fs.readFileSync(pathUrl, 'utf8');
  }

  doParsing() {}
  postCalculations() {}
  printData() {
    console.log(this.out);
  }
}

class DateParser extends DataParser {
  doParsing() {
    let dateRegx = /(0?[1-9]|[12][0-9]|3[01])[\/\-](0?[1-9]|1[012])[\/\-]\d{4}/gim;
    this.out = this.data.match(dateRegx);
  }
}

class CSVParser extends DataParser {
  doParsing() {
    this.out = this.data.split(',');
  }
}

class MarkupParser extends DataParser {
  doParsing() {
    this.out = this.data.match(/<\w+>.*<\/\w+>/gim);
  }

  postCalculations() {
    this.out = this.out.reverse();
  }
}

const dataUrl = '../../behavioral/data.csv';

new DateParser().parse(dataUrl);
new CSVParser().parse(dataUrl);
new MarkupParser().parse(dataUrl);

Day 19

Visitor Pattern

Visitor design pattern is a behavioural design pattern which lets you define new operations/behaviours without changing
the classes.

Real world Analogy

A good real world analogy is given by refactoring.guru where it says imagine a insurance agent who is eager to get new
customers, he will visit every building on the region and

if it’s a residential building, he sells medical insurance,
If it’s a bank, he sells theft insurance.
If it’s a shop, he sells fire and flood insurance.

Use cases

Visitor pattern is very useful when it comes with extending existing behaviours without changing the base class.

If you every wrote a GraphQL directive you've used visitor pattern.

GraphQL server exposes a "SchemaDirectiveVisitor" class which has methods like "visitFieldDefinition" & "visitEnumValue"
it implements the visitor pattern to add extra behaviours to the schemas.

Visitor pattern is also really useful for modifying AST trees where you can visit every node and modify it one by one. i
have a example on my git repo: https://github.com/anuraghazra/design-patterns-everyday

You can also implement visitor pattern to make Exporters as you can see on my example. i have a SVGExporter and
CanvasCallsExporter.

Example

Check out the example on github

ANNNDDD THATS IT! Phew! it was long.. i know you probably did not read it but thats ok, you can come back anytime
when you are stuck with a specific design pattern or confused about it.

Personally i feel like in web development world most useful patterns are:

Observer
Visitor
Iterator
Chain of responsibility
Strategy
Proxy
Decorator

Links:

Learning Resources:

I hope you find this post useful! Thanks for reading folks.

Building A React Folder Tree Component

Anurag Hazra — Thu, 30 Apr 2020 08:49:56 +0000

Photo by Johann Siemens on Unsplash
This post was originally published on my personal site

Hey folks! I hope you are doing fine in this pandemic situation, Today we will be creating a Folder Tree Component in
Reactjs from scratch.

Designing the API

Before creating any type of component in reactjs you should 1st design how the API would look like and then write the
necessary code to make it work.

Our Folder Tree Component will have two APIs

Declarative
Imperative

At first we will tackle the Declarative API which is really simple to create,

and in the second section we will do the Imperative API with recursive components.

Declarative API

The declarative API would look something like this :-

import Tree from './Tree';

const App = () => {
  return (
    <div>
      <Tree>
        <Tree.Folder name="src">
          <Tree.Folder name="Components">
            <Tree.File name="Modal.js" />
            <Tree.File name="Modal.css" />
          </Tree.Folder>
          <Tree.File name="index.js" />
          <Tree.File name="index.html" />
        </Tree.Folder>
        <Tree.File name="package.json" />
      </Tree>
    </div>
  );
};

As you can see we will have total of three components to work with

<Tree /> (the root)
<Tree.Folder /> (it will be collapsible)
<Tree.File />

Imperative API

Declarative APIs are simple & easier for users to structure the Tree, but in real world scenarios we will have a JSON
Object representing the Folder Tree and we need to render that with the Imperative API.

import Tree from './Tree';

const structure = [
  {
    type: "folder",
    name: "src",
    childrens: [
      {
        type: "folder",
        name: "Components",
        childrens: [
          { type: "file", name: "Modal.js" },
          { type: "file", name: "Modal.css" }
        ]
      },
      { type: "file", name: "index.js" },
      { type: "file", name: "index.html" }
    ]
  },
  { type: "file", name: "package.json" }
];

const App = () => {
  return (
    <div>
      <Tree data={structure} />
    </div>
  );
};

As you can see we have a JSON representation of the same tree we have in our declarative API.

Its an Array of Objects and each object has three properties

name
type (defines if its a Folder or File)
childrens (array of nested Files & Folders)

And we just passed this structure to our component which will handle the rendering, we will cover the
Imperative API later in the post but let us first finish our Declarative API

The Tree Component

Lets first install styled-components for styling our Components.

npm install styled-components

Our Tree component will be very simple it will only have some basic styling, it is so simple i don't even have to
explain it.

const StyledTree = styled.div`
  line-height: 1.5;
`;

const Tree = ({ children }) => {
  return <StyledTree>{children}</StyledTree>;
};

The File Component

In our File component we will also have a File Icon with some basic styling.

Lets install react-icons and import our File Icon

npm install react-icons

import { AiOutlineFile } from 'react-icons/ai';

const StyledFile = styled.div`
  padding-left: 20px;
  display: flex;
  align-items: center;
  span {
    margin-left: 5px;
  }
`;

const File = ({ name }) => {
  return (
    <StyledFile>
      <AiOutlineFile />
      <span>{name}</span>
    </StyledFile>
  );
};

We have a 20px padding left to push the Component to the right a little bit, and display flex properties to align the
icon & span correctly.

That's fine but that generic file icon does not look good, does it? lets change that.

We will make a map of extension icons and depending on the file extension we will give the file appropriate icon.

import { DiJavascript1, DiCss3Full, DiHtml5, DiReact } from 'react-icons/di';

const FILE_ICONS = {
  js: <DiJavascript1 />,
  css: <DiCss3Full />,
  html: <DiHtml5 />,
  jsx: <DiReact />,
};
export default FILE_ICONS;

And in the File component we will extract the extension from the name of the file and use that to render the icon

import FILE_ICONS from './FileIcons';

const File = ({ name }) => {
  // get the extension
  let ext = name.split('.')[1];

  return (
    <StyledFile>
      {/* render the extension or fallback to generic file icon  */}
      {FILE_ICONS[ext] || <AiOutlineFile />}
      <span>{name}</span>
    </StyledFile>
  );
};

It would look something like this.

Hooray our File component is done, let's move on to Folder component

The Folder Component

In the Folder component we will have

folder title
collapsible component
Nested childrens of File/Folder components

Initially our Folder component is very simple, just the title and childrens.

btw if you don't know what that children prop is then here's some resources

A quick intro to React’s props.children

A deep dive into children in React

import { AiOutlineFolder } from 'react-icons/ai';

const StyledFolder = styled.div`
  padding-left: 20px;

  .folder--label {
    display: flex;
    align-items: center;
    span {
      margin-left: 5px;
    }
  }
`;

const Folder = ({ name, children }) => {
  return (
    <StyledFolder>
      <div className="folder--label">
        <AiOutlineFolder />
        <span>{name}</span>
      </div>
      <div>{children}</div>
    </StyledFolder>
  );
};

And thats it, thats all we need for our Folder component but we also wanted the folders to be collapsible so lets add
that next.

To add the collapse feature we will add a Styled component and also add local state to keep track of
isOpen state of our component.

const StyledFolder = styled.div`
  padding-left: 20px;

  .folder--label {
    display: flex;
    align-items: center;
    span {
      margin-left: 5px;
    }
  }
`;
const Collapsible = styled.div`
  /* set the height depending on isOpen prop */
  height: ${p => (p.isOpen ? 'auto' : '0')};
  /* hide the excess content */
  overflow: hidden;
`;

const Folder = ({ name, children }) => {
  const [isOpen, setIsOpen] = useState(false);

  const handleToggle = e => {
    e.preventDefault();
    setIsOpen(!isOpen);
  };

  return (
    <StyledFolder>
      <div className="folder--label" onClick={handleToggle}>
        <AiOutlineFolder />
        <span>{name}</span>
      </div>
      <Collapsible isOpen={isOpen}>{children}</Collapsible>
    </StyledFolder>
  );
};

There we go! Our Folder Component is done, Yey!

Finalizing Tree Component

As you've noticed in our Declerative API design, we have & components we can just assign
the File & Folder component to our Tree's static methods.

const Tree = ({ children }) => {
  return <StyledTree>{children}</StyledTree>;
};

Tree.File = File;
Tree.Folder = Folder;

////////
// DONE! Lets try it out
import Tree from './Tree';

const App = () => {
  return (
    <div>
      <Tree>
        <Tree.Folder name="src">
          <Tree.Folder name="Components">
            <Tree.File name="Modal.js" />
            <Tree.File name="Modal.css" />
          </Tree.Folder>
          <Tree.File name="index.js" />
          <Tree.File name="index.html" />
        </Tree.Folder>
        <Tree.File name="package.json" />
      </Tree>
    </div>
  );
};

If we run the code now we will have a working React Folder Tree Component! Congrats 🎉🎉

Declerative Demo

Imperative API

OKAY! we are done with the Declerative API now lets work on the Imperative API.

To create the Imperative API we need recursion!

If you are not familiar with recursion then check out some resources

A Quick Intro to Recursion in Javascript

Intro to Recursion in JS

In our component we accept the data props and added an isImperative flag.

If we have the data prop and not the children that means the user is using the imperative api, and depending on that
variable we will be rendering the tree.

const Tree = ({ data, children }) => {
  const isImperative = data && !children;

  return <StyledTree>{isImperative ? <TreeRecursive data={data} /> : children}</StyledTree>;
};

As you've noticed we also added a new component called <TreeRecursive /> which will recursively look through the JSON
structure and render those nested files/folders, Lets implement it.

const TreeRecursive = ({ data }) => {
  // loop through the data
  return data.map(item => {
    // if its a file render <File />
    if (item.type === 'file') {
      return <File name={item.name} />;
    }
    // if its a folder render <Folder />
    if (item.type === 'folder') {
      return (
        <Folder name={item.name}>
          {/* Call the <TreeRecursive /> component with the current item.childrens */}
          <TreeRecursive data={item.childrens} />
        </Folder>
      );
    }
  });
};

Believe it or not, we are DONE! 🎉🎉 Run the code and see the magic!

Imperative Demo

Phew! That was amazing isn't it? if you made it this far, give yourself a tap on the shoulder because you just built a React Folder Tree Component!

Now for those who are looking for some more fun try to implement these features on your own :-

File/Folder Rename Support
File/Folder Creation Support
File/Folder Deletion Support
Save folder structure to localStorage Support

Foot notes

Check out my react-folder-tree component with full CRUD support.
CodeSandbox Link for Declerative API
CodeSandbox Link for Imperative API
A quick intro to React’s props.children
A deep dive into children in React
A Quick Intro to Recursion in Javascript
Intro to Recursion in JS

Thanks for reading the post, i hope you learned something and enjoyed it.

Stay safe, stay home!

Bye have a nice day!