DEV Community: Anton Korzunov

Weak memoization in Javascript

Anton Korzunov — Tue, 11 Jun 2024 07:56:40 +0000

I decided to write this article to explain how a few things work as I felt a lack of understanding. Things somehow connected to state management and memoization.
We need to talk about something very foundational, as well as about abstractions we can build on top.

This time nothing will be left uncovered. This time you will master worry-free memoization in javascript 😎

Memoization is such a common thing in JS world nowadays, common and very important. With the recent release of Reselect 5.0 it also became a little easier than before. Easier not to break fragile selectors without the need to understand all nuances.

Reselect 5 was released in Dec 2023, but the idea behind the breakthrough solution was boiling for quite a while, for a few years at least.
The first "modern" implementation I was able to find - weak-memoize - was created around 8 years ago.

I have reason to believe that the extended adoption time was influenced by my less-than-stellar communication skills and the challenge of conveying the principles behind "Weak Memoization," which I originally shared five years ago in Memoization Forget-Me.

Let's give it another shot.
Let’s walk the full journey from something 💁‍♂️ simple to something quite 👨‍🔬 extreme.
This time I'll make you believe.

Level 1 - make it work

Let's write a few lines related to performing an operation “once”.
What would the simplest memoization be?



// some place to store results
let storedValue;
let storedArgument;

function memoizedCalculation(arg) {
  // is the arg equal to the known one?
  if(arg === storedArgument) {
    return storedValue;
  }

  // if not - let's calculate new value
  storedValue = functionToMemoize(arg);
  storedArgument = arg;
  return storedValue;
}

// usage
const value1 = memoizedCalculation(1);
const value2 = memoizedCalculation(2);
const valueN = memoizedCalculation(2); // will be memoized

Looks familiar - I reckon a lot of projects have code like this in a few places.

The only real problem - this code is not reusable and… 🤮 global variables that are so hard to control, especially in tests. I reckon the obvious next step is to make it a little more robust and introduce a level 2 solution

Level 2 - put it in a box

Handling global variables is a complex job, so would making them local improve the situation?
How we can make this code more "local" and more reusable?

The answer is "factories"



// reusable function you can "apply" to any other function
+function memoizeCalculation(functionToMemoize) {
   let storedValue;
   let storedArgument;
   return function memoizedCalculation(arg) {
       // is the arg equal to the known one?
       if(arg === storedArgument) {
         return storedValue;
       }

       // if not - let's calculate new value
       storedValue = functionToMemoize();
       storedArgument = arg;
       return storedValue;
   }
+}

// fist create a memoized function
+const memoizedCalculation = memoizeCalculation(functionToMemoize);

// usage
const value1 = memoizedCalculation(1);
const value2 = memoizedCalculation(2);
const valueN = memoizedCalculation(2); // will be memoized

Interesting parts - nothing really changed from the usage point of view and nothing really changed from the function implementation - 99% of the code has been preserved, we just put another function around.

While this implementation is screaming "I am simple" - this is exactly how memoize-one is written, so it is “simple enough” to handle any production use case 🚀

This is a solution you actually can use. May be add .clear method to make ease testing, but that's all.

More importantly - "the original reselect" was also working this way, and that is "not the best way". Nobody was happy.

Something drastically changed in reselect 5, so let’s move forward and try to find that precious change.

Boss fight - there could be only one

The problem with reselect as well as memoize-one is that “one” - a single local variable used to store the results of the last invocation. In no circumstances it could be more than one, it just made this way.

Why its "one"? Everything is connected to the "pattern" being used and one's ability to cleanup the results of previous memoization.
That is the difference between "caching"(with cache-key, storage limits and time-to-life) and memoization free of any "complications".
Memoization Forget-Me explains these moments in detail.

🤔 How we can improve this? Maybe it's not "how" or "what". May be it's "where"?
🤨 Let me ask you - where this local variable is stored?

The correct answer for JavaScript is:

💁‍♂️ "it’s stored in a function closure”, without defining what is a “closure”

A more helpful answer is

🧐 "the variable is stored in a function stack”. The very one that can overflow.

In technical terms stack is an execution context - it stores information about current function arguments, all its local variables and where the function should return execution once it is done. It's a section in a memory holding the real data.

In the simplest situation calling a function "extends" stack and exiting a function "shrinks" it. Here is why calling to many functions can cause the stack overflow as it cannot grow endlessly.

However, in the Javascript world it is not so easy, because we have closures which can "see" variables from dead functions or in other words ➡️ the lifetime of a closure is unbound from the lifetime of its parent context. As a result "call stack" in JS is more alike a "graph of boxes" with personal stacks of different functions pointing to each other.

💁‍♂️ So every function has a little box📦 with the data. Very neat.
Here is an article with a little deep dive to v8 execution context details.

Every time you call a function it is executed using a different stack, a different context, a different "box". Exactly like React hooks being statically defined in a Function are magically getting values from React Fiber, which is an execution context for a particular component.

just ask yourself - where useState holds value. There should be a special place for it. There is always a special place for something, even in Hell...

👏👏 execution context gives an ability to run the same function with different variables 👏👏

You know - that sounds like this, which works almost the same way in JavaScript - providing context. And keep in mind - the keyword we no longer use is not only about classes - this works for every operation around.



 myFunction.call(this, arg1);

What if we use js context (this) instead of CPU context (stack)

Loading level 2 - somewhere else

First of all, I need to point at one implementation detail of memoize-one which considers a potential side effect of a hidden function argument(this) potentially leading to different outcomes

Consider the following code



class MyClass {
  onClick(event) {
     return this.process(event, this.state)
  }

  render() {
    return <div onClick={this.onClick}/>
  }
}

You might forgotten how it works, but in short - it does not 🤣 as we are losing this by reading a shared value from it. To correct implementation one need to inline callback



