I have been learning frontend system design by reverse engineering real products, and Google Photos was my first deep dive. One thing that stood out immediately was how they position thousands of thumbnail images in their grid. Instead of using top and left and other inset properties, they rely heavily on transform: translate3d(x, y, 0).

At first, this felt odd. Why would you use transforms for static positioning? Aren't transforms for animations and movement? The answer lies in understanding the browser rendering pipeline and the performance trade-offs involved.

The Browser Rendering Pipeline

When the browser renders a frame, it typically goes through these stages:

1. JavaScript: your code runs (event handlers, requestAnimationFrame, etc.)
2. Style: the browser computes which CSS rules apply to each element
3. Layout: the browser calculates the size and position of each element (geometry)
4. Paint: the browser turns those boxes into pixels (backgrounds, text, borders, images)
5. Composite: the browser assembles painted layers into the final frame you see

Not every change triggers every stage. The key difference between inset offsets and transform: translate() is which stages they force the browser to run.

Why inset offsets can be expensive

When you use inset offsets like top and left to position an element (assuming it is positioned with absolute, relative, or fixed), you are changing the element's layout geometry. That means the browser often has to run the Layout stage again to figure out where everything should be, and then repaint affected areas.

If you are moving hundreds of thumbnails during scroll or zoom, doing layout work every frame can cause jank and dropped frames because layout runs on the main thread and blocks JavaScript execution.

Why Transform: Translate Is Faster

transform: translate(x, y) does not change the element's layout box. The browser computes layout once (where the "reserved seat" is), and then it applies the transform visually during the Composite stage.

Because compositing can often happen on a separate compositor thread (sometimes GPU-accelerated), updating transforms can be much cheaper than triggering layout and paint repeatedly.

This is why transform is the go-to property for animations and frequent repositioning. It skips the expensive layout and paint steps in many cases.

What Does "Layout Space vs Visual Space" Actually Mean?

This was the concept that finally clicked for me.

When you use top/left, you are changing where the browser thinks the element's box is during layout. If you move element A with top/left, other elements might reflow around it (depending on positioning context).

When you use transform: translate(), you are keeping the layout box in the same place, but rendering the pixels somewhere else. That is why translated elements can overlap siblings without pushing them away. The layout "seat" stays reserved in the original spot, but the element is drawn offset from there.

A quick way to test this: put two inline-block divs side by side. Apply transform: translateX(50px) to the first one and it will overlap the second. Apply margin-left: 50px instead and the second will get pushed because layout space changed.

So Why Does Google Photos Use Translate for "Static" Images?

Google Photos is not actually static. Here is what is happening behind the scenes:

• Scrolling: as you scroll, the positions of visible tiles may need to shift (especially during smooth scroll or inertial scrolling).
• Virtualization: Google Photos only renders the thumbnails that are in or near the viewport. As you scroll, new DOM nodes are created for newly visible items, and old ones are destroyed. Each visible thumbnail still needs to be positioned at its correct x/y coordinate in the grid.
• Zoom and density changes: Google Photos lets you change the grid density (number of columns). When that happens, every thumbnail needs to move to a new position.
• Responsive layout: as the window resizes or the device orientation changes, the grid reflows and tiles move.

All of these interactions involve repositioning many elements frequently. Using transform: translate3d(x, y, 0) for that positioning keeps those updates smooth because they can often bypass layout and paint work.

Even in a virtualized list where nodes are being created and destroyed, you still need to position each visible node. Using transforms for that initial placement and any subsequent adjustments is cheaper than using top/left.

The Trade-Offs: Memory and Complexity

Using transforms is not free. There are trade-offs you need to be aware of:

• Increased memory usage: transforms can promote elements to their own composited layers, which are stored as textures (often in GPU memory). For a grid with hundreds of visible tiles, this can add up.
• Layer management overhead: the browser has to manage those layers, which has CPU and GPU cost. Too many layers can hurt performance instead of helping it.
• Stacking context issues: transforms create a new stacking context, which can affect z-index, fixed-position children, and overlays. This can complicate your CSS architecture.
• Layout doesn't update: since transforms do not change layout, overlaps can happen. If you want siblings to reflow around a moved element, you need layout-based positioning instead.

For Google Photos, the memory and layer overhead is worth it because the smoothness gains are significant for a highly interactive, scroll-heavy UI with thousands of items.

When Should You Use Top/Left vs Translate?

Here is a simple rule:

• Use top/left (or normal layout like flexbox/grid) when you want to define layout position, siblings should reflow around changes, and you are not updating positions every frame.
• Use transform: translate(...) when you are moving elements frequently (animations, drag, scroll positioning, interactive transforms), and you want smoothness without triggering layout and paint repeatedly.

Could Google Photos Have Used Top/Left Instead?

Yes, technically. But the performance and frame rate loss would have been noticeable, especially on lower-end devices. Smooth 60fps scrolling with hundreds of thumbnails updating position is hard to achieve if you trigger layout work every frame.

Using transforms is a deliberate architectural choice that prioritizes interaction smoothness over simplicity and memory efficiency.

My Takeaway

The key insight for me was understanding that top/left and transform: translate() are not just two ways to do the same thing. They operate at different stages of the rendering pipeline and have very different performance characteristics.

For highly interactive UIs (photo grids, drag-and-drop, smooth scroll experiences), treating transform as the default tool for movement makes sense. For more static layouts where you want layout to be the source of truth, stick with layout-based positioning.

If you are building a similar system, profile it. Use the Performance tab and Layers panel in DevTools to see which approach works better for your specific case. Do not just copy patterns blindly.

If a large language model cites a blog post and slightly hallucinates or mutates the URL slug, the link it generates can easily 404.

That is bad for:

• Readers who click a broken link and never find the content.
• Creators who lose traffic and context.
• The web because machine-generated citations become fragile.

To make my blog more resilient to this, I implemented fuzzy slug routing using fuse.js, so that even if an LLM or a human slightly messes up the slug, the user can still land on the right post.

The Problem: Generative Text, Fragile URLs

A typical blog URL looks like this:

`/blog/my-awesome-post-about-slugs`

This slug is usually:

• Derived from the post title.
• Treated as a strict, exact identifier.
• Assumed to match perfectly.

In a world where LLMs generate text, that assumption is increasingly weak.

An LLM might:

• Drop a word.
• Add an extra word.
• Change singular to plural.
• Slightly rephrase the title before slugifying.

For example:

• Original slug:

  `/blog/understanding-static-site-generation`
  

• LLM-generated slug:

  /blog/understanding-static-site-generators

To a human, that is clearly the same idea. To a traditional router, it is a completely different path that results in a 404.

What I really want is something like this: you are close enough, let me find the post you most likely meant.

The Idea: Treat the Slug as a Fuzzy Query

Instead of treating the slug as a hard, exact key, I treat it as a fuzzy search query over all my posts.

Conceptually, the flow is:

1. Read the incoming slug from the URL.
2. Use fuse.js to run a fuzzy search against a list of all posts.
3. If there is a strong enough match, resolve that post and render it.
4. If not, fall back to a proper 404.

This means that even if an LLM changes the slug slightly, there is still a good chance the user lands on the intended article.

Imagine the canonical slug is:

`/blog/fuzzy-slug-routing-for-blogs-in-the-llm-era`

But an LLM outputs:

`/blog/fuzzy-slug-routing-in-llm-era`

A traditional router sees a completely unknown slug and returns 404.

With this setup, that incoming slug is treated as a query, and as long as the similarity is high enough, it still resolves to the correct post.

Live demo

You can see this idea in action with two URLs.

