DEV Community: PuruVJ

Why I Analyzed 16,384 Bundle Combinations (And You Should Too)

PuruVJ — Sat, 14 Jun 2025 11:56:24 +0000

I believe in radical transparency when it comes to bundle sizes. When developers are choosing a library, they deserve to know exactly what they're paying for in terms of bundle impact. That's why, when building neodrag v3, I decided to analyze every single possible plugin combination and report precise bundle sizes for each one.

That meant analyzing 2^14 = 16,384 different combinations. Let me walk you through why I went to these lengths and how I tackled this challenge.

What is Neodrag?

Neodrag is a TypeScript drag-and-drop library that I've been working on for a few years now. Unlike other drag libraries that come as monolithic packages, I wanted to create something truly modular where developers only pay for what they use.

The library lets you make any DOM element draggable with a simple API, but the real power comes from its plugin system. Want bounds checking? Add the bounds plugin. Need grid snapping? Include grid. Touch support? touchAction. Each plugin handles a specific piece of functionality, and they can all work together seamlessly.

The v3 Architecture Challenge

Neodrag v3 represents a complete rewrite with a plugin-first architecture. Instead of cramming everything into one bundle, I broke functionality into 14 discrete plugins:

applyUserSelectHack - Prevents text selection during drag
axis - Constrains movement to X or Y axis
bounds - Keeps elements within boundaries
controls - Defines drag handles and no-drag zones
disabled - Programmatically disable dragging
events - Emits drag lifecycle events
grid - Snaps movement to a grid
ignoreMultitouch - Handles multi-touch scenarios
position - Programmatic position control
scrollLock - Prevents page scroll during drag
stateMarker - Adds CSS classes for styling
threshold - Prevents accidental drags
touchAction - Optimizes touch behavior
transform - Handles DOM transformations

The beauty of this approach is that a developer who just wants basic dragging can include only the essential plugins and get a tiny bundle. Someone building a complex interface can include everything they need without worrying about unused code.

But here's the challenge: with 14 plugins, there are 2^14 = 16,384 possible combinations. How do I tell developers the exact bundle cost of their specific configuration?

Why Bundle Size Transparency Matters

I've always cared deeply about performance. In my previous projects like neodrag v2, neoconfetti, and neotraverse, I established a reliable bundle analysis pipeline:

tsup for bundling with aggressive tree-shaking
rollup under the hood for optimization
terser for minification
brotli-size to get the final compressed size

This gives me the most realistic bundle size that users will actually download - compressed and optimized.

But here's what bothers me about most libraries: they give you one number. "Our library is 15KB minified + gzipped!" But what if you're only using 20% of the features? Are you still paying for the full 15KB?

With neodrag v3's modular architecture, I wanted to give developers precise numbers. If you use transform + bounds + threshold, I want to tell you exactly what that costs. Not an estimate, not a range - the actual bundled and compressed size.

That's going the extra mile for transparency.

The Technical Challenge: Understanding the Process

Let me walk you through what analyzing a single bundle combination actually involves. It's more complex than you might think.

For each combination, I need to:

Generate a test file with the exact plugin imports
Set up a temporary build environment with proper Node.js modules
Run the full build pipeline (bundling, tree-shaking, minification)
Measure the compressed result with brotli compression
Clean up temporary files

Here's what processing just one combination looks like:

async function measureCombinationWithBuild(plugins, tempDir, baseSize) {
  // Step 1: Create a temporary workspace
  const measureDir = resolve(__dirname, 'temp', 'measure');
  mkdirSync(measureDir, { recursive: true });

  // Step 2: Copy core package to node_modules (for proper imports)
  const nodeModulesSource = join(tempDir, 'node_modules');
  if (existsSync(nodeModulesSource)) {
    const nodeModulesTarget = join(measureDir, 'node_modules');
    mkdirSync(nodeModulesTarget, { recursive: true });
    copyRecursive(nodeModulesSource, nodeModulesTarget);
  }

  // Step 3: Generate test content for this specific combination
  const { actualImports } = getActualImportsForCombination(plugins);
  const testContent = `
import { DraggableFactory } from '@neodrag/core';
import { ${actualImports.join(', ')} } from '@neodrag/core/plugins';

export const factory = new DraggableFactory({
    plugins: [${actualImports.join(', ')}]
});
`;

  // Step 4: Write the test file and package.json
  const entryPath = join(measureDir, 'test.js');
  writeFileSync(entryPath, testContent);

  const packageJson = { name: 'core-analysis', type: 'module' };
  writeFileSync(
    join(measureDir, 'package.json'),
    JSON.stringify(packageJson, null, 2),
  );

  try {
    // Step 5: Run the full build pipeline
    await build({
      entry: { [filename]: entryPath },
      format: ['esm'],
      outDir,
      bundle: true,
      target: 'es2020',
      treeshake: { preset: 'smallest', moduleSideEffects: false },
      minify: 'terser',
      terserOptions: {
        compress: { dead_code: true, drop_console: true, unused: true },
        mangle: { toplevel: true },
      },
      noExternal: ['@neodrag/core'],
    });

    // Step 6: Read and compress the result
    const outputPath = join(outDir, `${filename}.js`);
    const content = readFileSync(outputPath, 'utf-8');
    const compressedSize = sync(content); // brotli-size

    // Step 7: Cleanup
    rmSync(measureDir, { recursive: true, force: true });

    return compressedSize;
  } catch (error) {
    console.warn(`Build failed for [${plugins.join(', ')}]: ${error.message}`);
    return baseSize; // Fallback
  }
}

That's a lot of work for one combination. File system operations, Node.js module resolution, AST parsing, tree-shaking analysis, minification, compression... Each combination takes anywhere from 200+ milliseconds to process completely.

Now multiply that by 16,384.

Scaling to 16,384: The Combination Generator

Here's where things get interesting. I need to generate every possible subset of 14 plugins. Fortunately, this maps perfectly to binary representation:

function* generateAllCombinations(allPlugins) {
  const n = allPlugins.length; // 14 plugins

  // Generate all numbers from 0 to 2^14 - 1 (16,383)
  for (let i = 0; i < Math.pow(2, n); i++) {
    const combination = [];

    // Check each bit position
    for (let j = 0; j < n; j++) {
      if (i & (1 << j)) {
        combination.push(allPlugins[j]);
      }
    }

    yield combination;
  }
}

This elegantly generates:

[] (no plugins) for i = 0
['applyUserSelectHack'] for i = 1
['axis'] for i = 2
['applyUserSelectHack', 'axis'] for i = 3
... all the way up to all 14 plugins for i = 16,383

Then I run the full analysis:

async function main() {
  console.log('🚀 Starting analysis of 16,384 combinations...\n');

  const allPlugins = getCorePluginExports(); // 14 plugins
  const sizes = {};

  let total = 0;
  let built = 0;

  for (const combination of generateAllCombinations(allPlugins)) {
    total++;

    // Progress logging every 1000 combinations
    if (total % 1000 === 0) {
      console.log(`🔄 Progress: ${total}/16,384 combinations processed`);
    }

    if (combination.length === 0) {
      // Base case - no plugins
      sizes[bitmask] = baseSize;
    } else if (isSubsetOfDefaults(combination)) {
      // Default plugins - estimate without building
      sizes[bitmask] = estimateSizeForDefaultCombination(combination, baseSize);
    } else {
      // Non-default combination - full build required
      const size = await measureCombinationWithBuild(
        combination,
        tempDir,
        baseSize,
      );
      sizes[bitmask] = size;
      built++;

      if (built % 50 === 0) {
        console.log(`    🔨 Built ${built} combinations so far...`);
      }
    }
  }
}

The Reality of 16,384 Builds

Let me paint you a picture of what this actually looks like when running on my M4 Max with 64GB RAM:

🚀 Starting analysis of 16,384 combinations...

📏 Measuring base size...
✅ Base DraggableFactory size: 3564 bytes

🧮 Generating combinations...
  🔄 Progress: 1000/16,384 combinations processed
    🔨 Built 50 combinations so far...
    🔨 Built 100 combinations so far...
  🔄 Progress: 2000/16,384 combinations processed
    🔨 Built 150 combinations so far...
    🔨 Built 200 combinations so far...
  🔄 Progress: 3000/16,384 combinations processed
    ...
    [30 minutes later]
    ...
  🔄 Progress: 16000/16,384 combinations processed
    🔨 Built 8,234 combinations so far...

✅ Processing complete:
  📊 Total combinations: 16,384
  🧮 Calculated in memory: 8,150 (default plugin subsets)
  🔨 Built with tsup: 8,234 (non-default combinations)

The full analysis completes in about 30 minutes on modern hardware. The M4 Max handles the parallel processing beautifully, and with 64GB of RAM, I never run into memory constraints. My laptop's fans do spin up and CPU usage stays high, but it's surprisingly manageable for such an intensive task.

Some combinations build quickly (simple plugins), others take longer (complex plugins with many dependencies). The bounds plugin, for example, pulls in additional helper functions. The controls plugin includes complex hit-testing logic. Each combination tells a story about exactly which code gets included.

Initially, I was storing the results like this:

{
  "keys": {
    "0": "applyUserSelectHack",
    "1": "axis",
    "2": "bounds",
    "3": "controls"
    // ... more plugins
  },
  "sizes": {
    "": 3564,
    "0": 3624,
    "1": 3608,
    "0,1": 3609,
    "0,1,2": 4235,
    "0,2,4,5,7": 4299
    // ... 16,000+ more combinations
  }
}

The string keys like "0,2,4,5,7" represented which plugins were included by their index numbers. This worked, but I started noticing some problems as the data grew.

The Breakthrough: Bitmasks for Efficiency

That's when I had a realization: this is a perfect use case for bitmasks. Since I only have 14 plugins (numbered 0-13), each combination can be perfectly represented as a 14-bit number.

// Convert plugin combination to bitmask
function combinationToBitmask(combination) {
  let bitmask = 0;
  for (const plugin of combination) {
    const pluginIndex = exportKeyMap[plugin];
    bitmask |= 1 << pluginIndex;
  }
  return bitmask;
}

Let me show you a real example. The combination "0,2,4,5,7" becomes:

Plugin 0: 1 << 0 = 1    (binary: 00000000000001)
Plugin 2: 1 << 2 = 4    (binary: 00000000000100)
Plugin 4: 1 << 4 = 16   (binary: 00000000010000)
Plugin 5: 1 << 5 = 32   (binary: 00000000100000)
Plugin 7: 1 << 7 = 128  (binary: 00000010000000)

Final bitmask: 1 + 4 + 16 + 32 + 128 = 181
Binary: 00000010110101

So instead of storing "0,2,4,5,7": 4299, I now store "181": 4299. Much more efficient!

The Results: Transparency in Action

After running my analysis pipeline on all 16,384 combinations, here's what I can now tell users with complete confidence:

Bundle Size Distribution:

Base size (no plugins): 3,564 bytes
Single plugin average: ~3,600-3,650 bytes (+36-86 bytes)
Two plugins average: ~3,650-4,200 bytes
Complex combinations: Up to 5,200+ bytes for feature-heavy setups

Most Efficient Combinations:

+18 bytes (+1%): [disabled]
+44 bytes (+1%): [applyUserSelectHack]
+50 bytes (+1%): [ignoreMultitouch]
+59 bytes (+2%): [axis]
+83 bytes (+2%): [grid]

Now when someone asks "What's the bundle cost of using neodrag with bounds checking and grid snapping?", I can give them an exact answer: 4,291 bytes compressed. Not an estimate. Not "around 4KB". The actual number.

The Lookup Implementation

I needed to maintain backward compatibility with my existing API, so I created a lookup function:

function find_combination_size(plugin_keys) {
  // Convert plugin indices to bitmask
  let bitmask = 0;
  for (const key of plugin_keys) {
    const plugin_index = parseInt(key);
    if (!isNaN(plugin_index)) {
      bitmask |= 1 << plugin_index;
    }
  }

  // Convert bitmask to string key for lookup
  const lookup_key = bitmask.toString();

  // Look up the exact combination
  if (lookup_key in sizes_data.sizes) {
    return sizes_data.sizes[lookup_key];
  } else {
    // Return base size as fallback
    return sizes_data.sizes['0'] || 0;
  }
}

// Usage remains simple!
find_combination_size(['0', '2', '4']); // → exact bundle size in bytes

Why This Matters

Building this analysis system wasn't just about showing off technical prowess. It's about respect for developers and their users. When you add a library to your project, you're making a commitment to everyone who will download your app. They deserve to know what they're getting.

The bitmask approach also gave me impressive technical benefits:

Memory: 78% smaller keys ("0,2,4,5,7" → "181")
Performance: O(1) array access instead of string parsing
Scalability: The system handles all 16,384 combinations efficiently

But the real win is transparency. No more guessing about bundle sizes. No more "it depends" answers. Just honest, precise numbers that help developers make informed decisions.

The Bigger Picture

This level of analysis might seem excessive for a drag-and-drop library, but I believe it represents where the JavaScript ecosystem should be heading. Users on mobile networks, developers optimizing for Core Web Vitals, teams trying to keep their bundles lean - they all deserve better than vague size estimates.

The full analysis now runs in about 30 minutes on modern hardware and gives users precise bundle size information for any plugin combination they choose. It's been a game-changer for neodrag v3's developer experience and reflects my commitment to radical transparency about performance costs.

neotraverse: unbloating traverse

PuruVJ — Thu, 11 Jul 2024 12:30:30 +0000

NPM: npmjs.com/package/neotraverse

GITHUB: github.com/puruvj/neotraverse

You might have heard of traverse. It's a package that allows you to traverse an object and execute a callback function on each property. It is quite a famous package, with over 8.5MILLION downloads per week. Oof thats a lot of downloads.

Recently, the author who took over the package released a patch update(0.6.8 -> 0.6.9), which increased its bundle size from 1.5KB to a whopping 18KB. All in a single patch update. How did that even happen? I'll explain in this post.

