We have codified our existence to bring it down to human size, to make it comprehensible, we have created a scale so we can forget its unfathomable scale


# Building a scalable Node.js API using repository service pattern

You might be reasonably annoyed that most Node.js API designs do not consider scalability and test coverage as one of the most important considerations in API design. People waste a considerable amount of time building Node.js `APIs` utilising a mixture of module / `middleware` patterns. Because that is what the courses, articles and tutorials teach you for 99.9% of the time. You probably have seen this before:
```ts
import express from 'express';

const app = express();
// logger.ts
const logger = (req, res, next) => {
  console.log('Logged');
  next();
}
//authenticate.ts
const authenticate = (req, res, next) => {
  // authenticate user 
  next(); 
}

app.use(logger); 
app.use(authenticate);

app.get('/', (req, res) => {
  res.send('Hello World');
});

app.listen(3000);


```
Here is the repository of the latest [Node.js course](https://github.com/ruskeyz/node-js-api-design) that I did. It has a great structure, the course is well written and was a joy to do. But as all of these all the courses that went through for my consideration: it is very basic and does not teach you how to handle scale, testing, and complexity. It does the job and does it well - but as the code grows it makes scaling and separating the logic incredibly complicated.


## The repository service pattern

One of the battle-tested and popular approaches to this kind of problem is utilising a repository service pattern. This pattern came from Java land: take a read of this [article about repository service pattern in Java](https://java-design-patterns.com/patterns/repository/#programmatic-example-of-repository-pattern-in-java). This pattern works really well in Node.js applications too. In this blog post we will be using examples from some take-home that I received some time ago. It displays and sorts data showing currency rates for a selected date. You can find it available [here](https://github.com/ruskeyz/full-stack-currency-ticker-service-repo). In essence: all you do is create classes for possible layers in API:

### Router

Router handles requests and validates data types

```ts
import express from "express";

import { ConsoleLogger } from "./utils/logger";
import { ExchangeRateRepo } from "./repositories/exchangeRateRepo";
import { ExchangeRateService } from "./services/exchangeRateService";
import { ExchangeRateHandler } from "./handlers/exchangeRateHandler";

const apiRouter = express.Router();

const consoleLogger = new ConsoleLogger();

const exchangeRatesRepo = new ExchangeRateRepo("./currencies.json"); // <-- data
const service = new ExchangeRateService(exchangeRatesRepo); // <-- business logic
const handlers = new ExchangeRateHandler(service, consoleLogger); // <--- handles http requests

//get EX dates
apiRouter.get("/exchange-rates/dates", handlers.getExchangeDates);
//get EX data
apiRouter.get("/exchange-rates/:date", handlers.getExchangeData);

export { apiRouter };
```

### Service

Service (or manager) is responsible for handling the business logic. That includes manipulating data, gluing different parts of data together and creating function that bring value to the company. Service is called from Router.

```ts
import moment from "moment";
import {
  CurrencyRate,
  ExchangeRateData,
  ExchangeRateMap,
  NewExchangeRateData,
} from "../models/exchangeRatesModel";
import { ExchangeRateRepo } from "../repositories/exchangeRateRepo";

export class ExchangeRateService {
  dataset: ExchangeRateMap;
  transformedData: NewExchangeRateData[];

  constructor(repo: ExchangeRateRepo) {
    this.dataset = repo.dataset;
    this.getExchangeData = this.getExchangeData.bind(this);
    this.transformedData = this.transformExRateData(this.dataset);
  }

  async getAllDates(): Promise<string[]> {
    let dates: string[] = [];
    for (let i = 0; i < this.transformedData.length; i++) {
      dates.push(this.transformedData[i].date);
    }
    return dates;
  }

  async getExchangeData(date: string): Promise<NewExchangeRateData> {
    const data = this.transformedData;
    const exchangeRateByDate = data.find((item) => item.date === date);
    if (!exchangeRateByDate) {
      throw new Error("Incorrect date selected");
    }
    return exchangeRateByDate;
  }

  transformExRateData(data: ExchangeRateMap): NewExchangeRateData[] {
    // Make an arr of dates to loop
    const currencies = Object.keys(data);
    if (currencies.length === 0) {
      // Handle the case where there is no data in the ExchangeRateMap
      return [];
    }

    let transformed: NewExchangeRateData[] = [];
    for (let i = 0; i < currencies.length; i++) {
      const currentCurrency = currencies[i];
      const currentData = data[currentCurrency];
      let previousData: ExchangeRateData;
      // We cannot get % ch for the first day, 0
      if (i === 0) {
        previousData = currentData;
      } else {
        previousData = data[currencies[i - 1]];
      }

      // calculatePercentChange and then push to DS
      const percentChangeRates = this.calculatePercentageChange(
        previousData.rates,
        currentData.rates,
      );
      //format dates
      const formatDates = moment(currencies[i], "YYYY-MM-DD").format(
        "DD-MM-YYYY",
      );
      transformed.push({
        date: formatDates,
        timestamp: currentData.timestamp,
        base: currentData.base,
        rates: percentChangeRates,
      });
    }
    return transformed;
  }

  calculatePercentageChange(
    previousRates: Record<string, number>,
    currentRates: Record<string, number>,
  ): CurrencyRate[] {
    const result: CurrencyRate[] = [];

    for (const currency in currentRates) {
      if (previousRates[currency] !== undefined) {
        const currentPrice = currentRates[currency];
        const previousPrice = previousRates[currency];
        const percentChange = Number(
          (((currentPrice - previousPrice) / previousPrice) * 100).toFixed(1),
        );

        result.push({
          name: currency,
          price: currentPrice,
          percentChange,
        });
      }
    }

    return result;
  }
}


```

### Repository

Repository handles all the communication with the database, and allows for clear separation between development, staging, production databases. The idea is to create a `Class` such as that handles communications with one entity. For example, `UsersRepository`, `PostsRepository`, and so on. Repository classes have an exclusive access to the database, which is strictly structured by migrations. It is a single source of truth that interacts with the database. This point is crucial in effectively utilising the Service Repository pattern.

```ts
import { readFileSync } from "fs";
import { ExchangeRateMap } from "../models/exchangeRatesModel";

export class ExchangeRateRepo {
  jsonFilename: string;
  dataset: ExchangeRateMap;

  constructor(filename: string) {
    this.jsonFilename = filename;
    this.dataset = JSON.parse(readFileSync(this.jsonFilename, "utf-8"));
  }
}

```

Service repository pattern presents a very intuitive workflow for testing. As a result of using the pattern, logic is effectively decoupled and mock testing becomes a breeze:
- `Router` class utilises `Service` classes.
- `Services` class utilises only the repository.
- `Repository` class only needs a link to the specified database.

### Summary

As a result of using service repository pattern, the application benefits from a clean separation of concerns, making it easier to test, maintain, and extend. Give service repository pattern a go, as it tends nicely to small and large projects alike. If you became interested in Node.js patterns, different approaches to testing and scaling your app: highly recommended reading [on Node.js patterns by Mario Casciaro and Luciano Mammino](https://www.nodejsdesignpatterns.com/). The book does not cover service repository pattern, but offers a great deal of depth in how structure Node.js applications.


Building a scalable Nodejs API using Repository Service pattern.

So you wanna surf? How far are you willing to go?

Building a Full Text Search Engine in Javascript

Scalable golang api example, production-ready microservices

Production Ready microservices or Kubernetes for dummies in golang

Why the order of looped maps in Golang is random


## Iterating over maps in golang

There is some interesting behaviour about how a for-range loop iterates over a map. 

```go
func main() {
	m := map[string]string{
		"a": "Alice",
		"b": "Ben",
		"c": "Charlie",
	}

	for i := 0; i < 3; i++ {
		fmt.Println("Iteration", i)
		for k, v := range m {
			fmt.Println(k, v)
		}
	}
}
```

When you build and run this program, the output varies. For example:

```shell 
Iteration 0
a Alice
b Ben
c Charlie
Iteration 1
a Alice
b Ben
c Charlie
Iteration 2
b Ben
c Charlie
a Alice
```

The order of the keys and values are always random. After some research, I have found out that is intentional security feature. 
If maps always hash items to the exact same values, and you know that a server is storing some user data in a map, you can actually slow down a server with an attack called *Hash DoS* by sending it specially crafted data where all of the keys hash to the same bucket.

To prevent this problem, the Go team made some [changes](https://github.com/golang/go/issues/2630). They modified the hash algorithm for maps to include a random number thats generated every time a map variable is created. Next, they made the order of a for-range iteration over a map vary a bit each time the map is looped over. These two changes make it harder to implement a Hash DoS attack.




Iterating over maps in Go

Fundamental in understanding of JS is the scope.


## Scope

Scope defines where the JS compiler looks for things like variables and functions. It is a set of rules that determines where and how a variable can be accessed in your code.

Lexical scope is a reference to JS on where to look for things, fixed at compile time ahead of execution.

Why? JS processes a scope & puts identifiers to recognise their position and how to execute them afterwards properly. Lexical scope is determined at compile time; once it runs through, it stays the same.

Why do we need scope?

-   Avoid name collisions
-   Security, extra layer against misuse
-   Protect yourself for future refactoring

![scope](/blog/lexical-scope.png)

Think of lexical scope as a building, going from the ground floor all the way to the top (global scope). It is a set of rules that determines where and how a variable can be accessed in your code. For example:

<Tabs id="scope" items={['Global Scope', 'Function Scope', 'Function inside a function scopeツ']} />

<Tab id='scope-0'>

```js{1,3}:scope-example.js
const teacher = 'Ilya'; // global scope

function otherClass() { // function scope
const teacher = 'Ilya';

    function ask(question) {
        console.log(teacher, question);
    }
    ask('Why?');

}
otherClass(); // Ilya Why?

ask('Why?'); // ReferenceError: ask is not defined

```

</Tab>
<Tab id='scope-1'>

```js{4,6}:scope-example.js
const teacher = 'Ilya'; // global scope

function otherClass() { // function scope
const teacher = 'Ilya';

    function ask(question) {
        console.log(teacher, question);
    }
    ask('Why?');

}
otherClass(); // Ilya Why?

ask('Why?'); // ReferenceError: ask is not defined

```

</Tab>
<Tab id='scope-2'>

```js{7}:scope-example.js
const teacher = 'Ilya'; // global scope

function otherClass() { // function scope
const teacher = 'Ilya';

    function ask(question) {
        console.log(teacher, question);
    }
    ask('Why?');

}
otherClass(); // Ilya Why?

ask('Why?'); // ReferenceError: ask is not defined

```

</Tab>

The scope of a variable is the region of your program in which you can access the variable, by its identifier, in which it is declared. In JavaScript, each function creates a new scope. Variables defined inside a function are not accessible (visible) from outside the function.
For more reference on the topic of scope, check out this [book by Kyle Simpson](https://www.oreilly.com/library/view/you-dont-know/9781449335571/). He is a fantastic author who helped me understand the topic of scopes once and for all.

> Historical bad part of JS: auto-global variables; if you try to assign a variable that's never been formally declared, JS auto-creates it in the global scope. NEVER DO IT!

> Variables are either a target position of an assignment(receiving it), or retrieving it (source position)

### Hoisting

**Hoisting** - convenience term which describes the lexical scope behaviour in which variable **declaration** is being moved up to the top of their module/function-level scope. However, only the declaration is moved, **not the assignment** of variable value.

```js
console.log(foo); // undefined
var foo = 1;
console.log(foo); // 1
```

A function declaration is being hoisted, not the function expression! When you define a function expression to a variable, the variable's declaration is hoisted, but the assignment happens at runtime

```js
// DECLARATION
console.log(foo); // Function: foo
foo(); // 'Fugazi'
function foo {
    console.log('Fugazi')
}

// EXPRESSION
console.log(foo); // undefined
foo(); // TypeError: foo is not a function
const foo = () => {
    console.log('Fugazi')
}
```

'let' and 'const' are hoisted as well, but accessing them before the declaration will give ReferenceError, you need to initialise them first.

### Closure

Closure is a function that remembers its lexical scope even when the function is executed outside that lexical scope. It is a function that has access to the parent scope, even after the parent function has closed.

It is a key 🔑 building block for JS, which makes it so functional. ( ͡° ͜ʖ ͡°)\_/¯

Closure is when a function can remember and access its lexical scope, the variables outside of itself, even when the outer function executes outside that scope.

Closure - is an inner function within a function that has access to the outer (enclosing) function's variables and parameters- via a scope chain.

Closure has three scope chains:

-   access to its own scope
-   access to enclosing function scope
-   access to global variables

To use a closure, define a function inside another function and expose it. To expose a function, return it or pass it to another function.

```js
function Counter(start) {
    const count = start;
    return {
        increment: () => {count++},

        get: () => {return count};
    }
}
const foo = Counter(4);
foo.increment();
foo.get(); // 5
```

Since it is impossible to reference or assign scopes in JS, there is no way of accessing `count` from the outside.

Closure is not capturing a value; it preserves access to variables.

#### Rules:

1. Inner function still has access to the variables in the outer function even after the outer function finished executing
2. Closures store references to the outer function variables; they do not store the actual value. Just like const a = const b [Values & References of primitive and objects](##values-and-references-of-primitive-types-and-objects)
3. Because closures have access to updated values of outer variables, it can lead to bugs using a for loop.

```js
for (var i = 0; i < 10; i++) {
    setTimeout(() => {
        console.log(i);
    }, 1000);
} // will print 10 ten times.
```

Anonymous arr Fn keeps a reference to i, at the time `console.log` is called, the `for loop` has already finished. To fix this, use an anonymous wrapper IIFE or initialise `let`:

```js
for (var i = 0; i < 10; i++) {
    ((e) => {
        setTimeout(() => {
            console.log(e);
        }, 1000);
    })(i);
}
for (let i = 0; i < 10; i++) {
    setTimeout(() => {
        console.log(i);
    }, 1000);
}
```

Anonymous Fn get called immediately with `i` and will receive a copy of `i` as its parameter `e.`

Assume that closure is a scope-based operation.

#### Use case:

Used for object data privacy, in event handlers and callback functions

> 💡 React: useEffect. It can lead to stale closure - variable falling out of sync.

> 💡 Nodejs: asynchronous non-blocking code functions

Some additional [reading on closures.](https://medium.com/javascript-scene/master-the-javascript-interview-what-is-a-closure-b2f0d2152b36)

### Modules

Modules encapsulate data and behaviour methods together. The state (data) is held (private) by its methods via closure.

JavaScript modules are a way to include and reuse code in your applications. They can help you organise your code, prevent naming conflicts, and make it more maintainable.

There are two main types of modules in JavaScript:

1. CommonJS modules are used in Node.js and designed to run on the server side. CommonJS modules use the `module.exports` and `require()` keywords to export and import code.

2. ECMAScript (ES) modules are a modern standard for JavaScript modules designed to run in the browser. ES modules use the `export` and `import` keywords to export and import code.

To create a module in JavaScript, you can define your code in a separate file and then use the `export` keyword to make the code available to other parts of your application. For example, if you have a file called `math.js` that contains a simple function to add two numbers, you can use the following code to export the function:

```js
export function add(a, b) {
    return a + b;
}
```

To use the module in another file, you can use the `import` keyword to import the code. For example:

```js
import { add } from './math';
console.log(add(1, 2)); // 3
```

Modules can also export variables, objects, and class definitions in addition to functions. You can also use the `export default` syntax to specify a default export for your module.

Using modules can help you structure your code and make it easier to manage and maintain. It's a good practice to use modules whenever possible to make your code more modular and reusable.



Understanding Scope

List of front end engineer topics that I have found interesting.

Front End Engineer Questions that you should know

We need to dig deeper, Cobb. We need more practical use cases for type assertion in typescript and react, Cobb.


## The Problem

Type assertion is a feature of typescript that allows you to override the type of a variable. It is a feature covered in books and tutorials but needs to be mastered or given good examples to shine genuinely. In this article, we will look at some of the use cases for type assertion in typescript and react.

## The Basics

TypeScript is a popular programming language that is a typed superset of JavaScript. One of the powerful features of TypeScript is its type system, which allows developers to catch type-related bugs at compile time. It can help prevent runtime errors and improve the overall reliability of your code.

One way to work with the TypeScript type system is through type assertion functions. These functions allow you to override the type of a variable and tell the TypeScript compiler that a variable has a specific type. It can be helpful when you want to use a variable in a way that is different from its inferred type.

For example, suppose you have the following code:

```ts
let foo = 'Hello, world!';
```

The type of `foo` is inferred to be a string by the TypeScript compiler. But what if you want to treat `foo` as a different type, such as a number? You can use a type assertion function to do that:

```ts
let foo = 'Hello, world!';
let bar = foo as number;
```

In the above code, we use the `as` keyword to tell the TypeScript compiler that we want to treat `foo` as a number. The compiler will allow us to use `bar` as a number in our code.

Type assertion functions do not change the type of a variable; they tell the compiler that the variable has a specific type. If you try to use the variable in a way that is not consistent with the asserted type, you will still get a compile-time error.

[If you would like to learn more about essential TypeScript Type Assertion Functions, read the official docs](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html?#type-assertions)

## Type Assertion Functions Usecases

Now with the basics out of the way, let's define the actual use case. You can assert type assertion functions to throw an error if the type does not match. The essential usefulness is that the code will only go through if the assumption is correct.

Let's use an example of a small independent vehicle dealership store that has a TS developer working tirelessly to build the best UX experience. (⌐⊙_⊙)

```ts
export type Car = {
    type: 'car';
    title: string;
    description: string;
};

export type Bike = {
    type: 'bike';
    title: string;
};

export type Tezzla = {
    type: 'tezzla';
    plug: boolean;
};

export type VehicleInStore = Car | Bike | Tezzla;

export function isCar(item: VehicleInStore): item is Car {
    return item.type === 'car';
}

export function isBike(item: VehicleInStore): item is Bike {
    return item.type === 'bike';
}

export function isTezzla(item: VehicleInStore): item is Tezzla {
    return item.type === 'tezzla';
}

export function assertCar(item: VehicleInStore): asserts item is Car {
    if (!isCar(item)) {
        throw new Error('Item is not a car, try Tezzla');
    }
}

export function assertBike(item: VehicleInStore): asserts item is Bike {
    if (!isBike(item)) {
        throw new Error('Item is not a bike');
    }
}

export function assertTezzla(item: VehicleInStore): asserts item is Tezzla {
    if (!isTezzla(item)) {
        throw new Error('Item is not a tezzla, try petrol');
    }
}
```

```ts
type Props = {
    item: VehicleInStore;
};

export default function StoreComponent({ item }) {
    switch (item.type) {
        case 'car':
            assertCar(item);
            return <CarComponent car={item as Car} />;
        case 'bike':
            assertBike(item);
            return <BikeComponent bike={item as Bike} />;
        case 'electric':
            assertTezzla(item);
            return <TezzlaComponent tezzla={item as Tezzla} />;
    }
    return null;
};
```

### Exhaustive Bonus

We can expand on this example even further by checking that every case is provided. Sometimes it is easy to forget to add a case to a switch statement when new `types` of product appear. 🍄 This can lead to bugs in your code. To prevent this, you can use the `never` type to tell the TypeScript compiler that a switch statement is exhaustive.

The aim is to make sure that the compiler will throw an error if the default case is called. This will ensure that you have handled every possible case in your switch statement.

```ts{48-51}
export type Car = {
    type: 'car';
    title: string;
    description: string;
};

export type Bike = {
    type: 'bike';
    title: string;
};

export type Tezzla = {
    type: 'tezzla';
    plug: boolean;
};

export type VehicleInStore = Car | Bike | Tezzla;

export function isCar(item: VehicleInStore): item is Car {
    return item.type === 'car';
}

export function isBike(item: VehicleInStore): item is Bike {
    return item.type === 'bike';
}

export function isTezzla(item: VehicleInStore): item is Tezzla {
    return item.type === 'tezzla';
}

export function assertCar(item: VehicleInStore): asserts item is Car {
    if (!isCar(item)) {
        throw new Error('Item is not a car, try Tezzla');
    }
}

export function assertBike(item: VehicleInStore): asserts item is Bike {
    if (!isBike(item)) {
        throw new Error('Item is not a bike');
    }
}

export function assertTezzla(item: VehicleInStore): asserts item is Tezzla {
    if (!isTezzla(item)) {
        throw new Error('Item is not a tezzla, try petrol');
    }
}
export function assertNever(value: never): never {
    throw new Error(`Unhandled discriminated union member: ${JSON.stringify(value, null, 2)}`);
}
```

```ts{16-17}:StoreComponent.tsx
type Props = {
    item: VehicleInStore;
};

export default function StoreComponent({ item }) {
    switch (item.type) {
        case 'car':
            assertCar(item);
            return <CarComponent car={item as Car} />;
        case 'bike':
            assertBike(item);
            return <BikeComponent bike={item as Bike} />;
        case 'tezzla':
            assertTezzla(item);
            return <TezzlaComponent tezzla={item as Tezzla} />;
        default:
            assertNever(item);
    }
    return null;
};
```

In summary, type assertion functions are a powerful tool for working with the TypeScript type system. They can help you catch type-related bugs at compile time and make your code more type-safe. By using type assertion functions, you can improve the reliability and maintainability of your TypeScript code. That's it, folks (҂◡_◡) ᕤ


Type Assertion Typescript

Remember... the CSS will be with you, always.


## The Problem

Do you know what really grinds my gears? Forgetting basic flexbox CSS, that's what. For this reason, I have created a `CSS cheat sheet` for myself and anyone else who might find it useful. The goal is two-fold.

1. to have a single page that I can reference when I forget how to do something in CSS. I'm sure I'm not the only one with this problem, so I'm sharing it with you.

2. To remember this visually. I'm a visual learner, so this is my beautifier approach to CSS that made it stick.

## Entree

### CSS Specificity

1. inline-style
2. `#`id selector
3. `.`class selector
4. element selector (e.g. `p`, `div`, `h1`)

[Read more on CSS Specificity](https://css-tricks.com/specifics-on-css-specificity/)

### Order of shorthand values for Padding and Margin

1. top
2. right
3. bottom
4. left

![padding and margin](/blog/clock.webp)

> Smaller elements look best with more considerable padding on the x and less on the y-axis.

To prove this point, let's look at how to create a rounded button in CSS with 3d css text.

<Codesandbox id="7565nx" />

As you can see from the example above, first 3d css text button looks more elegant.

### CSS relational values

**Em Values** default to 16px, calculate target value/default value of the parent. Em values change regarding font size.

**Rem Values** (root em) is taking values in relation to root value

```CSS
:root {
    font-size: 1em;
}
```

> Rule of thumb: use `rem` for font-size, `em` for padding & margin, pixels for borders and `%` for width & height of containers.

Function calc helps combine relational values of different types.

```CSS
:root {
font-size: calc(0.5em + 1vw);
}

```

### Image object-fit

Oh, the amount of times I've had to google this. `object-fit` is a CSS property that allows you to control how an image fits into its container. It's a great way to ensure your images are responsive and look good on all screen sizes.

```CSS
img {
    object-fit: fill; /* default */
    object-fit: cover; /* expands image to fit the block, think Album Cover */
    object-fit: contain; /* expand to the elements with respect to its size */
}
```

> Text has higher padding than the element itself. To fix this: multiply by 1.4, i.e. `6px` on top and bottom.

## Flexbox CSS Cheat Sheet

I love this flexbox cheat sheet! It provides an intuitive layout of flexible components.
Its main strength and ease of use is `one-dimensional` positioning. Think of your div container as a giant graffiti wall. You can paint your graffiti anywhere, but only on the `X` (starting from the left) or `Y` (starting from the top) axis.

![flexbox graffity](/blog/css-flex-graffity.png)

### Steps to create a flexbox:

1. `display: flex;` on the parent container
2. If required, define `flex-direction` (default is `row` or `X axis`)
3. If required, define margin (outer) or padding (inner) or flex value

### Flexbox Cheat Sheet

-   `flex-direction`: **row** ⬌ , column ⬍
-   `flex-wrap`: **nowrap**, wrap, wrap-reverse. // Defines whether the elements in the container will be moved to a new row (column, depending on flex-direction)
-   `justify-content`: **flex-start**, flex-end, center, space-between, space-around. How elements are positioned along the main axis
-   `align-items`: **stretch**, flex-start, flex-end, center, baseline. How elements are positioned along the opposite axis.
-   `align-content`: flex-start, flex-end, center, stretch, space-between, space-around. If flex-wrap is active, it assigns the padding of rows along the opposite axis.

**Flex elements properties:**

-   `flex-grow`: single number, a factor of growth of an element
-   `flex-shrink`: single number, a factor of deduction of an element
-   `flex-basis`: length or %, defines the initial size of an element
-   `align-self`: **auto**, flex-start, flex-end, center, stretch, baseline. Defines adjustment of the element along the opposite axis.

## Grid Cheat Sheet

Grid lunch - what a delight! Though a bit harder to grasp, CSS Grid is excellent for two-dimensional layouts (both: `x ⬌` and `y ⬍` ). You set elements in predefined areas inside the grid.
Each element in the grid should be a child-to-grid container.

**Basic setup:**

```CSS
display: grid
grid-template-columns: 1fr 1fr 1fr /* 3 cols of same width */
grid-template-rows: 1fr 1fr /* 2 rows of same height */
grid-gap: 0.5em 1em

```

#### 4 essential terms:

-   Grid Line: forms the structure of the grid. grid-gap goes above the grid line
-   Grid Track: distance b-n two Grid Lines. Has vertical and horizontal tracks
-   Grid Cell: unit in a grid, i.e. table cell
-   Grid Area: area of a few table cells

> To position elements in the grid, you can use the alternative syntax: grid lines or grid areas. I like grid areas more, but it depends on the task.

<Tabs id="grid" items={['Grids Lines', 'Grids Areas']} />

<Tab id='grid-0'>

```css
.container {
  grid-template-columns: [left-start] 2fr
               [left-end right-start] 1fr
               [right-end] /*defined and named 3 grid lines */
  grid-template-rows: repeat(4, [row] auto)
}
.main {
  grid-column: left /*takes space from left-start to left-end */
  grid-row: row 3 / span 2 /*places the element after 3rd row and takes 2 rows */
}
```

</Tab>

<Tab  id='grid-1'>

```css
.container {
  grid-template-areas: 'title title'
             'nav nav'
             'main aside1'
             'main aside2'/* aligning each grid cell with named grid areas */
  grid-template-columns: 2fr 1fr;
  grid-template-rows: repeat(4, auto)
}
.sidebar-top {
  grid-area: aside1;
}

/* to initialise empty grid cell in grid area: */
grid-template-areas: 'top top right
           'left . right'
           'left bottom bottom'
```

</Tab>

## Additional CSS cheat sheets

For dessert, I'm presenting [tailwind CSS](https://tailwindcss.com/). Once you know this cheatsheet by heart but still forget some stuff like I sometimes do, you will love tailwind. A day of learning curve will immensely speed up development time.

If you want to improve your knowledge of CSS further, I highly recommend looking at [CSS Secrets by Lea Verou](https://www.oreilly.com/library/view/css-secrets/9781449372736/). It's a fantastic book on CSS for both novices and veterans alike.

In conclusion: here are a bunch of links and tips:

-   CSS basic styling for a page

```CSS
:root {
box-sizing: border-box;
--gray-100: #f3f4f6;
--gray-200: #e5e7eb;
--gray-300: #d1d5db;
--gray-400: #9ca3af;
--gray-500: #6b7280;
--gray-600: #4b5563;
--gray-700: #374151;
--gray-800: #1f2937;
--gray-900: #111827;
/* Google tailwind colours for setting your colour variables */
}

\*,
::before,
::after {
box-sizing: inherit;
}

body {
background-color: var(--gray-300)
font-family: Roboto sans-serif;
line-height: 1.4em /* up to 1.6em; */
letter-spacing: 0.01em;
}

h1, h2, h3, h4 {
font-family: Kurale, serif;
letter-spacing: 0.03em;
}

body * + * {
margin-top: 1.5em;
/* This one is called lobotomic owl, which aims for any element that goes after another. So all elements do not equal the first daughter element of the parent. You can read about it in the link at the of the article */
}

.container {
max-width: 1080px;
margin: 0 auto;
}

```

-   [Read more on lobotomic owl](https://alistapart.com/article/axiomatic-css-and-lobotomized-owls/)
-   [SVG Helper](https://jakearchibald.github.io/svgomg/)
-   [Tool for CSS accessibility](https://github.com/postcss/autoprefixer)

## Grid Interactive Exercise

After a decent meal, I challenge you to create a grid and utilise some tricks here. Set a timer and implement a solution like in the final screen. Feel free to peek at the final solution after the time runs out. If you find this article helpful, you can press print and save this css cheatsheet as pdf download.

Your playground

<Codesandbox id="wi4c5z" />

Final Result

<Codesandbox id="rvsgqb" />


Interactive: CSS Cheat Sheet

How I stopped worrying and made typescript even stricter


Hello my dear friend! Hope you are doing well in those turbulent times. I am writing this post to share my experience with building enterprise React Typescript projects and how to manage them gracefully.

## The problem

Typescript has a miryad of settings in `tsconfig.json`, and apart from the most obvious that you should always do ("strict": true), take a look at the list of the most interesting ones:

```json
"allowUnreachableCode": true,
"allowUnusedLabels": true,
"exactOptionalPropertyTypes": true,
"noFallthroughCasesInSwitch": true,
"noImplicitOverride": true,
"noImplicitReturns": true,
"noPropertyAccessFromIndexSignature": true,
"noUncheckedIndexedAccess": true,
"noUnusedLocals": true,
"noUnusedParameters": true
```

I have found `noUncheckedIndexedAccess` to be particularly effective, because by default every index from an array is seen as the array element type. Even if it exceeds the items available and will result in `undefined`

Enabling “noUncheckedIndexedAccess” requires you to check the
element before using it.

For example, assume there is a black magic website that sells gifts on holidays:

```ts
export type ExtraGift = {
  name: string;
  price: number;
};

export const getExtraGift = (name: string): ExtraGift => {
	const extraGift = extraGifts[name] ?? [name, price: 0];
	return extraGift;
}
```

## The Solution

Anyhow, this is what I would consider a "decent" `tsconfig` starter to get "production-ready" React Typescript project around, and if you want, you can play with some extra settings from the list at the top

```json
// tsconfig.json
{
  "compilerOptions": {
    "target": "es5",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "forceConsistentCasingInFileNames": true,
    "noFallthroughCasesInSwitch": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "jsx": "react-jsx"
  },
  "include": ["src"],
  "exclude": ["node_modules"],
  "extends": "./tsconfig.paths.json"
}

// tsconfig.paths.json
{
	"compilerOptions": {
		"baseUrl": ".",
		"paths": {
			"@/*": ["src/*"]
		}
	}
}
```


How to make Typescript tsconfig strict

The problem

The Solution

What is the number one lesson you have learned from this article?

Recent publications