• fuzzy-matching-urls-in-the-ai-and-llm-hallucination-era is the canonical slug for this post.
• fuzzy-matching-urls-in-the-hallucination-era is a slightly altered slug that should still land on the same post.

Data Strategy: Precomputing data.json at Build Time

I use a CMS as the source of truth for my blog posts. A naive approach would be to call the CMS API on every request to resolve the slug.

That would be slower, dependent on external network calls, and unnecessary given that the content is mostly static.

Instead, I decided to handle this at build time.

During the build, I fetch all blog posts from the CMS and extract the core fields needed for routing and search, such as title and slug, and optionally tags or summary. I then serialize them into a static data.json file.

Here is the build time script that generates that file.

import { mkdir, writeFile } from 'node:fs/promises';
import path from 'node:path';
import { getClient } from './sanity-server';

async function generateBlogFuseData() {
  const blogs = await getBlogs();

  const filePath = 'src/fuse/data.json';

  await mkdir(path.dirname(filePath), { recursive: true });
  await writeFile(filePath, JSON.stringify(blogs), 'utf8');
}

generateBlogFuseData();

At runtime, the slug resolution layer does three simple things:

1. Load data.json.
2. Instantiate Fuse with that dataset.
3. Run a fuzzy search against slug and optionally title.

For my use case, slug is the primary field, and title can be a secondary field to catch more aggressive mutations.

The resolution logic looks like this conceptually.

In code, the core of the resolution function looks like this.

import Fuse from 'fuse.js';
import blogs from '../../../src/fuse/data.json';

async function getData(params: { slug: string }) {
  if (!params || !params.slug) throw new Error('No slug found in params');

  const fuse = new Fuse(blogs as Array<{ slug: string; title: string }>, {
    keys: ['slug', 'title'],
    useExtendedSearch: true,
    ignoreLocation: true,
    threshold: 0.44,
    minMatchCharLength: 6
  });

  const slugLength = params.slug?.split('-').length || 0;
  const relatedBlogs =
    slugLength >= 3
      ? fuse.search(params.slug).map(({ item }) => item)
      : [{ slug: '', title: '' }];

  const slug = relatedBlogs?.[0]?.slug;

  return { slug };
}

Take the incoming slug string from the URL. Run fuse.search on that slug. Inspect the top result. If its score is within a safe threshold, treat it as the resolved post. Otherwise, return a 404.

Because fuse.js runs on a static data.json that is generated at build time, this lookup is cheap and fast.

Why Bother: Robustness in an AI Heavy Web

This entire approach is about robustness.

LLMs will increasingly generate links. Some will be perfect, many will be close enough but technically wrong. Traditional slug routing is brittle: a single character off and the request fails.

Fuzzy routing offers graceful degradation: minor hallucinations still resolve to useful content.

It is also a small step toward making URLs more semantic instead of strictly token based.

Trade Offs and Considerations

This is not magic, and there are trade offs.

Ambiguity can show up if multiple posts are very similar, because fuzzy search might pick the wrong one. Threshold tuning matters a lot. You need to experiment to find the sweet spot between overly strict and overly forgiving. SEO still relies on canonical URLs. The fuzzy match is a way to serve content, but the canonical slug remains the source of truth.

In practice, for a personal blog or small content site, these trade offs are acceptable.

Conclusion

In a world where content is generated, links are machine written, and hallucinations are inevitable, relying on exact string equality for slugs feels outdated.

By precomputing a simple data.json at build time, using fuse.js to fuzzily match incoming slugs, and falling back to a 404 only when there is truly no good match, I have made my blog more resilient to LLM hallucinations and minor human errors while keeping the implementation simple and friendly to static hosting.

If you run a content site and expect LLMs to link to you, fuzzy slug routing is a small but meaningful upgrade to your URL strategy.

NOTE: LLM was used to help with grammar fixes in this blog post.

Seat-selection UIs (BookMyShow, District, Ticketmaster, etc.) look straightforward: show rows, show seats, let me click one.

But theatre layouts in the real world are messy:

• Seats are missing because there are aisles / stairs / empty spaces
• Some rows are shorter, some are split into blocks
• Different sections have different prices (“areas”)
• And the backend doesn’t hand you a clean 2D matrix - it’s usually sparse data

This post is basically a walkthrough of how I took a District API seat-layout response and turned it into a UI that can render any layout dynamically (without hardcoding positions).

This blog focuses on data structure + layout strategy. For curious ones, here's the demo link

What the backend JSON looks like (District API response)

The JSON I used came from a District API response. The file is an array of layout objects, and each object contains a seatLayout.

The important nested path is:

• seatLayout.colAreas.objArea[] → pricing sections (“areas”)
• objArea.objRow[] → rows
• objRow.objSeat[] → seats

Here’s a minimal representative snippet (one layout → one area → one row → two seats):

[
  {
    "seatLayout": {
      "name": "PVR",
      "colAreas": {
        "objArea": [
          {
            "AreaNum": 1,
            "AreaDesc": "Recliners",
            "AreaCode": "RE",
            "HasCurrentOrder": true,
            "AreaPrice": 385,
            "objRow": [
              {
                "GridRowId": 1,
                "PhyRowId": "P",
                "objSeat": [
                  {
                    "GridSeatNum": 4,
                    "SeatStatus": "1",
                    "seatNumber": 1,
                    "displaySeatNumber": "1"
                  },
                  {
                    "GridSeatNum": 12,
                    "SeatStatus": "0",
                    "seatNumber": 5,
                    "displaySeatNumber": "5"
                  }
                ]
              }
            ]
          }
        ]
      }
    }
  }
]

The detail that matters most for layout: GridSeatNum can jump (4 → 12). That jump is literally your aisle/gap. The backend doesn’t send “empty seats” for 5..11 - it just doesn’t include them.

What each field means for UI

• AreaDesc / AreaPrice: what you show above a section (like “Recliners ₹385”)
• PhyRowId: the row label you show on the left (“A”, “B”, “P”, “N”…)
• GridRowId: row position (vertical placement)
• GridSeatNum: seat position within the row (horizontal placement)
• SeatStatus:
  • "0" → available
  • "1" → occupied/unavailable
  • everything else (for this dataset) → treat as gap

The core problem: sparse lists don’t render like a theatre

If you render seats like this:

• row.objSeat.map(seat => <Seat />)

you’ll get something that technically shows seats… but it won’t look like the theatre map.

Because the UI needs to reflect things like:

• empty space between seat blocks
• aisles
• rows that are split in the middle
• missing rows (walking space)

A plain .map() compresses everything. The gaps disappear.

So the problem becomes:

How do you keep the “holes” in the data so the UI preserves spacing?

The strategy: indexed placement into pre-sized arrays

This is the entire trick.

Instead of rendering the sparse list directly, I convert it into something that behaves like a grid:

1. Create an array of length X filled with undefined
2. For every real item, place it at the index that represents its position

Then when you render the array, the missing indices stay missing - and that’s how you get gaps.

so your array would look something like [undefined, undefined, {...}, {...}, undefined]

Why this works

• Missing indices stay undefined → that becomes a gap
• Rendering is stable because index == coordinate
• A “gap cell” can be rendered as an invisible placeholder with the same size as a seat

Building a “grid” for the UI

There are two places where this idea shows up:

Row-level grid (vertical positioning)

Rows come as a list, but the GridRowId gives you a placement order/position. Sometimes there are intentional skips.

So you can build an array of rows where:

• rows[rowIndex] = row
• missing row indices remain undefined

Later, when rendering:

• undefined row → render a spacer row (or just keep the vertical gap)

That’s how you get gaps between rows without writing a bunch of layout-specific CSS.