class MyClass {
  onClick = (event) => {
     return this.process(event, this.state)
  }

In this case, every this.onClick would be a very unique and very own onClick. For me, it sounds like a memoization.

Wondering how this operation of assigning "class members" works 🤨? Typescript playground to the rescue. But to save a click...



class MyClass {
    constructor() {
        // just stores stuff in "this".
        this.onClick = (event) => {
            return this.process(event, this.state);
        };
    }
}

Looking back at the original render method reading this.onClick you might notice that a value of this matters.

So, let's imagine that this is always present. What about updating our memoization function a little bit?
What if we store our memoization results variable inside context, so we could have as many memoized results as we need?
Let’s do something very straightforward (and quite similar to the legacy React Context)



function memoizeCalculation(functionToMemoize) {
-   let storedValue;
-   let storedArgument;
   return function memoizedCalculation(arg) {
       // is the arg equal to the known one?
+      // let's store data not in the "function context"
+      // but the "execution context". 🤷‍♂️ why not? 
+       if(arg === this.storedArgument) {
+         return this.storedValue;
       }

       // if not - let's calculate new value
+       this.storedValue = functionToMemoize();
+       this.storedArgument = arg;
+       return this.storedValue;
   }
}

Now we have the ability to store more than one result because we store it in different contexts.



myFunction.call(object1, arg1); // will memoize
myFunction.call(object2, arg1); // will memoize SEPARATELY
myFunction.call(object1, arg1); // will reuse memoization
myFunction.call({storedValue:'return this', storedArgument:args1}, arg1); // will BYPASS 🙀 memoization

That would work, but would also create the same problem Legacy context had - naming conflicts. We used it at the last line above, it's cool, but please dont do that in the real code.
Can we do better? Well absolutely! One line will do the magic!



function memoizeCalculation(functionToMemoize) {
+   // a magic place for our data
+   const storeSymbol = Symbol();
   return function memoizedCalculation(arg) {
       // is the arg equal to the known one?
+       if(arg === this[storeSymbol]?.storedArgument) {
+         return this[storeSymbol]?.storedValue;
       }

       // if not - let's calculate new value
+       this[storeSymbol] = {   
+         storedValue: functionToMemoize(),
+         storedArgument arg,
+        }
+       return this[storeSymbol]?.storedValue;
   }
}

That looks great - we created a "magic key" to safely and securely store our data. Many solutions out there use a similar approach.
However, I am still not satisfied because we penetrate object boundaries and store information where we should not.

Could we do better?

Level 3 - The Better Place

🎉 this is the chapter where weak memoization starts!

In the example above we were using this to store information. We were storing this information directly inside this, but the task was always about tracking relations, nothing else.

information is related to this

this[key]=information

this[information]="related

Every time you encounter such a situation ask yourself - is there a better primitive to handle the job? In database terms, it could be a separate table storing relations, not another field on the thisTable

And indeed there is one primitive we could use here - Map, or to match our use case a WeakMap

WeakMap will hold information about A->B and automatically remove the record when A ceases to exist.
Semantically map.set(A,B) is equal to A[B]=true, but without hurting A

This is how our updates memoization will look like



function memoizeCalculation(functionToMemoize) {
+   // a magic store
+   const store = new WeakMap();
   return function memoizedCalculation(arg) {
       // is the arg equal to the known one?
+      const {storedArgument, storedValue} = store.get(this);
+       if(arg === storedArgument) {
+         return storedValue;
       }

       // if not - let's calculate new value
+      const storedValue = functionToMemoize();
+      // we do not "write into this", we "associate" data
+      store.set(this, {   
+         storedValue: functionToMemoize(),
+         storedArgument arg,
+        });
+       return storedValue;
   }
}

Now we store information related to this and functionToMemoize in some other place.

But the presence of context was an assumption, in reality is usually absent.
How we can change this approach to get at least some benefits from the given approach without relaying on this presence?

🤷‍♂️ Easy, just introduce another variable.



// "master default"
+ let GLOBAL_CONTEXT = {};
function memoizeCalculation(functionToMemoize) {
   // a magic store
   const store = new WeakMap();
   return function memoizedCalculation(arg) {
+      const context = this || GLOBAL_CONTEXT;
       // is the arg equal to the known one?
+      const {storedArgument, storedValue} = store.get(context);

And we can do another another step forward
What about automatic cleanup for all functions to ease testing (and help catching memory leaks).



let GLOBAL_CONTEXT = {};
// instantly invalidates all caches
export const RESET_ALL_CACHES = () =>GLOBAL_CONTEXT={};



+ export const GET_CONTEXT = () => userDefinedWay();
// ...
   return function memoizedCalculation(arg) {
+      const context = GET_CONTEXT();

So now we actually got this omnipresent context and more importantly - we can control the version of store exposed to the memoization by controlling this GLOBAL_CONTEXT.
Here we can even start using Asynchronous context tracking to have per-tread or per-test memoization separation out of the box.

And you know... I would only keep it and remove this we do not really use anymore 😎

🤑 BONUS: Just update GLOBAL_CONTEXT - all cache would be invalidated with all previous values garbage collected. Magic 🪄!

Cool, the code above is actually useful, but we are still quite far from anything useful and anything as good as reselect v5. Let’s follow to the next level!

Level 4 - cascading

Let’s make a little detour here. Reselect5 was not developed from the scratch, it was inspired by React.cache function, which is not deeply documented and not many developers really understand how it works.

So let’s check the code! Here is a link. And here is the first section of the code



export function cache(fn) {
  return function () {
    // try to read some "shared" variable, like `GET_CONTEXT` in the above
    const dispatcher = ReactSharedInternals.A;
    if (!dispatcher) {
      // If there is no dispatcher, then we treat this as not being cached.
      return fn.apply(null, arguments);
    }
    // and get some "fnMap", so alike to our "store"
    const fnMap = dispatcher.getCacheForType(createCacheRoot);

And it actually looks very close to the code we just written

some "omni present" variable - ReactSharedInternals.A gives us a pointer to the cache store
and we will "read" and "write" to it
there could be more than one such context at the same point of time, which is quite valuable for SSR being executed in a parallel
React.cache just stores result in different places for different renders.

But there is another important moment in React's implementation related to a "single result" being stored. React.cache uses cascade. And Reselect v5 does exactly the same, and memoize-weak does the same and kashe does the same



for (let i = 0, l = arguments.length; i < l; i++) {
      const arg = arguments[i];
      if (
        typeof arg === 'function' ||
        (typeof arg === 'object' && arg !== null)
      ) {
        // Objects go into a WeakMap
          cacheNode.o = objectCache = new WeakMap();
          objectCache.set(arg, cacheNode);
      } else {
        // Primitives go into a regular Map
          cacheNode.p = primitiveCache = new Map();
          primitiveCache.set(arg, cacheNode);
      }
    }

In some implementation null is rerouted to a const NULL={} object in order to allow WeakMap usage.

It creates a 🌳Tree-Like structure with nodes being WeakMap or Map, depending on the argument type.

Think about the RedBlack tree from above, with black nodes being Map and red nodes being WeakMap

One important downside of this approach could be found at the original issue

I use a WeakMap so that objects that can't be reached again get their cache entries garbage collected. Expandos aren't appropriate here because we also can GC the cache itself.

There are unfortunate cases like cachedFn('a', 'b', 'c', 'd', {}) will get its value GC:ed but not the path of maps to it. A smarter implementation could put the weakmaps on the outer side but it has to be more clever to ensure that argument index is preserved. I added some tests to preserve this in case we try this.

In the given example first arguments are not weak-mappable, so the cascade will be not garbage collected, but the values returned by a cached function - will.

Unless there is no weakmappable objects at all
But everything will be cleaned up once the current rendering ends and the "main symbol" get's removed.
so that's not an issue

🏆 The Cascade is what made Reselect 5 superior to all previous versions. Now it can store more than one value, because it's not a single local variable, its a tree 🏆

Level up - an extra ability

As long as we are using React as an example - there is one more feature connecting the dots between something we talked about - Taint API

taintObjectReference lets you prevent a specific object instance from being passed to a Client Component like a user object.

How does it work? Exactly like the "relations" from above (link to sources)



export const TaintRegistryObjects = new WeakMap();

export function taintObjectReference(
  message,
  object,
) { 
  // here it goes
  TaintRegistryObjects.set(object, message);
}

/// ...
const tainted = TaintRegistryObjects.get(value);
if (tainted !== undefined) {
    throwTaintViolation(tainted);
}

WeakMaps establishing relations and is helping with so many things.

So here it is

I hope you enjoyed this journey, and this evolution of concepts helped you better understand how things are connected and how different primitives can help you.

Go use this new knowledge!

Quick recap

every program need to store variables somewhere. Usually you don't control this moment, but sometimes you do
by controlling where values are stored you can create many different things - from weak memoization to react hooks
there are libraries our there, like the latest generation of reselect, that gives you superpowers to worry less about memoization
there are still some edge cases where you might need to have a special logic, for example with React separating memoization between different render threads
- kashe provides a little more low level control over it, including supporting nodejs's AsyncLocalStorage for thread separation. Give it a try.

PS: And as I've mentioned React, hooks, and stack -
The future of React.use and React.useMemo points at the interesting discussion that could be totally understood differently once hooks using fiber as a "single stack" model will start using something more like closures, ie independent context.

Partial: how NOT to mock the whole world

Anton Korzunov — Thu, 08 Feb 2024 03:31:12 +0000

Mocking is a very controversial concept in testing - some thought leaders advocate it as something "bad"😤, while others have to use mocks🙃 one way or another.
No matter what we think about it - mocks are around.

However, mocks can be different

they could be network mocks (use msw)
or they could be state mock injected by jest.mock or any other force (I would recommend magnetic-di)

But in all cases, there is a hill to die on - are you going to mock the entire universe 🛸 or just a little bit?

Let's start with the 🪐 entire universe

Jest.mock

jest.mock(or vi.mock) is a good example of "everything" - this helper mocks the entire module providing "empty stubs" for the original content.

Imagine a use case



// index.ts
import {getConfiguration} from './config';

export const isAdmin = () => getConfiguration().user.isAdmin;



// index.spec.ts
import {getConfiguration} from './config';
import {isAdmin} from './';

jest.mock('./config');

test('isAdmin', () => {
  // ??? 🤷‍♂️
  expect(isAdmin()).toBe(true); 
});

To make this test run you need to specify the correct mock override for getConfiguration. Can you do it?

Let's try



  jest.mocked(getConfiguration).mockReturnValue({
    // 50 different fields
    user:{
     // 20 other fields,
     isAdmin: true
    }
  });

So you can, but you have to specify the "whole world", or typescript will not be happy.

You will not like it as well 🤮

What about defaults?

A better way to manage mocks is by providing defaults one can "extend" from

For example



import {defaultConfiguration} from './configuration-test-utils';
// ...
jest.mocked(getConfiguration).mockReturnValue(
    merge({}, defaultConfiguration, {
       user:{
        isAdmin: true
      }
);

That would greatly simplify life and establish an environment easier to maintain.

However it is still about mocking the whole world, while you need only one field 😭

Only one!

In out case we dont need to mock everything, it's more about TypeScript being too type-safe. Let's stop this!



jest.mocked(getConfiguration).mockReturnValue({
    user:{
     isAdmin: true
    }
} as any/* 😘 */);

// test passes ✅

Well, as any is not the best idea. Here is where DeepPartial helps

Partial is a TypeScript helper making keys of an object non-required. DeepPartial is just a recursive helper for it. It has many implementations, here is one

This gives us the ability to write code like



jest.mocked(getConfiguration).mockReturnValue({
    user:{
     isAdmin: true
    }
} as DeepPartial<ReturnType<typeof getConfiguration>>);

Yeah, the last line is 🤮 and one can improve it with utilities like shoehorn hiding all complexity underneath.



import { fromPartial } from "@total-typescript/shoehorn";
jest.mocked(getConfiguration).mockReturnValue(fromPartial({
    user:{
     isAdmin: true
    }
}));

Better? Better!

....

However, what would happen if we change our code? You know - code always drifting somewhere...



export const isAdmin = () => (
  getConfiguration().user.isAdmin || 
  getConfiguration().user.isSuperAdmin
)

No tests will notice the difference, but our partial mock is no longer the correct one for our use case.

We need something better.

“actually better” is to refactor the code in a way you dont need to mock everything, but we are trying to complete the task without changing the game rules as not everybody can afford refactoring and not everybody want to make their test more testable for the sake or abstract testability (aka test induced design damage)

Something better

Let's change our test a little bit



// index.spec.ts
import {partialMock} from 'partial-mock'; // ⬅️⬅️
import {getConfiguration} from './config';
import {isAdmin} from './';

jest.mock('./config');

test('isAdmin', () => {
  // ⬇️⬇️
  jest.mocked(getConfiguration).mockReturnValue(partialMock({
    user:{
     isAdmin: true
    }
  });

  expect(isAdmin()).toBe(true);
  // but instead it will throw 
});

Here we used partialMock utility to apply DeepPartial(but shoehorn can do it), but also break test because the provided mock no longer represents the case.

reproducible example - https://codesandbox.io/p/sandbox/partial-mock-example-8vr77s?file=%2Fsrc%2Findex.ts%3A21%2C20

What about "over mocking"?

Imagine the opposite situation - something complex becomes simpler, but your mocks are still too much.

For example, imagine we do define isSuperAdmin missing in the example above, but we will no longer use it



const mock = partialMock<Data>({
  isAdmin: true,
  isSuperAdmin: true,
});
expectNoUnusedKeys(mock);

Sandbox - https://codesandbox.io/p/sandbox/overmocking-partial-mock-example-z8qd5w?file=%2Fsrc%2Findex.ts%3A22%2C1

That's it, folks

That's it - partial mock helps with the "over-mocking", situations where you mock too much, and it also solves problems with the "under-mocking" where you missing some important pieces.

Pretty sure you never though about under-mocking. Until now.

Link to follow:

🧶YarnLocking🔓 your dependencies

Anton Korzunov — Sun, 09 Oct 2022 04:13:02 +0000

Hey mate 👋. Have you seen a yarn.lock file? It can be package-lock.json, pnpm.lock or npm-shrinkwrap, it does not matter that much. What matters - this file have a purpose.

package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json. It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.
– A manifestation of the manifest

In short - lock files represents and store information about dependencies other than your direct ones, and particular version of such indirect dependency to use.

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

There is no time to explain everything in the details, let me show you the problem.

Chapter 1 - understanding the problem

Lets create an issue

Many of us used lock files for years and used them without any troubles. Everything seems good, but there is one nuance we need to discover. A little feature we are going to reveal. Let's run an experiment.
I will use yarn to demonstration purposes.

The experiment itself is for demonstration purposes only. Just blindly follow the steps or magic might not happen

Step 1. Create empty repository.
- yarn init and "install" it - yarn
- you should get an empty yarn.lock file and empty node_modules folder
Step 2. Let's add first dependency. Let it be tslib@2.0.3
- yarn add tslib@2.0.3
- that would create a record in yarn.lock like

tslib@2.0.3:
  version "2.0.3"
  resolved "https://something-something/tslib-2.0.3.tgz"
  integrity sha512-long-and-ugly==

Step 3. Let's massage our environment and manually amend package.json and yarn.lock to use tslib:^2.0.3
- in package.json: "tslib": "^2.0.3"
- in yarn.lock: tslib@^2.0.3
- then run yarn
- ⚠️ it is important to have the following record in yarn.lock, which means "tslib@2.0.3 used for tslib:^2.0.3"
  - 🤔 the same will happen if 2.0.3 is the latest version available. Well, it's not the latest now, but was in the past
  - 💡 please remember this moment as a direct edit of the lock file

tslib@^2.0.3:
  version "2.0.3"

Step 4. Add another dependency depending on tslib
- yarn add focus-lock (v0.11.2). This package depends tslib:^2.0.3😉. Perfect match.

let's verify - our yarn.lock should contain only two dependencies - focus-lock and tslib

So that's it. We have created a problem 😎. You don't see it? Yep, the real issue is that nobody sees this problem. But it's already here.

The problem is - we have two dependencies "perfectly" matching each other.

Is it a problem?

😉 Let's perform one more experiment.

Step 1: remove tslib
- yarn remove tslib
Step 2: check your yarn.lock, and it will be unchanged, as tslib is still used by focus-lock
Step 3: shrug 🤷‍♂️
Step 4: remove yarn.lock
- run rm ./yarn.lock
Step 5: reinstall packages
- run yarn

Now check your lock file 😉. It will contain the same tslib:^2.0.3, but this time it will be resolved to 2.4.0 (the last version available by the time of writing this article)

tslib@^2.0.3:
  version "2.4.0"

You might not get the joke, let me rephrase it

😳 Existing dependencies and the order of their addition affects the shape of the end artefact 😬

In the first experiment focus-lock reused preexisting tslib
In the second one there will no such constrain and it used the "freshest" one.

Read it another way - any new dependency you will try reuse what you already have. Any dependency you update will try to reuse what you already have. Your's legacy, your's past, your's yesterday affects your tomorrow.

As an example - nextjs installed today and the same version of nextjs installed tomorrow can have at least different version of caniuse, as it released on a daily schedule.

But that is just a half of the problem. The real one - you can still have unexpectedly obsolete packages and hear me out - focus-lock by itself is using and is being tested with tslib 2.3.1, declaring a version below as a dependency because "it does not need any newer". Or needs, but have no idea about it, because cannot test itself agains other versions of own dependencies.

Yep, this is exactly how I broke someone one's project - import error: '__spreadArray' is not exported from 'tslib'

Another example maybe?

The example above was a little synthetic. Ok, VERY synthetic. Frankly speaking it took a while for me to find a way of reproducing such behaviour in a short and sound way, as usually everything was working well. Without direct edit hack, the one I've asked you to remember, issue will be not created.
But what would be different?

Let's redo everything from scratch, but skip the hack. Depending on particular actions and events it can result in

tslib@^2.0.3, tslib@^2.4.0:
  version "2.4.0"

or TWO versions of tslib, which can be collapsed into one via deduplication and there is another story about it.

Our problem is a part of duplication one. About the same version fragmentation and bloating node_modules with, but more often without a reason.

You might have already A LOT of duplications in your lock file - try to dedupe them if you never tried and tell me the results. At least check how many tslibs you've got.

PS: deduplication is available for any package manager, as a built-in or as a separate package. Just google.

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

A real life example?

🤔 probably the last example was also now quite sound. Let's create something better. Something that has bitten me personally multiple times.

Let's talk about a real stuff, about consuming intertwined packages.

1️⃣ cool-widget uses cool-form uses cool-button (and other packages)
2️⃣ cool-widget uses cool-button as well 😎

Again - this case is not applicable to simple projects. This case is not very applicable to monorepos.
This case requires a presence of some flexibility and a non-zero distance between package. It needs a lag, it needs a gap, it needs a latency.

This case needs one repo consuming another to have a gap in the npm logistic layer in between

Let's create a supply chain disruption ⬇️

1️⃣ Imagine you have a Button. Just a button exported as a npm package - cool-button. Every UIKit has such primitive.
2️⃣ and then you use that cool-button in many other packages. For example in cool-form and cool-widget
3️⃣ and cool-widget uses cool-form
- It is a big organism consuming other molecules(form) and atoms (button).
...
➡️ And then you introduce a new major version of your very cool-button 🙀.

The tricky part here is how "major version update" propagates through packages:

cool-button should have get a major version bump due to public interface change
cool-form might got a patch update, as nothing changes for it's public interface. Button is implementation details and is not affecting look-n-feel of a form
cool-widget actually does not have to do anything.... or haven't updated all required dependencies yet.

Our cool-widget might be patch-updated, as it does not change public interface, just internals, and

it may use a new version of a cool-button, because some renovate-bot (or a button's developer) updated it in all consumers.
depend on a cool-form, which also was just updated to use a new button, but... 😉 there is no reason for cool-widget to update dependency on cool-form as nothing actually was changed. It's the same cool-form.

In other words - dependency `cool-form` will be kept as is

What 😕? How so? Why not updated?

Let's stop here and check if cool-widget have to react and incorporate every single move of every single piece. Any reason?

🤷‍♂️ Why someone should be bothered to bump every dependency in package.json every time every dependency, a little spare part of a bigger whole, updates? It could be ten times a day for ten packages, and it sounds like a lot of useless work! Especially some work is required to perform update, run test, verify the result, deploy the result. Oh

Ok, ok. Let's imagine you are fine with it, You want it. So a button update will cause:

1️⃣ a cascade update of ALL packages depending on it,
2️⃣ and then of all packages depending on just changed
3️⃣ and then of all packages depending on just changed
4️⃣ and then of all packages depending on just changed
5️⃣ should I stop here?

It actually can be a loop - sometimes packages might depends on previous versions of themselves. Like babel uses babel to compile self.
So 😕 I really hope you don't want that. You probably do update in batches, or not really doing it at all, and that's ok - if stuff does work, just don't touch it.

Long story short - cool-widget have got a new cool-button@v2 directly updated, but still have the old cool-button@v1 from the kept-as-is cool-form

So now we have two buttons, with different major versions, and this cannot be deduplicated.

😠: "HEY! Wait a minute. I've got you and I am promising to be a good lad and keep my deep dependencies up to date!"
😿: "Unfortunately this is not about you, this is __about packages created by someone else, about the packages you don't control"
😕: "I dont control?"
😾: "You don't"

You have got a problem with stale intermediate dependency. A dependency of your dependency which you don't directly control. And a dependency [of your dependency of your dependency]. And a dependency [of your dependency of your dependency of your dependency]. And ....

And that is the problem we were chasing all this time.

First time this issue was encountered back in 2017 – Yark: How to upgrade indirect dependencies?

Chapter 2 - Solving the problem

It's an easy job to point a finger on a problem and tell everyone - "People! Here is the problem".
It is completely another job to propose a solution.

Going back and upgrading

Lets make another step back and look on what you do control - the direct dependencies:

you can declare dependencies you need and their versions
- as their versions might represent a wide range - the particular versions to use will be stored in your lock file
- if by any reason you get a newer version of already existing dep - it will be automatically raised to the highest one. If not automatically, then after dedupe.
- 😅 so by installing a new dep you can change dependencies of your existing?
  - This is why changes in yarn.lock might need a review
you can manage and especially update those deps.
- use yarn up, or yarn upgrade-interactive
- or use a little bit more advanced npm-check-updates
- in both cases only package.lock gonna be changed

This is how you can control direct dependencies. The ones explicitly declared in your package lock. You have no control over indirect dependencies totally derived from requirements of the real ones.

Package managers are trying to preserve as much as possible in order to reduce the impact of the change and amount efforts users might need to perform in order to manage consequences. Known as Principle of least action.

Package manager's job is to keep things. Our goal is to _loosen some bolts...

Please welcome...

Yarn-unlock-file

yarn-unlock-file is a new library, capable of editing your lock file and addressing issues created by indirect dependencies

The simplest use case is nothing more than

npx yarn-unlock-file all
# and don't forget to
yarn

That is it - the command will:

🔐 keep any of dependencies declared by you
🔓 "unlock" all indirect ones
- "unlock" means "delete" old records from yarn.lock letting the newer, might be more correct versions to be installed

What you are dependencies?

There is one thing we forgot – the purpose of package managers. What is yarn, what is npm and what they do...

PackageManagers are primarily managing logistics - they provide transport layer between npm repository and your project.
Then PackageManagers are in charge to recreate the same environment, the same combination of packages across different machines to make our live more predictable.

However, if you use a library, you probably rely on it to be tested and behave well, but this is possible only if the library was assembled in your projects in exactly same way it was built and tested in the place of the origin - it's own space.

So it's important to let free artificial boundaries preventing the similar environments

Everything has limits, and a perfect tool capable to capture and freeze your decisions in time might need a hand.

No tool should change your decisions and change package versions picked by you, but it might help you manage decisions you haven't made consciously - concrete versions for your indirect dependencies.

Try commands like

npx yarn-unlock-file dev to update only devDependencies, or
npx yarn-unlock-file matching @material-ui/* to update dependencies of material-ui but not MUI itself

Safety first

There is a reasons why we are not just deleting yarn.lock - the result can be unpredictable. Or it can be "too much" - you will get a broken build or a broken application if your tests are not great in detecting anomalies.

One should bumping your dependencies regularly, but it's not always safe and can go unpredictable in large projects.
- One might update versions in the same range, and "unlocking" is a good way to do that.
One might still be cautions about updating direct dependencies, or even dependencies of dependencies. But not many layers is there?
- npx yarn-unlock-file levels all will tell you how much.
  - I haven't seen more than 8.
  - I haven't seen less than 3.
- 😎 updating dependencies of dependencies of dependencies should be safe
  - npx yarn-unlock-file all --min-level 3

Dry run

Well, why one should blindly trust some tool to delete only what you want. Trust, but verify. Use dry run mode.
npx yarn-unlock-file all --min-level 3 --dry-run

The picture above is a good indication of how many layers can be hidden inside a simple solution, memoize-one in this case.

One might ask the question - why level 8 dependency is-arraysh is here, and what causes it?

lets ask: yarn why is-arrayish > nyc#test-exclude#read-pkg-up#read-pkg#load-json-file#parse-json#error-ex#is-arrayish
let's update only this branch: npx yarn-unlock-file matching nyc --dry-run

1️⃣ look 2️⃣ pick min-level you are comfortable with 3️⃣ wipe

Note about Npm-check-Updates

ncu has a "doctor" mode to update dependency, run tests, and only then update another dependency.
While this works just great - it actually can tangle your lock file beyond imagination because packages you install today affects the shape of package you install tomorrow 😉

Having more control over this process is quite beneficial.

For years I was giving an advice of "just find something in your lock file and delete".
For years I was looking into yarn.lock updates to correct result of deduplication sometimes by selecting a few hundred of lines to delete and regenerate.

🤷‍♂️ enough is enough. It's time to understand that deterministic builds is one problem, but supply chain disruption is different.

Authors of packages and tools you use expect and test their creations using some know (to them) set of other packages and tools, which are in turn rely on some other set of libraries. Any dependency specified within an accepted "range", and most of them are, is a subject for version mismatch. Or an expectation that the end consumers will use a new patch version of a tiny library with something very important fixed.

There are dependencies you know, the ones you want to use.
Everything else has to be unlocked on a weekly basic.

You can use Renovate, Dependabot or npm-check-updates
// Detect dark theme var iframe = document.getElementById('tweet-1569310121880350722-730'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1569310121880350722&theme=dark" }

But it's not enough
https://github.com/theKashey/yarn-unlock-file

PS: Did you know that dependabot can update dependencies in your lock.file? Like here it bumps terser changing only lock file, because it's an indirect dependency.

So what?

Just try it

npx yarn-unlock-file dev
yarn

And then we will see 😈

💡: this is a first, partially experimental solution, currently capable to handle only yarn(v1 and v3).

UI? Piece a Cake

Anton Korzunov — Sun, 31 Oct 2021 08:17:41 +0000

One of the first false assumptions one could face during a long journey of becoming a developer, is that said journey is just about development, about you just writing some code.
Like - start a new project by writing code, and finish it in the same way.
Only later one will be told about testing, or the need to solve real customer problems, and other "business as usual" stuff, not sure which one came first.
It's fine to start your journey in this way, everything needs a beginning, but this is not how it should continue.

This is not how it could succeed.

Our job is not about writing code, it's about writing the right code, writing it "Once and only Once", testing it, solving problems and finishing assigned tasks.

It's not about creating >new< things, 
but more usually about changing the >old< ones.

Software engineering is programming over time. Engineering is about considering the long-term effects of your code. Both direct and indirect. Link

Read it this way - while moving forward think hard about what you are leaving behind and what you need to make the next step.
💡 Applicable to your life as well.

While the vast majority of information you can find out there is focused on how to "make" things, let's talk about future maintenance, about reducing different burdens - from the classical technical debt to cognitive load.

Let's talk about the multidimensional "Cake" approach, also known as Multitier architecture, also known as Onion Architecture, and how it applies to UI-based applications.

Where is the Problem?

The problem is not only "where", the problem is also "when".

Let's imagine that you are working on a very agile project, of course you are, and you just bootstrapped a new application that already has experienced two pivots and going to have another one.

The essence of Agile is about being reactive to the changes.

It is absolutely ok to start a random redesign, it's absolutely ok to abandon an almost complete feature and start redoing it in a little different way, it's ok to adapt for the new requirements and the only thing a developer should be focused on this point - be able to preserve as much as possible, about how NOT to start every time from the scratch. That happens to all of us but is not any efficient.

While the majority might understand the solution for a "Happy Live" as Pit of Success, where a well-designed system makes it easy to do the right things and annoying (but not impossible) to do the wrong things, it's still about making things(note "do the right thing"), not changing something existing, even something created yesterday (we "agile", right 🙄?).
I reckon the Solution for the change might have roots in the Chaos Engineering, where you have to accept that something will go wrong, a build a system resilient to it. While the essence of this philosophy is something you should always have in mind, there is another way to address the same problem.

Chaos? This is what happens during(before or instead of) the family Christmas dinner, meetup and especially during the Gala Concert - too many things are happening at once and everybody is just running around screaming. In all cases, the path to success is to have some protocols, procedures and preparation.

Path to Success is a proper foundation.

Standing on the shoulders of Giants - a general concept that prior knowledge, and not only knowledge, could and should be used today 👇

Using the understanding gained by major thinkers who have gone before in order to make intellectual progress

every time you use webpack, or any other bundler, and do not create your own one - you stand on the shoulders
every time you use React, or any other UI abstraction - you stand on the shoulders
every time you use any library, not writing code from scratch - you stand on the shoulders

The majority of developers would use some preexisting (third party) solution to solve their problem, and would stand on the shoulders of other developers and "The Platform", but the same majority of developers are also missing the ability to stand on their own shoulders.

👉 every time you need to change something, there should be a giant you can rely on. You have to giant yourself.

A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination. What is a 'Platform' anyway?

I've seen it

We will jump into some concrete examples shortly, but let's first create some concepts to act as a foundation, let's create our first small Giant, the one you should know very well.

🤖 Terminator 1 -> 🦾 Terminator 2 -> 🦿Terminator 3. They all are backing plot of each other. Without the very first you cannot have the second.
📖Book (Hobbit) -> 💍Film (Hobbit, well 3 films). While there are many differences between the book and the film, they share the same foundation
🤯Total Recall(1990) -> 🤯Total Recall(2012). Those films have nothing in common, except 😉 the same foundation.

Every remake, every sequel or prequel, every film based on a book or a book based on a film are examples of Standing on the Shoulders of Giants

Which other Giants exist?

Layers

Before you run away let us pick some examples you definitely will understand. Probably it will be more correct to say - that a lot of people for some strange reason expect you to understand it, and once upon a time during every second interview for a JavaScript position you might be asked about this thing, and it always was not very clear for me, like it's 100% not related... until today.

The Layers of OSI Model, also known as a internet layer cake

Hey! I said do not run away! Look how one layer of OSI stands on the shoulders of another.
There is no difference for you how the device you are reading this information from is connected to the internet - Ethernet, Wifi, 2G, 4G or 5G - it just works. The top-most(7th) layer is unbound from any network hardware.

Implementation details are abstracted into many layers and some of those layers are even interchangeable(WiFi!==Ethernet!==Cellular).

I hope you would like to experience the same smooth journey during UI development. Strangely, but often developers are trying to shorten processes, collapse layers and especially not separate concerns and trying to get something valuable from it. Again and again, with no Giants supporting them.

Well, might be using OSI as an example was a little too much, but

would you consider React as a layer?
would you consider webpack as a layer?
would you consider MaterialUI as the next layer?
and NextJS as one more extra layer?

For the User, there is no difference if an Application has been built with Nuxt, Next or bare webpack. For webpack there is also no difference if it is used by the application directly or hidden inside Next.

Can you see all those giants, on the shoulder of which your application is standing?

If you ever wonder why your node_modules are so huge, better to say GIGANTIC -> that's it! 😅

Another good example is Redux, as "Redux" by itself means nothing. It can be very different and you'll never know which recipe was used to bake it.

Redux+Thunk, or Redux+Saga provides a little more context for an expected taste of a given solution, however only RTK looks like a properly layered cake. Mmmm, tasty!

The Whole and the Parts

Speaking of Redux, there is a very common "mistake" in the understanding of the difference between "Redux" and "Context API". To be more concrete - the difference between useReducer + React.Context API and Redux as the latter is technically the same as "Reducer + Context".
Right after the React Context presentation many people, really many people, were wondering - 🤔 do they really need Redux or what?

Well, probably they didn't, but the more proper way to explain what is wrong with such a common and simple misconception is to refer to Weinberg’s Law of Decomposition, which states "the whole is greater than the sum of its parts".

Very easy to prove, just combine baking 🤯 soda and vinegar 💥.

By the fact, Redux is not only reducers, but also patterns, DevTools, and different middlewares for different use cases.
While Redux is ContextAPI + Reducer, it is BIGGER than a sum of its parts.

👉 the real work of an engineer is to see such bigger wholes looking at the pieces. Some things are visible only from a distance. Take a step back, do not focus too much on low-level details.

An interesting moment about said law is that it simultaneously states the opposite:

Weinberg’s Law of Decomposition is subtler. It says that if you
measure a system according to some gauge of functionality or
complexity, and then decompose it, and measure up what you
end up with, that the sum of the parts is greater than the whole.
Huh? This seems to contradict the Law of Composition.

The best way to read this is to accept that you are never going to consume something in full, as a whole, only the required pieces. And there will be always some stuff left unused.

Very easy to prove, just combine Cola and Whiskey 🤢

Foundation: the Essence and the Variables

The very first step towards our goal is the ability to... leave something behind. Separate flyes and cutlets, extract placeholders from templates, and split a single whole into the Essence and the Variables.

The best and the most common example for this are DSLs - Domain Specific Languages, including any Template languages, including React.

😉 is there any difference between <div>{{userName}}</div> and <User name={userName}>?

A very important moment is that the Essence/Variables Separation can be performed by:

moving the Essence to the Layer below (sinking functionality)
Variables would be "kept"(emerge) automatically, as you will need to find a way to configure the underlying functionality.

This concept is almost equal to Software Product Line - methods, tools and techniques for creating a collection of similar software systems from a shared set of software assets using a common means of production.

This is also quite close to the Ports and Adapters(hexagonal architecture), where the "actual functionality"(Platform capabilities) is hidden behind Adapters (Essence in this case), which are in turn hidden behind Ports(Variables in this case).

To better understand, let's create a few examples:

Button Group

At many sites you might see Buttons positioned next to each other. Technically speaking they are nothing more than two Buttons placed in one parent and separated by some Gap. However, does it mean that this is what you should do?

const ActionButtons = () => (
   <div style={{display:'grid', gridGap:'16px'}}>
    <Button>Do</Button>
    <Button>Something</Button>
   </div>
)

How many different ways you know to create said gap, and how many different gaps you can use - 2px, 4px, 20px?
Probably said gap should be proportional to Button size to create a "coupling" between two buttons and let you use a larger gap to create a "distinction".

This is why it's very important to create an abstraction - ButtonGroup

   <ButtonGroup /* don't think how*/>
    <Button>Do</Button>
    <Button>Something</Button>
   </ButtonGroup>

Or even give underlying logic more control over look-n-feel, and create an opportunity to collapse a few Buttons in one group into one Dropdown on mobile devices.

  { ifMobile ? (
    <Dropdown caption="Edit">
      <Button>Edit</Button>
      <Button>Delete</Button>
    </Dropdown>
   ): (
    <ButtonGroup>
      <Button>Edit</Button>
      <Button>Delete</Button>
    </ButtonGroup>
  // ⬇️⬇️⬇️⬇️
  <ResponsiveButtonGroup
    actions={[
     { label: 'Edit', action: ... },
     { label: 'Delete', action: ... },
  />

Move one giant shoulder up. There are so many reasons to have buttons grouped somehow, and all those use cases can be named to be used for a known reason!

Table

Table is another example where second-abstractions can help you a lot.
Let's imagine you need to display a table. You have two options:

render the table by yourself
use some other library to do it

In the first case you might need to spend more time than needed to handle edge cases, implement virtualisation, sorting, you name it.
In the second case, you might find any particular library to not matching your expectations in some details with no ability to change the pre-backed solution.

Often in such case, developers are picking the first case as the only possible, while they always need the second - some "solution" they can just use. It just has to be "as they want".
In the Component Approach such a solution is known as a Component 🤷‍♂️, no more, no less.

So, yes, go with option one, pick your way to render HTML, not a big deal, pick the way you do(if you do) virtualisation, pick the way to handle "table data" - there are many headless tables on NPM, and assemble in a way you need.
If one day later you will have another use case with slightly different requirements - create another Component, assembled in another way.
But it is important to have this intermediate abstraction layer, which states "This is how tables are made here", as exactly this point may change in time (redesign) and you want to avoid Shotgun surgery or Domino Effect. You want a single change to a single component on UIKit/Design system side, not any client code.

You want to stand on Giant Shoulders.

Modal

Modal is a combination of both cases above.

Modal itself should just provide you a ModalDialog functionality.
But the Application might need:
- ConfirmModal, having a Cancel button and the Action button, next to each other in some particular order (depending on the operation system), with (probably) Cancel autofocused.
- InformationModal, having only one Got it button
- OperationModal to indicate some process and having no buttons.

Plus FileModal, that is not a "Design Primitive", but a separate experience with its own rules and principles.

HTML Dialog Element -> JS Modal Dialog -> Use Case Dialog

🤷‍♂️ We are ok to use window.alert and window.confirm, but almost no "UI-library" provide a second-abstraction over their modals to reflect the same functionality.

Modal is a lower-level construct that is leveraged by the following components:

Dialog

Drawer

Menu

Popover

(source Material UI)

If it is ok for you to use a Modal in some patterns, some of which do not look that modal, why not create more patterns that are closely relayed to the Modal/Dialog, but represent particular use case?

Once you have a foundation - try to build something from it
and create a foundation for the next layer. 

Then try to build something from it.

Unidirection flow

Another crucial but constantly overlooked part of separating something into layers is the controlling of the relations.

level above should be built on the level below
- in no circumstances level below can know about layer above
level above should be confident in the level below
- level below should change less frequently

This translates into two well known and well hated and thus ignored laws:

Law of Demeter or principle of least knowledge. Read it as - you can know about webpack, webpack cannot know about you.
Stable Dependency Principle stating that components dependencies should be in the direction of stability, so you can build your code Once and only once, and not rewrite it every month to adjust to ever-changing platform.
- mind Shotgun surgery and Domino Effect, there is basically no time for it.

Middle-level architecture

So, UI is a piece a cake?
👉 Yes, it is if you think about it as about Cake. Layer on top of another Layer.

Are you already using Onion Architecture, where layers are separated?
👉 Of course. Look inside your node_modules, and think how many other packages, libraries and layers are hidden behind the ones you know about.

There are High-Level Architecture(read pictures) and Low-Level Architecture(building primitives), what is this one about?
👉 And this one is about something exactly in between - Middle-level Architecture, combining "some given blocks" to create an Application according to HLA.
The one usually forgotten, and the one you always have to define for yourself by yourself.

Actionable advice

Take a single component and try to find another structure inside it. Find a Modal behind a Dialog, find a FocusLock behind that Modal, go to the very end on the left (atoms) and then go back to the very right(combinations).

Think in Atoms -> Molecules -> Organisms, not from Atomic Design point of view, but as a unidirectional complexity flow.
Remember the Table – you should be able to have a Complex Component A break it into pieces and assemble into Complex Component B. Then go back to those pieces and break them down.
👉 That is converting a single whole to the Essence and the Variables.

The point here - layers should not interfere, and should not be used in skip levels(Organism should never use Atom) that will enable their reusability and provide maintainability free from Shotgun Surgery.

Create a fancy cake, starting from More Generic layers and going to Less Generic ones.

And a cherry on top.

BEM vs CSS Grid

Anton Korzunov — Sat, 28 Aug 2021 05:14:18 +0000

BEM is not a “naming convention”. It’s a separation between Blocks and Elements. And Modifiers... but let’s just forget about them for a while.
Today we better focus on something different.

So, I've written this article because people do not understand the core principles behind BEM, not to be able to see them behind other features.
This is why let’s forget about BEM for a while as well.

To get things started we all can generally agree that…

CSS Grids are awesome 🥳

The main difference between display block and display flex is that the first one sees all children nodes as a separate elements, while they act like a Team🤜 within flex – they can grow and shrink.
They are connected.

Grid fosters this connection, lets you handle bigger blocks, giving more power and more control.

But there is one big difference, really BIG difference, - the majority of power and control is given to the “grid parent”, not “grid element”

Let's imagine a conversation between Grid and Cell:

🤖: Dear Grid-Item, I've prepared a place for you, where shall you stay according to my very plan 😈
📦: Can I have my own opinion?
🤖: Dear Grid-Item, well yes, some of you can move self to other places, but not particularly you 😅. Please stay within my template because I do have a plan for you 👮🏻‍♂️.

And like the Grid, which can use grid template or grid areas to control all direct children, BEM also has a plan...

BEM has a Plan

Technically speaking BEM works in the same way as Grid - they share the same ideology. BEM is just not bound to the "2d grid" and one level of children nodes.

It can be easier to think about BEM from a Component Model point of view:

there is a Parent component and a few Elements
according to the plan Elements has to be placed in some well known location.
children Elements should not think or even know about their placement.

const ParentTemplate = () => (
  <html>
    <body>
      <header>
        <slot>
           <Component1 /> <--- Another block
        </slot>
      </header>
      <main>
        <slot>
         <Component2 /> <--- Another block
        </slot>
      </main>
    </body> 
  </html>

A few rules

Let me be honest - there are two major sites about BEM methodology, where you can read some information - http://getbem.com/ and https://en.bem.info/. I hope you likely to see the key information hidden between the lines, but according to my experience no one has seen it yet.

BEM is not about that-strange__naming--convention
BEM is about the Separation between B and E

Here is what you might miss:

Elements do not lay themselves out. Parent Block does
Block style themselves and layout only their children.
Blocks cannot be (visually) styled 🎨 outside, except via own known Modifiers
Every Element can be a Block

Note: "Children" is not an "immediate DOM node". Still easy to think in React terms - children is everything defined among component

const List = () => (
 <ul> // children
  <li> // also children
   <SomeItem> // still children, but also a Block
  </li>
 </ul>

Rule them all

How Block can rule children? Usually (for the last 15 years? BEM was created back in 2006) by passing extra classname, which is expected to obey the principles above and cannot style children, except using modifiers defined in the children.

modifiers are equal to (React) props

Block only can:

lay Elements inside. In the same way Grid can lay Grid-Items inside.
configure own children by picking/using different modifiers/props, but only among the explicitly supported by children Components. Well, you can do the same with Grids, not something particular bound to BEM.

Look like there are at least something in common between BEM and Grid. Grids are just more about "how" to do something - they are providing a particular way to command a Browser Engine. While BEM 🤷‍♂️ it's just a way to keep things clear

Both Grid and BEM define layout for their children gently asking those children not to interfere.

While this moment might sounds like NOT something really important - it is the core essence of both technologies

Step away from technical implementation. Try to understand the intent behind the actual approach and principles according to which both technologies ended like this.

What to do

(dimension) do not let components define own dimensions - different Parents can have different Plans
- and your parent will configure "you" one way or another - or by placing "you" in grid (browser layout) or by giving you extra classname with flex styles (explicit layout). That is not "your" problem.
(gaps) do not let components define margins - that gonna break any order anyone will try to establish
- margins are still file, just define it "inside" block, the area under your control, not "outside", creating unexpected behaviour for consumers.
(isolation) do not style other components, tell them what they shall do

So what?

So please stop writing random code, which always ends in some messy, completely unmaintainable state, causing a lot of performance issues, especially if you overuse CSS-in-JS for no reason.

Think structurally. Think in relationships. Think about you styles in the same way you think about your code, files, function and packages - and I believe there are some rules you follow and some pain you've experienced due to bad habits.

Well, apart of Grids there is another concept which should explain you the main point behind separation of responsibilities and concerns - Open Closed Principle, a part of SOLID pattern

software entities should be open for extension, but closed for modification

Which, in this case, controls what Elements can be asked to do by Blocks(blocks are "extension"), and how Blocks could not affect Elements(which are "closed for modification")

What Problem We Solve

Anton Korzunov — Thu, 26 Nov 2020 06:07:48 +0000

There is a single question you should ask yourself a few times a day. Every time it will sounds a little different, and every time it will require an absolutely different answer.

Ask yourself:
   `What Problem We Solve`
   `Which Problem We Solve`

👉 Where What/Which is a choice between a number of possibilities.

The System

What problem we solve?

Is there any need to solve this problem? This problem, in this area.
Does anyone need your solution?

Which problem we solve?

Where are many different kinds of a single problem. Do we know which one we are going to solve?
Who is solving others?

What Problem we solve?

Is it a problem? Will anyone be happy if we resolve it? Does anyone ready to pay for it?

What problem We solve?

Are we the right people to solve this problem? Are we able to do it? Are we missing something or actually have everything to make it happen?
Might be another team can do better?

What problem we Solve?

Well, do we know what solve the problem? Can we understand that the problem is actually solved? Are we going to solve it completely or just make it a little better?

Do we have a solution already? In this case, go backwards and find the problem it can be applied to efficiently.

Actually sounds very SIMple (Specific, Important, Measurable) framework, as many others which were created to help you to 1) start something, 2) maintain, and 3) finish.
Take a look at Why What How post for details.

Does it work?!

While it can sound too simply - that simplicity is the key to efficiency.
Just ask yourself this question every time you need to make a next step to understand where you are, and clarify how to make that next step.

Firstly, it works like planning and inspiration. You need to find the right problem to solve. Or you can try to find the right problem for a solution you just envisioned.

Secondary, it works like QA-kickoff, ensuring that the next step is worth making. That we should try to solve this problem, not find a better problem to solve.

Then it works like… QA-kickoff, ensuring that the right team was given the right task. Maybe it’s the right time to get more people on board.

And at last, it defines The End Goal. Explains why it will be a solution. Why people will need it, use it, and be happy with it.

Ask yourself

🤷‍♂️ Why you need a new phone. What problem it will solve?
🤷‍♂️ Why you need new work. What is the problem?
🤷‍♂️ Why this PR should be merged. What problem does it solve?
🤷‍♂️ Why should we apply the principles above? We?

Prior art

The origin of this principle is The API Book by Twirl.

Sergey KonstantinovFollow

Developing APIs for over a decade: maps APIs, integration APIs, reviewing W3C specs, etc.

Don't have an answer to any part of the Question? Probably you should solve another problem.

Which? 🤔 What? 😲 Oh! 🙀

The limits of 2 dimensions

Anton Korzunov — Thu, 05 Nov 2020 10:58:54 +0000

This article was written to design a solution for terravigil.com articles ordering. It will start as a problem related to articles, and will end with the same problem as well. But in between...

Let's do some math:

open your favourite site with some articles on the main page - bbc.com, reddit or dev.to, it does not matter.
check what you see
probably that's latest and the best news or articles

latest AND the best.
These are two different properties to order. Simultaneously.
These are two different dimensions to discover.

💡 There is an easy way to "experience" this problem - open any table within some table processor (Excel) and try to sort by a field. And then another field. And then by two fields simultaneously -

😅 but there is no such operation.

Speaking in a more common language (SQL):

you can ORDER BY time, rating LIMIT 10
but it will first sort by time and only then by rating.

Want to get by time AND by rating simultaneously - that is not possible, the ordering is happening sequentially, or it's better to say in the 1D world.

However, it's easy to start the story from another example. From the actual 2D world. Something we all experienced, and able to understand.

From maps 😉

Maps

🗺 Maps are 2D. Obviously.

Let's do some math:

open your favourite site, powered by some maps, and displaying some stuff on the map (that's important!).
check what you see.
probably there are some "dots"(Points Of Interest) on that map.

For the sake of simplicity - let's use domain.com.au as an example.

Let's check what we actually looking at:

✅ it's a City Of Sydney
✅ majority of POIs are located in the Downtown
✅ there are almost 9000 places to rent
💩 just a few dozen are displayed

So, this is "our situation" - we have more data than we could, or should display, so we have to apply some limits - we have to pick "latest AND the best" items to display.

We have to pick the best items with restriction by X and Y. Already 1-dimensional ordering and 2-dimensional filtering.

However, I would like to point in that strange fact, that there is almost no information outside of Downtown.

Probably nobody is selling or leasing their houses so far from the centre. People are not living in those wild areas! Sounds reasonable? 🤷‍♂️ why not?

However, let's double-check it - zoo-oo-ooming in!

😎 I would assure you, there is life outside of Sydney's CBD, we just are not able to see it due to limitation of 2D dimensions.

I've got a video for you

👉 In short: there is A LOT of "dots" outside the Downtown, but we don't see them.

The root cause of this effect is - information tend to be displayed in the areas of higher density. And yes - it comes, and become worse and worse, with a scale.

information tend to be displayed in the areas of higher density. Every entity has an equal probability to be picked, and that's why higher "density" produces more "picks"

Actually, the root cause here can be observed as the overall "speed" of updating information on the map as well.
Every time I move the map, domain fetches the new information from the backend, and then displays it. Very often, especially within "areas of high density", the updated data does not represent the previous dataset (it might be very different), even if I am searching roughly the same area.

This causes heavy load on the backend, very slow and non-responsive frontend, as well as annoying POI-glittering. Really VERY annoying. Especially when some point you had a plans to inspect just disappears...

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

Living in 2-dimensions

We have two problems here:

Problem 1

Every request is unique. You can move a map as you want, and every time it would be absolutely unique. You will have to reach the server, spend time, return a unique result.

Two customers, looking at one area, are looking at ABSOLUTELY different ones.

There is one thing you have to understand - maps "displaying" some stuff are here for some time. For "some time" - since IE6 and pre-iPhone era. Since "before" AWS. Since the times, when you had a single database for all 1000000 customers per day.
In other words - 10 years ago you were not able to "scale up", and had to provide performant and efficient backend, or your Frontend will DDOS your backend.

And cartographical services of the past have to solve the problem. And had solved it.
But cartographical services of the present are not giving a crap, resulting in the issue mention above, the fix for which is known for years. > The solution will be explained later

Problem 2

Problem number 2 consist of the other two problems:

SELECT * WHERE X and Y gives us 10.000 records. So you can select much more information than you can display. So you have to LIMIT it. But limiting needs sorting to keep "the best" records.
ORDER BY rating is keeping records in the areas of higher density. And you want to display all possible opportunitues. If all records have the same probability to be displayed - the result would represent just information density.

And "information density" is the problem you have to fix first. Not to fix - but neutralize.

Clustering

For example, you can do N smaller requests to "cover" the whole requested area.

SELECT WHERE X and Y ORDER BY rating LIMIT 100 
⬇️⬇️⬇️
100 times x(SELECT WHERE x and y ORDER BY rating LIMIT 1)

This time instead of one big select we are making a dozen smaller, every of which still tends to display the most "dense" part of it, but covering the whole block more or less evenly.

However - it is not efficient. There is a better way - group by

SELECT WHERE X and Y ORDER BY rating LIMIT 100
⬇️⬇️⬇️
SELECT WHERE X and Y GROUP BY (ROUND(x/10), ROUND(y/10)) ORDER BY rating

In this case we have grouped all points in some "smaller area" together, resulting potentially up to 100 rows(0.1x0.1 grouping).
This is, again, not efficient, but could it help us with reducing dev city of the data and making coverage a bit more “flat”.

We just make a complex task a bit simpler.

However, this is not clusterization we probably should use to properly display high density information. All we did is aggregation, and that's enough! But we did it not in the best way.
There is a better one.

Problems with "random queries"

group by ROUND(x/10) is not working. /10 should be different for every zoom level. With every zoom, Map becomes twice bigger, so multiplier should also adjust (x2 every zoom) > Plus grouping is actually slow. No matter how you do it - it would be slow.
WHERE x BETWEEN left and right would be unique for every user looking at your map. And that is a problem bot only for the network cache, but for the database cache as well > 👉 Two customers, looking at one area, are looking at ABSOLUTELY different ones.

Z for Z-code

The goal of aggregation is to collapse some records, which could be grouped somehow, into one record.
For 2d data the most common solution is known as Z or Morton code, as well as geohash, Gray code or Hilbert curve - they all are some sort of spatial filling curves, literally a line which stitches N dimension together.

it is called "Z" because every iteration it "Z" itself (and Hilbert curve "U" itself)

It might take a while to understand how such curves work, but the essence of the idea is simple:

values which are "close" on the curve, are "close" in the N-dimension as well

In our case that would sounds like

SELECT WHERE X and Y 
GROUP BY zcode & 0xFFFF00  <---
ORDER BY rating LIMIT 100

Where 0xFFFF00 is playing a role of a "mask" and groups 😎values which are "close" on the curve😎 effectively clustering elements which are close to each other in 2D.

The explanation how "clustering" work is best seen on Bings Tile "coordinate" System - quadkeys (the same Z code) which uses 2 bits (0-1-2-3) per one "division". So masking the "following" bits can "group" all points with the same beginning of the code. And all points in one "rectangle" will have the same beginning.

Word-to-vec

A bit different approach is used in search engines, which also need to find and rank something among a billion documents.
"Similarity" search is one of key algorithms there, and word2vec is a key technique here.

As the name implies, word2vec represents each distinct word with a particular list of numbers called a vector. The vectors are chosen carefully such that a simple mathematical function (the cosine similarity between the vectors) indicates the level of semantic similarity between the words represented by those vectors.

Mathematically speaking it's the same case - "close" words or "documents" would end "close" to each other in the (very) multi-dimension space (for the reference it's not 2D or 3D, but closer to 1000D).

Terravigil

However let's back to our articles case, about displaying "the best and the most fresh" data.

What we actually want:

we want to see "the best of the best" news longer - more people should read them
we want to display hot news as soon as possible, so freshness is important
but there two points violates each other

There are two possible solutions here: buckets and score

Buckets

Selects news in predefined time internals, and order inside each group separately.
Literally "display top news of today" and then "display top news of tomorrow".

the size of a bucket can be adjusted, like more than a day or less than a day
buckets might overlap, like you can merge the top news today, and the top news from the past week.
buckets can be fixed (in time), thus cacheable, or floating, changing intervals they represent every minute or hour.

Buckets are first ~~sort by time~~ bucket by time, then sort by rate.

Score

Selects news ordered by a single "score", which is the main problem of this article.
While spatial curves can help with 2D and other geometrical cases - they are more or less useless for this particular case.

Why? Because some elements "close" on the 2D plot would be VERY far on the curve. Just think for "start" is different from the "end", while curve starts and ends in the same point.

Solution here is to use or special "vector" data formats or databases known as KNN - k-nearest neighbours search (or Nearest centroid.

Javascript implementation https://github.com/mourner/rbush-knn
ElasticSearch https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/knn.html
Postgres support it as a part of PostGIS - remember that our problem can be seen as a geometrical problem
MySQL does not have any efficient way to handle this, and you will probably kill your database if you try.

A sample data set of points considered as "neighbours"

Conclusion

Long story short - Terravigil uses buckets as long as it's easy to design them and understand how they work, so you can create a correct result.
As well it uses score to derive a single metric from many different other signals to at least understand which article is "the best".

But all you have to do - just look at the problem from another angle. If you were told to do a 2-dimensional sorting, thinks about limits of the 2-nd dimension.

And it's not just about how to do it, it's also about how to make it FAST.

"Why? What? How?" framework

Anton Korzunov — Wed, 14 Oct 2020 04:53:35 +0000

"We cannot solve our problems with the same thinking that created them" – Albert Einstein

This is Why→What→How, as well as Why←What←How.
A way you move forward, and the way you take a step back.
You will see.

An evil Jinn

Once upon a time I've used a concept of an Evil Jinn, which turns your wishes against you:

😎: (why) have no idea why, but...
😎: (what) I want to be rich!
🧞‍♂️: (how) There are many different ways to make your wish come true. I'll pick the most painful one.
🧞‍♂️: so, here you go. You are rich as Scrooge McDuck. Because you are Scrooge McDuck. Well, exactly as you commanded, master. Have a good day, quack. Quack 🤣, gosh, another looser.
😎: 😟, hey! wait! I didn*x$ssshhh 💨. Quack!

This is what happens when your goal is what and you are not thinking about how. You gave too much power to the 🧞‍♂️, haven't explained constraints and the detailed requirements.

👉 Take a step back. Try to find why you want to be rich.

There is a whole film about this - Bedazzled

Frameworks

There are many other widely known frameworks developed to help you avoid painful consequences of unwise decisions.

OKR
SMART
and SBI. All have a purpose to help you structure something from "end to end" and "understand better".

For example - understand what you truly desire and what is truly required. And separate one from another.

OKR

Objectives and key results is a goal-setting framework for defining and tracking objectives and their outcomes. Used to run many businesses and make planning.

OKRs comprise an objective, clearly defined goal and 3–5 key-result specific measures used to track the achievement of that goal. The goal of OKR is to define how to achieve objectives through concrete, specific and measurable actions. The key benefits of OKRs are focus, alignment and engagement.

The biggest difference OKR and his best friend KPI (often used together) is the last point - focus, alignment and engagement.
Key Performance Indicator alone is a subject for Goodhart's law, which is derived from the Heisenberg's Uncertainty principle

Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.

In other words - key results without an objective is a road to Hell.

OKR can be read as:

WHAT you want to achieve. "I want to be rich!" 😎
WHY you want it. "It will let me buy a new car!!"
HOW to do it. Not able to give you an advice, but here is multiple steps, key results, which will lead you to the goal.

and that's a very poorly designed OKR 😉

It's very important to distinguish the goal and the result. True Goal should be a direction, not something that you can achieve.
👉 If you can achieve it - it is a key result. Just a step on the way to the goal.

Life is a journey not a destination:

Key Results are the journey
Objective is the destination

SMART

S.M.A.R.T. - is very alike Fallout SPECIAL, but for project management. A mnemonic acronym, and a very role-playing in both cases.
SMART is a way you can describe your objective. The definition should be:

Specific – target a specific area for improvement.
Measurable – quantify or at least suggest an indicator of progress.
Assignable – specify who will do it.
Realistic – state what results can realistically be achieved, given available resources.
Time-related – specify when the result(s) can be achieved.

So your objective should not be just "I want to be rich!", it should be a little SMARTer. At least more Realistic, and Time-related - you probably want to be rich today, not 70-y years later.

🧞‍♀️ is waiting for your mistake, looking for every missed detail in your WHAT he could use against you.

Another important moment about SMART, as it pointed by authors a few times:

It is the combination of the objective and its action plan that is really important. Therefore serious management should focus on these twins and not just the objective. Thank you Wikipedia.

Which is again - an objective without key results is not something good.

There are more mnemonic acronym based approaches

SMARTer or SMARTAA

A smarter SMART with more features

Trackable and Agreed

CLEAR

Collaborative, Limited, Emotional, Appreciable, Refinable

SIMple goal framework

Specific
Important
Measurable

RISK

Requirements
Information
Suppositions
Knowledge

Requirements: what is the expected result of this project

Information: is all the information clear about what I need to do and all it’s parts

Suppositions: are my assumptions true? Is there any flawed assumptions?

Knowledge: do I have the required knowledge to understand and solve the problem? Do I need to learn something new?

SPEAKING

Setting and Scene, Participants, Ends, Acts sequence, Key, Instrumentalities, Norms, & Genre

SBI

The Situation-Behavior-Impact Model (SBI) was created to provide a better feedback - make it structured, reduce the anxiety of delivering feedback and also reduce the defensiveness of the recipient.
The SBI feedback model is simple and direct:

you capture and clarify the Situation
describe the specific Behaviors observed
and explain the Impact that the person’s behavior had on you.

Like:

today, after reading this article, I liked it.
yesterday during the meeting, your internet connection was unstable, we lost you
last year, we had a lunch together, you will owe me

Sounds too simple and almost obvious but this is the goal - provide you with a framework to make so. You don't have to think much about the SBI - just follow the pattern.

The hack is: Situation/Behavior/Impact is the same thing as Arrange/Act/Assert!

AAA: First you set up all the data you need for your example (Arrange), then you call the method under test (Act), then you verify the output was up to your standard (Assert).

First explain all the circumstances (Situation/Arrange), then you explain what the individual did (Behavior/Act), then you explain how it ended (Impact/Assert).
And yes, this means that the “system under test” is the individual.

SBI(as well as tests) can be viewed differently if flip it:

I want to cause an Impact
Which behaviour I should use
In which situations it will work

Then you can work towards creating such situation. You know what you have to do.

🤔 Not much difference from OKR - moving towards some goal.

And here we go. Let's try to derive a new system from the existing ones.

WHY/WHAT/HOW

I did not invent WWH. It was in use by therapists, especially Psychotherapy for ages. As well as detectives, marketologs, analysts and so on used it.

To be honest I never had any therapy, but from many different films I know that their job is to explain WHY you are you. WHY you are doing that, not this. Their job is to find root of your behaviour and explain it to you. Hello Sigmund Freud my old friend.

But we are not here for the therapy. Right?

My grandfather knew what he needs, and usually was asking his grandsons to help him.

every time he asked us to do something, my brother was doing exactly WHAT he was told to do.
and I was asking WHY.
And it was way faster to do that something, than to explain me why it’s needed.

It's ok, and sometimes you need to do what you were told to do. But it's better to think what you are doing, how you are doing it, and why.

Why was the change made this way?

How does it help?

Is it working as we want?

Let's imagine you are looking at the code. You can see only how it was written. Then you understand what was made, and then you can think about why it was made.
You are real detective 🕵️‍♀️!

Why

Every time I ask my kids to clean the house - am not expecting questions like

"WHY". To keep it clear, dummy!
"WHAT". What?! Clean the house!
“HOW”? "How" is ok, as long as there are many ways to keep it clean, and, ok, you can skip mopping today.

Jokes apart - why should always come first. After you have a reason, a target to reach - "I like the house to be tidy",- you might find a way to fulfil it, probably home chores are the solution; and then find an exact way to do it (vacuum, mopping, and so on).

Recently our kids at last got the point - we didn't ask them to do home chores (which are how). We wanted their rooms to be clean (which is what). They did not yet understand why we need it, but already can act more thoughtfully, keeping everything constantly tidy and not spending too much time on chores.

WHY is like - you want the iPhone 12. But... why? Do you really need it?
So you will be told why you need it, and why you can't live without it any longer.

Go To the Apple Store! Now!
This is how you can get ~that~what thing, and click thing button to watch our why presentation one more time 😉

There is the same point, from a different perspective - from a Start With Why. Like this is “why” you are buying an iPhone every year - you believe in Apple's stories.

What

What is a problem? I mean - what is a problem. What is what people tend to start from.

we want that no matter why
Let's do it! I have no idea why
I WANT TO BE RICH!

But why? Is there any reason? You might want to buy a new house? Why? Might be you need more space? Why?

👉 Every time you what - make a step back and find your why. Only then make a step forward to how.

That’s a standard trick, especially in movies - when someone is going to do something - as them why.

And then the bad guy will start a long monolog explaining his devil plans and the reasons to nuke the city. Got enough popcorn?

What is always the least valuable thing. It is in between of WHY and HOW.

How

And how is always different. How is the end and the beginning (remember - this is Why→What→How, as well as Why←What←How).

TypeScript is "how". It's not going to fix anything without a fixable subject.
GraphQL is "how". This is how you talk to server, but not "why"
Expensive Nikon Camera is "how". You can picture the same "what" using your phone. So why?
Almost any other technological solution is a senseless "how" without an Objective and Reason.

Refer back to the other models and try to understand that it is all One Question. A holistic point of view.

Note the difference:

How are you doing
What you are doing
Why you are doing

How can this help you?

It can help you code

Coding is how. Keep in mind what while you are doing it (and it is what as well).
Don't think much "what you are writing", think "what you are doing". That will protect you from refactoring for the sake of refactoring, hooks for hooks, speed for speed.

This is something OKR is about - to keep the right direction

"It is the __combination_ of the objective and its action plan that is really important"_.

Planning is what. What is something to do, something you are doing, or done. An objective.
But how to decide what to do? Find the most and least important, and even define the way to calculate the importance?

`Why` is usually a missing part. Start from it, and end on it.

React, Angular, Vue - they are different how, different why, but the same what.

What is something user might experience, and it does not matter how it is made.

However - make a step back - why you should pick one framework, but not another? It's not only about customer experience, but developer experience, and (sometime the main) business needs and requirements.

A single what might driven by different why. One why can create any what. There is an infinite number of how you can actually implement it.

There is another mental concept here - blind men and an elephant - which is about a single thing(an elephant), can be described in many ways.

You can have a problem to solve - it's why. Take a step forward and find what you can do to solve it.
You can have an idea - it is what. Take a step back to double-check does it worth it, and then step forward to find a way to make it real.
You can just want to apply something, try a new language or framework, play around... solve something in a better way? It's how, and it need what and why > except you just enjoy doing it.

Too many people are just doing. Using Redux because they were told to. Not understanding CSS or CAS theorem. Focused only on the code.

Too many people are just doing a thing. No matter how, and it ends as a technical debt nightmare. But we are building a cool this? Sure?

Too many people are after "why". They might truly believe that it's a good reason... to start a war for example. This is not how you should resolve problems and not what you have to do.

This all working only holistically.

Technical and non-functional requirement

Wikipedia defines:

Broadly, functional requirements define what a system is supposed to do and non-functional requirements define how a system is supposed to be.
Functional requirements are usually in the form of "system shall do ", an individual action or part of the system, perhaps explicitly in the sense of a mathematical function, a black box description input, output, process and control functional model or IPO Model.
In contrast, non-functional requirements are in the form of "system shall be ", an overall property of the system as a whole or of a particular aspect and not a specific function. The system's overall properties commonly mark the difference between whether the development project has succeeded or failed.

functional requirements is what
non-functional requirements is how
👉 both are not why

Conclusion

Let me be short - this is a stock photo about "talking therapy".
On the left is your spaghetti code, and on the right is Why/What/How

It's really that simple.

PS: Read the Duck Tales for more mental models you can apply as a software engineer.

PPS: And “Start With Why” talk - https://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action - the same idea, different order.

🤔 why did I write this post? I know what I wrote, and how I wrote it, but why.........

You dont need CSS-in-JS #2: What?

Anton Korzunov — Thu, 19 Mar 2020 10:02:51 +0000

In the first part, I've tried to explain what CSS-in-JS is nothing more than a style delivery system, not style system, and you actually don't need it.
The question - why do you actually need?

What's the goal?

There are 3 things you might need:

ship the result as fast as possible. Bussiness would appreciate. Common rumours usually tangle CSS-in-JS and Dev speed, however, I am not sure why they are tanged.
make something reusable. Like build your own UI Library (everybody builds their UI Libraries nowadays), and by some reason it's like HAVE TO BE written using CSS-in-JS. Don't ask me why.
share that UI library across different product and teams.

There is also one, or two more things, which you also need, but they were not present in the list above, and the majority ignores their absence.

client side performance. It should be fast. My kids still use IPad Mini 2 (5 years old), my mother-in-law uses some laptop which was cheap 5 years ago, and not it's almost not working...
server side performance. It should not cost you much, as well as SSR is working better then it's FAST.
you should understand what you are doing, and how it would work.

And actually, the last point is the most important one. And it's not bound to CSS-in-JS or -CSS.

I urge you to read this presentation - Crafting Stateful Styles - about rethinking WHAT to write inside CSS. Like one more methodology.

Let's go deeper

Your style is not a collection of props

 color: while
 {(props) => props.isPrimary && `color:blue`}

Sounds familiar? Sounds terrible! There is no way to predict how your styles would look like with some random set of props, and many different combinations are possible.

BEM(CSS) as well as trousers(CSS-in-JS) has an idea of "modifiers" which are a more "static" and predictable way to handle complex styles.

Reusability is about separation

This is something people are usually missing in CSS-in-JS - a "methodology", like SMACSS, BEM and visa versa.
And the core idea of probably all those metodologies (but not technologies) is separation - a separation between Block and Elements, as well as State and Theme in SMACSS.

Every element would be "constructed" from different style pieces, and expect you do add a few more pieces to complete the picture.

For example in BEM terms Button is a Block. And Block may not define dimensions. That leads to the expectation that you will consume Button as an Element of your component. And Element might define dimensions.

Block styles are meeting Element styles and forming a Voltron

In JS we are talking about reusability, composition and all that stuff. In CSS there is the same stuff, just use it.

Conclusion

CSS is not your friend, and CSS-in-JS is not your foe. People saying you should use X, but not Y - are your enemies.

And all the people saying you should use CSS-in-JS, not CSS are just victims.

It's not about the technologies, but about the way you use them.
About the reason to use in one or another way.

are you getting any feasible improvements from Y
are you sure, any number or at least theoretical proofs?
what would change in a year? I am speaking of tech debt.

You dont need CSS-in-JS #1: Why?

Anton Korzunov — Thu, 19 Mar 2020 10:02:43 +0000

The cover image was taken from another article, named exactly the same You Don't Need CSS-in-JS: Why (and When) I Use Stylesheets Instead by @colbyfayock, however there are not much articles like that (except this one - You Don't Need CSS-in-JS, which uses the same image and, well, the same author 😎), or like this - usually everybody praises CSS-in-JS.

Why CSS-in-JS is so COOL?!

Because it's much better than just CSS, according to the other authors:

5 reasons to go with CSS in JS for your next application

Ruben ・ Mar 19 '19

#javascript #css #discuss

Global namespace

Like CSS shits into the global namespace, while CSS-in-JS provides you an "encapsulation" plus "isolation.

👉 use CSS Modules, they are providing the same level of the thing above, and in the exactly the same way - "hashing" classNames, so they would never conflict.

Implicit dependencies

By which different authors imply ~~technologies~~ methodologies like BEM, SMACSS or Atomic CSS, which might help you to to reduce the lack of built-in scoping mechanism.

👉 please go read about these methodologies again. They have nothing with "scope" and "namespacing", only with separation of conserns, the majority of CSS-in-JS believers truly understand.

Dead code elimination

Like in CSS-in-JS you can have your styles next to your component, and delete them as you delete your component. For example. It might also be just about styles no longer in use.

Is it true? With CSSModules you refer to your styles as styles.someClass, making the fact of usage explicit, and it should be:

not a problem to delete Component.scss when you delete Component.js
not a problem to track which styles are used, and which are not. That's a linting/IDE problem, not something bound to the technology itself.

👉 that's not a problem of technology. That's problem of your code style

Minification

CSS out of the box doesn’t have a feature to minify code.

As well as for JavaScript. It's faster to fix the problem, that to talk about it.
Even more - usually CSS minification happends on the css-chunk level, which may contain many .css files, which may contain styles for many components. Read - it WAY MORE EFFICIENT.

Sharing constants

CSS-in-JS is quite good with it. It's easy to share js constants.
LESS/SASS is not worse - it's easy to share constants from CSS->to->JS, and back using webpack loaders.

👉 ... and yes - usually everyone is talking about constants, not dynamic variables.

People use CSS-in-JS to create dynamic styles, and share some variables from JS. Like gridSize or whiteColor, or margin-left. They are using dynamic nature if CSS-in-JS to create static styles, which will be never changed in runtime. The night mode included. It could no more than a media query - it's more about your code style.

Let's double-check

@mxstbr, creator of Styles Components once wrote an article Why I Write CSS in JavaScript. So Why?

CSS-in-JS boosts my confidence

I can add, change and delete CSS without any unexpected consequences. My changes to the styling of a component will not affect anything else. If I delete a component, I delete its CSS too.

👉 CSSModules. Full Stop.

keeps our codebase clean and lets us move quicker

With CSS-in-JS, we automatically sidestep common CSS frustrations such as class name collisions and specificity wars...regardless of experience levels.

👉 No, only methodologies prevents specificity wars, as well as helping moving forward regardless of experience levels.

C'mon - it's possible to create terrible things with CSS, and CSS-in-JS as well. Nothing stops you. That's not something CSS-in-JS could you give - that's you.

Keeps CSS small

Regarding performance, CSS-in-JS libraries keep track of the components I use on a page and only inject their styles into the DOM.

👉 That "tracking" costs WAY more that extra work browser could perform working with a bit larget CSS tables.

Just follow the best practices, which usually sounds like - don't use nested selectors, as long as browser matches them from left to right, so they might greatly slowdown CSS engine...

Pit of success

CSS-in-JS combines all these benefits into one handy package and enforces them. It guides me to the pit of success: doing the right thing is easy, and doing the wrong thing is hard (or even impossible).

👉 That's not truth, in the moment of "right thing", and especially in the moment of "even impossible". CSS-in-JS is actually causing more chaos than helping making things "right".

There are "better" versions or CSS-in-JS, like styled-system - it's a SYSTEM, or xstyled - which is also a SYSTEM, or thousers - which is a real styling STATE MACHINE.

However, CSS-in-JS by itself is usually nothing more than style delivery system. It doesn't give you anything special. It's up to you how to use it.

Performance

While my .js bundles are slightly heavier, my users download the smallest possible CSS payload and avoid extra network requests for .css files.

This leads to a marginally slower time to interactive, but a much quicker first meaningful paint! 🏎💨

CSS-in-JS send only the critical CSS to the user for a rapid first paint. Which is called critical css extraction and not a feature of CSS-in-JS

🎨 Optimising CSS Delivery

Anton Korzunov ・ Oct 4 '19

#css #webdev

Recap: CSS in JS benefits

Generates minimum CSS requires, which is not required.
Good runtime performance, which is way worse than with a plain CSS-in-CSS
Supports dynamic styling, which you might not need
Easy to pre-render important CSS, which also possible with CSS-in-CSS
Letting to extract all CSS to CSS, if you want

Recap: CSS in CSS benefits

Generates big style chunks, which is easy to optimize in bulk.
It's way faster to load and parse CSS files, than JS files
Unbound caching for JS and CSS, leading to a better user experience.
Letting you embed CSS in JS, if you want.

So... honestly - there is no GOOD reason to use CSS-in-JS. Probably you need something else. Something more (like a "system"), or something less(like just styles). Usually less.

The Duck Tales

Anton Korzunov — Wed, 19 Feb 2020 05:31:55 +0000

Once upon a time I was thinking about all the stupid things and other shenanigans I've done throughout my life. Things, I never wanted to create, things I never wanted to rewrite, and things I wanted to never see again. About thoughtfulness and a bit of wisdom.

4 things to keep in mind:

🦆: If it walks like a duck and it quacks like a duck, then it must be a ~~duck~~ JavaScript Duck-Typing.
🙈🙉: Our world is experienced differently by blind or deaf people, but it's still the same world, just different perspectives - 6 vs 9, as well as blind men and an elephant
👁: An observable system is one whose internal state can be deeply understood just by observing its outputs.
🔨: if all you have is a hammer, everything looks like a nail - Law of the instrument

Which was originally known as "Give a boy a hammer and chisel; show him how to use them; at once he begins to hack the doorposts, to take off the corners of shutter and window frames, until you teach him a better use for them, and how to 👉keep his activity within bounds👈."

And I am going to give you a really BIG HAMMER. Believe me or not, you can use it to hammer literally any problem.

church bells ringing.
the appearance of a man in a tuxedo with a woman in a flowing white gown.
rice flying through the air.

🙀 sounds like a wedding! // The theory behind Complex event processing.

There is a little problem with React and Redux state. And the idea of State in general - it's not necessarily a state, that's just a collection of some values - a few key/value pairs just met in one place and formed some data. Dead data. Impossible data.

Confused? Well, "confused" is your state. My words have changed something inside you, and the result can be observed as a final emotional state on your face – 😕

But - if you walks like a confused and you quacks like a confused, then you are a confused. And everything else is implementation details 😟

That is a core idea of Duck Typing and this idea will save your life. Already saved, maybe even multiple times, because Ducking – is what doctors do.

It's called a triage – an attempt to understand the patient's state, the major problems and the minor problems, to save their lives. Just by looking at them, looking at how they walk and how they quack. Hopefully just looking first, and using surgery to get guts out only if necessary.

Triage is the process of determining the priority of patients' treatments based on the severity of their condition - Wikipedia

In short, when a patient comes – nurse checks:
1) the patient is yet alive
2) is not actively dying
3) and has a medical insurance
No insurance? Then the patient is probably healthy.

If it walks like a 🤒, and quacks like a 🤧 – it's 😷! Cut a leg!

Just remember the last time you went to the GP - they asked you some questions, measured your temperature and pressure, and came up with some conclusion about your health problem - like drink more water. Next!

Usually, there are enough indicators to intent the overall system state - is it actually in a "healthy" state(it does not matter how exactly) or it's in an "unhealthy" state(does not matter how exactly).

The goal of triage is not to heal💉, but plan the next step.

Signs, Signs are everywhere! Just read them! And dont forget to left the breadcrumbs, that’s called a good UX. And rice flying through the air.

In the same way doctors are able to understand what’s wrong with you JavaScript is able to understand why undefined is not a function. Well, what is a function? What is an object? What is an array?

if something has .push and .forEach - then it could be an Array. Or, at least, something Iteratable. 👉 it doesn't have to be an Array - it should 🦆 as Array.

But there is one moment - a thing could contain many different properties, implementing different interfaces, like IDuck, IQuacker as well as IEggLayer, and duck like a pack.
This makes things a bit complicated... to explain...

What I am looking for?

I personally prefer to call a principle behind this question a WTF principle - like you are displaying your cool stuff to a friend, manager, investor or QA engineer, and they are asking you: "_So, ok that was cool, but could you please explain 👉WTF is this👈?".

Belive the old pirate - this is exactly how all your friends are thinking about your new creation.

You may replay in a short and sound manner - 🤬, but you know, there should be a better way to answer, and a bit more polite.
And probably your friend, manager, investor or QA/QE need different responses.

It's actually very hard to predict what these different people might want to hear from you, it's better and much easier to understand what they need to hear. To do this let's just imagine that they are in the same situation as you, and would have to talk about "your stuff" with someone else. Then - let's go and find the top of this food chain:

💰CEO: Hey, I need you to build a new feature. I don't care how you will do it, I just trust you.
😎Director: Hey, I need you to build a new feature. I don't care how you will do it, I just trust you.
😸Manager: Hey, We need you to build a new feature. I don't care how you will do it, I just trust you.
👻Quality: Hey, I do care how you will do, not what. And I just don't trust you.
🤖Developer: 👉Hey, I've built a cool stuff👈

There is an expectation of Trust going from the top to the bottom, and no one is actually interested in the implementation details... so...

So the expectations for the backflow are the same - something they can trust, and nobody interested how you actually did it - that's implementation details, not the product itself. And you were asked to create a product 😉.

And "trust" means - your work shall meet some expectations, probably unique for every level.

If it walks like our acceptance criteria, and quacks like what we asked for – it's our feature! 🚀Ship it immediately🚀!

This is something you shall keep in mind -

Prefer Integration Tests? Think twice

Anton Korzunov ・ Jul 29 '19

#testing #webdev #codequality #tdd

Duck typing

As I said above - a single thing could quack like a pack of ducks. Let's ask every 🦆 in that pack, how it quacks about a Good Product:

💰bussiness: It should be profitable. My Your salary depends on it.
🤖developer: It should be maintainable.
🚀performance: Loading time can't be more than 2 seconds.
🕸network: latency below 300ms.
🕵️‍♀️QA: code coverage above 95%.
👩‍🎤design: all margins should be the same.
🚔GDPR: Ha-ha! Gotcha!
👂a11y: don't forget about us
🤖another developer: And it still should be fun!
🕵️‍♀️QA: me again. Here are 20 testing notes you should check your PR against, which is basically everything above. You're welcome, enjoy your day.

Yep, QA/QEs are duck typing their expectation since forever.

Long story short - if Product wants to be a Good Product it should meet different and parallel expectations. For every case, there should be a simple acceptance criteria, and it should be clear how to meet these requirements.
One by one.

To better understand this moment, let's take a step back, and refer to the ancient knowledge. To the Blind men and an elephant

A group of blind men heard that a strange animal, called an elephant, had been brought to the town, but none of them were aware of its shape and form. Out of curiosity, they said: "We must inspect and know it by touch, of which we are capable". So, they sought it out, and when they found it they groped about it.

In the case of the first person, whose hand landed on the trunk, said "This being is like a thick snake".

For another one whose hand reached its ear, it seemed like a kind of fan.

As for another person, whose hand was upon its leg, said, the elephant is a pillar like a tree-trunk.

The blind man who placed his hand upon its side said the elephant, "is a wall".

Another who felt its tail, described it as a rope.

The last felt its tusk, stating the elephant is that which is hard, smooth and like a spear.

In some versions, the blind men then discover their disagreements, suspect the others to be not telling the truth and come to blows.
In some versions, they stop arguing, start listening and collaborate to "see" the full elephant.
In another, a sighted man enters the parable and describes the entire elephant from various perspectives, the blind men then learn that they were all partially correct and partially wrong.

👉 🦆 are the blind men and your application is an Elephant 👈

You might try to describe it in various ways, and then find a whole object, matching all expectations at once.

In big companies, there are different ceremonies, patterns, protocols and standards you have to meet to launch a new product. You have to pass audits and reviews, but that is... so boring.

There should be a better way to understand what shall be done, and thus let's recall another piece of ancient knowledge, recall what a classic said (Lev Tolstoy, 1828):

All happy families resemble each other,
each unhappy family is unhappy in its own way.

In other words: happy families share a common set of attributes which lead to happiness, while any of a variety of attributes can cause an unhappy family.

This concept, known as Anna Karenina principle, is quite fundamental and explain a lot - from animal domestication to PayPal (🤷‍♂️ according to Wikipedia)

And you know - All happy families resemble each other, as well as All Little Black Rain Clouds resemble each other. There is no difference.
They are all black, rainy, and not as small as that bear. Oh, that's a bear!!!

And again, it's a subtype of Duck Typing.

We will return to the little+black+rain+clouds later, as well as check why the green great dragon cannot exist...

Behaviour

Let's try to formalize Duck Typing for some Application. Should be pretty straightforward (if not - we are doing something wrong):

Let's imagine you are a QE, and I am demoing my stuff to you
Then, when I press that button
Something magical should happen (and not an explosion)

Not quite formal? What about this:

Given: "localhost:8080/my-cool-app"
opened in a Google Chrome

When: I press the Big Blue Button

Then: "Hello World" is displayed

That might look like BDD testing, with all those Given/When/Then, but it's actually Duck Typing, again and again.

Given: a 🦆
When: you kick the 🦆
Then: it quacks
So: 🦆 is alive

This principle also is known as smoke tests

an acceptance test is preliminary testing to reveal simple failures severe enough to, for example, reject a prospective software release. Smoke tests are a subset of test cases that cover the most important functionality of a component or system.

Let's write a bit more tests

What would you say about this one?

Given: a 🥛 glass of water
Then: it's full
When: you take a sip
Then: it's 70% full

When: you take a sip
Then: it's 40% full

When: you take a sip
Then: 🥛 glass is empty

Probably there are some implementation details. Like 30/30/40 per cent of the water sipped every time. That's too fragile

Given: a 🥛 full glass of water
When: you take 3 sips
Then: 🥛 glass is empty

Much more compact, and sound.

6 vs 9 ?

6/9 is about different perspectives. Like the 🥛glass could be 50% full as well as 50% empty.
What if the same actions affect more that one thing?

Given: you are thirsty 
When: you take 3 sips
Then: you are full

Of course! You action affects not only a 🥛glass, but you as well.
Another example? The opposite this time.

Given: 🌏 is spinning
When: you take 3 sips
Then: 🌏 is still spinning

All our tests are the same:

Given

you open some Page, or mount some Component
you provide some data, or some props

When

you click somewhere
you change some props or data
you perform some action

Then

you again check something
you expect to be "somewhere"

 Given 👉 When 👉 Then

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

What it actually IS? Remove all sugar, remove all extra words. What is THE MAIN?

Given -> When -> Then

Precondition -> Action -> Postcondition

Somewhere -> Action -> Somewhere else

Where we are -> What we do -> Where we are

Long story short - this is how State Machines works. All those BDD tests are testing nothing more but transitions from one State to another State, caused by some event. Nothing more.

Or from some data to some data, like in Redux/Flux

State + Action = New State

This image is taken from @davidkpiano presentation Infinitely Better UIs with Finite Automata, and there is also a few xstate-related articles you can read at dev.to (and much more in the wild).

No, disabling a button is not app logic.

David K. 🎹 ・ Nov 13 '19

#state #statemachine #react #async

Quack!

However, you know, state machines are great... but while we are talking about them, you probably do not use them in your code.
However, I would not be so sure, even if you really don't use them intentionally, explicitly or even implicitly.

Finite State Machines are all about the finite amount of States something could be in, and by some reason. Like could be little black cloud not rainy? Could large rainy cloud not black? What is your expectations from the cloud? Why do you think it is rainy?

Even if David once said - "disabling a button is not app logic" - "Disabled Button" has to have disabled attribute, or at least looks like disabled. Well, quacks 🦆 like a disabled, so everyone will understand your intent. WAI-ARIA included.

👁: An observable system is one whose internal state can be deeply undertood just by observing its outputs.

So, keeping the main principles of Duck Typing - is it possible to infer the Page State from observing the Page?

What if we know how every page state should quack. Could we find the right duck?

🦆 + action = 🦆

However, is it really the case? Let's recall the case with a cup of water.

Given: you are thirsty 
When: you take 3 sips
Then: you are full

You were in one 🦆, took an action, and now you are in another 🦆. In reality you just drunk some water, and your digestion system reported that your are now ok. In fact you are not yet, the water is yet in your digestion system.
👉 The BDD test is actually testing a derived reaction. Which is even not real.

It tests the RESULT, not the implementation details. You heard it multiple times, and let's recall another ancient knowledge to understand the meaning.

Life is a journey, not the destination.

Well in our case it’s the opposite. The destination is the reality, and the journey is an implementation detail.

To finish the moment, to find the journey’s end in every step of the road, to live the greatest number of good hours, is wisdom.

Allegory of the cave, Plato's, 514ad. Which is, long story short, "The Matrix".

Plato begins by having Socrates ask Glaucon to imagine a cave where people have been imprisoned from childhood. These prisoners are chained so that their legs and necks are fixed, forcing them to gaze at the wall in front of them and not look around at the cave, each other, or themselves.
Behind the prisoners is a fire, and between the fire and the prisoners is a raised walkway with a low wall, behind which people walk carrying objects or puppets "of men and other living things".
The people walk behind the wall so their bodies do not cast shadows for the prisoners to see, but the objects they carry do.
The prisoners cannot see any of what is happening behind them, they are only able to see the shadows cast upon the cave wall in front of them. The sounds of the people talking echo off the walls, and the prisoners believe these sounds come from the shadows.
👉 The shadows are reality for the prisoners because they have never seen anything else; they do not realize that what they see are shadows of objects in front of a fire

By now you should understand, that your code, your codestyle, patterns and everything else are "the real objects", but "the prisoners", your users in this case, are able to see only shadows.

Real customers are facing the combination of many unrelated to each other processes, TCP/IP and the way their screens displays the data included.

😉 if it walks like an Application, and it swims like an Application, that's an application, not a random collection of bytes.

Reverse Duck

Reverse Duck is what our E2E tests (should) look like
– open some page, and assert some selector. If that selector exists – then we are on the expected page, and the test continues.

We are doing some actions, and again checking some selectors - is our page walks like the right page?
doing more actions, and again checking selectors - is our page swims like the right page?
Oh, it is not? quack!

Every test starts in one 🦆, and ends in another 🦆. Your ability to test your application is limited to your ability to define those distinct states, and here a picture, explaining a lot, again from one of David's presentation. Write fewer tests this time.

👉On the picture: you are in the State A, and you know "how" to go from it to State B or State C - you can create an automated test checking that your application is working "as designed".

All good applications resemble correct ~~business processes~~ state machines behind.

Having your application described as a state machine you CAN try to move from one State to another State and assert the result. Like:

have you reached the right State, as it was designed?
could go from the Very Beginning to the Very End?
could you test transition between any sibling states?
could you start your application in any Specific State? If not then why?
could you understand that your application is in some Specific State right now?

Works in a quite obvious way - exactly as we need:

Given: 🦆 > ducks like your Home Page
When: You press The Most Important Button
Then: 🦆 > still ducks like your Home Page 😅

Unfortunately, not many application works that way, especially SPAs - usually, they are a bit more complex. Usually, our applications are Big Machines, composed of Smaller machines - 🦆🦆🦆🦆, the Pack of Ducks.

If you just clicked The Most Important Button - it might open a Modal Dialog - like it added something on the page, something parallel to everything else. A new 🦆.

Given: 🦆 > ducks like your Home Page
When: You press The Most Important Button
Then: 🦆 > still ducks like your Home Page, 
         > and The Modal Dialog
         > and network activity indicator
         > and system await user action
         > ....
         > there are just not “blind monks” describing your Elephant

Good examples of "small machines", many of which could be found inside bigger ones are React Hooks - small and simple state machines. And they can form React Component - a Big Machine, the composition of some data machines (useState) plus effect machines (useEffect).

There is no way you can reproduce a really Big Machine using one State, but who said it should be one?

when you are opening your application – you are changing it State. From Closed to Open.
when you changing а current page – you are changing a nested machine state or sub-state. From Page A to Page B.
when you are changing something on a page, filling inputs in the Form you are not changing anything, except machines inside those inputs.
but once you have filled everything a Form State could change – Empty->Invalid->Valid.
there are many state machines coexisting in your application. Without proper management it is leading, I'm afraid, to Schizophrenia
with proper management, they form Akinator, which is nothing more than a pretty big decision tree, which is, well, Recursive Duck Typing. And Triage.

To prevent any misunderstandings let's define terminology:

State – is an internal state of an object, not observable from outside. Like React or Redux state. It could be even NOT used for the current page (There is always some useless pieces of data 😿)
Duck State – is a part of an underlying state machine, including the “shadow” of explicit machine observable from outside. And let's call it a Phase.

Phase of a State Machines is the current state this machine is in. Like you are reading article. State machine might be in single one state at the one point of time, but remember 🦆🦆🦆 - there could be parallel and nested machines.

It's easy to distinguish State and Phase:

State could be a composite object, with dozen variables inside.
Phase always just one. The something major about the subject greatly altering subjects behaviour.

think about the blind monk. The monk as to describe what he experienced in one or two words. Which?
If you are not able to do it - add more monks.

Tier

You cannot represent😅 your application with a simple and only one state machine - the real application is like a puzzle, or even like a Quest.

you are in point A
you have to play a mini-game, like a boss fight, to move to point B
you are in point B
...
that minigame is an application inside an application - a nested submachine
that forms multi-layered, multi-dimensional or multi-tiered architecture

Or a Timing/Flow/Sequence Diagram, which explains what is happening layer by layer.

Multitier architecture is quite common and popular. Many patterns could be considered as multi-tiered - from microservices to MVC.
Usually, the separation between tiers is "logical": Presentation layer, Service Layer, Business logic layer, Data access layer. This is how the majority understands it. Not me.
I don't like this sort of separation, as well as I hate "testing Pyramid" and the separation between unit/integration and E2E tests - it's not logical.

Really, "the difference" between unit and E2E tests that the first usually runs on the "server", and the "second" in the Browser. It's a separation by the tool used to run your tests, not the tests. And that's a good example of abstraction leaking.

the first tier is a feature definition. It defines how something should work. This is what you want to build, not how.
the second tier is a testing layer. A duck machine, where you have to define how every particular state quacks. This is where Design and Observability met each other.
the third tier is the implementation of a specific component. Of a Step. How a single Big Machine should work.

is the current duck walking as expected, is current duck quacking as expected.

If no duck is quacking – it's a fail.

If more than one duck is failing – it's a fail.

Surprisingly – the last tier is helping to re-define the first. No Phases should quack the same. If something is different inside – it should be different outside.
Situations when customer trying to click a save button, without any effect cos it's "disabled", but not from UI perspective – much be not possible.

If this is a major behavioural condition – it shall have its own Phase, own State, and shall have its own Duck🦆.

By fact - is very hard to define the proper requirements, it’s really easy to desire something not you really want.
Like “build it with React and Redux” cannot be a business requirement, and usability, conversion rate and a11y cannot be a technical one.

Let’s refer to another ancient knowledge - the Djinn in the bottle.

🧞‍♂️: here I stand, let’s make it fast - 3 wishes
🙀: I want to be riiiich!
🧞‍♀️: as you wish, 😈

A moment later you are rich. Very rich. And old. And everybody hates you. And trying to kill you. Cos you are Narcos.
Not actually what you wanted, but exactly what you’ve asked for.

Just for your information - there is a film about it - Bedazzled.

As a test, Elliot wishes for a Big Mac and a large Coke. The Devil takes him to McDonald's and places the order. Elliot has to pay for it, because, "there ain't no such thing as a free lunch." After taking Elliot to her office, based at a nightclub in Oakland, the Devil convinces Elliot to sign her contract, and delivers further wishes. Each wish has Elliot living them out with Alison and his co-workers in surrogate roles. However, the Devil always spoils his wishes by adding something he does not expect or want.

And, to be honest, that evil djinn, who is going to use everything you said against you... is you, who is doing exactly what was asked for, but... the devil is in details. And that you is your project manager.

Well, manager, you’ve got what you deserved. Next time be more precise, wish something you really need.

It's always about your Duck definition. How it quack, what you asked Djinn for, what is the story of the blind man.

Conclusion

The Duck Typing is a pattern matching. Is a way to define what something is by observing it.
It is a way to understand what something actually is.
It is a requirement to left some breadcrumbs, some details and nuances to be able to distinguish one duck from another.
It is how to stop being an evil djinn.
About what does really matters, and what is not.
It's about design, UX, monitoring and observability. As I've said in the beginning - you can hammer literally everything with it.

The mental models derived from duck typing might help you develop a more thoughtful solution, which would do what you really need, as well as define and clarify why you actually need.

Next time you will be asked to do something, just quack.

PS: and here are the slides from the talk

IE11 and the Missing Polyfills

Anton Korzunov — Wed, 11 Dec 2019 06:44:12 +0000

It was a beautiful sunny day, and our brand new site was working well, as it usually does, however, nobody(except us) knew how cool is it, yet 😉. Our startup was in the stealth mode.
We had no traffic, no customers, and, obviously, no worries.

Everything was perfect - the code was DRY, KISS, fast, best practices applied, dependencies up to date, and even UX design was not that bad.
And it was a launch day!

All systems ready! Prepare! Launch 🚀🚀🚀!
3 seconds! Telemetry! All green! 10 seconds! 60 seconds!
🥳 We are online! 🥳

We were confident - everything is ok. Of course, there was no reason to worry - we had proofs that everything is perfect: 100% unit test coverage and puppeteer based E2E tests would not let any bug to exists.

We were online...

We were happy...

We were not expecting anything bad to happen... but it happened...

...shouted rollbar, the service we use to monitor our frontend errors.

...this and nothing more, keeping silence for the next minute.

And then it happened AGAIN! And AGAIN! And AGAIN, and our happy life was destroyed, and our belief in ourselves has vanished 😭😭😭...

...

Sound like a scary story? Well, it was very scary, and a bit unexpected. But, looking behind, we did everything to get into this trouble - we haven’t provided required polyfills to let our so cool, and so modern code work in the legacy browsers, the browsers no developer would ever use, the browsers which are still around.

According to the statistic - usually, almost 90% of your customers are expected to use more or less “modern” browsers, however, in some cases, it might be as low as just 50%. It depends who you are, where you are, and your target audience.

Percentage of Instagram users with ES2017 supported vs unsupported browsers, source.

BTW: React and Create-React-App still supports IE9, 🦖

And we nor made our code better for modern ones, shipping more compact and fast “ES6” to the browser, which old browsers are absolutely unable to understand, but the new ones could benefit from. Nor made our code compatible with those “old” browsers, shipping everything in "ES5", as well as adding the “missing pieces”, known as polyfills, without which nothing would work as expected.

Polyfills are in fact a very bad thing, as long as they are a very big thing. Don't add them unless you need them. (well, so we didn't)

I would ask you one thing: what is better - provide the best experience possible for the majority of your customers, like around 90%, and let the other suffer... or provide the same "not great" experience for everyone, including that “majority”.

And would you be surprised, if I tell you that no matter what you do, you will pick the first way? There are always people who cannot run as much JavaScript as you are sending, or just some settings and environments where JS is disabled at all.

If not JavaScript, then CSS - maintaining perfect result across different browsers, when some of them just don’t (yet) support something is hard and (and that’s the truth) economically inefficient.

Even more - the common "target" for the bundle is "2 last versions + Firefox ESR + IE11". So IE11 is the minumum requirement, a vast majority of sites are designed to work with.
But what if I am using IE10, or QQ Browser Mobile? (and I have no idea what it exactly is, but that’s not quite “standard” thingy).

So here is the point: it would be better for you to handle the bigger part of your customers in the best possible way - ie ship as modern code, as possible. However, you always should be ready to ship de-modernized bundles for your other users, which should not be forgotten.

de-modernized. de-gradated. de-evoluted. devoluted

PS: Have you heard about “graceful degradation”? Not a new thing.

🦎 -> 🦖

However, this story is not about modern bundles from es5/es6/es7 perspective. This story is about polyfills. And polyfills - language features polyfills, as well as web platform polyfills, could be a quite big thing (and we are trying to make this “efficient”).

I am still remembering my PTE English exam, where you have to explain a random picture or graph. _What could you tell me looking at this picture?

By looking at this picture (I’ve borrowed from Smart Bundling), there are 4 points I want to highlight:

you don't have to ship polyfills to a browser which supports these features. Polyfills exists to polyfill something missing.
you don't have to ship a polyfill which is not going to be used straight ahead. You need it only when it's actually required.
and you have to have all "missing functional parts" when they needed, or your code would produce a runtime exception.
there is no way to automatically detect which parts are missing 🤔. Well, that’s not clearly visible from the image, but is true.

The missing parts

Let's imagine you use vanilla JavaScript. You do Object.entries, and it just works. For you. However it would not work for IE11, that's a sad but obvious fact.

You may see the error in logs, and add @babel/polyfills for the first time. It's like the first thing to do, and the first result in a google search. That's fixing the problem, but is adding too much stuff you don't need - like all possible polyfills.

Should be a better way.

useBuitIns

So, you google deeper, and found that babel could magically make everything better - just use usebuiltins: "entry"



{
  "presets": [
    [
      "@babel/preset-env",
      {
        "useBuiltIns": "entry"
      }
    ]
  ]
}

What does it do? It replaces @babel/polyfill with polyfills actually required by target system, sometimes just halving their count. Once you configured - "modern + IE11" it will remove polyfills for IE9-10, as well A LOT of polyfills for Android related browsers.

However, that "half" still might include stuff you are NOT using, and there is another option to tackle this - usage



        "useBuiltIns": "usage"

the usage is a bit smarter than entry - it would add polyfills only for stuff you are using in real. Halving already halved size.

haven't used WeakSets? Removed!
no RegExp? Removed!
using Symbols? Polyfills!
not using String.repeat? Re... Well...

What's not so great...

Actually "useBuiltIns": "usage" is not removing anything - it is adding. Is somehow detect that stuff got used, work it out.

Usage has two design problems:

it's actually not quite "smart", as long as ”JavaScript”. I mean "JavaScript" is the reason why it’s working in a not best way. > - If you do anything.description it would add polyfill for Symbol.description, cos ".description" 😉 > - If you do Symbol.toStringTag it will add:
- es.symbol.to-string-tag
- es.math.to-string-tag
- es.json.to-string-tag Cos, you got it, .toStringTag 😉. As long as it's really don't know all types - JS is not a typed language. it’s 🦆 Duck Typing. If something quacks like toStringTag - get it polyfilled!

There is no way to fix it - false positives would not break your application, while false negatives might. So - live with it.

This is not a "real" problem. You might just get more polyfills that you really need, but still less than with entry mode.
And, the main difference, you will get required polyfills where you need them, not at your entry point. So this more is the code splitting best friend.

the second problem is more severe. usage is about "usage", and "usage" only within files "under babel management". If some of your node modules requires any polyfill - it would not be detected, and you will have to add it manually. I hope before shipping stuff to production. Well, like we did. 🥳

Sometimes you might work this out expending babel to the whole node_modules, but that's not always an option.

However enabled by default for create-react-app as well as parcel

CoreJS2 and CoreJS3

By fact, there are two useBuiltIns usage plugins - one is for corejs-2 and one is for corejs-3.
v3 "detects" much more cases, which is good from one point of view - you are more "safe", but from another, it leads to a much higher level of false positives.

Theoretically - a whole corejs3 is 50kb gzip, but you might need only 2kb from it.

Takeaways?

use @babel/polyfill or underlaying core-js to make your application compatible with a wide amount of customers browsers, including aged or bugged browsers.
use @babel/preset-env with useBuiltIns: "entry" to safely reduce the number of polyfills sent.
use @babel/preset-env with useBuiltIns: "usage" to UNsafely reduce the number of polyfills sent even more.
😉 don't forget - using only one bundle for all customers is making this sort of optimizations inefficient, as long as too many polyfills, prepared for "legacy targets" would be sent to "modern targets". As well as less compact js code.

8 polyfills(24kb) were needed for modern bundle, and 37(154kb) were required for IE11 in our case. Sizes are before gzip.

⚠️ spoiler alert ⚠️

Core Duo

So, to get something measurable from shipping right polyfills to the right client you have to send a different code to different clients.

There are simple ways to do it:

use polyfills.io to automatically deliver all required polyfills. One line fix 😉. One more blocking script at your head 🤔.
use pika to deliver legacy/modern bundles. Sounds just amazing 🥳. Probably you have to change all your build pipeline 🤓.

There is a bit harder way - use double bundling or multicompiler mode to create different bundles targets, and that's the best you might get, but it's hard to manage. In terms of code-splitting, prefetching and service-workers.
parcel2 is promising to get it working out of the box, time will show how useful it is.

There is another question to ask yourself -

Which bundle to build?

And how this "double bundling works", and which operations are required to make your code compatible with browsers, and what's the goal...

And that's simple, really simple - modern browsers are able to run your code as-is.

Babel, as well as TypeScript are here to create a "lower" version of your code (babel initially was named 6to5, it was converting es6 to es5, you got it 😉).

The idea about bundling is to get your files, combine them together, and create a version for a "lower target". Like es5, eatable by any browser. Well, eatable with not language "downgraded", but also with "missing pieces" polyfilled, keep that in mind.

Double-bundling is doing exactly that, just twice - first for one target, and secondary for another. Modern and legacy. Module and no-modules.

And I think there is a more efficient way to handle it

🦎 -> (devolution) -> 🦖

Idea behind devolution is simple:

you are compiling your bundle, you can run in your browser. Like the "modern" one
devolution takes it as an input, and produces the legacy output, with language version "downgraded", and requited polyfills added.
it makes it faster than bundler, with easier configuration, however with some cost to the final bundle side.

Let's go step by step:

you are compiling your bundle to a modern target

Just do it. Pick esmodules target, which targets browsers with "module" support, or pick even higher target, without old Safary inclided. Feel free to use preset-modules, which creates more compact es6 code than preset-env, however not adding any polyfills

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

`devolution` takes it as an input, and produces the `legacy` output

Run run yarn devolution and it will first create a self-documented .devolutionrc letting you configure absolute everything.
The second run will create a legacy bundle.

Well, asciinema is not looking good at dev.to content width :(

The process is split into a few steps:

detecting required polyfills, using port of babel's usage plugin.
adding missing polyfills, as well as elaborating what is required where
recompiling code to another target, by fact - devoluting it
re-minification of result code, to keep it compact
and that's all..

There is only one piece left - pick the right bundle to use, and that's easy - just import the right one, everything else, including _webpack_pulbic_path_ update is already inside.



<script> 
  var script = document.createElement('script');
  var prefix = (!('noModule' in check)) ? "/ie11" : "/esm"; 
  script.src = prefix + "/index.js";
  document.head.appendChild(script);
</script>

This is the main difference between approach undertaken by devolution and common "double bundling" - devolution produces two structurally identical directories, the difference in only public path.

The process is working quite fast, as long as:

all heavy lifting is already done by the bundler
each file is managed in a separate thread, so if you are using code splitting the process might be quite fast.
you can opt-in for swc, making compilation 10 times faster - there is no need to apply any babel plugins again - they are already applied, so we are able to use more specialised tools.
bonus: you are getting polyfills for the "whole" bundle, all your node_modules are covered. As well as es5 for the whole bundle - if you are using some es6-based @sindresorhus modules, like query-string - it would just work without any extra configuration!
another bonus: it does not matter which framework or bundler you are using - this is working at deployment time. So - it would work even for closed systems like CRA.

In numbers - it's taking 10 seconds to handle bundle it takes 30 seconds to build 😒, and 30 seconds to handle bundle it takes 20 minutes to build 😃.

Bonus - you might use preset-modules, which is not adding any polyfills to create a bundle, and then use devolution to add required ones for your "esm bundle".

The point

The result bundles are the same. They are just laying in different directories. You can use __webpack_public_path__ to control which one has to be, or is loaded, while parcel would work out of the box.

Read an article about shipping module/nomodule bundles for details:

🛳 Optimising JS Delivery

Anton Korzunov ・ Oct 4 '19

#webdev #codesplitting #javascript

The real conclusion

you have to ship polyfills to support all possible browsers your customers might use
it's quite bad idea to ship all theoretically required polyfills to everybody
consider separating bundles for the "modern" and "legacy" browsers, or, at least, separating polyfills you are sending to your clients. Or, at least, use babel/polyfill with entry module useBuiltIns

And keep in mind

you are going to send more javascript code to the aged browsers, as long as it would be a result of a transpilation from es6-es7-es8.
amount of polyfills to be sent would increase and the numbers of features to polyfill grows
the "legacy customer" will suffer in any case, as long as even "modern customers" suffer - there is too much javascript around.
however, you might help at least the majority with a few lines

Start using double bundling. Please.
⚠️ However, removing polyfills, you dont need for the more modern bundle, could drive the biggest impact to the bundle size ⚠️, especially for the entry chunk.

Don't be a 🦖, let devolution handle it. At least give it a try, you can setup it in moments and start being more efficient.



yarn add --dev devolution
yarn devolution [source-dist] [target-dist]
// like
yarn devolution build build

feel free to use as modern code anywhere. node_modules included. Create as modern bundle as you can, and devolute it as a whole.
be confident - all polyfills are included. devolution uses the same usage-plugin @babel/preset-env uses internally and you can configure corejs version to use.
it's just a few lines to add it to your setup and start shipping separated bundles for different customers.
well, it's the only one "safe" way to use @babel/preset-modules
it's 100% configurable. .devolutionrc.js let you control almost everything
and it's fast - multy threaded nature with optional usage of lighting fast swc transpiler.

DEV Community: Anton Korzunov

Weak memoization in Javascript

Level 1 - make it work

Level 2 - put it in a box

Boss fight - there could be only one

Loading level 2 - somewhere else

Level 3 - The Better Place

Level 4 - cascading

Level up - an extra ability

So here it is

Quick recap

Partial: how NOT to mock the whole world

Jest.mock

What about defaults?

Only one!

Something better

What about "over mocking"?

That's it, folks

🧶YarnLocking🔓 your dependencies

Chapter 1 - understanding the problem

Lets create an issue

let's verify - our yarn.lock should contain only two dependencies - focus-lock and tslib

Is it a problem?

😳 Existing dependencies and the order of their addition affects the shape of the end artefact 😬

Another example maybe?

A real life example?

This case needs one repo consuming another to have a gap in the npm logistic layer in between

So now we have two buttons, with different major versions, and this cannot be deduplicated.

Chapter 2 - Solving the problem

Going back and upgrading

Yarn-unlock-file

What you are dependencies?

Safety first

Dry run

Note about Npm-check-Updates

So what?

UI? Piece a Cake

Where is the Problem?

Path to Success is a proper foundation.

I've seen it

Layers

The Whole and the Parts

Foundation: the Essence and the Variables

Button Group

Table

Modal

Unidirection flow

Middle-level architecture

Actionable advice

BEM vs CSS Grid

CSS Grids are awesome 🥳

BEM has a Plan

A few rules

Rule them all

What to do

So what?

See also:

Wait!

What Problem We Solve

The System

What problem we solve?

Which problem we solve?

What Problem we solve?

What problem We solve?

What problem we Solve?

Does it work?!

Prior art

Sergey KonstantinovFollow

The limits of 2 dimensions

Maps

Living in 2-dimensions

Problem 1

Problem 2

Clustering

Problems with "random queries"

Z for Z-code

Word-to-vec

Terravigil

Buckets

Score

let's verify - our `yarn.lock` should contain only two dependencies - `focus-lock` and `tslib`

`Why` is usually a missing part. Start from it, and end on it.

Conclusion