Until 0.6.8, traverse had no dependencies. It was a simple package with a single file. It was owned by a user named James Halliday, also known as substack. He recently deleted his entire github account around 0.6.7(Or so I've been told). It went to the new author, and he added some needed features to 0.6.8. However, 0.6.9 added 3 dependencies. Just 3. It may not seem a lot, but there's an insane entanglement of dependencies in this package, which is enough to make someone quit webdev entirely. Here it is:

Source: @passle_

First graph is 0.6.8, second is 0.6.9. Just look at that graph, its scary. And what's messed up more, is that some of these transitive dependencies lead back to a dependency up in the chain, causing circular dependencies. Can this cause npm to download multiple versions of the same package? I don't know for sure, but it's not a good thing either way. Circular dependencies and references some of the hardest things to reason about in software engineering after caching and naming.

It's like a Christopher Nolan movie, just not as entertaining 😄

Deeper issue

Go to index.js, hit CMD + F and search for TODO:. What you will see will scare you.

The comments are scattered through, so I'll just copy and consolidate all the lines here for you to see:



// TODO: use call-bind, is-date, is-regex, is-string, is-boolean-object, is-number-object
// TODO: use isarray
// TODO: use for-each?
// TODO: use object-keys
// TODO: use reflect.ownkeys and filter out non-enumerables
// TODO: use object.hasown

6 comments, and 11 dependencies mentioned. 11. Means the author already had planned to inject more of his dependencies. And yes, a simple search will tell you that the current author is the author of all these libraries as well.

This stuff makes feel unsettled. As a web developer and npm publisher with more than 100,000 downloads per month, I'm not sure if I should be doing this. No one should be doing this. I strive to keep my packages as small as possible, and aggressively aim to have zero dependencies. And these comments signify that this package isn't getting any lighter.

So I decided to take things into my own hands.

neotraverse

Introducing neotraverse, a fork of traverse.

Zero dependencies
1.54KB min+brotli
Built-in types. Say bye to @types/traverse
ESM-first
Legacy mode for drop-in replacement
Aggressively modern

Installation



npm install neotraverse

Usage



import { Traverse } from 'neotraverse';

const obj = {
  a: 1,
  b: 2,
  c: {
    d: 3,
    e: 4,
    f: {
      g: 5,
      h: 6,
      i: {
        j: 7,
        k: 8,
      },
    },
  },
};

new Traverse(obj).forEach(function (value) {
  console.log(value);
});
// Output: 1, 2, 3, 4, 5, 6, 7, 8

API is identical to what it was before, except traverse is a class now: new Traverse(obj).

Legacy mode

If you have too many instances of traverse in your codebase or you're running on an older version of NodeJS without ESM support, you can use the legacy mode.

ESM:



import traverse from 'neotraverse/legacy';

CommonJS:



const traverse = require('neotraverse/legacy');

const obj = {
  a: 1,
  b: 2,
  c: {
    d: 3,
    e: 4,
    f: {
      g: 5,
      h: 6,
      i: {
        j: 7,
        k: 8,
      },
    },
  },
};

traverse(obj).forEach(function (value) {
  console.log(value);
});

// identical to the above
traverse.forEach(obj, function (value) {
  console.log(value);
});

// Output: 1, 2, 3, 4, 5, 6, 7, 8

Behind the scenes

There are some internal tooling changes:

Fully TypeScript. That includes source code and tests
pnpm instead of npm.
Vitest instead of tape(Which also is the current author's package 😅)
tsup. No build step before, now it's needed for typescript and multiple targets.
Remove eslint. Not a fan of linters, but that's for another day.

Attempt 1: Blindly converting to TypeScript

I tried converting the code to TypeScript, but there was a big flaw in this plan: non-typescript files don't usually adhere to strict structures, which means typescript will just throw errors. So naturally, I used my judgement to replace non-working code with working TS code. Problem is, the tests weren't passing afterwards.

Your own assumptions aren't always right.

Attempt 2: Test-driven development

I don't write many tests, but in this case, the existing test suite helped a lot.

After the first attempt had failed, I went with a bottom-up approach. I converted all the tests over to Vitest, and removed all the new TypeScript code in favor of the same old JS code. This made the entire file go red with TypeScript errors, but that was irrelevant at that time.

Then i ran vitest. The nice thing about it is that it runs in watch mode by default. Which means, everytime I change my source file, it runs all the tests again, and it takes less than 1second to run all the tests. It was literally Test driven development.

Targeting the dependencies

The 3 dependencies responsible for the entire havoc in the first place: gopd, typedarray.prototype.slice, which-typed-array.

I deleted them all and replaced them with their native equivalents.

gopd -> Object.getOwnPropertyDescriptors
typedarray.prototype.slice -> TypedArray.prototype.slice
which-typed-array -> ArrayBuffer.isView(value) && !(value instanceof DataView);

which-typed-array doesn't have a direct equivalent in new code because it was ultimately used to check if an object was a TypedArray, the type of the array wasn't used at all

After this I noticed some tests were failing, so I tweaked the implementations here and there until they were fixed.

Aggressively typescript

Now I started to work on types. I added in types, started getting rid of legacy checks until most of the file was properly typed. This didn't cause any test failures thankfully.

function constructor to Class

The code for traverse function was a class but in pre-es2015 style, which is not even a class:



function Traverse(obj) {
  // OMITTED FOR BREVITY
}

Traverse.prototype.get = function (ps) {
  // OMITTED FOR BREVITY
};

Traverse.prototype.has = function (ps) {
  // OMITTED FOR BREVITY
};

I took this opportunity to rewrite the codebase to ES2015 style, which is a class:



export class Traverse {
  constructor(obj) {
    //  OMITTED FOR BREVITY
  }

  get(ps) {
    //  OMITTED FOR BREVITY
  }

  has(ps) {
    // OMITTED FOR BREVITY
  }
}

Top it off, I also provide traverse(a function which is a wrapper around the class) as the default export, so you can use it as a drop-in replacement.



function traverse(obj, options) {
  return new Traverse(obj, options);
}

And ofc, traverse also supports methods on function constructors, so you can do this:



const traverse = require('neotraverse');

traverse.forEach(obj, function (value) {
  console.log(value);
});

Enabling this was simple:



const traverse = (obj: any, options?: TraverseOptions): Traverse => {
  return new Traverse(obj, options);
};

traverse.get = (obj: any, paths: PropertyKey[], options?: TraverseOptions): any => {
  return new Traverse(obj, options).get(paths);
};

traverse.set = (obj: any, path: string[], value: any, options?: TraverseOptions): any => {
  return new Traverse(obj, options).set(path, value);
};

traverse.has = (obj: any, paths: string[], options?: TraverseOptions): boolean => {
  return new Traverse(obj, options).has(paths);
};

traverse.map = (
  obj: any,
  cb: (this: TraverseContext, v: any) => void,
  options?: TraverseOptions,
): any => {
  return new Traverse(obj, options).map(cb);
};

As you can see, each method initializes the class again, which is a huge overhead, but for compatibility, it's is supported. Avoid using it if you can.

This is a huge change, but it's worth it.

Backwards compatibility

This library will provide a direct legacy mode, which is CJS, and ES5 syntax, so it supports a lot of the older environments as well old Node versions.

For this I have a legacy.cts file which exports only traverse function, and nothing else. Not even the types.



const traverse = require('./index.ts');
module.exports = traverse.default;

All the compilation of new features into old ones is done internally by @swc/core, which is a very fast compiler. Luckily its all built-in into tsup, which is the build tool I use for every single package I publish and cannot recommend it enough.

Conclusion

This package will always be compatible with the latest version of traverse. Period. There are multiple packages already that do the same, but folks who still use it would prefer to not change their codebase. And I respect that.

If you or your company intentionally use traverse, I urge you to migrate to this package. We've seen the author's intention to bloat this up more and more, whereas I promise that neotraverse will forever be a 0 dependency modern yet backward compatible package.

Lastly, I intentionally did not keep my FUNDING.yml file in this repo, which is the first thing previous author did when he took over traverse, so if you want to support me, the link is: Github Sponsors

Peace ✌️

perf: private count vs #count

PuruVJ — Fri, 05 Jul 2024 10:28:53 +0000

Which one is faster: private count or #count?

If you are a JavaScript developer, you might have heard about the concept of private and public properties in JavaScript. JavaScript only had public properties until 2019, until Chrome shipped the Private Class Fields feature.

class Person {
  #name: string;
  age: number;
}

TypeScript has had public and private properties since forever:

class Person {
  private name: string;
  public age: number;
}

As you can see, it's not as compact as JS version, but it works well. But what are the differences between the two? How do TypeScript's private properties work?

TypeScript lies

TypeScript lies to you. The private property is not actually private. It's invisible, not inaccessible. TypeScript will mark the property as private, but it can not prevent you from accessing it.

Input:

class Person {
  private name: string;
  public age: number;

  constructor() {
    this.name = 'Harry';
    this.age = 17;
  }
}

JS Output:

'use strict';
class Person {
  constructor() {
    this.name = 'Harry';
    this.age = 17;
  }
}

Declaration(d.ts) output:

declare class Person {
  private name;
  age: number;
  constructor();
}

There is nothing stopping anyone from accessing person.name. Sure there will be red squiggles in the editor, but it can be bypassed.

An excerpt from Harry Potter to understand it better:

Snape’s eyes were fixed upon the door. His nostrils flared. He was walking slowly toward it, his wand held out in front of him like a weapon.

“Potter,” he breathed, his eyes narrowing, “I know you’re here. You can’t hide forever.”

Snape took another step forward, his free hand outstretched, fingers splayed, as though he could almost sense Harry’s presence through the cloak. Harry held his breath, trying to remain as silent and still as possible while Snape’s hand moved closer and closer, searching the air just inches from his face.

What is the actual performance difference?

We know TypeScript lies. So what? There is no performance difference. Right? Right???

TLDR: There is no performance difference for ~~most~~ any practical use case. Literally none. Go use JS private properties(#count) over private count in TypeScript, it's more robust.

However if you wanna hang around to see how I reached that conclusion and when there actually is a performance difference, then you can read on.

Setting up benchmark

We'll use an extremely simple benchmark to see the performance difference. Plain vanilla JS.

How are you going to emulate TypeScript private properties in JS?

Easy: TypeScript private properties are just JS public properties. In fact, I also lied to you. This post isn't a difference between private count vs #count in JS. It is a difference between public and private properties in JS. Plain and simple.

class Something {
  #a = 1;
  #b = 2;

  a = 4;
  b = 2;

  constructor() {
    const start_time = performance.now();
    for (let i = 0; i < 1_000_000; i++) {
      this.#a + this.#b;
    }
    console.log('Private:', performance.now() - start_time);

    {
      const start_time = performance.now();
      for (let i = 0; i < 1_000_000; i++) {
        this.a + this.b;
      }
      console.log('Public:', performance.now() - start_time);
    }
  }
}

Pretty simple, right? We're just creating a class with two public and two private properties, and then we're timing how long it takes to access them a million times.

Executing this is one line:

new Something();

And this is it. I pasted this directly into Chrome Devtools console, and it gives me this:

Private: 3.4000000059604645
Public: 2.300000011920929

So private property access is 1.47x slower than public property access. That's it. It may seem a lot but don't forget, we're accessing them a million times. If I run it for only 1000 times, then the output is this, most of the time:

Private: 0
Public: 0

It's so fast there's no difference calling it a thousand times, and in most prod apps it will be called just a few times.

There's more: Caching

The above is the result on first run, means the class instance is created for the first time and Browser hasn't cached the class yet. But what if we run it a few more times and see how cache affects the result?

new Something(); // Repeat this line 10 times
new Something();
new Something();
new Something();
new Something();
new Something();
new Something();
new Something();
new Something();
new Something();

And this is the result:

Private: 3.7000000029802322
Public: 0.6000000089406967

Private: 0.7000000029802322
Public: 0.699999988079071

Private: 0.800000011920929
Public: 0.5

Private: 0.8999999910593033
Public: 0.5

Private: 0.7999999970197678
Public: 0.5999999940395355

Private: 0.7000000029802322
Public: 0.5999999940395355

Private: 0.7000000029802322
Public: 0.6000000089406967

Private: 0.5999999940395355
Public: 0.6000000089406967

Private: 0.7000000029802322
Public: 0.5

Private: 0.7000000029802322
Public: 0.5

The very first time, the browser cached public property access, making it almost 6.2x faster than (correspondingly) private property access. But the rest of the time, public properties are cached well enough such that there are multiple instances of 0.5.

Private properties are always a bit slower even when cached, in fact most of the time its 1.4-1.5x slower, in line with uncached benchmark above.

I bet this is because browser has to keep track of checks for private properties to deny any external access to them. It's like building a backend. A backend may be cached really really well in Redis, but every request requires checking authentication adds some overhead.

Conclusion

There is no performance difference for ~~most~~ any practical use case. Literally none. Go use JS private properties(#count) over private count in TypeScript, it's more robust.

Peace ☮️

Jotai: The ultimate React State Management

PuruVJ — Mon, 29 Nov 2021 11:40:24 +0000

Jotai is a relatively new state management library for React. It's simple, but make no mistakes, it's a robust library.

Jotai is based on the new Recoil pattern and library by Facebook. More than half a decade ago, Facebook created a pattern and library for state management in React called Flux .

On this pattern, some non-Facebook devs created a new library of their own that was more robust, simpler to use, and took the React world by storm. This library is Redux . Now Facebook has Recoil, which has different ideologies than Flux.

The same is the case with Jotai and Redux. Let's explore some of these.

Why Jotai?

Minimalistic API - Jotai has a simple API design and is a joy to work with.
Tiny bundle size - Jotai's footprint is really small and won't be a performance block in your site/app
Loaded to the brim - Jotai comes with a lot of
Performant - Jotai is BLAZING FAST. It's runtime performance is insane!
TYPESCRIPT!! 🥳🥳 - First class TypeScript Support!! Comes with Typings pre-installed, and TypeScript authoring experience is beyond heavenly.

Ideological differences from Redux

Jotai is very different from Redux and React Context API in almost every way. But there's one central concept that is the catch-all—the one that you need to internalize.

Redux stores are monolithic, but Jotai is atomic.

This means, in Redux, it's a pattern to store all the needed global state in the app in one single big object. In Jotai, it’s the opposite. You break your state into atoms i.e. - one store for one single store, or for closely related state.

Getting started with Jotai

Installing Jotai

# pnpm
pnpm add jotai

# npm
npm install jotai

# Or if you're a yarn person
yarn add jotai

Setting it up in the app

Jotai requires a provider to be present in the parent of the current component where it is being used. The simplest way to do would be to wrap the whole app in the provider as shown below 👇

// index.jsx (or index.tsx)
import React from 'react';
import ReactDOM from 'react-dom';
import { App } from './App';

// Jotai provider
import { Provider } from 'jotai';

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

Now you can use jotai anywhere in your app!

Basic syntax

Now that our basic setup is done let's have a look at the syntax!

Creating your first atom

Atoms are the building blocks of universe and clump together into molecules--

No, not that atom 😅.

Jotai atoms are small isolated pieces of state. Ideally, one atom contains very small data (although it's just a convention. You could still put all your state in one atom, though that would be very slow performance-wise).

So here's how you create your first atom

import { atom } from 'jotai';
const themeAtom = atom('light');

And that's it! You have your very first piece of state in!!

Notice I suffixed my atom name with Atom, as in themeAtom. It's not a rule or an official convention., I simply choose to name my atoms like this for clarity in a big project. You can name it just theme rather than themeAtom 🙂

Now, how do you use it? Well, using it is a cross between the useState and useContext hooks.

import { useAtom } from 'jotai';

export const ThemeSwitcher = () => {
  const [theme, setTheme] = useAtom(themeAtom);

  return <main>{theme}</main>;
};

See? Exactly like useState, but the only difference is that the atom we created is to be passed to useState. useAtom returns an array of size 2, where the 1st element is a value and the 2nd element is a function, to set the value of the atom. This makes all the components relying on this atom update and re-render.

So, if we put it all together, the complete code would look like this 👇

import { atom, useAtom } from 'jotai';

const themeAtom = atom('light');

export const ThemeSwitcher = () => {
  const [theme, setTheme] = useAtom(themeAtom);

  return <main>{theme}</main>;
};

And notice the setTheme isn't used yet. Let's change that 👇

import { atom, useAtom } from 'jotai';

const themeAtom = atom('light');

export const ThemeSwitcher = () => {
  const [theme, setTheme] = useAtom(themeAtom);

  return (
    <main>
      <p>Theme is {theme}</p>

      <button onClick={() => setTheme(theme === 'light' ? 'dark' : 'light')}>Toggle Theme</button>
    </main>
  );
};

Check it out @ CodeSandbox

This, my friend, is just the beginning. Jotai can do so much more!

But this alone doesn't give much perspective. What's special about a button that toggles a value 🙄? And I agree. This example is pretty boring. Let's use Jotai to make an actual theme switcher.

Jotai In Practice: Theme Switcher hook

Nowadays, theme switching is needed in every single app, website, and heck, even blog sites (Especially blogs). And it can be quite daunting to make a theme switcher. First, you have to set up your CSS Variables. Then you have to start with a theme, post which you have to make a button that switches the theme. Then you have to make sure to remember the preference using localstorage API. But that brings you full circle to picking up the right value when the page loads, and also not messing with SSR and prerendering and...

Yeah, it's pretty complicated. A problem any developer would dread before attempting (I did 🥶).

So, that's the best kind of thing to make, and let's use Jotai to do it. You'll be astonished at how simple Jotai can make it.

So, here are our goals:

Works on server side (As in not referring to document or window without protection).
Picks up locally stored value in localstorage.
If no local value, tries to get the device preference, whether the device theme is light or dark.
Current theme should be available as a state that re-renders components it is being used in.
Changing the state should update localstorage accordingly.

So now that our list is complete, let's look at the code 👇

import { atom, useAtom } from 'jotai';
import { useEffect } from 'react';

const browser = typeof window !== 'undefined';

const localValue = browser ? localStorage.getItem('theme') : 'light';
const systemTheme =
  browser && matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light';

// The atom to hold the value goes here
const themeAtom = atom(localValue || systemTheme);

/** Sitewide theme */
export function useTheme() {
  const [theme, setTheme] = useAtom(themeAtom);

  useEffect(() => {
    if (!browser) return;

    localStorage.setItem('theme', theme);

    document.body.classList.remove('light', 'dark');
    document.body.classList.add(theme);
  }, [theme]);

  return [theme, setTheme];
}

A lot going on here. So here's the breakdown.

We check whether the current code is running in the browser or not. If we're running the code in SSR or prerendering, this value will be false.

We get the value stored in localstorage. If localstorage has the theme in it, then we'll consider it the highest priority, as it would be the one chosen by the user. Also, because there's no localstorage in Node, we have to fallback to the default value of light if it's running in the SSR mode.

We also retrieve the device preference using prefers-color-scheme: dark, in case the localstorage value doesn't exist. Again, this falls back to value light if device preference is dark or code is running in SSR.

Finally, create the atom. This will be our main store where we actually store the current theme, usable and changeable as state. Notice the value we give it: localValue || systemTheme. Here's what can happen with these values:

If running in SSR/Prerendering mode, localValue = 'light' and systemTheme = 'light', localValue || systemTheme will turn out to be light. So, important point here: Your app in SSR will be themed with light theme, so if you prerender your app, it will end up with light theme, in terms of plain HTML. As the JavaScript loads, it will sync to the most relevant theme possible.

Why didn't I just put the localValue and systemTheme variables inside the hook? The reason: If I put them in the hook, everytime the hook is initialized in any component, or a component re-renders, this hook will run again, and will fetch these values again from localstorage and media queries. These are pretty fast, but localstorage is blocking, and when used a lot, can introduce jank. So we initialize these 2 vars once in the lifetime of the app, because we need these only to get the initial value.

Finally, let's begin our hook:

Let's make this atom a local state using useAtom: const [theme, setTheme] = useAtom(themeAtom);. These will be our theme in the form of state. Themes can be modified using setTheme.

Next thing, we got the most important part of our hook that will actually make the current theme known to our CSS.

useEffect(() => {
  if (!browser) return;

  localStorage.setItem('theme', theme);

  document.body.classList.remove('light', 'dark');
  document.body.classList.add(theme);
}, [theme]);

It's useEffect that runs whenever theme changes, as you can see in the array in the 2nd argument. When this runs, it checks if the code is running in the browser. If it isn't, it simply stops further execution by doing a return.

If it is successful, it goes on and removes all the classes corresponding to put themes on <body>, then it adds the class corresponding to the latest value of theme variable.

Finally, we return the [theme, setTheme] pair as it is, so we can use it just like we use useState. You could also return these as objects { theme, setTheme } giving them explicit naming.

This is it for this hook.

And I got my TypeScript kin covered too 😉👇

import { atom, useAtom } from 'jotai';
import { useEffect } from 'react';

export type Theme = 'light' | 'dark';

const browser = typeof window !== 'undefined';

const localValue = (browser ? localStorage.getItem('theme') : 'light') as Theme;
const systemTheme: Theme =
  browser && matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light';

// The atom to hold the value goes here
const themeAtom = atom<Theme>(localValue || systemTheme);

/** Sitewide theme */
export function useTheme() {
  const [theme, setTheme] = useAtom(themeAtom);

  useEffect(() => {
    if (!browser) return;

    localStorage.setItem('theme', theme);

    document.body.classList.remove('light', 'dark');
    document.body.classList.add(theme);
  }, [theme]);

  return [theme, setTheme] as const;
}

So this is the final code we got for switching themes robustly. This hook is simple and understandable (I hope 😅), due to the simplicity of Jotai.

But here's the thing. We haven't saved much code using Jotai compared to using the Context API. That code would be almost this simple, just have a little more boilerplate. So there really isn't much difference here.

But, here comes a twist: We can get rid of even more code by using something that Jotai provides: atomWithStorage

We can move the logic of syncing to localstorage completely, both from inside the hook as well as outside.

Rewriting the hook with atomWithStorage

atomWithStorage is a special kind of atom that automatically syncs the value provided to it with localstorage or sessionStorage (Or AsyncStorage, if used with React Native), and picks the value upon the first load automatically! It's available in the jotai/utils module, and adds some bytes other than the 2.4KB of Jotai Core.

So here's how we would rewrite it:

import { useAtom } from 'jotai';
import { atomWithStorage } from 'jotai/utils';
import { useEffect } from 'react';

const browser = typeof window !== 'undefined';

// The atom to hold the value goes here
const themeAtom = atomWithStorage(
  'theme',
  browser && matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light',
);

/** Sitewide theme */
export function useTheme() {
  const [theme, setTheme] = useAtom(themeAtom);

  useEffect(() => {
    if (!browser) return;

    document.body.classList.remove('light', 'dark');
    document.body.classList.add(theme);
  }, [theme]);

  return [theme, setTheme];
}

As you can see, we completely got rid of localstorage from the code, and we have a new thing atomWithStorage. First argument is the key to store it in localstorage. As in, if you specified theme as value here, you would retrieve it from localstorage using localstorage.getItem('theme').

As you can see, the code itself isn't much smaller in terms on lines of code. It's just 20% smaller, which isn't a big number in case of this already-small file. The main part here is that we got to hide the complexity away thanks to atomWithStorage. Now we don't have to keep the local value storage in mind, just have to focus on our main logic and remember that this value is synchronized locally, and that's it.

And using this hook ultimately is super simple,

import { useTheme } from './use-theme';

export const ThemeSwitcher = () => {
  const [theme, setTheme] = useTheme();

  return (
    <main>
      <p>Theme is {theme}</p>

      <button onClick={() => setTheme(theme === 'light' ? 'dark' : 'light')}>Toggle Theme</button>
    </main>
  );
};

And it just works!! 🪄

More about Jotai

So this was the basic intro to Jotai. I added in the atomWithStorage utility function to show how powerful and simple it can make your code. I will touch on these utilities later on. For now, let's explore more about the basic atom and useAtom, and how they give you superpowers.

Derived atoms

Sometimes, you want to make an atom rely on another atom(s), meaning -you want to compose multiple atoms together into one big computed atom. That is extremely simple with Jotai.

Readonly atoms

Readonly atoms are derived atoms that rely on other atoms, and we can't change their values directly.

For example, these atoms' usage would be as follows 👇

const [derivedValue] = useAtom(derivedAtom);

There's no setDerivedValue here, no setter function. We can only read this atom. Changing the atoms it is derived from will automatically update this value.

But enough talk! Now let's see how to create these derived atoms.

You have seen this atom until now 👇

const store = atom('someValue');

But guess what? Atoms can take a function as a parameter 👇

const store = atom((get) => get(someAtomDefinedSomewhere));

Here, instead of a raw value, we pass a callback. This callback has a parameter get, which allows you to access the raw, live values of other atoms. With this raw value, you can do anything. Multiply it, concatenate it, map it, reduce it, whatever. The sky’s the limit.

And you can do a lot more with this. For example, one simple example would be to have a list of all the keys of an object that match a specific criteria to be in an array.

Here's the object

export const appsStateStore = atom({
  finder: false,
  launchpad: false,
  safari: false,
  messages: false,
  mail: true,
  maps: true,
  photos: false,
  facetime: true,
  calendar: false,
});

Define the atom that will hold the open apps in an array 👇

const openAppsStore = atom((get) => {
  const apps = get(openAppsStore); // Gives the raw value { finder: false, launchpad: false, ...

  // Filter out the values who are marked as false
  const openAppsList = Object.keys(apps).filter((appName) => apps[appName]);

  return openAppsList;
});

And this is it!! As you tweak the values in the appStateStore, setting them to true and false, the openAppsStore will reflect the changes and the components using this store will also be updated with new values.

You can also compose together many different atoms together 👇

const xCoordinateAtom = atom(0);
const yCoordinateAtom = atom(0);

// Compose 'em all
const distanceFromOriginAtom = atom((get) =>
  Math.sqrt(get(xCoordinateAtom) ** 2 + get(yCoordinateAtom) ** 2),
);

You can tweak the xCoordinateAtom atom and yCoordinateAtom, and the distanceFromOriginAtom will update with the new values!!)

It's a mathematical formula to calculate the distance of a point from the origin (0, 0). If you didn't get it, no worries, I just want to get the point across that you can compose together different atoms seamlessly. That's it! 🙂

Readable & Writable atoms

These are atoms that are derived from other atoms, but can also be modified on their own by the user.

const readWriteAtom = atom(
  (get) => get(priceAtom) * 2,
  (get, set, newPrice) => {
    set(priceAtom, newPrice / 2);
    // you can set as many atoms as you want at the same time
  },
);

This atom, when you set its value, triggers the custom write function we provide, and can modify the atoms it relies on. It's basically two-way data binding. You change priceAtom, this readWriteAtom gets updated. You update readWriteAtom, priceAtom gets updated. Mindblowing, right 🤯🤯?!?

Beware though: As magical as this seems, it's two-way data binding. There have been controversies in the past about it, and rightfully so, as debugging and keeping the flow of data sane becomes extremely hard with these. That's why React itself has only one-way data binding. So use this atom carefully.

Async Atoms

From this point, we enter a very dangerous territory: Async rendering, aka React Suspense.

Sometimes your atoms have to be asynchronous, that is, rather than getting values instantly, they pull from a remote source using fetch, which is when you have to suspend the rendering and wait for the data to come back.

Here's a little code demonstration of using async atom 👇

const fetchCountAtom = atom(
  (get) => get(countAtom),
  async (_get, set, url) => {
    const response = await fetch(url);
    set(countAtom, (await response.json()).count);
  },
);

function Controls() {
  const [count, compute] = useAtom(fetchCountAtom);
  return <button onClick={() => compute('http://count.host.com')}>compute</button>;
}

But this above won't work if you don't wrap Controls in a Suspense 👇

<Suspense fallback={<span />}>
  <Controls />
</Suspense>

Async Atoms are extremely useful in building real world apps, because these apps are mostly CRUD apps with data fetching added in.

The Best of Utils

If you loved atomWithStorage and your head is spinning with all the possibilities it could unlock, I got many more awesome Jotai utils for you.

atomWithStorage

I covered this one in the very beginning of the article when I refactored the useTheme hook to use this special atom. It accepts a key (The name by which it is stored in localstorage), and the initial value. Then you change this atom, and its value will be persisted locally and picked up after the page reloads.

import { atomWithStorage } from 'jotai/utils';

const darkModeAtom = atomWithStorage('darkMode', false);

This atom is also SSR friendly, so you can SSR your app away with absolutely no issues.

This atom can store value in sessionStorage too, so the atom's value will be persisted until the browser is closed. Handy if you're building a banking web app, where having short sessions is preferable.

It also works with React Native, so it's pretty much universal 🤩

atomWithReset

Sometimes you need to reset your state to what it was originally. Traditionally, the way to do that has been to store the initial value in a variable, create a state with that variable as the value, and when needed, setState back to that initial value. The code would look like this 👇

import { atom, useAtom } from 'jotai';

const initialValue = 'light';

const themeAtom = atom(initialValue);

function ThemeSwitcher() {
  const [theme, setTheme] = useAtom(themeAtom);

  const toggleTheme = () => setTheme(theme === 'light' ? 'dark' : 'light');
  const resetTheme = () => setTheme(initialValue);

  return (
    <>
      <button onClick={toggleTheme}>Toggle theme</button>

      <button onClick={resetTheme}>Reset theme</button>
    </>
  );
}

This is fairly easy, but here's a more Jotai-ish way of doing the same thing 👇

import { useAtom } from 'jotai';
import { atomWithReset, useResetAtom } from 'jotai/utils';

const themeAtom = atomWithReset('light');

function ThemeSwitcher() {
  const [theme, setTheme] = useAtom(themeAtom);
  const reset = useResetAtom(themeAtom);

  const toggleTheme = () => setTheme(theme === 'light' ? 'dark' : 'light');

  return (
    <>
      <button onClick={toggleTheme}>Toggle theme</button>

      <button onClick={reset}>Reset theme</button>
    </>
  );
}

As you can see, we simplified our component a little. Not much, in this case, as it's a very simple example. But I personally have used this reset atom in my apps with full blown complex logic based components, and it just makes the code much more sane, idiomatic, and bug-free.

selectAtom

If there was a coolness counter for libraries and frameworks, Jotai alone would've broken it with this little util.

Let’s consider you have a big object.

const defaultPerson = {
  name: {
    first: 'Jane',
    last: 'Doe',
  },
  birth: {
    year: 2000,
    month: 'Jan',
    day: 1,
    time: {
      hour: 1,
      minute: 1,
    },
  },
};

// Original atom.
const personAtom = atom(defaultPerson);

And say, a lot of components rely on this specific atom, but need only parts of this.

The thing is when you update this atom, all the components relying on this atom will rerender. Even if you change just the birth.time.minute, the whole thing is going to count as an update and all the components will re-render. This is how React works, unfortunately.

But worry not, for Jotai has a solution for this too! selectAtom allows you to create a derived atom with only a subpath of the whole object.

const firstNameAtom = selectAtom(personAtom, (person) => person.name.first);

firstNameAtom is a read-only derived atom that only triggers when the person.name.first property changes, and it holds the value of person.name.first.

You can update the birth.time.hour field(By updating the whole atom with new values), and the component relying on firstNameAtom will remain unchanged. Amazing, right?

Applying on Objects

There arises a problem: If you listen to a field that is an object, person.birth, this atom isn't gonna be very efficient. Jotai uses the equality check(===) to check if the atom's part is changed or not and should be re-rendered. The thing is, no 2 objects are ever the same. The === checks objects by reference, not values. So basically, this atom is pretty useless in that scenario. But not quite!

You can provide a 3rd argument to this selectAtom, which is your own version of an equality check. You can write your custom function to check the objects.

const birthAtom = selectAtom(personAtom, (person) => person.birth, deepEqual);

OFC, writing your own deepEqual is hard, so it's recommended to go with lodash-es's isEqual function.

import { isEqual } from 'lodash-es';

const birthAtom = selectAtom(personAtom, (person) => person.birth, isEqual);

If seeing lodash gives you anxiety about bundle size, I assure you, isEqual of lodash-es is tree-shakeable, just 4.4KB minified, and even smaller in gzip/brotli. So no worries 😁

This can take the performance of your app from zero to hero. Literally!

freezeAtom

import { atom } from 'jotai';
import { freezeAtom } from 'jotai/utils';

const objAtom = freezeAtom(atom({ count: 0 }));

freezeAtom takes an existing atom and returns a new derived atom. The returned atom is "frozen" which means when you use the atom with useAtom in components or get in other atoms, the atom value will be deeply frozen with Object.freeze. It would be useful to find bugs where you accidentally tried to mutate objects which can lead to unexpected behavior.

This atom is mostly for debuggability, for when you mutate an object state(which you aren't supposed to do in React, but hey, we're all humans). This is such a common case, that I'm really glad Jotai folks are providing such high quality debugging tools.

waitForAll

Remember the section above about Async atoms? This util is for that, and quite a handy one it is.

const dogsAtom = atom(async (get) => {
  const response = await fetch('/dogs');
  return await response.json();
});

const catsAtom = atom(async (get) => {
  const response = await fetch('/cats');
  return await response.json();
});

const App = () => {
  const [dogs] = useAtom(dogsAtom);
  const [cats] = useAtom(catsAtom);
  // ...
};

So you have these 2 async atoms, and you're using them in the app. All fine. But there's a little problem here: The component will wait for the first atom dogsAtom to go fetch data, return, then it will move to the next atom catsAtom. We don't want this. Both these atoms are independent of each other, we should rather fetch them in parallel(Or concurrently if you are a hardcore JavaScripter 😉)

So, we basically want to do something like an await Promise.all(...) on these atoms. The way to do that is using the waitForAll util.

After using, our code becomes 👇

const dogsAtom = atom(async (get) => {
  const response = await fetch('/dogs');
  return await response.json();
});

const catsAtom = atom(async (get) => {
  const response = await fetch('/cats');
  return await response.json();
});

const App = () => {
  const [[dogs, cats]] = useAtom(waitForAll([dogsAtom, catsAtom]));
  // ...
};

Now it waits for both of them to resolve, and then returns an array of the data returned by both. Kind of like an await Promise.all statement.

Literally, at this point, React should absorb Jotai into itself, it's way too good!!

And these are only half of all utils provided by Jotai. There are so many, I'd could write a whole book about it . Head over to Jotai Documentation to learn about em.

Jotai is good with its relatives 🤝

Jotai isn't anything like other libraries. which are like: "You shall only have me in thy package.json!!!"

No, Jotai doesn't work like that! Jotai itself is a great state management library, but it also allows you to seamlessly integrate with other state management libraries.

Here are all the official integrations that come with Jotai:

Immer
Optics
React Query
XState
Valtio
Zustand
Redux
URQL

Now, at this point, the blog post is already way too lengthy to cover the above integrations, but I want to cover Immer. Why? Because of the biggest pain point with React state: Immutability.

Immutability is great, and it makes wrapping your head around React State easy, but it can make things very hard when your state is an object. Then you have to do the whole song and dance of spreading the object and merging with the properties you want to update.

function UpdateUser() {
  const [user, setUser] = useState({
    id: 23,
    name: 'Luke Skywalker',
    dob: new Date('25 December, 19 BBY'),
  });

  // Update the dob
  const updateDob = () => setUser({ ...user, dob: new Date('25 November, 200ABY') });

  return <button onClick={updateDob}>Update DOB</button>;
}

As you can see in the updateDob method, we have to spread the original object, and pass the field we want to update. This is OK. But what if the object is many levels deep and we want to update an object very deep.

It becomes so convoluted that I personally never even tried it. I just re-architected my state to be shallower in some way and then update that. I am more of a Svelte person than a React person, and in Svelte, you can simply mutate the state and it just works.

user.dob = new Date('25 November, 200ABY');

And it goes extremely deep too!

state.depth1.depth2.depth3.depth4 = 'something';

So all the song and dance required in React always felt wrong to me.

But this is where Immer comes in. Immer allows you to directly mutate the state, and it just works. Take a look for yourself

import { atomWithImmer } from 'jotai/immer';

const userAtom = atomWithImmer({
  id: 23,
  name: 'Luke Skywalker',
  dob: new Date('25 December, 19 BBY'),
});

function UpdateUser() {
  const [user, setUser] = useAtom(userAtom);

  // Update the dob
  const updateDob = () =>
    setUser((user) => {
      user.dob = new Date('25 November, 200ABY');
      return user;
    });

  return <button onClick={updateDob}>Update DOB</button>;
}

Here, the setUser works differently. It's a callback that passes you the current value of the state. This value is a copy of the original value. You can mutate this copy as much as you want inside the callback, and finally just return it, Jotai and Immer will automatically reconcile the changes without any of the bugs that come with mutating. Freaking awesome!

Conclusion

Alright!! This was a lengthy article! Congratulate yourself for making it to the end (skimming through counts too 😉).

This article is just a little glimpse of Jotai. There's so much more at Jotai docs. You should definitely check them out.

Peace out✌️

macOS Web: Why I moved from React to Svelte

PuruVJ — Sun, 29 Aug 2021 12:20:11 +0000

Read in light, midday, dark or radioactive theme

macOS is an amazing operating system. It looks really good, works really fast(Thanks to Apple's hardware), is very consistent, and overall an amazing experience.

Personally, I have never been much infatuated with macOS. But that changed last year when macOS Big Sur came out with the super sleek and modern design with those beautiful blurs. I instantly fell in love with it 😍 Just look how beautiful it is 😌

Unfortunately, I couldn't afford to buy the MacBook(You're overpriced, Apple 😑), but I couldn't not want it. I spent weeks just watching review videos and screenshots of it. I am not a designer, but I have a good taste in design, and Big Sur was it! Finally, when the craving became too much, I was like, "Screw it! I'll just make it myself"

So that's what I did 😁 I recreated the interface of macOS Big Sur for Web. You can see it @ macos.vercel.app.

Early days (React)!

I began working on this project back in November 2020, with the stack being React with Snowpack as the bundler+dev server, JSS for styling, and restater for state management, and I created just the topbar(without the opening menus), the animated dock, and the background. Nothing much, really. Quite easy to do. You can visit it here macos-web-mmo5af3r6.vercel.app

The dock animation isn't as smooth as it is in the latest iteration if you look closely. Not to mention, this very simple app is using loads of dependencies. It loaded 146KB min+brotli of JS, and 0KB of CSS(It was CSS-in-JS, so no separate CSS file). For reference, the current version in Svelte loads only 28.5KB of JS, and 3.6KB of CSS, and it does a lot more than the November version.

Here's the package.json dependencies field of the November version 👇

{
  "@material-ui/core": "^4.11.0",
  "@mdi/js": "^5.8.55",
  "@rooks/use-raf": "^4.0.2",
  "@tippyjs/react": "^4.2.0",
  "date-fns": "^2.16.1",
  "framer-motion": "^2.9.4",
  "react": "^17.0.1",
  "react-dom": "^17.0.1",
  "react-helmet-async": "^1.0.7",
  "restater": "0.0.12",
  "use-sound": "^2.0.1"
}

See?! So much stuff for so little!

So this was the state of the app. Then I didn't work on it. I was bored of it. Then I had an accident, broke my spine, was prescribed 3 months bed rest. I was so bored out of my mind, I thought, what the heck, I'll just continue working on it.

So I revived the project, made some heavy changes. Like I threw away restater library to use Jotai, because it was much simpler.

Fast forward two months, I made some drastic changes. I replaced Snowpack(Bundler and dev server) with ViteJS. Why? No specific reason, I just felt it was more polished and had some superb features which I could use to make the app smaller in size.

I replaced the existing JSS style with styled-components. Not perf-related really, just that writing CSS as JS objects wasn't fun.

I also got rid of some dependencies to reduce bundle size.

That brings us to 120KB min+brotli JS. You can see it for yourself: macos-web-git-feat-switch-to-vite-puruvj.vercel.app

I was still not satisfied with it. The app felt slow, the dock animation was janky, menus wouldn't open up instantly. Not satisfactory!

Then, I did something very drastic: I moved the app from React to Preact.

The era of Preact

Yepp!! I did that. I'm crazy that way 😏

Anyways, moving React to Preact was a very smooth experience. I just had to install the official @preactjs/preset-vite Vite plugin by Preact team, and it took care of aliasing react in import React from 'react' to preact/compat and everything. It was very seamless. It just worked. Huge kudos to the Preact team!!

And that, my friend, made all the difference in the world.

The site got fast. Animations lost their jank. Menus opened instantly. Everything just worked!.

And the best part: Bundle size went down by a lot!!. React + React DOM is 42KB. Preact Core + Compat is just 4KB, max!

You can check it out here yourself macos-web-git-feat-move-to-preact-puruvj.vercel.app.

You will find the bundle size is not drastically less here compared to the previous React iteration. That's because I added some dependencies in the period before transitioning.

This was great, but there was one problem: Too many dependencies.

Here's the package.json dependencies field 👇

{
  "@mdi/js": "^5.9.55",
  "@rooks/use-raf": "^4.9.2",
  "@tippyjs/react": "^4.2.3",
  "color2k": "^1.2.4",
  "date-fns": "^2.18.0",
  "framer-motion": "^3.10.0",
  "idb-keyval": "^5.0.4",
  "immer": "^8.0.1",
  "jotai": "^0.15.0",
  "preact": "^10.5.12",
  "prop-types": "^15.7.2",
  "react-helmet-async": "^1.0.9",
  "react-is": "^17.0.1",
  "react-lazily": "^0.9.0",
  "react-rnd": "^10.2.4",
  "react-slider": "^1.1.4",
  "react-sound": "^1.2.0",
  "styled-components": "^5.2.1",
  "styled-reset": "^4.3.4",
  "throttle-debounce": "^3.0.1",
  "tippy.js": "^6.3.1",
  "use-interval": "^1.3.0"
}

This is a lot of dependencies at this point. Doesn't look good, does it? 🤐

Goodbye styled-components 🏳️

So in my quest to make the app smaller and faster, I found styled-components to be one of the roadblocks.

What was the issue with it? Well, first thing, CSS-in-JS is always less performant than just raw CSS(Well written CSS. Bad, duplicated styled don't count 😼). 2nd, styled-components added 12KB bundle size to the app.

And the most important one: The output CSS wouldn't minify.

Generally, when you are writing in .css or .scss files, your CSS is minified completely, that is all spaces and line breaks are removed, making it smaller to send over the wire.

But with styled-components, because I'm writing the CSS inside JavaScript strings, the CSS tooling can't minify it by default, so that CSS remains unminified.

See? All the code is here as it is.

And I couldn't use the babel-plugin-styled-components, as it wouldn't work with Vite, for some reason. And leaving Vite wasn't an option.

So it was then that I decided to move to the basics, CSS Modules (SCSS Modules, to be exact 😉)

So I did that. Took a lot of effort, but the final result was worth it. It took the JS size from around 110KB to 85KB, and the CSS was 3.3KB. This was a huge amount of reduction and made the app feel really fast. The burden of supplying CSS was removed from the JS, and that alone made a lot of difference.

Here's an in-detail write-up of moving to CSS Modules: Why I moved from Styled Components to (S)CSS modules

And, because this process required me to touch the whole project at once, I got the chance to revisit some not-so-good code and improve it, resulting in me getting rid of a lot of dependencies. This is the package.json's dependencies field after this change 👇

{
  "@mdi/js": "^5.9.55",
  "@reach/slider": "^0.14.0",
  "@rooks/use-raf": "^4.10.0",
  "@tippyjs/react": "^4.2.5",
  "clsx": "^1.1.1",
  "date-fns": "^2.19.0",
  "framer-motion": "^4.0.3",
  "idb-keyval": "^5.0.4",
  "immer": "^9.0.1",
  "jotai": "^0.16.0",
  "preact": "^10.5.13",
  "react-rnd": "^10.2.4",
  "tippy.js": "^6.3.1",
  "use-interval": "^1.3.0"
}

That's a lot of reduction compared to the previous iteration.

So all this brings us to the final situation of macOS: Built in preact, styled with CSS Modules, only 85KB loaded at first, and pretty smooth usage.

But me being me, I strived to make it even better. Because there wasn't much scope for radical techniques, I resorted to the ultimate technique: Code Splitting

Go Code splitting!

Implementing Code splitting was very easy. The components that aren't needed on the first load, I split them away into their own separate chunks.

One component where I do code splitting was the AppNexus.tsx. This is basically a gateway to render the right app component when you open any app. This is as easy as 👇

import { AppID } from '__/stores/apps.store';
import { lazy } from 'react';

type AppNexusProps = {
  appID: AppID,
  isBeingDragged: boolean,
};

const Calculator = lazy(() => import('./Calculator/Calculator'));
const VSCode = lazy(() => import('./VSCode/VSCode'));
const Calendar = lazy(() => import('./Calendar/Calendar'));

const PlaceholderApp = lazy(() => import('./Placeholder/Placeholder'));

export const AppNexus = ({ appID, isBeingDragged }: AppNexusProps) => {
  if (appID === 'calculator') return <Calculator />;
  if (appID === 'vscode') return <VSCode isBeingDragged={isBeingDragged} />;
  if (appID === 'calendar') return <Calendar />;

  return <PlaceholderApp appID={appID} />;
};

See?? Super easy to do!!

This brought the initial bundle size down to just 62KB min+brotli with 3.9KB of CSS. 23KB smaller
by just dynamically importing stuff 🤯🤯

And this is when I took a break from this project(again!)...

Until 12th August 2021, when I was so bored I decided to just rebuild the whole thing again in Svelte. So that's what I did.

Svelte: The golden age

I began migrating on the morning of 12th August, kept at it the whole day, and got the Dock, the menubar, and the action center working, as it was a matter of copy-pasting only.

As for the dock animation, I had already done an article about it, so all I had to do was just copy-paste stuff, again 😏.

I continued on the 13th too, working the whole day, implementing the different apps. Finally completed by the end of the day.

Results

Unsurprisingly, the bundle size went down and runtime performance went up. If you have been following Web Dev news on Twitter and Reddit, you probably saw this coming from a mile away.

But the extent of these improvements was very surprising. I'll just let the cat out of the bag: Initial bundle size went down to 28.5KB of JS, min+brotli🤯🤯🤯🤯🤯. That's less than half of what it was before.

And runtime performance went up by a lot. With the previous version, the dock animation could get janky when my computer was overloaded. Not by a lot, but it was visible. After I moved to Svelte, even that much jank was gone. Fully gone!

The process

The process of migrating to Svelte from a React app was gruelling and hard and rough and mentally taxing. It was exhausting.

Ignore the line above, it was total BS 🤣

Moving to Svelte was an extremely simple process. It was literally copying the JSX code, pasting it as is, removing the CSS Modules stuff, and adding regular old classes.

Because Svelte's state is very close to React's useState, moving it was a matter of copy-pasting all the state-related code and modifying it to be a regular Variable.

So this 👇

const [xPos, setXPos] = useState(0);
const [yPos, setYPos] = useState(0);
const [isMenuVisible, setIsMenuVisible] = useState(false);

became this in svelte 👇

let xPos = 0;
let yPos = 0;
let isMenuVisible = false;

This is it. Literally got rid of a lot of noise, but the skeleton structure remained the same.

But what about Global state?

Yes, global state would've been a problem, but the thing is: It Wasn't.

Moving React global state would be a huge pain if I were using the React Context or Redux, where person A tells person B to tell person C to change the state. I personally never liked this Reducer pattern. It made sense to use it on super big codebases, but I never encountered the problem myself.

So I searched rigorously for a global management system as simple as possible. I already had a taste of the simplicity that StencilJS store and Svelte Stores provided.

After searching long, I found this amazing library called Jotai which provided a global state very very similar to Svelte Stores, and I freaking loved it!!! 😍😍

It was exactly what I needed.

Here's a little snippet of how it works 👇

// Create global store
const themeAtom = atom('light');

// Inside the component
const [theme, setTheme] = useAtom(themeAtom);

It makes the state management very linear, just like useState. Which made migrating it to Svelte extremely easy.

I copied the atoms as is, renamed their function to writable, remove the whole const [val, setVal] = useAtom(someAtom); syntax entirely and put a $ before the store where I was using it. And that's it! This is literally how I migrated away.

What about Styles?

The same thing literally. Because Styles were just plain SCSS, independent of the framework, there was literally nothing to do here. Just copy-pasted styles from the .scss file to the Svelte SFCs, and we're done.

This whole process was so simple, that it took me just 2 days to completely migrate away.

Observations

Here are my takeaways from this whole process 👇

Svelte Code is much simpler

This comes as no surprise, Svelte code is much shorter, more readable than JSX.

I tweeted a little part of it 👇

Source

Every single component in the new Svelte Codebase is around 20-30% smaller. The number of files is literally half as before, cuz I don't need to separate .scss files anymore. Styles exists in the one .svelte file only.

And some components that are now longer than before, are longer because I got rid of some abstracted small components entirely, which I had refactored away earlier. Because Svelte is so simple in terms of readability, I could just inline these components and the code still looked very clean. 💯 points for Svelte!!

Svelte Motion = 🔥

macOS is an Operating system, and no OS is complete without animations. This is where Svelte's built in Motion stores and transitions come in.

Svelte's Motion stores are extremely lightweight, and extremely powerful. They power the dock animation when you hover over it, and using them is extremely easy.

Previously I was using Framer Motion. Framer Motion is a great library and my go-to thing for animations in P/React. But there's just one little issue with it: It's not exactly small 🥲

This is the bundlephobia size of framer-motion

This isn't very big, but this ain't small either. 32KB Gzip is a lot 🤐

Framer Motion's size is indicative of its capabilities. Framer Motion can do a lot. Really, it can do anything animation related under the sun.

But ofc, there's no such thing as a good tool and a bad tool. There's only the right tool for the JOB, and Framer Motion was overqualified for my use case.

But Svelte fit right in. It had exactly what I needed(Except for one small piece, which I got from popmotion. Jut 3Kb big 😌), and most importantly, it allowed me to programmatically handle it, which is easier than going the declarative route.

Here's a little example. Go to macos.vercel.app, click on any icon on the dock. It jumps up and down once.

Animating that with Framer Motion looked somewhat like this 👇

const [animateObj, setAnimateObj] = useState({ translateY: ['0%', '0%', '0%'] });

<motion.span
  onTap={() => setAnimateObj({ translateY: ['0%', '-39.2%', '0%'] })}
  initial={false}
  animate={animateObj}
  transition={{ type: 'spring', duration: 0.7 }}
  transformTemplate={({ translateY }) => `translateY(${translateY})`}
>
  {/* Markup */}
</motion.span>;

This is pretty simple, but there are a few issues with it: Have to tell it to not run in the beginning, how to translate it. All these can be condensed into 1 big issue: It's declarative.

I'm a JS guy first. Declarative programming doesn't come naturally to me. I see the world as cause and effect. You click, something happens.

Doing the same thing in Svelte was much easier and programmatic 👇

<script>
  // Spring animation for the click animation
  const appOpenIconBounceTransform = tweened(0, {
    duration: 400,
    easing: sineInOut,
  });

  async function openApp(e: MouseEvent) {
    /* State related stuff */

    // Animate the icon
    await appOpenIconBounceTransform.set(-39.2);

    // Now animate it back to its place
    appOpenIconBounceTransform.set(0);
  }
</script>

<span style="transform: translate3d(0, {$appOpenIconBounceTransform}%, 0)">
  <!-- Stuff -->
</span>

It's very clean and simple now. Plus it's not declarative anymore. I tell the program explicitly when to go up, and when to come back down. The program literally reads like this: Go up -39.2%, and when you're done with that, go down to base position. As simple as that ¯\_(ツ)_/¯

Those transitions 😍

Transitions in Svelte are basically animations to be run when some DOM is created or destroyed. This is nearly impossible to do in P/React without relying on external libraries like Framer Motion. But in Svelte, this is in-built and extremelyyyyyyy easy to do.

So, ofc, I put in transitions everywhere I could. Earlier, when you opened/closed any app, there was no transition. Now, when you close a window, it collapses into itself while closing, giving an awesome transition.

Adding this window close transition was literally just this 👇

<script>
  function windowCloseTransition(el, { duration = 300 }) {
    const existingTransform = getComputedStyle(el).transform;

    return {
      duration,
      easing: sineInOut,
      css: (t) => `opacity: ${t}; transform: ${existingTransform} scale(${t})`,
    };
  }
</script>

<section out:windowCloseTransition></section>

And that is it!! Now there's a really nice transition, with around 10 lines of code only.

I see this as an absolute win ~~ Professor Hulk

I added in transitions in many other places which I couldn't add before with Framer Motion. Not because they weren't possible, but because the syntax felt unnatural there, but here in Svelte, it just fits right in!

Final Words

Really, moving to Svelte made me realize how extremely powerful it is. A lot of React developers treat Svelte as a toy(I was one of them), but really, it isn't a toy. In fact I'd say it's more powerful than React. Yes, less control over everything than React, but it is a better choice for 95% of developers than React anyway.

Hope you liked this half-historical half-technical article, and it gave you some enthusiasm to try Svelte, if you haven't already.

Peace out ✌️

Trying Golang as a JavaScript lover

PuruVJ — Wed, 18 Aug 2021 06:51:43 +0000

Read in light, midday, dark or zombie mode 😈

I have been into coding since early 2015. That's about 6 years now. In that time I have done HTML CSS JavaScript, its supersets TypeScript(My favorite language of all time 😌) and Dart, some light Python, and C and C++ in university curriculum.

Recently, Golang caught my eye. So I had been casually reading its documentation, the tutorial, some articles. Not really trying it out, in the sense of opening VSCode and writing the actual code.

I was just trying to get a feel for the patterns. Because the more sources you learn from, the better you become, no matter if the context is entirely different. Concepts and Patterns bleed over to other things.

Now here's one thing about me: I am a die-hard JavaScripter(That's not an official term, but who cares, let's consider it is, for now 😋). I write everything in JavaScript or TypeScript(Basically JavaScript with Types and futuristic features). Whether it's an app, or a small script or heck, even something where using Python would be better, I still go with JavaScript.

Why? Because JavaScript is extremely flexible. As a language alone, it can literally do anything. It is a very easy language. There are a dozen ways to do anything in it. Then you include the Modular aspect of it in the equation, and the huge registry, NPM, and JavaScript reaches a godly level.

Yet at the same time, it is explicit enough. You have to declare variable first before using it with const or let, unlike Python, which leads to confusion about where the variable is coming from!!

JavaScript uses curly braces for blocks instead of indentation. People would say Python looks cleaner without those braces, and I agree. It looks cleaner. But while reading, that indentation confuses me, as in, the line I'm reading belongs to which block exactly. Plus writing it is really risky. You might end up accidentally removing indentation from a line at the end of a block and it becomes a part of the outer block. It has happened to me, countless times.

These are some reasons why JavaScript is my favorite. So where does Go factor in on it?

Let's see!

TLDR

Sorry, there's no TLDR for this article. It's just a documentation of my experience 🥲

Disclaimer

Before we start, here's something I wanna make clear: This isn't an organized technical article about pros and cons of Go or JavaScript. This is a completely Subjective article about what I like about Go and what I don't like about it. If yur here for a hardcore, informative article about Go and JavaScript, you will be disappointed 😅

But hey, if you wanna read a first hand experience, this is it!! Read on!! 🤩

So with that out of the way, let's begin!

Why even try Go?

This is a valid question. You just read that I know many languages, and even on top of that, I use JavaScript for everything. So what gives? Why try to fit another language in my tiny brain?

The problem was when JS was way too big!!

What do I mean by that? Let's rewind a little!!

The lazy undergraduate

Spoiler: I am the lazy undergraduate in question 😄.

I took admission in university a few months back. Thanks to Covid-19, our classes are fully online. It means there are a bunch of Google meet links that I had to hunt for, for every class.

So the actual process was:

Open up the timetable every hour and see which class is next.
If there's a class in next hour, find out its link.

Believe me or not, this process took 5 minutes. EVERY. SINGLE. TIME! 5 minutes isn't a lot, but you count these 5 minutes for every time I had to it, and combine it, that's around 10+ hours wasted just for finding the link.

And worse than that is the repetition. As a programmer, you know how horrible it is do the same boring task again and again. And unlike non-programmers, you can't accept the situation and get used to it. You have to automate it, even if it takes hours.

So hey, that's what I did!!

I created a script that would run in the background, and open the class link in the browser 5 minutes before the class started. Just like that!!

In comes Deno

If you're like, "Hold up a minute, what's Deno doing an article about Go?", lemme explain.

Deno is platform for JavaScript/typeScript, like NodeJS, with the added benefit of compiling your code into machine level code, or an executable file.

This was perfect for me. I could write code in my favorite language, and convert it over to an executable that I could configure to run on System startup, so I'd never have to run it myself ever again.

Only it wasn't perfect 🤐🤐

The code itself was amazingly easy to write. I completed it in 3 hours, because I was so familiar with TypeScript.

But where the issue was while compiling the code into an executable.

The executable's size was 56 MB for windows, and as high as 90MB for MacOS M1.

56MB isn't a lot for me. Even 90 MB is nothing. But it kept nagging at me. I try to keep the sizes of apps/websites I build as low as I can, and 56MB felt just way too big for that.

And not only that. Because I had made this project public(Here it is: PuruVJ/auto-class-launcher-deno) and usable for everyone, my batchmates tried to use it, and well, 60-90Mb was way too big for them, due to limited internet and all.

So I got a good excuse to re-write it.

Node was out of question because any script in it would require NodeJS to be installed on the system and overall a more complicated process.

I turned towards Rust! I had been jumping to learn Rust for quite some time, cuz of its performance and modernity and all that stuff.

But oh boy, Rust was hard. Extremely hard!! I gave up after a few hours.

Then, I finally turned towards Go!!

Learning Go

I sat down at night to make it. I created the project, initialized the Go boilerplate(which is just a go.mod file and a main.go with 4 lines of code), then I opened up the Go Tutorial.

Yeah, this might seem strange to you. Initialize a project, and then start learning that thing? Why would you do that?

Well, I'm a huge proponent of Learning by Doing, where you learn the bare minimum upfront, and the rest you learn by trying to make a small project in it. It makes you learn the concept the hard way, but really fast, without wasting any time on trivialities.

In case of Go, though, I didn't need anything upfront, cuz I had seen the syntax before a bit and it looked simple enough to me.

Spoiler: Learning by Doing really works, I learnt basic Go in 3-4 hours only 😉

Results

Before I jump into the experience, here's the straight up results 👇

If you're unable to read the image(Screenreader/Slow network), it's a comparison table showing Deno generated binary size to be 57 - 90MB and memory consumption to be 6 - 11MB, whereas with Go, the binary size is 2.6 - 2.9MB, and RAM consumption is 1.5 - 7MB.

Mindblown right 🤯?! Such a huge difference in the binary size. The Go version is straight away 22 - 31 times smaller!!

And even the max memory consumption of Go binary is similar to the minimum memory consumption of the Deno program.

The reason the memory consumptions varies is because both these Go and Deno do garbage collection, so the objects and constructs are garbage collected eventually and memory consumption drops down, because the binary knows it need not keep those things in memory anymore.

Observations about migrating

This, folks, is the part you came to read about really. Read on!

So I migrated the whole app to Go, (mostly) bug free, in 1 day.

And here's my observations, as an avid JavaScripter learning Go for the very first time!!

Not very different (In a good way 🙂)

Really, that's the first point I noticed about it. It isn't much different from JavaScript. There are variables, functions, if, else, for, switch blocks, Error handling system and what not.

That is the main point of Go, really!! It combines all the knowledge of 60 years of programming into a very simple and wise language which doesn't invent a lot of new stuff. Rather, it focuses on problems that aren't even code related, which are just as important as the code itself, like feature creep, standard formatting, great package management system and stuff that isn't answered well enough in a majority of languages to the day. And OFC, can't forget Goroutines 😌

OFC, it depends on how comfortable you're with programming languages, generally, but if you're very comfortable with TypeScript or Dart or any other statically typed language, you'll feel right at home with Go.

But even then, it isn't necessary to know a Statically typed language before, as Go will infer as much of the types as it can without you needing to tell it much.

Variables are Pythonic, but not quite...

Here's how JavaScript variables are defined.

// Declare variable
let someVal;
someVal = 'hello';

// Set it to something later on
someVal = 'world';

If you wanna do it explicitly in TypeScript,

let someVal: string;
someVal = 'hello';

// Set it to something later on
someVal = 'world';

OFC, TypeScript is intelligent and you don't always need to specify types for a variable.

As you can see, it's extremely clear where this variable is defined. You are scrolling through a file, there's the big const and let glaring right at you. The source is extremely clear.

Now let's come to Python.

The above example of declaring a variable here 👇

someVal = 'hello'

# Set it to something later on
someVal = 'world'

Can you the declaration part and the part where we set it's value to something, later on in the program? There's no difference. No way to know where this variable was defined. It's irritating in my opinion. There needs to be some distinction between the two.

Now, why I talk about Python variables? Cuz Golang variables, in their simplest form, are very much like Python variables, but they have one extra character that prevents the confusion that Python variables introduce. That character is :

someVal := "Tell me. Do you bleed?"

// Set it to something later on
someVal = "You will!"

A little dialogue from Batman vs Superman 🦇

1st time, I'm declaring the variable using the := operator. But when setting its value later in the program, I use the regular = operator.

This is a small thing, but it makes a huge difference!! I even actually prefer it over JavaScript's let variable declaration. It is cleaner, but not so clean it sacrifices developer ergonomics.

And if you prefer a more verbose way, that's there too

var someVal string = "hello"

Just like JavaScript's var someVal = "hello", but here the data type is necessary. If you're a TypeScripter, you'll feel right at home here.

And ofc, you also have const in go, and its declaration is the exact same as doing it in JavaScript

const someVal = "hello"

I really love the fact that Go goes the extra length to keep the code clean, but doesn't shy away from providing the standard, more verbose APIs when they're needed. It's the best of both worlds.

Type System

Go's Type system is similar to the type system of TypeScript, where most of the time, you don't even need to specify types for your variables.

In TypeScript, this below:

const x = 'hello';

is inferred as string automatically. Same with number or boolean or just anything.

Go works like this too!!

x := "hello"

x is inferred as string. Works similar to TypeScript!!

This kind of type system is personally my favorite!! Having too much type information makes the code hard to scan, in my opinion! Having types only where absolutely needed is the way I roll, and I am glad Go has that same philosophy 🤩

OFC, there was one place where I found Go's system to be less convenient.

You see, in the project, I input the timetable and link information from an external .json file. That JSON file has the following TypeScript structure 👇

type ClassConfig = {
  link?: string;
  times: {
    day: 'mon' | 'tue' | 'wed' | 'thu' | 'fri' | 'sat' | 'sun';
    time: string;
  }[];
}[];

As you can see, I have an object type inside the main object type. If you're a TypeScript developer, you wouldn't even think about it twice.

But in Golang, you can't define a type with a struct inside struct 🤐

So I had to do this

type ClassTime struct {
  Day  string `json:"day,omitempty"`
  Time string `json:"time,omitempty"`
}

type Class struct {
  Link  string      `json:"link,omitempty"`
  Times []ClassTime `json:"times"`
}

type ClassConfig map[string]Class

So yeah, I had to declare 2 more types to get the TypeScript behavior 🥲.

Those tags in structs are a way to tell go to expect this data to be a json field, and don't include a field if it is not there in the JSON itself.

Standard library is the 🧑‍🍳😘

Bonus points if you figured out the heading 😜

JavaScript doesn't have a standard library. Sure, it has some really good global functions that you can snatch up and use directly, but they don't qualify as standard lib.

Go is the opposite. By default, globally, it doesn't provide much.

But you start importing stuff from the built in standard library, you can achieve a lot!!

Want JSON? Import json package, and use it.

Need to do math? Import math package, and use it!!

But you're wondering, doesn't that add an extra step over just using the Math.* and JSON.* objects of JavaScript? Yes, it does!

But that doesn't mean that Go is bad for not having global objects like these, or JS is bad for having global objects that are just lying around in the namespace. No.

Go is a compiled language. It takes all the code you wrote, inlines everything you imported, and then convert it to machine level code. JS on the other hand is an interpreted language. What you write is what is executed in the browser ultimately, so no conversion required. So there, having these objects available isn't a big problem.

But in Go, if you include every in-built module by default, its final output size is gonna be huge. No one likes big file sizes. So by importing only what you need, output size stays small.

And the standard library has just so much more stuff than Math and json packages. It has packages that in Node/Deno world, you'd be installing from npm/pulling it with a URL.

Here are some great libs 👇

bytes - Dealing with Byte slices
context - Defines the Context type, which carries deadlines, cancellation signals, and other request-scoped values across API boundaries and between processes.
database - Interfaces for dealing with Databases(SQL only, at the moment)
embed - For embedding resources into your final binary so no need to ship many different files
time - For dealing with dates and times.
flag - Package flag implements command-line flag parsing. This is really shocking to me, cuz in Node and Deno, you always have to pull in another library for dealing with CLIs. And here, you're getting that literally built-in here 😻

There's so much more great stuff in Go Standard Library!! I highly recommend you to check it out.

go:embed is DOPE!! 🤯🤯

While building this script, I had a little hiccup: How to store a default timetable config in the binary itself? 🤔

In Deno, I had directly inlined the config inside a .ts file as a simple JS Object. But I didn't want to do it, as declaring nested objects in Go is more work. You have to specify object with their struct type next to them everytime. Overall, didn't feel like a good idea ultimately.

go:embed comes to rescue!!

Rather than explaining what it does, I'll just show you 👇

import ( _ "embed" )

//go:embed sample.json
var sampleConfigStr []byte

See the comment //go:embed sample.json? This is all we need actually! With this, Go will get this file, and embed it in the variables defined on the next line. Here I have specified the variable to be a Byte array, but it could've been a string too. And it would just work 🤩

I ship the sample.json file, which is the default timetable now, directly in the binary. No need to download the timetable separately.

VSCode extension is a gem

Did I mention how marvelous Go's VSCode extension is 😍?!

It provides blazing fast intellisense.

It allows you to auto import packages from standard library while typing. So if you're typing fmt., and fmt hasn't been imported, it will show you the methods available on fmt, and when you use the autocomplete to type out the method, it will automatically import that package for you!! No need to go to the top of the file and add the package to the import list. This feature is really good.

It creates tests for your functions automatically. Just right click inside the function, and click on Generate unit tests tests, and bam!! You have a tests file now!!

And, remember the Class type definitions above?

type ClassTime struct {
  Day  string `json:"day,omitempty"`
  Time string `json:"time,omitempty"`
}

type Class struct {
  Link  string      `json:"link,omitempty"`
  Times []ClassTime `json:"times"`
}

type ClassConfig map[string]Class

Notice all these json: tags in the definitions. These were added by the extension, not me. I struggled to add these myself for some time, but it didn't work, cuz I was adding spaces here and there, but you aren't supposed to add those. So I put the cursor in the struct definition, right click -> Add tags to struct field. It added these tags and the code worked finally.

There's a lot more this extension does. It's extremely well crafted, so much so that after you go back to a TypeScript project after this, you actually start feeling homesick for this extension(extensionsick?). And that's saying a lot, cuz TypeScript tools in VSCode is on a godly level.

No .map .filter .every 😭

All these were the good parts of Go. But there are some things in Go that I didn't like as a JavaScripter. People may argue that Go is better for it, but that doesn't mean I have to like it.

Which leads to this point: Go doesn't have arr.map, .filter, and all the superb array methods that exist on arrays in JS. Which means I have to use loops for everything.

Loops aren't bad, but after using these Array methods for so long, using loops feels like going back to the stone age 🤧

Heartsick for the +

This is a super nitpick and I might as well not include it in this post, but I might as well just do 😉.

In JS, you have this little trick to convert any data type to a number, by just putting a + symbol before it.

+'hello'; // NaN
+'11.5'; // 11.5

+true; // 1
+false; // 0

This trick is very useful in JS. Sadly, Go doesn't have this, you have to use strconv.Atoi function, which you can't use in value, as it returns a tuple of value and error, so you need an extra line

hours, _ := strconv.Atoi(timeArr[0])

This isn't much more code, but nothing beats the simplicity of +timeArr[0] 😌.

I acknowledge that returning an error is probably better than returning a NaN, but still, it's more code.

Reinvent the module system please 🙏

This was probably the most painful aspect. In JS, you write some reusable code in another file than your main file, say math.js.

In math.js you can export the functions you need 👇

export function square(a) {
  return a ** 2;
}

And then import it when you need to use.

Go also has ways to import and export from other packages, but that's it. Import and export from packages, not other files. Other files in your project with the same package <name> specified in them have everything shared among them, which, in my humble opinion, is not good. Globals was a huge problem in JavaScript world, and that's the reason we have modules now in JS(After 10 years of people making their own module systems. Yup, the problem was that big).

Now, I have a feeling file based module system probably won't come to Go anytime soon, but still, if you can do it Golang folks... 🥲

Final words

Don't let the last few sections make you shy away from trying Go, moving to Go was a very positive result ultimately, and I'd recommend every single JS developer to try Go.

Hope this article brought you some enthusiasm for trying Go, and some newfound respect for JS(Necessary once in a while thanks to Tech twitter 🙄)

Peace ✌️

The Zen of Preact's source code

PuruVJ — Sat, 01 May 2021 04:02:04 +0000

Artwork by Fernando Jorge

Read in light, dark or sepia theme

Preact is [web dev]household name at this point. Almost every web developer who's been in this business for longer than 2 years has heard of it and maybe even tried it themselves. And probably reached the same conclusion as me: It's awesome!! 😻.

So today, I'm gonna do a deep dive into Preact's source code, and remark on some interesting things I find there.

What is Preact?

In case you're not familiar, Preact is the 3KB alternative to the 42KB of React, by Jason Miller. It's fully compatible with React's API and supports all packages that rely on React. Its awesome that way.

Observations

Before we look at the code, I'll remark on some things about Preact.

Written in TypeScript, but not quite...

Preact's source code is written in TypeScript, but the main files themselves aren't. The main files with the functionality are written in plain JavaScript, but they use JSDoc to pull in Types from TypeScript Definition files (.d.ts).

An example:

This is the types.d.ts file:

export type RenamedType = number | null;

And here's the JS file

/**
 * @param {import('./types').RenamedType} a
 * @param {import('./types').RenamedType} b
 * @returns
 */
function sum(a, b) {
  return a + b;
}

As you can see, the JavaScript code is just that: JavaScript. You won't see TypeScript style type specified in it. Rather all type information is specified in comments, which are ignored completely. There's a whole article about Using TypeScript without TypeScript, but the TLDR; here would be: Avoid development time tooling. If its just plain JS, you don't need to run a file watcher to transpile files as you change them. Just run what you got. And you already got a TypeScript compiler running all the time without you explicitly running it: Your VSCode.

This is a very interesting approach and I see more and more libraries take it up, especially non-UI libraries(For UI libraries, you already got a web server running, so adding in TypeScript in the tooling won't change much, go ahead and add TypeScript)

Very well written code

I don't need to say this out loud really, but Preact's source code is very very well written and commented, as you'd expect from such a paramount framework.

It reuses itself a lot

Yup. One of the reasons Preact is so small is that it reuses it's own exported function in its other exported functions. A LOTT!! I'll show you some places where this happens

Disclaimer

This is not gonna be a complete breakdown, and won't be sequential. Preact is quite a big library to cover in a blog post, so I'll just cover the interesting parts.

So, let's begin!! We'll look at some interesting things in the core module(i.e., the one when you type import {} from 'preact'), then we'll get to hooks

Core module

index.js

As is the tradition, let's start with the index.js file:

export { render, hydrate } from './render';
export {
  createElement,
  createElement as h,
  Fragment,
  createRef,
  isValidElement,
} from './create-element';
export { Component } from './component';
export { cloneElement } from './clone-element';
export { createContext } from './create-context';
export { toChildArray } from './diff/children';
export { default as options } from './options';

Notable points: h, which is Preact's JSX factory, is actually named createElement. Just like React.createElement. But is exported as h because it allows you to write raw Preact(Without JSX), also because it was initially inspired from HyperScript 👇

h('div', { class: 'haha' }, h('span', { key: 34 }, h('h1', {}, h('span', {}, 'Whoa'))));

Also it is notable that it exports createElement as it is too, to maintain compatibility with React.createElement

create-element.js

import options from './options';

export function createElement(type, props, children) {
  /*...*/
}

export function createVNode(type, props, key, ref, original) {
  /*...*/
}

export function createRef() {
  return { current: null };
}

export function Fragment(props) {
  return props.children;
}

export const isValidElement = (vnode) => vnode != null && vnode.constructor === undefined;

Omitted createElement and createVNode as they're quite big.

createRef

Let me blow your mind. refs in P/React are basically used to encapsulate values that shouldn't trigger re-renders and are not re-created on every re-render. Lets see how Preact defines it:

export function createRef() {
  return { current: null };
}

A ref is just an object with current property set to null. It's always advertised as that, but I never thought that it's actually an object internally too.

A little clip of me when I found this out 👇

Fragment

Next up, we have Fragment. Its also another astonishing thing.

export function Fragment(props) {
  return props.children;
}

Fragment, just returns its children. That's all! 🤯🤯

I knew that's what it's supposed to do, but I always pictured some complex code. Didn't realise that it was just this super simple thing.

isValidElement

/**
 * Check if a the argument is a valid Preact VNode.
 * @param {*} vnode
 * @returns {vnode is import('./internal').VNode}
 */
export const isValidElement = (vnode) => vnode != null && vnode.constructor === undefined;

Simply checking if the current Virtual DOM Node passed to it is valid or not. Again, one liner, super small, but here's a pattern I found out by looking at this code only. Notice @returns {vnode is import('./internal').VNode} in JSDoc. The code is basically using type guards. Right in the JSDoc. I haven't seen this pattern before, which is all the more proof that reading code written by those smarter than you can make you a better dev.

render.js

Remember the index.jsx file, where you initialize your Preact app

import { render, h } from 'preact';
import App from './App';

render(<App />, document.querySelector('#app'));

This is the render function 👇

export function render(vnode, parentDom, replaceNode) {
  if (options._root) options._root(vnode, parentDom);

  // We abuse the `replaceNode` parameter in `hydrate()` to signal if we are in
  // hydration mode or not by passing the `hydrate` function instead of a DOM
  // element..
  let isHydrating = typeof replaceNode === 'function';

  // To be able to support calling `render()` multiple times on the same
  // DOM node, we need to obtain a reference to the previous tree. We do
  // this by assigning a new `_children` property to DOM nodes which points
  // to the last rendered tree. By default this property is not present, which
  // means that we are mounting a new tree for the first time.
  let oldVNode = isHydrating ? null : (replaceNode && replaceNode._children) || parentDom._children;

  vnode = ((!isHydrating && replaceNode) || parentDom)._children = createElement(Fragment, null, [
    vnode,
  ]);

  // List of effects that need to be called after diffing.
  let commitQueue = [];
  diff(
    parentDom,
    // Determine the new vnode tree and store it on the DOM element on
    // our custom `_children` property.
    vnode,
    oldVNode || EMPTY_OBJ,
    EMPTY_OBJ,
    parentDom.ownerSVGElement !== undefined,
    !isHydrating && replaceNode
      ? [replaceNode]
      : oldVNode
      ? null
      : parentDom.firstChild
      ? EMPTY_ARR.slice.call(parentDom.childNodes)
      : null,
    commitQueue,
    !isHydrating && replaceNode ? replaceNode : oldVNode ? oldVNode._dom : parentDom.firstChild,
    isHydrating
  );

  // Flush all queued effects
  commitRoot(commitQueue, vnode);
}

export function hydrate(vnode, parentDom) {
  render(vnode, parentDom, hydrate);
}

First off, very well commented.

From how well I can make sense of the situation here, render function is basically making a commitQueue to store all the changes needed to be done. next, the diff function is taking in the old VNode and the new VNode, making sense of situation and figuring out which DOM Nodes need to be updated, and populating commitQueue.

Then its basically committing these changes. Its just like how we do it in Database. We perform some operation in batch, the commit, so they all get applied one by one at the same time.

I would love to cover diff in the blog post too, but its so big it has its own 500 lines long file 😵. All you have to know, its job is to figure out which DOM Nodes need to be updated and which to keep the same.

hydrate

This function is very interesting, as it nothing but calling the render function. But something even more interesting, its passing along itself as the 3rd argument. And if you look again at render function, it actually has an if condition looking if the function passed to it is named hydrate. Heck there's even a comment about abusing the 3rd argument 😂. These people are way too smart!!

I'm probably exhausting my repeat limit, but darn!! Preact's reuse of itself is really, darn good!!!

create-context.js

This one will probably excite you, as Context is a very, very loved API by a majority of P/React developers. This wasn't always the case, but the useContext hooks made it very easy to use context. Way too easy!!

const { lemonsCount, setLemonsCount } = useContext(lemonsContext);

import { enqueueRender } from './component';

export let i = 0;

export function createContext(defaultValue, contextId) {
  contextId = '__cC' + i++;

  const context = {
    _id: contextId,
    _defaultValue: defaultValue,
    /** @type {import('./internal').FunctionComponent} */
    Consumer(props, contextValue) {
      return props.children(contextValue);
    },
    /** @type {import('./internal').FunctionComponent} */
    Provider(props) {
      if (!this.getChildContext) {
        let subs = [];
        let ctx = {};
        ctx[contextId] = this;

        this.getChildContext = () => ctx;

        this.shouldComponentUpdate = function (_props) {
          if (this.props.value !== _props.value) {
            subs.some(enqueueRender);
          }
        };

        this.sub = (c) => {
          subs.push(c);
          let old = c.componentWillUnmount;
          c.componentWillUnmount = () => {
            subs.splice(subs.indexOf(c), 1);
            if (old) old.call(c);
          };
        };
      }

      return props.children;
    },
  };

  // Devtools needs access to the context object when it
  // encounters a Provider. This is necessary to support
  // setting `displayName` on the context object instead
  // of on the component itself. See:
  // https://reactjs.org/docs/context.html#contextdisplayname

  return (context.Provider._contextRef = context.Consumer.contextType = context);
}

This file, this small file, is all there's to the core context API. These 42 lines do so much(Comments excluded).

So, let's inspect Consumer. Go back a long time back and remember we used to use Consumer to access context data.

This is how it looks

<Consumer>{(data) => <div>Hello {data}</div>}</Consumer>

This looks pretty manageable, but it could get worse when your code grew.

So, if we look at the code of Consumer, it's just this:

Consumer(props, contextValue) {
  return props.children(contextValue);
},

That's it!! Its expecting its children to be a function, and it's simply calling it with the context data. Suddenly the Consumer pattern example above makes sense 🤯🤯.

As for Provider, what it's doing mostly is modifying its parent component's lifecycle hooks to watch for context state changes.

Lastly, there's the return statement at the bottom. The last line is big mutation trick that is used often while coding classical languages like C, C++, Java etc, that is, returning a variable and mutating it at the same time. Here, it is mutating it for the sake of Preact devtools, so as to show the displayName in devtools, as React Devtools do.

And now, its time for the section you probably came here for entirely: HOOKS!!

Hooks

So, first off, Hooks are located in a separate directory. Unlike React, everything is opt-in in Preact, which makes the Minimalist in me rejoice. There's intentionality in every thing you do here. I 😍 that.

So, let's start off with the very, very first hook you ever encountered: useState

But Beware, a twist lies here 😈

useState

This, is useState:

export function useState(initialState) {
  currentHook = 1;
  return useReducer(invokeOrReturn, initialState);
}

Mindblown right? As you can see, useState is basically calling useReducer, which is another standard React hook. So basically, useState is just an alias of useReducer, you could say.

The variables invokeOrReturn and currentHook are defined in the same file, in the module scope and managed by Preact.

And lemme give you another nugget. See the currentHook = 1 expression? Guess what: It's not needed in the core functionality. It exists solely for Preact Devtools. That is, if Devtools weren't a consideration, this code might as well have been:

const useState = (initialState) => useReducer(invokeOrReturn, initialState);

Literally a one liner!! 🤯🤯🤯🤯

Again, intense focus on the whole self-reusing thing I keep repeating.

All the heavy lifting here is done by the useReducer, so let's look at it next.

useReducer

export function useReducer(reducer, initialState, init) {
  /** @type {import('./internal').ReducerHookState} */
  const hookState = getHookState(currentIndex++, 2);
  hookState._reducer = reducer;
  if (!hookState._component) {
    hookState._value = [
      !init ? invokeOrReturn(undefined, initialState) : init(initialState),

      (action) => {
        const nextValue = hookState._reducer(hookState._value[0], action);
        if (hookState._value[0] !== nextValue) {
          hookState._value = [nextValue, hookState._value[1]];
          hookState._component.setState({});
        }
      },
    ];

    hookState._component = currentComponent;
  }

  return hookState._value;
}

I'll admit I don't fully understand what's going on here 😅, but something that caught my eye here: Look at the hookState._value = [ declaration inside the if block. Its an array with 2 elements. 1st element is simply a value. 2nd one is a function.

Wait a sec. 1st element a value, 2nd element a function...

Holy smokes!!! Its the [state, setState] pair returned from useState 😵😵

const [state, setState] = useState(Infinity); // 😈

if that didn't blow your brains apart, I dunno what will.

Next up: The 2nd most famous hook!

useEffect

export function useEffect(callback, args) {
  /** @type {import('./internal').EffectHookState} */
  const state = getHookState(currentIndex++, 3);
  if (!options._skipEffects && argsChanged(state._args, args)) {
    state._value = callback;
    state._args = args;

    currentComponent.__hooks._pendingEffects.push(state);
  }
}

Aha!!! Notice the if block here. We're checking for 2 things.

!options._skipEffects - Preact has an options config, where you can turn off all side effects from running. So to run this useEffect, we have to make sure its safe to run effects.

argsChanged(state._args, args): This one is very interesting. Remember the 2nd argument you pass to useEffect?

useEffect(() => {
  /* Do epic shit */
}, [emojiUpdated]);

Guess what, argsChanged is the function responsible for checking if changes were made in the dependencies passed to useEffect. Here, we pass it state._args, the argument list maintained by Preact for this specific hook, and the 2nd argument is the new set of dependencies. If any changes are detected, this function returns true, and the effect is run again.

As for argsChanged function, its simply this 👇

function argsChanged(oldArgs, newArgs) {
  return (
    !oldArgs ||
    oldArgs.length !== newArgs.length ||
    newArgs.some((arg, index) => arg !== oldArgs[index])
  );
}

Its basically checking if oldArgs even exist or not at first. Why?

Cuz the dependency list passed to useEffect itself could be a state holding an array.

const [deps, setDeps] = useState([]);

useEffect(() => {
  /* Do epic shit */
}, deps);

OFC, a simple reason could be that you didn't pass the array. That is what most people would do rather than this above method 😅.

2nd, its checking if argument list length is different or not. This is a smart move, because if the array size itself is changed, you don't need to go through and check every value.

The cheapest function call is the one you never make ~~ Jason Miller

And finally, when all these conditions are true, we finally check if the values match up using the arr.some method.

From what I can tell, this function is written in a way to stop as soon as it can. You could've written this same function in a way that it would do all these things, and then tell the result. Here, through some clever short circuiting , they made this function pretty efficient.

useLayoutEffect

export function useLayoutEffect(callback, args) {
  /** @type {import('./internal').EffectHookState} */
  const state = getHookState(currentIndex++, 4);
  if (!options._skipEffects && argsChanged(state._args, args)) {
    state._value = callback;
    state._args = args;

    currentComponent._renderCallbacks.push(state);
  }
}

This hook is very, very interesting. If you read the code of useEffect, you'll find that they are exactly the same, except for the very last line.

In useEffect, it is 👇

currentComponent.__hooks._pendingEffects.push(state);

Whereas here it is 👇

currentComponent._renderCallbacks.push(state);

In useEffect, the effects to executed are pushed to a queue that executes asynchronously.

Whereas in useLayoutEffect, the effects are pushed to the render callbacks, making it execute eagerly, as the rendering is going on. That's why its called use*Layout*Effect.

Next up, is another hook that will blow your mind and change the way you write your Refs. Yepp, you guessed it right, its useRef 😎

useRef 😎

This hook's implementation is so cool that I can't help but put the Sunglasses emoji in front of it 😁

export function useRef(initialValue) {
  currentHook = 5;
  return useMemo(() => ({ current: initialValue }), []);
}

If you notice, useRef is just useMemo in disguise, with an object that has one property: current with value null.

So, effectively, you could write your refs as memos

const containerElementRef = useMemo(() => ({ current: null }), []);

Don't take this too seriously though. Its better if element refs are assigned to proper useRef values only, as it is cleaner, the syntax is built around it.

What I wanna point at is, is that a lot of people, especially beginners, equate Ref as the thing that holds DOM references, and that's all it do. Which is not a good thing really.

But when you look at this code and realise that the Ref is just a value that's cached for the lifecycle of the component, clarity sinks in. The mental block and the sense of magic goes away, and you feel fully in control.

useCallback

export function useCallback(callback, args) {
  currentHook = 8;
  return useMemo(() => callback, args);
}

And here's another hook that's just useMemo under the hood. This gives me the lols 😂😂. At this point, I'm simply giggling silently seeing that everything in Preact hooks is just useMemo.

useMemo

Ahh, the star of the show, useMemo!!🤩 Finally!

export function useMemo(factory, args) {
  /** @type {import('./internal').MemoHookState} */
  const state = getHookState(currentIndex++, 7);
  if (argsChanged(state._args, args)) {
    state._value = factory();
    state._args = args;
    state._factory = factory;
  }

  return state._value;
}

This one is pretty simple. Get the state for this specific hook, compare the previous dependencies to the new and update values and factory function passed to it if anything changes.

And this again is so small, it makes me laugh as well as cry. Seriously, going through this codebase gives me huge imposter syndrome everytime. The architecture is so damn well done that code duplication isn't needed anywhere here, so everything is super small. Well done Preacters 🥲

useContext

One of the most favorite hooks of all time, useContext 😍

export function useContext(context) {
  const provider = currentComponent.context[context._id];
  // We could skip this call here, but than we'd not call
  // `options._hook`. We need to do that in order to make
  // the devtools aware of this hook.
  /** @type {import('./internal').ContextHookState} */
  const state = getHookState(currentIndex++, 9);
  // The devtools needs access to the context object to
  // be able to pull of the default value when no provider
  // is present in the tree.
  state._context = context;
  if (!provider) return context._defaultValue;
  // This is probably not safe to convert to "!"
  if (state._value == null) {
    state._value = true;
    provider.sub(currentComponent);
  }
  return provider.props.value;
}

Lots of comments here. If I remove all of them

export function useContext(context) {
  const provider = currentComponent.context[context._id];
  const state = getHookState(currentIndex++, 9);
  state._context = context;
  if (!provider) return context._defaultValue;
  if (state._value == null) {
    state._value = true;
    provider.sub(currentComponent);
  }
  return provider.props.value;
}

Are you kidding me!?!? Just 7 lines in the body, and you have the biggest simplification that came when React hooks launched. What sorcery is this!! 😑😑

Notable points here: If no provider is detected, it returns a default value, thanks to that 1 liner if statement. And if no value is found here, preact subscribes the current component to the context.

useErrorBoundary

export function useErrorBoundary(cb) {
  /** @type {import('./internal').ErrorBoundaryHookState} */
  const state = getHookState(currentIndex++, 10);
  const errState = useState();
  state._value = cb;
  if (!currentComponent.componentDidCatch) {
    currentComponent.componentDidCatch = (err) => {
      if (state._value) state._value(err);
      errState[1](err);
    };
  }
  return [
    errState[0],
    () => {
      errState[1](undefined);
    },
  ];
}

I'm a huge, huge fan of Preact for providing a useErrorBoundary hook. In React, if you want error boundaries, you have to create a class component yourself and set at the root of your component tree. Whereas it ships by default in Preact, which makes my heart flutter 😅

Notable points here: This hook mostly sets the componentDidCatch lifecycle to catch the errors and do what you tell this hook to do. Its more or less same as you yourself making a class component, only you don't have to nest anything here, just drop this hook in any component thats on top of the component tree.

That's it for hooks. I didn't cover useDebugValue and useImperativeHandle, as I have never had to use useDebugValue, and useImperativeHandle is deemed unsafe to use ¯\_(ツ)_/¯

A note on simplicity

Notice how I've been saying the code is super simple. Well, it is super easy to read, because that's how simple it is, but writing it is hard. Simplicity is rarely easy, its always harder to achieve. Writing a good, emotional rollercoaster in 100 words is hard. Throwing out excessive clothes is hard. Having a clean desk is harder than a cluttered desk.

And making 3KB code for what was originally 42KB is hard.

Subtraction is harder than addition, division is harder than multiplication.

Making Preact by no means would've been an easy task, but Jason did it amazingly, and all the contributors that jumped in later made it even greater, while still keeping everything small and simpler. This is a monumental task. Hats off to the Preact team for this effort

This is it for today!

Signing off!!

Why I moved from Styled Components to (S)CSS modules

PuruVJ — Fri, 16 Apr 2021 04:34:37 +0000

Read in light, dark or mid-day theme

Artwork by Lucas Benjamin

This blog post will be about my reasons to move from Styled Components to SCSS Modules. Its gonna be a raw and non-technical one (i.e., you probably won't learn anything new from it).

What is styled-components?

Styled Components is a radical, new way of writing CSS for your React components. You can simply create components out of your styles

export const Main = () => {
  return <HelloWorld>Hello World</HelloWorld>;
};

const HelloWorld = styled.h1`
  font-weight: 700;
  line-height: 1.618;
`;

This is a very, very convenient way of writing CSS. All your CSS lives in the same file as your main logic. It's ultimate Colocation. Plus if you're a freak about small components, this really enforces you to write small components, cuz the components grow large very quickly thanks to all 3 techs in a single file: HTML + CSS + TS(Yes, I'm one of those people who breath TypeScript 😋). So you kinda feel obligated to break your components into smaller pieces, which is ultimately good. Modularity is paramount.

Its just like Svelte and Vue's SFCs. They figured it out correctly, while this makes me mad about React.

Anyways, rant aside, this way of writing styles is really good, I can't insist enough. Need dynamic prop based styles? No worries, just pass props over to your styled component, and use it in there

export const Main = () => {
  return <HelloWorld weight={600}>Hello World</HelloWorld>;
};

const HelloWorld = styled.h1<{ weight: number }>`
  font-weight: ${({ weight }) => weight};
  line-height: 1.618;
`;

Pardon the TypeScript code if you're not familiar with it or hate it. It can't be helped. Its part of my very being now 😇.

And yes, it automatically does the scoping and vendor prefixing. vendor prefixing is runtime generated, that is it determines if the browser needs vendor prefixes, then it will churn out styles with vendor prefixes. Its like a sweet runtime PostCSS and Autoprefixer running in the browser.

It makes stuff very very easy. But this is where it starts to go wrong if you don't fully understand how React and its rendering processes work.

What are CSS Modules?

CSS Modules are a slightly-less radical way of writing CSS. Its basically separate CSS files, but only modular. Syntax remains the same mostly, but it's scoped to the components where it is used (By mangling class names). The general pattern of these is this:

|-HelloWorld
  |-HelloWorld.tsx
  |-HelloWorld.module.css

Notice I use .css at the end. It could be .scss or .less or .styl too, you name it. I personally use SCSS modules.

Notice that our CSS Module has in the name itself that its a module, *.module.*. Its a Convention over Configuration approach, very prevalent in futuristic bundlers like ESBuild, Vite, Snowpack, etc.

And to use them, you import the css file in JS, and refer to it like this.

import css from './HelloWorld.module.css';

export const Main = () => {
  return <h1 className={css.helloWorld}>Hello World</h1>;
};

Meanwhile our CSS file:

/* HelloWorld.module.css */

.helloWorld {
  font-weight: 700;
  line-height: 1.618;
}

The generated CSS is something like this:

/* HelloWorld.module.css */

.__B56BLAH_helloWorld_4269BRUHBRUH {
  font-weight: 700;
  line-height: 1.618;
}

The className is mangled, and the value is substituted in place of css.helloWorld in our component.

Alright I took some artistic liberty and added some weird Elon Musk-y stuff there. The actual mangled output would be much smaller and sane 😁.

CSS modules are very handy for this. Plus you can add tooling like autoprefixer to add vendor prefixes, compile stuff back to old CSS for browser compatibility.

The app in question

Now the intro is over, let's look at the app which I moved from Styled components to CSS modules. Let me introduce you to my baby, macos.now.sh, a macOS Big Sur clone written In Preact, TypeScript and uses Vite as the bundler. Check it out, I think you'll like it (Tip: Just hover over the app dock at the bottom).

Anyways, this whole app was written in Styled Components, until I threw it out of the 30+ components in favour of CSS Modules.

Why? 🧐

The simple answer 👇

Just kidding 😅. Here's a full technical explantion 👇

CSS not minified

Take a look at this image 👇

This the main production bundle of the app. As you can see, it's minified in some place, and not, in other places. You can see the unminified part is the CSS part. These are the styles I wrote as template literals(Or string literals, I mix both up 😅). As these aren't CSS to bundler's internal CSS minifier, it stays as it is, which is kinda bummer. I am a die-hard performance freak, and the 1st rule of performance on Web: Bundle and minify your resources. Make them as small as possible, then make them even smaller ¯\_(ツ)_/¯.

Seriously, you can check this file out right here: https://macos-web-fwyxhwxry-puruvj.vercel.app/assets/index.da0c587c.js

Why not use the babel plugin? 🤨

If you don't know, Styled Components has a Babel plugin for this purpose exactly, minifying the CSS inside the template literals, and its pretty decent.

But it wasn't working for me.

No literally, it wasn't working for me, as in I set up the babel plugin and did the correct config, installed the plugin, but no it wasn't working. Something was going wrong with Vite's plugin running. The plugin was working, as build times had increased a lot from before, but the output was still not minified. The same plugin worked perfectly in a create-react-app reproduction I created to check this.

But anyways, even if this problem was solved, there's a bigger Elephant in the room

CSS injected by JS

All of this CSS still lives in the JavaScript, and is only applied when JS is evaluated by the browser, and I'm pretty sure you know of this, JavaScript is HEAVY!!!. It takes quite some CPU power to parse it, and it's heavy on main thread. Our HTML being rendered by JS itself is pushing the limit, but rendering CSS using JS too? That's way too much load on the browser.

Browsers have become amazingly efficient at parsing JS as well as rendering HTML and CSS, all in parallel. But JavaScript doing all the work, well, browsers still aren't that efficient at it(For good reason).

If you want ultimate performance, CSS in separate files or inlined in style tag is the way too go. It doesn't get better than that.

Performance had become important

When I started this project almost 6 months ago (November 2020), I made myself a little deal: Do not stress about the performance. Off course, at that time, Performance meant just lower bundle sizes, not runtime performance, cuz I really had never run into any runtime perf issues before. But this project is different in the sense that there's a lot going on. There are loads of requestAnimationFrames, tons of component, lot of global state, and what not going on. And all of it is on the screen at once. You can't really lazy load much stuff, cuz almost everything is eagerly loaded.

All of it was weighing down the runtime perf of the app. The dock animation was janky, the menus took a while to open up, theme switching was also noticeably janky. So I had to finally consider the runtime performance. And the most obvious choice was to start throwing out fancy stuff and move back to basics again.

Did it work?

Absolutely!! The performance increased like crazy. Both runtime as well as bundle size.

This is the compressed CSS file output. Its run through Autoprefixer for vendor styles, and Vite automatically puts it into a single CSS file, super compressed. Take a look yourself 👇

And here's the index.js 👇

Completely minified, JS lives in js files, CSS lives in its own file, and its all processed parallelly by the browser, styles aren't generated for every prop change like in styled components. Only the classes are applied, and the styles for that are already present in the CSS file. Just like the old times, simply and fast.

Reduced Bundle Size

This total maneuver took away 60KB from my bundles, which is just huge. I removed styled-components, react-is(Styled components require it for some reason), styled-reset and color2k(For color manipulation).

If you have been coding for some time, you'll know how incredibly satisfying deleting old stuff is. 😌

What did it cost?

Yup. I lost something: A great API design.

Writing styles in Styled Components is a pleasure. The API design is amazing, and I prefer it over CSS modules in terms of writing the code.

If you aren't using a style, means you aren't using a component, so the component will be called out by VSCode as not being used, so you can easily remove it. No more dead styles!!

Plus, compare the component below in Styled Components:

interface ActionCenterSurfaceProps {
  grid: [[number, number], [number, number]];
  children: ComponentChildren;
}

export const ActionCenterSurface = ({ grid, children }: ActionCenterSurfaceProps) => {
  const [[columnStart, columnSpan], [rowStart, rowSpan]] = grid;
  const [theme] = useTheme();

  return (
    <Container
      columnSpan={columnSpan}
      columnStart={columnStart}
      rowSpan={rowSpan}
      rowStart={rowStart}
      theme={theme}
    >
      {children}
    </Container>
  );
};

type ContainerProps = {
  columnStart: number;
  columnSpan: number;

  rowStart: number;
  rowSpan: number;

  theme: TTheme;
};

const Container = styled.section<ContainerProps>`
  display: grid;
  grid-auto-rows: 1fr;
  gap: 0.25rem;

  position: relative;

  padding: 0.5rem;

  border-radius: 0.75rem;

  background-color: hsla(${theme.colors.light.hsl}, 0.5);

  ${({ columnStart, columnSpan, rowSpan, rowStart, theme: localTheme }) => css`
    grid-column: ${columnStart} / span ${columnSpan};
    grid-row: ${rowStart} / span ${rowSpan};

    box-shadow: hsla(0, 0%, 0%, 0.3) 0px 1px 4px -1px, 0 0 0 ${localTheme === 'dark' ? 0.4 : 0}px hsla(
          ${theme.colors.dark.hsl},
          0.3
        );
  `};
`;

This is one of my components in Styled Components before. As you can see, it accepts values that are numbers. If there were booleans, it would've been easy to make a class and apply the styles then. But here, the value can be anything.

And now look at the new CSS Module version:

Component:

interface ActionCenterSurfaceProps {
  grid: [[columnStart: number, columnSpan: number], [rowStart: number, rowSpan: number]];
  children: ComponentChildren;
}

export const ActionCenterSurface = ({ grid, children }: ActionCenterSurfaceProps) => {
  const [[columnStart, columnSpan], [rowStart, rowSpan]] = grid;
  const [theme] = useTheme();

  return (
    <section
      className={css.container}
      style={
        {
          '--column-start': columnStart,
          '--column-span': columnSpan,
          '--row-start': rowStart,
          '--row-span': rowSpan,

          '--border-size': `${theme === 'dark' ? 0.4 : 0}px`,
        } as React.CSSProperties
      }
    >
      {children}
    </section>
  );
};

And the CSS for this component:

.container {
  display: grid;
  grid-auto-rows: 1fr;
  gap: 0.25rem;

  position: relative;

  padding: 0.5rem;

  border-radius: 0.75rem;
  box-shadow: hsla(0, 0%, 0%, 0.3) 0px 1px 4px -1px, 0 0 0 var(--border-size) hsla(
        var(--app-color-dark-hsl),
        0.3
      );

  background-color: hsla(var(--app-color-light-hsl), 0.5);

  grid-column: var(--column-start) / span var(--column-span);
  grid-row: var(--row-start) / span var(--row-span);
}

As you can see, the prop values are passed to the CSS using CSS variables. This method is good too, but the Styled Components method is cleaner in my opinion.

In future, I might try out libraries like Linaria which, during coding have the exact same API as styled-components, but the runtime is completely removed on build and the CSS is extracted into separate CSS files, which is super DOPE!!! 🤓

Alright, that's it for today.

Signing off!! 👋

Do you read your own blog posts after publishing?

PuruVJ — Sun, 11 Apr 2021 12:15:50 +0000

Do you really read own blog posts after they're verified and published? Write in comments, or if you wanna keep it a secret, vote here:

p:\uru_vijay

@puruvjdev

Question for bloggers: Do you *really* read your own blog post after you have verified and published them?.

12:11 PM - 11 Apr 2021

Amazing macOS Dock animation in Svelte

PuruVJ — Fri, 02 Apr 2021 08:32:03 +0000

Read in light, dark or sepia theme

macOS Dock, when you hover over it, has such a good feedback animation. The current icon your cursor is over becomes big, and the nearby icons become bigger too, but as you move your cursor, the icons' size changes based on distance from your cursor, kinda like this below 👇

Pardon the bad quality 😁. Pretty slick, right? So interactive, so playful, its just freaking good 😍

But here's a twist. That isn't macOS. There are no tooltips, no desktop icons, even the animation looks bouncier.

Ladies and Gentlemen, what you see above is the final product we're gonna make in this blog post using Svelte. In less than 100 lines of logic 😎

That looks way too good for just 100 lines 🧐🧐

I know!! That's the beauty of Svelte 😌

Don't believe me? You can check it out right here: Demo.
And here's the original source code @ Github: Source

Feel free to read the source code directly, if you feel like you can understand what is going on just from reading the source. And if you can't, no problem, that's what this article is for 😎

Let's dive into it!!

Tech Stack

Here's what the tech stack is gonna be for this little demo:

Svelte
popmotion library
Typescript 4
Vite

What's with Vite? 🤔

Vite is the new cool kid in the block 😎. Its basically a bundler and dev server like Webpack(With the Dev Server plugin), only it comes with everything pre-built and pre-configured, so you can jump into the code directly.

It won't change how we write the code, only the way we refer to our assets changes a bit, so you don't have to worry about it much.

Popmotion?

Yeah, this is an animation library on which the utterly awesome Framer Motion library is build. We don't really need the animation related stuff from this library, only a small helper function that is essential for this demo. Install it beforehand

npm i popmotion

Or if you're a Yarn person

yarn add popmotion

Preliminary setup

Our demo won't look good without that slick background and the great CSS everywhere. So let's set up the basic shell of our application.

So let's start with the root component.

<!-- App.svelte -->

<script>
  import Dock from './lib/Dock.svelte';
</script>

<main>
  <Dock />
</main>

<style>
  main {
    max-width: 100vw;
    height: 100vh;

    background: url('/wallpaper.jpg');
    background-size: cover;
    background-position: center center;
  }
</style>

Let's break it down

We're importing the Dock component. It's not declared yet, so there will be red squiggles in there. We'll declare it in a moment.
We have a main tag enclosing the Dock element.
We have our styles here. These are simply set so that the beautiful macOS Big Sur wallpaper takes up all the space and adjusts to different viewport sizes gracefully.

So we end with this beautiful view 👇

Notice we're referencing wallpaper.jpg as if its next to our current file, but it isn't. It's inside Vite's public folder. You can refer to those files as if you're current component in inside the public folder. This holds for <link>, <img>, <a> tags and what not. Go crazy 🤪!

The Dock

So let's set up the actual Dock.svelte component.

Here it is 👇

<script lang="ts">
  import DockItem from './DockItem.svelte';

  const apps: string[] = [
    'calendar',
    'facetime',
    'finder',
    'launchpad',
    'mail',
    'maps',
    'messages',
    'photos',
    'scared-cat',
    'safari',
    'system-preferences',
    'view-source',
  ];

  let mouseX: number | null = null;
</script>

<section class="dock-container">
  <div
    class="dock-el"
    on:mousemove="{(event) => (mouseX = event.x)}"
    on:mouseleave="{() => (mouseX = null)}"
  >
    {#each apps as appID}
    <DockItem {mouseX} {appID} />
    {/each}
  </div>
</section>

<style>
  .dock-container {
    margin-bottom: 0.3rem;
    left: 0;
    bottom: 0;
    z-index: 9900;
    position: fixed;

    width: 100%;
    height: 5rem;

    padding: 0.4rem;

    display: flex;
    justify-content: center;
  }

  .dock-el {
    backdrop-filter: blur(5px);
    background-color: hsla(240, 3%, 11%, 0.4);

    box-shadow: inset 0 0 0 0.2px rgb(245 245 245 / 70%), hsla(0, 0%, 0%, 0.3) 2px 5px 19px 7px;

    padding: 0.3rem;

    border-radius: 1.2rem;

    height: 100%;

    display: flex;
    align-items: flex-end;
  }
</style>

Ooh, there's a lot going on here!! Let's break it down.

import DockItem from './DockItem.svelte';

const apps: string[] = [
  'calendar',
  'facetime',
  'finder',
  'launchpad',
  'mail',
  'maps',
  'messages',
  'photos',
  'scared-cat',
  'safari',
  'system-preferences',
  'view-source',
];

let mouseX: number | null = null;

We're importing the DockItem component. It is the heart of the whole demo, as all the animation is handled within it. I'll show you how to write it soon.
Next up we have a list of all app IDs. Why are these needed? Because our app icons are stored by these names only, so we can easily <img src= them.
And here we have a mouseX variable, which we're gonna be tracking the current x-coordinate of our mouse (Distance of mouse from the left side of the screen). Notice we have defined its type as number or null. It will be null when the mouse isn't on the dock, so as to prevent any unintended resizing of elements. So we initialize it as null.

Now, analyzing the html part:

<section class="dock-container">
  <div
    class="dock-el"
    on:mousemove="{(event) => (mouseX = event.x)}"
    on:mouseleave="{() => (mouseX = null)}"
  >
    {#each apps as appID}
    <DockItem {mouseX} {appID} />
    {/each}
  </div>
</section>

We have a section.dock-container as the container for the whole dock. This itself isn't the dock, it contains the dock. Its just an invisible container to center the dock.

Next here we have the div.dock-el, which is the dock itself.

Notice the event handlers we have put on this element.

on:mousemove="{(event) => (mouseX = event.x)}"

This simply sets the value of the mouseX variable to the value of mouse's x-coordinate, or simply the distance from the left side of the screen.

on:mouseleave="{() => (mouseX = null)}"

This simply sets the value of mouseX back to null, as a way of telling our components that dock isn;t being hovered over, so it can disable the animation.

How does this tie into the whole thing? I'll explain soon.

Next up we have this little section:

{#each apps as appID}
<DockItem {mouseX} {appID} />
{/each}

We're looping through all the apps, which if you remember is the array of IDs of apps, by which name the app icons are stored in the public folder.

Next up is the DockItem taking in mouseX and current appID as props. We'll see how these are used within the component.

The juicy stuff 😋

Let's do the DockItem element now.

I'll drop the whole code here. Its quite big. Try reading it before the explanation, then the explanation will make more sense.

<script lang="ts">
  import { interpolate } from 'popmotion';
  import { spring } from 'svelte/motion';
  import ButtonBase from './ButtonBase.svelte';

  /** Block 1 */

  export let appID: string;
  export let mouseX: number | null;

  let el: HTMLImageElement;

  /** Block 2 */

  const baseWidth = 57.6;
  const distanceLimit = baseWidth * 6;
  const beyondTheDistanceLimit = distanceLimit + 1;
  const distanceInput = [
    -distanceLimit,
    -distanceLimit / 1.25,
    -distanceLimit / 2,
    0,
    distanceLimit / 2,
    distanceLimit / 1.25,
    distanceLimit,
  ];
  const widthOutput = [
    baseWidth,
    baseWidth * 1.1,
    baseWidth * 1.618,
    baseWidth * 2.618,
    baseWidth * 1.618,
    baseWidth * 1.1,
    baseWidth,
  ];

  let distance = beyondTheDistanceLimit;

  const widthPX = spring(baseWidth, {
    damping: 0.38,
    stiffness: 0.1,
  });

  $: $widthPX = interpolate(distanceInput, widthOutput)(distance);

  let width: string;
  $: width = `${$widthPX / 16}rem`;

  /** Block 3 */

  let raf: number;

  function animate(mouseX: number | null) {
    if (el && mouseX !== null) {
      const rect = el.getBoundingClientRect();

      // get the x coordinate of the img DOMElement's center
      // the left x coordinate plus the half of the width
      const imgCenterX = rect.left + rect.width / 2;

      // difference between the x coordinate value of the mouse pointer
      // and the img center x coordinate value
      const distanceDelta = mouseX - imgCenterX;
      distance = distanceDelta;
      return;
    }

    distance = beyondTheDistanceLimit;
  }

  $: raf = requestAnimationFrame(() => animate(mouseX));
</script>

<section>
  <ButtonBase>
    <img bind:this="{el}" src="/app-icons/{appID}/256.png" alt="" style="width: {width};" />
  </ButtonBase>
</section>

So let's break down the JS part of it. Notice there are blocks in the JS code. As in 👇

/** Block 1 */

There are blocks in the code. So let's break them down block by block.

Block 1

/** Block 1 */

export let appID: string;
export let mouseX: number | null;

let el: HTMLImageElement;

Nothing much here. We're exporting the 2 props we passed to this element in the Dock component above

<DockItem {mouseX} {appID} />

Then we have an el. This is going to hold the reference to the main image element. This image element is the one whose width would be animated. We have to refer it so as to compute the correct width during the animation.

Block 2

/** Block 2 */

const baseWidth = 57.6;
const distanceLimit = baseWidth * 6;
const beyondTheDistanceLimit = distanceLimit + 1;
const distanceInput = [
  -distanceLimit,
  -distanceLimit / 1.25,
  -distanceLimit / 2,
  0,
  distanceLimit / 2,
  distanceLimit / 1.25,
  distanceLimit,
];
const widthOutput = [
  baseWidth,
  baseWidth * 1.1,
  baseWidth * 1.618,
  baseWidth * 2.618,
  baseWidth * 1.618,
  baseWidth * 1.1,
  baseWidth,
];

let distance = beyondTheDistanceLimit;

const widthPX = spring(baseWidth, {
  damping: 0.38,
  stiffness: 0.1,
});

$: $widthPX = interpolate(distanceInput, widthOutput)(distance);

let width: string;
$: width = `${$widthPX / 16}rem`;

Let's break it down.

First off we have baseWidth variable. As the name suggests, it is gonna be the width of the images when they're not being hovered. But there's more. We're gonna build our whole animation calculations based on this variable.

distanceLimit and beyondTheDistanceLimit variables are used to setup how far from the cursor's position items should be scaled up

Next up we got an array distanceInput. To explain it, let's take a look at the photo below 👇

As you can see, we are hovering over the messages app, so it's the biggest right now. The vertical green line is where the cursor would be lying at the moment. The arrows extend out to 3 icons, on each side of the currently hovered over icon. Notice, that the farther you go, the smaller the icons become.

We can assert from this that the size of the icon is a function of its distance from the cursor. But what is the function?

By function I refer to mathematical functions, as in y = x + 1, or y = x^2 + x + 1.

Don't worry, we won't go into any math here. We'll let a helper function figure out the relationship between the distance and the size. I'll explain that in a moment.

And next we have a widthOutput array. Notice the pattern in here. First element is small, 2nd is bigger. 3rd is even bigger. 4th is the biggest! 5th is as small as the 3rd. 6th as same as 2nd, and 7th is the smallest, same as the first.

You can see this symmetricity in the distanceInput too. 7 items, following a similar pattern to widthOutput. So these arrays are related.Now all we need to do is find out how to relate them, so we can calculate the width for every icon based on its distance from mouse.

This is where the helper function to generate that relationship comes in. We're gonna use the popmotion library finally. It has a function interpolate that does that for you.

Before that, let's create our spring animation first.

let distance = beyondTheDistanceLimit;

const widthPX = spring(baseWidth, {
  damping: 0.38,
  stiffness: 0.1,
});

distance here is the variable in which we're gonna track, you got it, the distance of current item's center point from cursor. For now we'll initialize with the value of beyondTheDistanceLimit, so we don't get any accidental animations when user just hovers over dock.

widthPX is the actual spring animation, imported from svelte/motion. For an initial value, we simply pass it the baseWidth, which we want the icon to have when we aren't hovering over it or when it is far away.

We also have a config for this spring animation, in which I have put some sensible values to make the animation look natural. Feel free to play around with these.

Now we have this little snippet:

$: $widthPX = interpolate(distanceInput, widthOutput)(distance);

We're using Svelte's reactive statements to watch distance, and when it changes, our interpolate function will basically figure out the width for the current app icon, and set the value of widthPX to it. As widthPX is a spring timed store, it will simply keep changing bit by bit after we have set its value, just like a spring.

Next up, we have some unit conversion:

let width: string;
$: width = `${$widthPX / 16}rem`;

widthPX is in pixels. Pixels will work too, but I'm a rem and em guy. I like all my units to be in rems. So I will declare a value to hold the value in rem

As $widthPX will be constantly changing, we need to put a reactive statement here to make sure width is always synchronized.

Block 3

/** Block 3 */

let raf: number;

function animate(mouseX: number | null) {
  if (el && mouseX !== null) {
    const rect = el.getBoundingClientRect();

    // get the x coordinate of the img DOMElement's center
    // the left x coordinate plus the half of the width
    const imgCenterX = rect.left + rect.width / 2;

    // difference between the x coordinate value of the mouse pointer
    // and the img center x coordinate value
    const distanceDelta = mouseX - imgCenterX;
    distance = distanceDelta;
    return;
  }

  distance = beyondTheDistanceLimit;
}

$: raf = requestAnimationFrame(() => animate(mouseX));

Next up, we have the block 3 here.

We first declare a variable raf. This will hold a requestAnimationFrame instance. It's not needed, but not having it resulted in some bugs for me, so better keep it.

Next up, we have the animate function. We're passing in mouseX, the cursor's current position passed to it by the array element.

Inside the function, we got a condition checking if el, the image element exists, and the mouseX isn't null. This is the explanation folks, why mouseX value is either number or null. When it's set to null by the Dock component, the animation is simply ignored thanks to the if statement here.

Next up, in the if statement, we're simply doing some calculations to calculate distance of the center of the image from the cursor, adn finally setting the distance variable to the distance.

If any of the conditions fail, we simply set distance to be beyondTheDistanceLimit, so it falls out of the widthOutput range, and isn't animated

Remember how we have a reactive statement watching distance?
$: $widthPX = interpolate(distanceInput, widthOutput)(distance);
When the distance changes, widthPX will be updated. This in turn will update width to take on the value in rems.

Next up, we have a very important line here. A reactive statement requesting a requestAnimationFrame when running this function.

Note: Not assigning the RequestAnimationFrame to a variable(raf in this case) results in some bugs.

This is the end of the logic. Most of the work is over now. All we need to do now is set up the markup

Markup

<section>
  <ButtonBase>
    <img bind:this="{el}" src="/app-icons/{appID}/256.png" alt="" style="width: {width};" />
  </ButtonBase>
</section>

Just a section wrapping our image element for semantics, then we got a custom ButtonBase Svelte component. This is an unstyled button component that I created for general use. I'll drop the component code below. Not much to see here.

next up we have the star of the show: The img element.

We're doing a bind:this to set element reference to el variable.
src is requesting the icon from the public folder. In Vite, if something is in public folder, you can refer to it as if it was in the same directory as the file you're writing code in. We're injecting the appID prop in the string.
Lastly, style="width: {width}" is the one doing all the magic here. Simply setting width property to the width variable will do all we need it to do.

Lastly, this is the ButtonBase code:

<button {...$$props}>
  <slot />
</button>

<style lang="scss">
  button {
    color: inherit;
    text-decoration: none;
    vertical-align: middle;

    border: 0;
    border-radius: 0;

    outline: 0;

    margin: 0;
    padding: 0;

    display: inline-flex;
    align-items: center;
    justify-content: center;

    position: relative;

    user-select: none;

    appearance: none;

    background-color: transparent;

    -webkit-tap-highlight-color: transparent;

    &:not(:disabled) {
      cursor: pointer;
    }
  }
</style>

And the animation is done.

Demo.
Source

Hope you got something good out of it

Signing off 🖖

Mindblowing 🤯 TypeScript tricks

PuruVJ — Fri, 19 Mar 2021 17:46:24 +0000

Read on my blog in light, dark or sepia mode

Apologies for the clickbaity title 🙃. But it is in good faith, cuz I'm gonna introduce you to some TypeScript related tricks that are bound to blow your mind to pieces. And if you can read the whole post without feeling wonder at any trick, great for you!! You're TypeScript pro already 🥳

So let's cut to the chase.

A little note...

The level of this article is Advanced. You may not understand how things work. However, you don't have to. You only have to copy paste the snippet, and understand how to use it, as these will make your life easy, and overtime, you'll get the know-how of how these actually work.

In-built types 🥱

These are some of the built-in helper types in TypeScript. I'll keep this section short, as you can read about these anywhere. A good starting point would be TypeScript Docs Then we'll get to the juicy stuff 😋

Pick

It allows to pick specific fields from a type/interface, along with their types and create a brand new type. Let's take a look at this 👇

type UserFields = {
  id: number;
  name: string;
  gender: 'male' | 'female' | 'non-binary' | 'prefer-not-to-say';
  dob: Date;
};

type NameAndGenderOnly = Pick<UserFields, 'name' | 'gender'>;

// This is equal to 👇
type NameAndGenderOnly = {
  name: string;
  gender: 'male' | 'female' | 'non-binary' | 'prefer-not-to-say';
};

See!?! The same types, without any duplication.

Partial

This is the most used type of mine. If you have a type/interface, and for some reason, you wanna make all its fields optional, this is it 👇

type UserFields = {
  id: number;
  name: string;
  gender: 'male' | 'female' | 'non-binary' | 'prefer-not-to-say';
  dob: Date;
};

type OptionalUserFields = Partial<UserFields>;

// This is equal to 👇
type OptionalUserFields = {
  id?: number;
  name?: string;
  gender?: 'male' | 'female' | 'non-binary' | 'prefer-not-to-say';
  dob?: Date;
};

Readonly

This is very useful, when you wanna make sure that an object's properties can't be changed in your code. Think of it as a const for your object properties.

type UserFields = {
  id: number;
  name: string;
  gender: 'male' | 'female' | 'non-binary' | 'prefer-not-to-say';
  dob: Date;
};

const userData: Readonly<UserFields> = {
  id: 100,
  name: 'Puru Vijay',
  gender: 'male',
  dob: new Date('12 Nov, 2001'),
};

Trying to modify any property like userData.name = 'Hoolalala' will result in error.

Record

Now we are getting to the good stuff. I've had a new-found respect for Record recently, while working on my current project macos.now.sh (Shameless Plug, It's basically a macOS Big Sur clone written in Preact and Vite).

Take a look at this 👇

export type AppName =
  | 'finder'
  | 'launchpad'
  | 'safari'
  | 'messages'
  | 'mail'
  | 'maps'
  | 'photos'
  | 'facetime'
  | 'calendar';

/** Which apps are currently open */
export const openApps: Record<AppName, boolean> = {
  finder: false,
  launchpad: false,
  safari: false,
  messages: false,
  mail: false,
  maps: false,
  photos: false,
  facetime: false,
  calendar: false,
};

As you can see, this is just a simple key-value pair. But I wanted to enforce that this object contains all the apps listed in the AppName union type, and that all the values are boolean only. I also wanted to be presented with an error if I add a new app to the list, which would make me add that app's key value pair to this openApps object.

This is where Record comes in. It's simply a way to enforce the types of the keys as well as values. Another layer of safety that TypeScript adds.

Juicy stuff 😋

Now the fun part begins.

Retrieve element type from Array

Suppose you have an Array, and you wanna extract the type of each Element from an array

type ArrayElement<
  ArrayType extends readonly unknown[]
> = ArrayType extends readonly (infer ElementType)[] ? ElementType : never;

We're using TypeScript's infer here, which helps pick out specific types from a complex type.

Here's how to use it:

type A = ArrayElement<string[]>; // string
type B = ArrayElement<readonly string[]>; // string
type C = ArrayElement<[string, number]>; // string | number
type D = ArrayElement<['foo', 'bar']>; // "foo" | "bar"
type E = ArrayElement<(P | Q | R)[]>; // P | Q | R

type Error1 = ArrayElement<{ name: string }>;
//                         ^^^^^^^^^^^^^^^^
// Error: Type '{ name: string; }' does not satisfy the constraint 'readonly unknown[]'.

There's a bit simpler version to get the element type.

type ArrayElement<ArrayType extends readonly unknown[]> = ArrayType[number];

Retrieve type from a promise

Ever wanted to retrieve type from a function that returns a promise? You might've tried this:

function returnsPromise(): Promise<number>;

let num: typeof returnsPromise;
//       ^^^^^^^^^^^^^^^^^^^^^
// num: () => Promise<number>

We want num's type to be the returned type of the promise(in this case number), and the above solution definitely didn't work.

The solution is to once again use infer to retrieve the type from the promise:

type UnwrapPromise<T> = T extends (props: any) => PromiseLike<infer U>
  ? U
  : T extends PromiseLike<infer K>
  ? K
  : T;

usage:

function returnsPromise(props: any) {
  return Promise.resolve(6);
}

const num: UnwrapPromise<typeof returnsPromise> = 8;
//    num: number

Here we wrapped a function that returns a promise into this type. This works directly with a regular Promise<unknown> type too.

Why PromiseLike instead of Promise? \

Promise interface comes with lot of pre-built methods exclusive to promises. But sometimes, you wanna create functions that return a .then just like Promises, but not have all the properties that Promises do. In that case, we use PromiseLike

Aside: You could rename UnwrapPromise to be BreakPromise. Doesn't affect the code, but its good for laughs 🤣🤣

Turning a tuple into union types

This is a tuple:

const alphabets = ['a', 'b', 'c', 'd'] as const;

Note: Without as const at the end, typescript will interpret the type as string[], not as a tuple

Now we want to use these specific strings as union types. Easy peasy.

type Alphabet = 'a' | 'b' | 'c' | 'd';

This will do. But let's assume that this type and the array above are gonna end up in different files, and the project grows quite big, then you come back a few months later, and add another value e to the alphabets variable, and BOOM!!! The whole codebase breaks, because you forgot to add e in the Alphabet union type.

We can automate the Alphabet union type generation, in such a way that it pulls its members directly from alphabets variable.

type Alphabet = typeof alphabets[number];

And here's the universal type safe helper:

type UnionFromTuple<Tuple extends readonly (string | number | boolean)[]> = Tuple[number];

Usage:

const alphabets = ['a', 'b', 'c', 'd'] as const;

type Alphabet = UnionFromTuple<typeof alphabets>;
//  type Alphabet = 'a' | 'b' | 'c' | 'd'

Why readonly array? \
\
This section is about Tuple to Union types, but in the code itself we haven't used the word tuple. The reason is that tuple isn't a keyword. As far as TypeScript is concerned, a readonly Array is a tuple. There's no Tuple type or anything. That's why I'm making sure the type passed to UnionFromTuple is a tuple, not an array. If its an array, its basically the same as the section above where we retrieved the element type from an array

Union types from object

Let's say we have this object:

const openApps = {
  finder: false,
  launchpad: false,
  safari: false,
  messages: false,
  mail: false,
  maps: false,
  photos: false,
  facetime: false,
  calendar: false,
};

And I want to create a union type that's based on the keys specified here. If I add an extra key-value pair to this object, I want the union type to include that too.

Here's the solution:

type KeysOfObject<T extends { [K in string | number]: unknown }> = keyof T;

Usage👇

type App = KeysOfObject<typeof openApps>;

This will be equal to 👇

type App =
  | 'finder'
  | 'launchpad'
  | 'safari'
  | 'messages'
  | 'mail'
  | 'maps'
  | 'photos'
  | 'facetime'
  | 'calendar';

A better Object.Keys

Looking the article, it seems like its a compilation of Helper Types, which is the case. But in this one, I'm gonna share a tip which isn't the most mind-blowing or the coolest. Its pretty boring, but the important thing is that it's the most MOST useful tip in this whole article. If you have to take something away from this article, take this. Ignore the whole article except for this part.

Let's look the object from before:

const openApps = {
  finder: false,
  launchpad: false,
  safari: false,
  messages: false,
  mail: false,
  maps: false,
  photos: false,
  facetime: false,
  calendar: false,
};

Say I wanna apply Object.keys to get an array of the keys of this object.

const apps = Object.keys(openApps);
//  ["finder", "launchpad", "safari", "messages", "mail", "maps", "photos", "facetime", "calendar"]

Its not exactly a problem, per se, but it would be great to have Object.keys return the union types array of the keys.

So let's investigate the issue. We'll start with Object.keys definition in pre-built lib.d.ts:

interface ObjectConstructor {
  //...
  keys(o: object): string[];
  keys(o: {}): string[];
}

If you find it weird that keys is defined twice, its called Function/Method overloading. You can basically define multiple function declarations for flexible usage.

As you can see, its hard coded to always return string[]. I'm sure its there for good reasons, but its quite inconvenient for me, so I'm gonna override this method to infer the keys correctly from what it is passed.

If you have a root .d.ts file in your project, put the snippet below right in it.

type ObjectKeys<Obj> = Obj extends object
  ? (keyof Obj)[]
  : Obj extends number
  ? []
  : Obj extends Array<any> | string
  ? string[]
  : never;

interface ObjectConstructor {
  keys<ObjectType>(o: ObjectType): ObjectKeys<ObjectType>;
}

Now let's try the code above with the new Object.keys:

const apps = Object.keys(openApps);
// const apps: ("finder" | "launchpad" | "safari" | "messages" | "mail" | "maps" | "photos" | "facetime" | "calendar")[]

Don't trust me? Check it out yourself @ TypeScript Playground

Note: All the credit goes to Steven Baumgeitner's blog post about this exact same thing. I just ripped it off 😁. You can read more about fixing Object.keys on his blog post.

So, this is it!! Hope you got something out of this blog post!

Signing off!!

Moving React app to Preact ⚛ in 10 minutes with Vite

PuruVJ — Tue, 09 Mar 2021 08:20:24 +0000

Read on my blog in light, dark or sepia mode

Heya you awesome dev!!Glad to see ya here 🙂. This post is just a recount of my experience when I moved a medium size React app(30+ components) to use Preact, in just 10 minutes.

Is it true?

In case you are wondering if my claim of moving an app this big from one framework to other in just 10 minutes is true or just some clickbaity hoax, I assure you it isn't true. It didn't take 10 minutes for this.

It took somewhere around 8-9 😅😁

Yup. It took less than 10 minutes to move it. I put 10 minutes in the title b'coz humans love multiples of 10 a lot 😉

What is this app?

Alright, so the app in question is a fun side project I'm working on, macOS Web, which is basically a MacOS Big Sur clone for Web(Don't tell Apple 🤫). As you can see in the screenshot below, it looks like MacOS Big Sur, just running in the browser.

I started making it in React and Snowpack (Think of it as Webpack that does everything you want it do, without telling it anything) boilerplate, then around 2 weeks back, I moved it from Snowpack to Vite (Similar to Snowpack, just more refined and with more features.), and got some really cool features out of it.

Then just a few days ago, I tried an experiment to move it to Preact. I treat this project as a playground of sorts and am constantly stirring things up in it. I just made a new branch, and started fooling around. And surprisingly, this whole moving took less than 10 minutes.

Process

Here's a brief breakdown of the whole process.

Installing right dependencies

This is parts of my package.json file before the transfer:

{
  "dependencies": {
    "react": "^17.0.0",
    "react-dom": "^17.0.0"
  },
  "devDependencies": {
    "@types/react": "^17.0.0",
    "@types/react-dom": "^17.0.0",
    "@vitejs/plugin-react-refresh": "^1.3.1",
    "vite": "^2.0.5"
  }
}

As you can see, we have react and react-dom as dependencies, their respective TypeScript Typings as devDependencies, along with vite itself, and lastly the special package @vitejs/plugin-react-refresh. This last package is responsible for the Hot Module Reload magic of Vite with React.

Note: The package.json above contains only the relevant code for this article. There are over 20 dependencies in the actual project.

So how do we move to Preact then? The answer lies in looking at the preact-ts(Preact starter with TypeScript) starter template of vite, and the only content here was 👇

{
  "dependencies": {
    "preact": "^10.5.9"
  },
  "devDependencies": {
    "@prefresh/vite": "^2.0.0",
    "vite": "^2.0.5"
  }
}

Whoa!! That was drastic!! Notice that there's no preact-dom here, as preact has all the DOM stuff built in. Plus we have a different package @prefresh/vite. This I gathered was the HMR module for Preact with Vite.

So all I did was delete the react related packages, and installed these 2 packages(preact and @prefresh/vite).

Why no @types/preact?

Well, We needed @types/react because React doesn't ship its own Typings, which can make DX feel like shooting in the dark, so the community has kindly provided types themselves for it. \
But preact is a different story. It ships its own TypeScript typings, so we don't need any extra packages. It's just awesome that way 😍.

Modifying vite.config.ts

The vite.config.ts with React 👇

import { defineConfig } from 'vite';
import reactRefresh from '@vitejs/plugin-react-refresh';

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [reactRefresh()],
  esbuild: {
    jsxInject: `import React from 'react'`,
  },
});

And the new config is:

import { defineConfig } from 'vite';
import prefresh from '@prefresh/vite';

// https://vitejs.dev/config/
export default defineConfig({
  esbuild: {
    jsxFactory: 'h',
    jsxFragment: 'Fragment',
    jsxInject: `import { h, Fragment } from 'preact'`,
  },
  plugins: [prefresh()],
  alias: {
    react: 'preact/compat',
  },
});

Notice the esbuild property. Vite is built on top this super fast ES module bundler esbuild, here we are passing some options to it. jsxFactory and jsxFragment are exactly what they look like. The jsxInject here is a very ✨magical✨ property, that automatically puts the statement passed to it in every single file, so it saves you the trouble of importing h from preact in every single file, or React for a react app. And during the production build, vite strips out unnecessary imports, so files not needing preact will end up with no preact at all. So no harm is done ultimately.
In the plugins property, I have replaced reactRefresh with prefresh, and now our app supports HMR for preact.
Lastly, alias is the most, MOST important property here. In this project, I'm using 15+ packages that import directly from React, and moving to preact would have broken them completely. So the alias property accepts a key value pair. In this case, I'm pointing react to preact/compat, which is preact's compatibility layer to work with existing react apps.

Fix tsconfig.json

We are using TypeScript with React, and we have to tell it that the JSX factory and fragments are now different, so let's do that small change.

{
  ...
  "jsx": "preserve",
  "jsxFactory": "h",
  "jsxFragmentFactory": "Fragment"
  ...
}

Modify index.tsx

The entrypoint of our app is the index.tsx app, which would need some modification to work with preact. Luckily the changes needed are tiny.

The code before 👇

import ReactDOM from 'react-dom';
import { Desktop } from './views/desktop/Desktop';

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

Here we are doing a ReactDOM.render. But preact itself has a render method. SO let's swap it out with.

import { render } from 'preact';
import { Desktop } from './views/desktop/Desktop';

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

And BAM!! That's it. Only these 4 files needed to be changed. And this is how it all happened in less than 10 minutes.

Results

Let's talk business. What benefits did I get out of this weird, eccentric wish to move a whole codebase from one framework to another?

No need to change imports

There are over 30+ files that import something from react. And even now, they're importing from react. Only difference is that its actually preact/compat underneath. I didn't have to go and change every single import.

Reduced bundle size

react alone isn't everything. It needs to be paired up with react-dom, to actually render stuff on web. Both of these combined weigh 129KB minified, and 42.4KB min+gzip. That's not much really, but I'm a bundle size freak. I want as less size as possible.

Moving to preact did that for me. preact is just 4KB min+gzip. 90% smaller!🤯🤯. Quite miraculous, right?

Runtime performance

Oh boy, this one is very very interesting.

You see, first I heard of preact was 3 years ago. I found out this 3KB alternative to React, and I quite liked the concept. I also read in some article that its runtime performance was much better. I didn't care at the time, because really, browsers are amazingly fast, and runtime perf didn't matter to me much. So I never cared about it.

But in macOS Web, I realized I desperately needed better runtime performance because of some very janky animations in it. The whole app was very laggy. This was one of the motivations of switching to preact.

So when I was done moving the app, and fired up the dev server, my jaw dropped to the floor.

All the jank was gone!! Literally GONE. Just vanished in thin air. When I hovered over the dock, perfectly smooth. When I open menus, perfectly smooth. When I switched between light and dark themes, perfectly smooth.

You can try it out yourself. (Better you view them on desktop)

React version 👉 macos-web-fyri0fstj-puruvj.vercel.app \
Preact version 👉 macos.now.sh

See for yourself which is smoother.

Unsung hero

Until now I've been singing about Preact, but the true hero of the story is Vite. Look back into the section where I'm installing the dependencies. There's only 1 needed devDependency needed there, vite. vite does everything for you under the hood. It transpiles typescript without any unneeded packages, it transforms JSX into JS readable format, it minifies the crap out of the bundles, it supports all kind of pre-processors, and it does all that without you telling it to do that.

If I had initialized this app with create-react-app, which is kind of the standard, this migration wouldn't have been possible, as it would take a lot of time and lots of banging your head against the wall.

But with vite, it was easy as npm install preact and changing index.tsx to use preact instead of react.

Vite is very amazing, and very versatile. I'm very much in love with it and have no intention of moving away from it anytime soon.

And if you're skeptical about it, Vite is created by the creator of VueJS, Evan You. And its not just for Vue, it's very much framework agnostic. You can use it with any framework(React, Preact, Vue, lit-element, and more. Heck even the next version of svelte is going to be based on Vite itself).

So I really invite you to check Vite out sometime. It's like a breath of fresh air. Vite Homepage

I hope you got something good out of this article 😉.

Signing off!