Seat-level grid (horizontal positioning)

Same idea inside a row.

Seats come as a list, but each seat has GridSeatNum (think “column index”).

So you build:

• seats[colIndex] = seat
• missing indices remain undefined → aisle/gap

When you render the seats array:

• real seat → render a button
• missing seat → render a placeholder cell

Rendering becomes trivial after grid alignment

Once the data is “grid-aligned”, rendering is boring (which is what you want):

• render areas (pricing sections)
• for each area, render rows (including empty slots)
• for each row, render seats (including empty slots)

The only important UI rule is:

A gap must still occupy space.

So even if a seat slot is missing, the placeholder should have the same width/height as a real seat cell. That keeps everything aligned.

Flexibility: any seat at any 2D point

At this point every seat effectively has a coordinate:

• row index → Y
• column index → X

And because the backend is giving you these indices (GridRowId, GridSeatNum), you’re not guessing. You’re just placing items where the backend intended.

Practical notes / lessons learned

• Stable sizing matters

If a seat cell is size-9, then your “gap cell” also needs to be size-9. Otherwise alignment breaks.

• Don’t let layout collapse

If you rely purely on flex without placeholders, the browser will naturally collapse empty space. The whole point of the indexed placement is to preserve those empty slots.

• Keys and rerenders

If you generate random keys on every render, React can’t reconcile properly and you’ll get unnecessary rerenders.

For production, prefer stable keys like:

• area.id
• row.id
• seat.id

Summary

If I had to summarize the whole approach:

• The API gives you sparse lists + placement indices (GridRowId, GridSeatNum)
• Convert sparse lists into index-addressable arrays
• Render those arrays, and treat missing slots as real “gap cells”

That’s it. No magic. Just respecting the indices and making sure “missing” still takes up space.

If you’re reading this alongside the code:

• one step converts the District response into internal Area/Row/Seat objects
• another step grid-aligns rows and seats into index-based arrays
• the UI renders those arrays, and missing indices become visible spacing

Optional future improvement:

• If seat selection/state management grows complex, add Redux-style normalization (entities-by-id + selectors). That optimizes updates/lookups - it’s separate from the grid geometry problem

References

• Repo - https://github.com/shubhamverma1811/frontend-prep
• Code - https://github.com/ShubhamVerma1811/frontend-prep/tree/main/frontend-system-design/bookmyshow_district/src
• Live - https://frontend-prep-react-repl.vercel.app/

NOTE: LLM was used for grammatically fixes.

I tried to implement two of the algorithm, Fixed bucket and Sliding Window Counter, using Go(Golang) and Redis.

You can know more about rate limiters and their algorithms from the resources below.

Here are some screenshots:

Fixed (without and with limit):

Sliding window counter:

• Without rate limit, we can see that within the past 5 mins, 10 reqs were made

• With rate limit, within the past 5 mins, more than 10 reqs were made, so the API is now rate limited

The main function contains a http server with two endpoints for each algo. I created a RateLimiter middleware for each of these endpoints, if rate limiter is not enabled, the handler functions execute.

func main() {
	mux := http.NewServeMux()
	rl := &RateLimiter{}

	mux.HandleFunc("GET /fixed", rl.FixedBucket(func(w http.ResponseWriter, r *http.Request) {
		w.Header().Set("Content-Type", "application/json")
		w.WriteHeader(http.StatusOK)

		res := APIResponse{
			Message: "Fixed API endpoint",
		}

		json.NewEncoder(w).Encode(res)
	}))

	mux.HandleFunc("GET /window", rl.WindowCounter(func(w http.ResponseWriter, r *http.Request) {
		w.Header().Set("Content-Type", "application/json")
		w.WriteHeader(http.StatusOK)

		res := APIResponse{
			Message: "Window API endpoint",
		}

		json.NewEncoder(w).Encode(res)
	}))

	log.Fatal(http.ListenAndServe(":8080", mux))
}

Rate Limiter is a struct with two methods.

type RateLimiter struct{}

Fixed Bucket

This algo is pretty simple, you have a bucket of "counts". If the counts runs out you are rate limited. The bucket is also refilled at a specific rate, I've used go routine to refill it at 1 count per second.

For every request hit, we decrement the count. Oh, and I am using Redis to store the bucket and it's count.

func (rl *RateLimiter) FixedBucket(next http.HandlerFunc) http.HandlerFunc {
	rdb.Set(ctx, "bucket", LIMIT, redis.KeepTTL)

// Refills every 1 second until the bucket is filled
	go func() {
		for {
			time.Sleep(time.Second)
			if v, _ := strconv.Atoi(rdb.Get(ctx, "bucket").Val()); v < LIMIT {
				rdb.Incr(ctx, "bucket")
			}
		}
	}()

	return func(w http.ResponseWriter, r *http.Request) {
		val, err := strconv.Atoi(rdb.Get(ctx, "bucket").Val())

		if err != nil {
			log.Panic(err)
			os.Exit(1)
		}

		w.Header().Add(HRLIMIT, fmt.Sprint(LIMIT))
		w.Header().Add(HRREM, fmt.Sprint(val))

// if bucket becomes empty, throw rate limit error and status code
		if val <= 0 {
			w.Header().Set("Content-Type", "application/json")
			w.WriteHeader(http.StatusTooManyRequests)
			res := APIResponse{
				Message: "Rate Limit reached",
			}
			json.NewEncoder(w).Encode(res)
		} else {
		// For every hit, decrement the count
			rdb.Decr(ctx, "bucket")
			next.ServeHTTP(w, r)
		}
	}
}

Sliding Window Counter

This is one of the most efficient algo. It basically checks if in the past time window, did you go over the rate limit count.

For example at 10 req/5 min - for every hit it will check if from now to 5 mins ago, did the endpoint hit 10 request.

If yes - rate limit, else - increment the count for current unix time. And, we delete all the keys stored in the redis that were older than the window time.

func (rl *RateLimiter) WindowCounter(next http.HandlerFunc) http.HandlerFunc {

	return func(w http.ResponseWriter, r *http.Request) {
		ok, err := rl.isAllowed(rdb)

		if err != nil {
			log.Panic(err)
			os.Exit(1)
		}

		if !ok {
			w.Header().Set("Content-Type", "application/json")
			w.WriteHeader(http.StatusTooManyRequests)
			res := APIResponse{
				Message: "Rate Limit reached",
			}
			json.NewEncoder(w).Encode(res)
		} else {
			next.ServeHTTP(w, r)
		}
	}
}

The isAllowed method takes in reference to redis and returns is rate limiting should be allowed or not.

func (rl *RateLimiter) isAllowed(r *redis.Client) (bool, error) {

	now := time.Now()
// We truncate the API hit time to only it's minute value, so 14:23:43 converts to 14:23:00
	timeStamp := strconv.FormatInt(now.Truncate(time.Minute).Unix(), 10)

// then we store it in the redis KV
	v, err := r.HIncrBy(ctx, "window", timeStamp, 1).Result()

	if err != nil {
		return false, err
	}

// If the value for the current minute itself passes the limit, then we rate limit
// so 14:23:00 had a count of more that LIMIT
	if v > LIMIT {
		return false, nil
	}

// Then we also delete all the keys from the redis that are older than the window.
// Ex: 5, keys that contained the timestap older that 5 mins from before are deleted
	vals, err := r.HGetAll(ctx, "window").Result()

	if err != nil {
		return false, err
	}

	total := 0
// this code, takes the time when API hit, subtracts window time, truncates it and gets the Unix value
// so, if API hits at 15:00:53, this would return 14:55:00
	threshold := now.Add(-time.Minute * time.Duration(WINDOW)).Truncate(time.Minute).Unix()


// loop for all the keys, some error handling and type conversion
	for k, v := range vals {
		intKey, err := strconv.Atoi(k)

		if err != nil {
			return false, err
		}

// if key in redis is still uder the window, increment the total count, else delete that key
		if int64(intKey) > threshold {
			val, err := strconv.Atoi(v)

			if err != nil {
				return false, err
			}

			total += val
		} else {

			r.HDel(ctx, "window", k)
		}
	}

// If the total within the WINDOW time exceeds limit then we rate limit
	if total > LIMIT {
		return false, nil
	}

	return true, nil
}

That's it. These were the two algos that I tried to implement in Go using Redis. Rate limiters used in production are more complex than this, they have something called config store and other pieces to them.

And they also use a dynamic keys like IP address or user ids to track each individual requests unlike in this blog with fixed key names like "bucket" and "window". You can read more on them from the refs.

References:

• Source code of this blog
• An alternative approach to rate limiting
• System Design Mock Interview: Design a Rate Limiter (with Meta Engineering Manager)
• Designing and implementing a sliding window based rate limiter

His blog talks about starting initiative for doing anything. I am gonna keep my blog more on the lines of tech.

We as software engineers often have some side or hobby projects. Some for learning purposes, some for building out real world products. But they all start with an idea.

I am sure we all at one point must had an idea of building something, It happens with me all the time, I have list of such ideas where I list down new ideas from time to time.

But I never get started on them. I've had ideas of products that were eventually made by people out there who took the intiative.

Lemme share the screenshots of some my ideas from my list:

• I had this idea to build a extension that would translate YT audio before it was even a thing on YT. But now, it's an actual feature on YT.

• Had the idea to check load diff in a Figma file (like a Git diff) before it was a thing. I think a year back Figma announced this feature.

The point I am making is, if you have an idea to build something, do it. Does not matter if you are starting it out thinking of turning it into an actual product or building it to just try out a tech stack.

Just build stupid shit.

I feel every portfolio website of an engineer must have a section or a page dedicated to side projects they tried out and abandoned it half way. (//TODO: Add a URL of my site when I eventually have a page for it).

Half baked projects tell more about a engineer than completed ones.

Currently, I've been playing around with a lot of tech (those who read my prev blog) be it FE, System design, Go lang and so on..

Hopefully, I'll follow my own thoughts and continue building stupid shit.

These were my raw thoughts that I always had in the back of my mind from quite some time and the blog by Aaron nudged me to put it out here.

Before starting with 2024, let's see which points/technologies I had chance to try out.

2023

• React. This one shouldn't be a surprise, every other project uses React. Although, I did get to work with the infamous RSC for my personal projects.

• Next.JS. Shouldn't be surprise either. Worked with the RSC and app directory.

• Mobx. I use it every day at work for production projects. Love the simplicity.

• Javascript/Typescript/Node. Every day at work.

• Tailwind. My go to for styling every personal projects.

• Nativebase. I use it every day at work for production projects.

• Testing: Cypress and Percy. Got to work with Cypress to implement E2E flows and UI testing with Percy.

• Go. Go wasn't in the prev list, I picked it up around Nov last year and absolutely loving it.

• Rust. Started learning Rust around September last year. Wrote rust for solving advent of code problems.

Projects that I built in 2023:

1. Added new features in the Feedly extension I made for Raycast
2. Built First "Craft" using CSS
3. Released "Delete shorts from YT" browser extension
4. Added Chezmoi completions to oh-my-bash
5. Built CX, A URL shortner in Go
6. Built X, A CLI Bookmarks manager in Go

2024

This year I am more interested in learning about the paradigms, patterns, methodology, working of a technology rather than learning the frameworks themselves.

Gonna stick to 1-2 languages and their frameworks. But would be open to try out new tech stuff.

Languages:

• Typescript/Javascript. Would continue using TS/JS without any doubt. For this year, I'd try to improve my TS types knowledge by trying Type challenges.

• Node/Bun. Already started to switch from Bun to Node in personal projects, and started to you Bun for writing scripts.

• Go. I really want to learn a low language this year, gave Go a try recently and I am abosultey loving it. This language is easier than Python yet packs so much. Definetly would be my go to language for backend related stuff.

• Rust. As of now, Rust is my "advent-of-code" language, I haven't found my usecase of Rust other than building Tauri Apps. I'd probably use Rust to solve DSA-ish problems and build Tauri Apps or in a very rare case contribute to OSS project.

• CSS. I really thought I knew CSS until I saw these tweets from Jhey, James and Nev. Trying to reproduce these effects and learning about these CSS properties would be on my list.

• HTML. Explore the Canvas and the SVG elements more. The above CSS tweets use canvas and svg elements extensively.

• Python. I call Python my GPT language, sure I can write scripts using python but I do not want to. The only reason I use python is to visualize charts for some data. And I'll often create a notebook and use GPT to help me achieve it.

Frontend Frameworks:

I am gonna stick with React and Svelte but open to try other frameworks.

• React/Next.JS. Would continue to work on only because it's needed at work. Kinda lost interest in React after all the new RSC stuff.

• Svelte/Svelte-kit. Would be my go to choice for FE from now on for personal projects.

• Framer Motion. Really want to get into building micro/macro animations on the web using framer motion, the only other reason to continue using React.

• React Native. The whole native ecosystem is quite overwhelming for me. I can build basic RN apps with screens and navigation, not sure if I'd try more of this stuff in this year.

Backend:

I have been interested in diving deep in the backend for a while. The backend I know as of now is to be able build a web server using Express, creating routes, middlewares and REST endpoints.

People like Hussein, Aaron, Arpit and Alex would be my go to learn BE, DB, System Design and Networking related stuff.

Do not have any particular frameworks in mind for BE. Probably gonna follow Roadmap.sh for BE.

• Fiber. Fiber is web framework for Go inspired by Express. This would be my go to to implement any server in Go.

• Gorm. Gorm is data modelling for Go, I'd be using it model Database schemas

Databases:

I know very little knowledge about DBs, I can write simple CRUD queries, perform joins, create basic normalized modals. But, can I write better queries, performant and fast queries? Nope.

DBs is a vast topic with dedicated Database engineers, I do not aim to be that. My aim is to be able to write and understand day-to-day topics that a typical BE engineer in a mid sized company would do.

• SQL. PostgreSQL/MySQL, dive a bit deeper on the topics I know now and want to explore.

• Redis. Kinda have gist of it, it's a hashmap, want to try out it's practical usecases.

• NoSQL. I have worked with Firebase and tried Mongo. Not necessarily anything particular I am trying to look for this year.

DevOps:

Not really a devops fan. If I can automate a task by deploying it on a cloud machine, you have my attention.

• Docker. I had followed docker tutorials from YT and have a basic gist of what it's capable of. Now I want to try it out by actually dockerzing a simple project and deploying it somewhere.

AI/LLMs:

LLMs and the products that utilize them are definetly here to stay.

I am not really into training models and customizing the params. Rather, I am interested into using the existing models and creating useful tools.

Probably be on the lookout for interesting models on HuggingFace, Replicate.

System Design

Don't really know much on this, follow ByteByteGo and other SD channels to understand basic principles of building apps.

Role related things

For the more SE related things, I've already started reading this book by Gergely.

Other things

Well, I might not get to try everything I mentioned above, or I might try things that are not mentioned here. You never know.

Worked with

• React
• NextJS
• MobX
• Tailwind
• NativeBase
• Typescript

Want to learn

Tech

• Remix
• Solid JS
• Zustand, Jotai
• Bascically understand the diff b/w these frameworks. What are signals in Solid, Evolution of these frameworks (Kent's blog)
• React Native - Architecture before the code
• What is Reactivity. Why is React reactivity. What are other stuff like this.
• TRPC - Why.What.How
• Zod
• GraphQL / Apollo
• Redis
• Docker
• Cloudflare and CF Workers
• System Design
• Design Patterns
• Monorepos
• Monoliths
• System / Design Architectures
• Edge runtime stuff
• React 18 stuff, concurrent mode, streaming, ssr, use hook
• Next 13 app dir stuff
• Micro animations
• Typescript - understand types better
• Role related things like SE practices, daily things, what makes a senior dev
• Rust
• CSS ecosystem
• CSS in JS, CSS server side
• Chakra
• Radix UI
• emotion WHy What
• Styled comps?
• Web components?
• Accessibility
• React patterns
• State mgmt patterns
• Testing related stuff
• TDD, unit tests, integrations..

You might want to use next/image component to render your images in your blog posts for better performance.

But there is no way to resize your images in Markdown.

So, We can use a simple plugin that I've created called rehype-image-resize to resize your images in Markdown. You can head over to the NPM page to know more about the plugin.

This blog is my way of demonstrating that the plugin works.

All the images in this blog are resized using the plugin.

You can inspect any image in this article and see that the next/image is being used.

Images from Unsplash rendered using Next/Image

Image 1

Image 2

Image 3

Although, if you are Tailwind for styling, you'll notice that the styles are not applied on the server rendered pages.

For this to work, we need to enable an experimental feature in next.config.js

const nextConfig = {
  //...
  experimental: {
    optimizeCss: true, // enabling this will enable SSR for Tailwind
  },
};

We also need to install Critters

yarn add -D critters

Next.JS will internally use this library called Critters

Now, all you do is yarn build and then yarn start.

Make a Postman call and under "Preview" you could see that the Tailwind styles are now getting applied at the server!

Here are the before and after screenshots:

Before

You can see that no styles are applied on the server rendered page.

After

After the changes are made, you can see that the styles are applied on the server rendered page.

Gotcha:

If you are using the @tailwindcss/typography plugin, you'd notice these warnings in your logs.

More info here

Although, if you are Tailwind for styling, you'll notice that the styles are not applied on the server rendered pages.

For this to work, we need to enable an experimental feature in next.config.js

const nextConfig = {
  //...
  experimental: {
    optimizeCss: true, // enabling this will enable SSR for Tailwind
  },
};

We also need to install Critters

yarn add -D critters

Next.JS will internally use this library called Critters

Now, all you do is yarn build and then yarn start.

Make a Postman call and under "Preview" you could see that the Tailwind styles are now getting applied at the server!

Here are the before and after screenshots:

Before

You can see that no styles are applied on the server rendered page.

After

After the changes are made, you can see that the styles are applied on the server rendered page.

Gotcha:

If you are using the @tailwindcss/typography plugin, you'd notice these warnings in your logs.

More info here

This blog is not meant to be a tutorial for Remix, Prisma or Auth0. It is only meant to show how to setup a simple authentication system using them.

Getting Started

For the curious ones, here’s the direct Repo link: https://github.com/ShubhamVerma1811/remix-prisma-auth0-starter

Or you can start off by installing these dependencies in the existing Remix project..

I chose Vercel as the hosting platform while creating the project so you might see some file differences and remix config differences. But those should not matter.

yarn add @prisma/client remix-auth remix-auth-auth0

yarn add -D prisma ts-node typescript

Project structure

.
|-- README.md
|-- app
|   |-- entry.client.tsx
|   |-- entry.server.tsx
|   |-- root.tsx
|   |-- routes
|   |   |-- auth
|   |   |   |-- auth0
|   |   |   |   `-- callback.tsx
|   |   |   `-- auth0.tsx
|   |   |-- index.tsx
|   |   |-- login.tsx
|   |   `-- logout.tsx
|   |-- services
|   |   `-- session.server.ts
|   `-- utils
|       |-- auth.server.ts
|       `-- db.server.ts
|-- package.json
|-- prisma
|   |-- schema.prisma
|   `-- seed.ts
|-- public
|   |-- build
|   `-- favicon.ico
|-- remix.config.js
|-- remix.env.d.ts
|-- server.js
|-- tsconfig.json
`-- yarn.lock

Integration

Setup Prisma

You can directly follow the steps for this written in the Remix docs for Prisma

https://remix.run/docs/en/v1/tutorials/jokes#connect-to-the-database

// app/utils/db.server.ts
import { PrismaClient } from '@prisma/client'

let db: PrismaClient

declare global {
  var __db: PrismaClient | undefined
}

// this is needed because in development we don't want to restart
// the server with every change, but we want to make sure we don't
// create a new connection to the DB with every change either.
if (process.env.NODE_ENV === 'production') {
  db = new PrismaClient()
} else {
  if (!global.__db) {
    global.__db = new PrismaClient()
  }
  db = global.__db
}

export { db }

Creating session in Remix

So we can store the user’s session in the cookies

More info on sessions in the Remix docs. https://remix.run/docs/en/v1/api/remix#using-sessions

// app/services/session.server.ts
import { createCookieSessionStorage } from '@remix-run/node'

// export the whole sessionStorage object
export let sessionStorage = createCookieSessionStorage({
  cookie: {
    name: '_session', // use any name you want here
    sameSite: 'lax', // this helps with CSRF
    path: '/', // remember to add this so the cookie will work in all routes
    httpOnly: true, // for security reasons, make this cookie http only
    secrets: ['s3cr3t'], // replace this with an actual secret
    secure: process.env.NODE_ENV === 'production' // enable this in prod only
  }
})

// you can also export the methods individually for your own usage
export let { getSession, commitSession, destroySession } = sessionStorage

Creating the authenticator client that uses Auth0 strategy.

• In this file, you’ll be setting up the Auth0 strategy using remix-auth. You’ll be needing callback URL, client ID, client secret and tenant ID of your application.
• Here were are creating a new instance of the Authenticator from remix-auth.
• And creating Auth0 strategy config to the authenticator.
• The 2nd argument of the strategy takes a callback that would return you the Auth0 profile after successful login.
• We take that profile data and make an upsert operation using Prisma.
• upsert would either create a new user in the DB or return as the user that already exists.

// app/utils/auth.server.ts
import { Authenticator } from 'remix-auth'
import { Auth0Strategy } from 'remix-auth-auth0'
import { sessionStorage } from '~/services/session.server'
import { db as prisma } from './db.server'

// Create an instance of the authenticator, pass a generic (optional) with what your
// strategies will return and will be stored in the session

export const authenticator = new Authenticator(sessionStorage)

let auth0Strategy = new Auth0Strategy(
  {
    callbackURL: process.env.AUTH0_CALLBACK_URL!,
    clientID: process.env.AUTH0_CLIENT_ID!,
    clientSecret: process.env.AUTH0_CLIENT_SECRET!,
    domain: process.env.AUTH0_DOMAIN_URL!
  },
  async ({ accessToken, refreshToken, extraParams, profile }) => {
    const email = profile.emails?.[0]?.value
    // Get the user data from your DB or API using the tokens and profile
    return prisma.user.upsert({
      where: {
        email
      },
      create: {
        email,
        name: profile.displayName
      },
      update: {}
    })
  }
)

authenticator.use(auth0Strategy)

Routing

Create auth0 route.

// app/routes/app/auth0/auth0.tsx
import type { ActionFunction, LoaderFunction } from '@remix-run/node'
import { redirect } from '@remix-run/node'
import { authenticator } from '~/utils/auth.server'

// If user directly goes to this page, we redirect to login
export const loader: LoaderFunction = () => redirect('/login')

// Post request sent to this route would be handled by the authenticator and redirect you to the Auth0's login page.
export const action: ActionFunction = ({ request }) => {
  return authenticator.authenticate('auth0', request)
}

Creating callback route

// app/routes/app/auth0/callback.tsx
import type { LoaderFunction } from '@remix-run/node'
import { authenticator } from '~/utils/auth.server'

/*
We import the authenticator and based on the login state we redirect them to the
either success or failure redirect
*/

export const loader: LoaderFunction = ({ request }) => {
  return authenticator.authenticate('auth0', request, {
    successRedirect: '/',
    failureRedirect: '/login'
  })
}

Creating login route

import type { LoaderFunction } from '@remix-run/node'
import { Form } from '@remix-run/react'
import { authenticator } from '~/utils/auth.server'

// If the user lands on this page, we redirect back to / if they are already logged in.
export const loader: LoaderFunction = async ({ request }) => {
  return await authenticator.isAuthenticated(request, {
    successRedirect: '/'
  })
}

// This form would take us to the auth0 route, which would redirect to the Auth0 login page.

export default function Login() {
  return (
    <Form action='/auth/auth0' method='post'>
      <button>Login with Auth0</button>
    </Form>
  )
}

Creating the logout route

// app/routes/app/auth0/logout.tsx
import type { LoaderFunction } from '@remix-run/node'
import { authenticator } from '~/utils/auth.server'

// Here we use the logout function of the authenticator to logout the user and clear the Auth0 session.
export const loader: LoaderFunction = async ({ request }) => {
  return authenticator.logout(request, {
    redirectTo: '/login'
  })
}

Protecting routes using our Authenticator.

We are now ready for our routes to be protected.You can simple add the authenticator to the route’s loader.

For example, If you want to protect the route /, you can do the following:

import type { LoaderFunction } from "@remix-run/node";
import { authenticator } from "~/utils/auth.server";

// When the loader of this page is ran, we will check if the user is logged in.
//  and on failure we redirect to the login page.
export const loader: LoaderFunction = async ({ request }) => {
   await authenticator.isAuthenticated(request, {
    failureRedirect: "/login",
  });

  //... other code here that returns something from the loader..

};

export default function Index() {
  return (
    // ...
  );
}

That’s it! You have now added Authentication and Protected routes for your application using Remix + Prisma + Auth0.

References:

• Starter Template for this blog
• Remix-Auth
• Remix-Auth-Auth0
• Prisma Upsert

One of them is the Open Graph meta tag. It is used to display a thumbnail of the article sites like Twitter, Discord and many more.

<meta property="og:image" content="http://example.com/image.jpg" />

We’ll need to handle the following:

• Styling
• Font family
• Responsiveness

There are many image manipulation libraries like Jimp or Sharp, but they can’t handle the above points.

You know what can handle it? It’s HTML!

So we will be using Puppeteer that would spin up a headless browser and take a screenshot of the html page.

We will be using the following libraries:

• Express - For spinning up the server
• Puppeteer - For spinning up the browser
• Handlerbars - For rendering the html
• Tailwind CSS - For styling the html

And all this would be deployed on Vercel. This way we could use the Serverless Functions.

Let’s get started.

Here is the file structure:

File Structure

.
|-- api
|   `-- index.ts
|-- package.json
|-- src
|   `-- templates
|       |-- basic
|       |   `-- index.hbs
|       `-- fancy
|           `-- index.hbs
|-- tailwind.config.js
|-- vercel.json
`-- yarn.lock

Creating the HTML/HBS Template

The HTML code could be anything, that’s up to you. For sake of this blog, we are using a simple template.

I am using Tailwind CDN for styling. Utility Classes FTW!

Head of the HTML

We are importing fonts, and using TailwindCSS CDN for styling.

<!-- templates/basic/index.hbs -->

<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>{{title}}</title>
    <link rel="preconnect" href="https://fonts.googleapis.com" />
    <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
    <link
      href="https://fonts.googleapis.com/css2?family=Karla&display=swap"
      rel="stylesheet"
    />
    <script src="https://cdn.tailwindcss.com?plugins=line-clamp"></script>
  </head>
  <!-- body ... -->
</html>

Body of the HTML

Nothing much here apart from Tailwind CSS classes, just a title and date that handlebars would dynamically update.

<!-- templates/basic/index.hbs -->

<body
  class="image relative bg-black font-bold w-[2240px] h-[1260px] p-32 font-[Karla]"
>
  <h1 class="text-gray-300 text-4xl">SV.</h1>
  <h1
    class="text-white my-32 py-2 leading-[80px] text-6xl line-clamp-3 font-medium"
  >
    {{title}}
  </h1>
  <h1 class="text-white font-normal my-32 text-3xl line-clamp-3">
    {{date}} | by Shubham Verma
  </h1>

  <div class="bg-inherit w-full h-full absolute -z-10"></div>

  <h1 class="text-gray-300 mb-32 absolute bottom-0 text-4xl">shbm.fyi</h1>
</body>

Creating the Server and the Handlerbars Template.

Imports

// api/index.ts
import chromium from 'chrome-aws-lambda' // required for deploying on Vercel
import express, { Request, Response } from 'express'
import { readFileSync } from 'fs'
import Handlebars from 'handlebars'
import path from 'path'

const app = express()

Creating the get Route

Overview of the get route:

1. We spin up the puppeteer browser.
2. Get the title and date from the query string.
3. Compile the hbs template and pass in the title and date.
4. Render the html.
5. Take a screenshot of the html.
6. Close the browser.
7. Return the screenshot as a response.

In the very end we are adding this line

module.exports = app;

This is for Vercel to deploy a serverless function.

app.get('/', async (req: Request, res: Response) => {
  try {
    // All these configurations are required for puppeteer, if you are deploying on Vercel!
    // https://github.com/vercel/community/discussions/124
    const browser = await chromium.puppeteer.launch({
      args: [...chromium.args, '--hide-scrollbars', '--disable-web-security'],
      defaultViewport: chromium.defaultViewport,
      executablePath: await chromium.executablePath,
      headless: true,
      ignoreHTTPSErrors: true
    })
    // const browser = await chromium.puppeteer.launch()
    const [page] = await browser.pages()

    const { template = 'basic', title, date } = req.query

    // Reading the template
    const _template = readFileSync(
      path.join(process.cwd(), `src/templates/${template}/index.hbs`),
      'utf8'
    )

    // Compiling the template
    const html = Handlebars.compile(_template)({
      title,
      // get date in this format - 21st April 2020
      date:
        date ??
        new Date().toLocaleDateString('en-GB', {
          day: 'numeric',
          month: 'long',
          year: 'numeric'
        })
    })

    // Rendering the html and taking a screenshot
    await page.setContent(html)
    const take = await page.$('.image')
    const ss = await take.screenshot()
    await browser.close()

    // Returning the buffer of the screenshot.
    res.setHeader('Content-Type', 'image/png')
    res.setHeader('Cache-Control', 's-max-age=1, stale-while-revalidate')
    res.send(ss)
  } catch (err) {
    console.error(err)
    res.send('Error')
  }
})

// Required if you are deplying Express on Vercel as a Serverless Function.
module.exports = app

Deploying on Vercel

Create a vercel.json and add the following:

// vercel.json

{
  "rewrites": [
    {
      "destination": "/api",
      "source": "/(.*)"
    }
  ]
}

All set! You can now deploy the server on Vercel.

You can try it out by going to https://og.shubhamverma.me/?title=Hey there .It will take time to load up, because first it’s serverless and second we are spinning up puppeteer.

Please don’t over do it. I’ve got Vercel Serverless Limits 😅

References:

I have Open Sourced the code for this project on Github.

Here is the Repo link - https://github.com/ShubhamVerma1811/open-graph-api

Try it out – press cmd+k (macOS) or ctrl+k (Linux/Windows), or click the CMD icon in the header above.

Awesome! Now let’s start.

All the code used in this blog is available on this CodeSandbox Link. CSB LINK

We will be using a library called KBar

Adding Provider and actions

In your root file, wrap the App with a KbarProvider and pass it the default actions prop

// index.js

import { KBarProvider } from 'kbar'

const actions = [
  {
    id: 'youtube',
    name: 'Youtube',
    shortcut: ['g', 'y'],
    perform: () =>
      (window.location.href = 'https://www.youtube.com/watch?v=dQw4w9WgXcQ')
  },
  {
    id: 'twitter',
    name: 'Twitter',
    shortcut: ['g', 't'],
    keywords: 'twitter',
    perform: () => (window.location.href = 'https://twitter.com/verma__shubham')
  }
]

return (
  <KBarProvider actions={actions}>
    <App />
  </KBarProvider>
)

Now if you press the shortcut, you will see that nothing happens. This is because we haven’t added the other utilities that Kbar provides.

Adding KBar utilities

Let’s add the below code.

// index.js

import {
  KBarAnimator,
  KBarPortal,
  KBarPositioner,
  KBarProvider,
  KBarResults,
  KBarSearch
} from 'kbar'

const actions = [
  //...
]

return (
  <KBarProvider actions={actions}>
    <KBarPortal>
      <KBarPositioner>
        <KBarAnimator>
          <KBarSearch />
        </KBarAnimator>
      </KBarPositioner>
    </KBarPortal>
    <App />
  </KBarProvider>
)

Now we are able to see a search box when you press the shortcut! But you’ll notice nothing happens when we search.

Why are our default actions not rendered?

Adding the KBarResults

• Create a component called Results.
• The useMatches() hooks returns us the results of the searched query.
• We will use the KBarResults component to render the results.

const Results = () => {
  const { results } = useMatches()
  return (
    <KBarResults
      items={results}
      onRender={({ item, active }) => {
        return typeof item === 'string' ? (
          // For sections.
          <div> {item}</div>
        ) : (
          // For the items.
          <p
            style={{
              backgroundColor: active ? 'gray' : 'white',
              height: '50px'
            }}
          >
            {item.name}
          </p>
        )
      }}
    />
  )
}

// USE THE ABOVE COMPONENT right after the KBarSearch />

// ...
;<KBarProvider>
  <KBarPortal>
    <KBarPositioner>
      <KBarAnimator>
        <KBarSearch />
        {/* USE THE Results COMPONENT here*/}
        <Results />
      </KBarAnimator>
    </KBarPositioner>
  </KBarPortal>
  <App />
</KBarProvider>
// ...

Adding nested Results

If you open up Kbar on this website, you will see a “Search Blogs” item which opens up nested results. Let’s see how its done.

• All we need to do it add a action and reference the other actions with a parent key.

// Change the actions variable to this

const actions = [
  {
    id: 'youtube',
    name: 'Youtube',
    shortcut: ['g', 'y'],
    perform: () =>
      (window.location.href = 'https://www.youtube.com/watch?v=dQw4w9WgXcQ')
  },
  {
    id: 'twitter',
    name: 'Twitter',
    shortcut: ['g', 't'],
    keywords: 'twitter',
    perform: () => (window.location.href = 'https://twitter.com/verma__shubham')
  },
  {
    id: 'search-blogs',
    name: 'Search Blogs',
    shortcut: ['s', 'b']
  },
  {
    id: 'blog-1',
    name: 'Blog 1',
    parent: 'search-blogs'
  },
  {
    id: 'blog-2',
    name: 'Blog 2',
    parent: 'search-blogs'
  }
]

Toggling KBar using the useKar hook

In our App.js file, we will use the useKBar() hook to toggle KBar.

import { useKBar } from 'kbar'
import './styles.css'

export default function App() {
  const kbar = useKBar()

  return (
    <div className='App'>
      <h1>Hit Ctrl + K or Cmd + K</h1>
      <button
        onClick={() => {
          kbar.query.toggle()
        }}
      >
        Toggle Kbar
      </button>
    </div>
  )
}

That's it! Now you can toggle KBar by pressing Cmd + K on macOS

or Ctrl+K on Windows/Linux. And also by clicking the CMD icon button.

My Socials

• Twitter - @verma__shubham
• GitHub - ShubhamVerma1811

The GitHub repo for this blog is added in the references.

We have created a basic app template using the npx create-turbo@latest.

I have made a small change in that template, by moving pages, styles into the src folder, so the folder structure would look something like:

.
|-- apps
|   |-- docs
|   |   `-- src
|   |       |-- pages
|   |       `-- styles
|   `-- web
|       `-- src
|           |-- pages
|           `-- styles
`-- packages
    |-- config
    |-- tsconfig
    `-- ui
        `-- components

1. Installing Tailwind.

We’ll start off by installing tailwindcss, postcss and autoprefixer at the root of your project.

yarn add -DW tailwindcss postcss autoprefixer

Optionally you can also install prettier-plugin-tailwindcssfor sorting those tailwind classes in the components. Check the references below to learn more.

Our root package.json would look like:

{
  // ...
  "devDependencies": {
    "autoprefixer": "^10.4.2",
    "postcss": "^8.4.6",
    "prettier": "^2.5.1",
    "prettier-plugin-tailwindcss": "^0.1.7",
    "tailwindcss": "^3.0.23",
    "turbo": "latest"
  }
  // ....
}

2. Creating tailwind.config.js and postcss.config.js

In our packages/config, let’s create tailwind.config.js and postcss.config.js

• In tailwind.config.js, add the following:

module.exports = {
  content: [
    '../../packages/ui/components/**/*.{ts,tsx}',
    './src/**/*.{ts,tsx}'
  ],
  theme: {
    extend: {}
  },
  plugins: []
}

• In postcss.config.js, add the following:

module.exports = {
  plugins: {
    tailwindcss: {},
    autoprefixer: {}
  }
}

3. Using the above configs in our apps and packages

• We have created the common configs, Now we are ready to use them in our apps/web, apps/docs or app/{name} directories.
• Again create tailwind.config.js and postcss.config.js in our apps/{name} directories and in packages/ui

Add the following in the files:

module.exports = require('config/tailwind.config')

module.exports = require('config/postcss.config')

Lastly, in our next.config.js for both web and docs add this if it’s not already present:

const withTM = require('next-transpile-modules')(['ui'])

module.exports = withTM({
  reactStrictMode: true
})

That’s it! You are now ready to use Tailwind CSS with Turborepo!

References

• Github Repo for this blog
• Automatic Tailwind CSS Class Sorting

🎉 So I created an extension that can finally support that for your React files!

Links Below

Here are the before and after screenshots:

Contributing

I am open for contributions.Feel free to raise features requests or PRs!

Head over to the Github repo and make a pull request or raise features requests or issues.

Running Locally

Clone this repo and start the “Debug: Start Debugging” command

Support

If you liked this extensions then check out my other extensions and follow me on twitter.

Made with ❤️ by Shubham Verma

Installation

• Before getting starting, I assume you have already initialized a NextJS project.

yarn add @next/mdx @mdx-js/loader

OR

npm install --save @next/mdx @mdx-js/loader

Configuration

• In our next.config.js, add the following

const withMDX = require('@next/mdx')({
  extension: /\.mdx$/
})

module.exports = withMDX({
  pageExtensions: ['js', 'jsx', 'ts', 'tsx', 'md', 'mdx']
})

Usage

Now we can create a index.mdx file in our src

<!-- src/pages/index.mdx -->

# This is a Markdown Syntax

## React starts from here

import { useState } from "react";

export const Home = () => {
  const [count, setCount] = useState(0);
  return (
    <div>
      <h1>Count {count} </h1>
      <button onClick={() => setCount((prev) => prev + 1)}> Increment </button>
    </div>
  );
};

<Home />

## React ends here

## I can continue to write Markdown here

Output

References

• NextJS PageExtensions
• MDXJS
• MDX and NextJS

Socials

If you like my content then do follow me on Twitter Shubham Verma

map is an Array method that takes in a callback and returns an array of items that were returned from the callback

Example:

const arr = [1, 2, 3, 4];
const res = arr.map((el) => el * 2);

console.log(res); // returns [2,4,6,8]

Let’s create our own map method called myMap

• myMap() takes in a parameter which a callback/function.
• It has a results array that gets returned by the myMap function.
• The returned values from our cb are pushed in the results array.
• The this here would be the array that we will use this myMap function on.
• The traditional map() callback can take 3 args. element, index and the source arr. We have done the same.

function myMap(cb, thisArg) {
  const arr = [];

  for (let i = 0; i < this.length; i++) {
    if (!Object.hasOwn(this, i)) {
      arr.push(this[i]);
    } else {
      arr.push(callbackFn.call(thisArg, this[i], i, this));
    }
  }

  return arr;
}

// Doing this will allow us to use arr.myMap() syntax
Array.prototype.myMap = myMap;

const arr = [1, 2, 3, 4, 5, 6];
const myMapResult = arr.myMap((el, _idx, _arr) => {
  return el * 2;
});

console.log(myMapResult); //[2, 4, 6, 8, 10, 12];

Filter

filter() is an Array method that takes in a callback and returns an array of items that satisfy the condition provided in our callback

Example:

const arr = [1, 2, 3, 4];
const res = arr.filter((el) => el % 2); // only return even numbers

console.log(res); // [2,4]

Let’s create our own filter method called myFilter

• myFilter() takes in a parameter which a callback/function.
• It has a results array that gets returned at the end.
• The returned values from our cb are pushed in the results array.
• The this here would be the array that we will use this myFilter function on.
• The traditional filter() callback can take 3 args. element, index and the source arr. We have done the same.

function myFilter(cb, thisArgs) {
  if (!Array.isArray(this)) {
    throw new TypeError('FIlter must be run on array');
  }

  const arr = [];

  for (let i = 0; i < this.length; i++) {
    if (callbackFn.call(thisArg, this[i], i, this)) {
      arr.push(this[i]);
    }
  }

  return arr;
}

// Doing this will allow us to use arr.myFilter() syntax
Array.prototype.myFilter = myFilter;

const arr = [1, 2, 3, 4, 5, 6];

const foo = [
  { name: 'S', age: 2 },
  { name: 'V', age: 3 },
];

const myFilterResult = foo.myFilter((el, _idx, _arr) => {
  return el.name !== 'S';
});

console.log(myFilterResult); // [{ name: "V", age: 3 }]

Reduce

Here the MDN definition of it.

The reduce() method executes a reducer function (that you provide) on each element of the array, resulting in a single output value.

It takes in two important parameters. accumulater and currentValue

Example:

const arr = [1, 2, 3, 4];
const res = arr.reduce((acc, curr) => {
  acc += curr;
  return acc;
}); // 10

console.log(res); // 10

Lets create our own reduce() method called myReduce()

• myReduce() takes in a parameter which a callback/function.
• It returns a single reduced value.
• The returned values from our cb is assigned to the acc.
• The this here would be the array that we will use this myReduced function on.
• The traditional reduced() callback can take 4 args. accumulator, currentValue, index and the source arr. We have done the same.

function myReduce(cb, initialValue) {
  let prev = typeof initialValue !== 'undefined' ? initialValue : this?.[0];
  if (!this.length && typeof prev === 'undefined')
    throw new Error('emoty lenfth');

  let i = typeof initialValue !== 'undefined' ? 0 : 1;

  for (; i < this.length; i++) {
    if (Object.hasOwn(this, i)) {
      prev = cb.call(this, prev, this[i], i, this);
    }
  }

  return prev;
}

// Doing this will allow us to use arr.myReduce() syntax
Array.prototype.myReduce = myReduce;

const myReduceResult = arr.myReduce((acc, curr, _idx, _arr) => {
  acc += curr;
  return acc;
});

console.log(myReduceResult); // 21

If you find any errors or edge cases in the above code then please let me know. I am happy to learn about them and add them here.

In the next blog in this series, I’ll try and write our own debounce function from the loadash library

Also, if you guys want to see polyfills of your libs then let me know in the comments.

Hope this blog was helpful to you.

In this blog, I’ll show you exactly how to do that with your NextJS pages using Higher-Order Components 1

There can be several ways of authenticating a user like using cookies or JWT tokens.2

I’ll be using JWT token as an example, where the accessToken is stored in the localStorage

Let’s consider a page “/dashboard”. This page should be only accessed by authenticated users

In our Dashboard.jsx

// pages/dashboard.jsx
import withAuth from 'HOC/withAuth.js'
const Dashboard = ({ user }) => {
  return (
    <div>
      <h1>Dashboard</h1>
      <h2>{user.name}</h2>
    </div>
  )
}

export default withAuth(Dashboard)

Notice that we are importing withAuth.jsx and exporting the page by passing it as an argument. That is all we need to do for our pages.

In our withAuth.jsx

I’ll show you two methods of implementations:

• Method 1: We don’t verify the token
• Method 2: We verify the token

Method 1: (We don’t verify the token)

// HOC/withAuth.jsx
import { useRouter } from 'next/router'
const withAuth = (WrappedComponent) => {
  return (props) => {
    // checks whether we are on client / browser or server.
    if (typeof window !== 'undefined') {
      const Router = useRouter()

      const accessToken = localStorage.getItem('accessToken')

      // If there is no access token we redirect to "/" page.
      if (!accessToken) {
        Router.replace('/')
        return null
      }

      // If this is an accessToken we just render the component that was passed with all its props

      return <WrappedComponent {...props} />
    }

    // If we are on server, return null
    return null
  }
}

export default withAuth

Method 2: We need to verify the token.

// HOC/withAuth.jsx
import { useRouter } from 'next/router'
import { useEffect, useState } from 'react'
import verifyToken from 'services/verifyToken'

const withAuth = (WrappedComponent) => {
  return (props) => {
    const Router = useRouter()
    const [verified, setVerified] = useState(false)

    useEffect(async () => {
      const accessToken = localStorage.getItem('accessToken')
      // if no accessToken was found,then we redirect to "/" page.
      if (!accessToken) {
        Router.replace('/')
      } else {
        // we call the api that verifies the token.
        const data = await verifyToken(accessToken)
        // if token was verified we set the state.
        if (data.verified) {
          setVerified(data.verified)
        } else {
          // If the token was fraud we first remove it from localStorage and then redirect to "/"
          localStorage.removeItem('accessToken')
          Router.replace('/')
        }
      }
    }, [])

    if (verified) {
      return <WrappedComponent {...props} />
    } else {
      return null
    }
  }
}

export default withAuth

Footers:

1. React Higher-Order Components
2. User authentication in NodeJS

Wasn’t that easy!

I hope this blog helped you. If you got any queries or feedback then let me know 😀