
**Zod** is the TypeScript-first schema validation library with static type inference. It's functional approach to data validation is [parse-dont-validate-in-typescript]() which parses the data in order to validate and catch errors.

## Why use Zod?

- **TypeScript support:** Zod has TypeScript support, which lets developers to detect type issues early on, making it easier to discover and repair bugs.
- **Improved data quality:** Developers may guarantee that the data they are working with is in the right format and fulfills particular restrictions by utilizing Zod to validate and coerce input data. This can assist to reduce mistakes and enhance data quality overall.
- **Simplified code:** Developers may easily design and maintain validation code because to Zod's clear and simple syntax for constructing schemas. This can assist to decrease the amount of boilerplate code required and make it easier to reason about the data flowing through an application.
- **Flexibility:** Zod may be used in a number of situations, including online forms, REST APIs, and others. It also allows developers to construct custom validation methods, allowing them to validate data using their own business logic.
- **Lightweight:** Zod is a lightweight library with no external dependencies.
- **Cross-platform:** Zod works in both browser and Node.js, allowing it to be utilized in a wide range of applications and environments.

## How to use Zod

### Example using validate method

```ts
const z = require("zod");

// Define a schema for the input data
const schema = z.object({
  name: z.string(),
  phone_number: z.number().min(0).max(12),
  email: z.string().email(),
});

// Input data to be validated and coerced
const input = {
  name: "Dwarves Foundation",
  phone_number: 123456,
  email: "team@dwarves.foundation",
};

// Validate and coerce the input data
const data = schema.validate(input);
console.log(data);
/*
{
  name: 'Dwarves Foundation',
  phone_number: 123456,
  email: 'team@dwarves.foundation',
}
*/
```

In this example, we define a schema using the Zod library that specifies the types and constraints for the input data. The `schema.validate(input)` function is used to validate and coerce the input data to match the schema. If the input data is valid and meets all the constraints defined in the schema, it will be returned in a proper format, otherwise it will throw an error with the validation issues.

In this case, the input data is an object that has a name, phone number, and email address. According to the standard, the name and email should be strings, and the phone number should be a number between 0 and 12.

It also ensure that the email is valid email.

This way the application can be sure that the data it is receiving is in the correct format, and that any issues with the data will be caught early on.

### Example using parse method

The `parse()` method in the Zod validation library is used to parse and validate input data, and return the parsed data in the correct format. It is similar to the `validate()` method, but it also removes any extra properties from the input data that are not defined in the schema.

```ts
const z = require('zod');

// Define a schema for the input data
const schema = z.object({
  name: z.string(),
  phone_number: z.number().min(0).max(12),
  email: z.string().email(),
});

// Input data to be parsed and validated
const input = {
  name: 'Dwarves Foundation',
  phone_number: 123456
  email: 'team@dwarves.foundation',
  extra_property: 'This should not be included in the output'
};

// Parse and validate the input data
const data = schema.parse(input);
console.log(data);
/*
{
  name: 'Dwarves Foundation',
  phone_number: 123456,
  email: 'team@dwarves.foundation',
}
*/
```

In this example, the input data contains an extra property `extra_property` which is not defined in the schema, it will be removed from the parsed data, resulting in a cleaner object without any unnecessary properties.

`parse()` method is useful when the input data may contain extra properties that are not needed by the application. It also ensures that the input data matches the schema and that any issues with the data will be caught early on.

It's also worth mentioning that, like `validate()`, if the incoming data does not match the schema, `parse()` will throw an exception indicating the validity issues.

## Zod vs Yup

**Zod** and **Yup** are both JavaScript libraries for data validation, but they have some key differences:

- Syntax: Zod and Yup have different syntax for defining schemas. Zod uses a fluent interface with a chainable API, while Yup uses a plain object to define the schema.
- TypeScript support: Zod is built with TypeScript, which means it has excellent typings, making it easy to use in a TypeScript environment. Yup does not have built-in TypeScript support, but it can be used in a TypeScript environment with the use of an additional package.
- Error message: Yup allows to specify custom error messages for each field, which can be useful for displaying error messages to the end-user. Zod, on the other hand, does not provide a way to specify custom error messages.
- Utility functions: Zod provides a number of utility functions such as the ability to extract values from an object based on a schema, and to create an object with default values based on a schema. Yup does not have similar utility functions.
- Performance: Zod is smaller in size and it's faster than Yup, which means it could be a better choice for applications that need to handle a large amount of data validation.
- Popularity: Yup is more popular than Zod because it's been around longer and has a larger community of developers.

Both Zod and Yup are robust validation libraries, and the choice between them is based on your project's specific demands, syntax preference, and the capabilities that you require.

## References

- <https://zod.dev/>
- <https://github.com/jquense/yup>
- <https://blog.logrocket.com/comparing-schema-validation-libraries-zod-vs-yup/>
- <https://blog.logrocket.com/schema-validation-typescript-zod/>


Zod is the TypeScript-first schema validation library with static type inference.

Validation with Zod


**What happens if you invoked the component function directly in React?:
Let's take a look at this example:**

```javascript
const ExampleComponent = () => {
  const [input, setInput] = useState("");
  //do something here
};

export const App = () => {
  const [show, setShow] = useState(false);
  return (
    <div>
      <button onClick={() => setShow(!show)} />
      {show && ExampleComponent()}
    </div>
  );
};
//This will trigger error "Render more hooks than during the previous render"
//Solution: use <ExampleComponent /> instead
```

**So why does this happen?**

- By doing so, you are essentially integrating ExampleComponent and App into a super component and treating ExampleComponent as a custom hook that is executed immediately before the return statement, which means that whenever some states in ExampleComponent change, the entire App re-renders.

- The first time the App renders, the show state is false therefore the ExampleComponent doesn't render and only use 1 hook.

- When we click the button, the show state is true which makes the ExampleComponent render and trigger the second hook in the ExampleComponent which violates [React rule of hooks](https://reactjs.org/docs/hooks-rules.html).

**How to avoid it?**

- Use React Component Syntax <ExampleComponent /> which translate into React.createElement(ExampleComponent, null) making the properties of that component in the VDOM tree controlled by the ExampleComponent.


What happens if you invoked the component function directly in React?

Invoking component functions in React


The _**"parse, don't validate"**_ approach is all about processing incoming data and failing in a controlled manner if parsing fails. It is all about leveraging trustworthy, secure, and typed data structures within your code and ensuring that all incoming data is handled at the very edges of your systems. Instead of passing receiving data deep into your code, parse it immediately and fail quickly if necessary.

Parsing is better than validation because it requires you to explicitly handle every incoming data. It provides a type-safe method of working and makes it difficult to spread harmful material throughout your apps and data storage. However, it is true that parsing frequently incorporates data validation.

## Overview

### What is parsing?

- **Parsing** is the process of analyzing a string or symbol either in natural language, computer languages or data structures, conforming to the rules of a formal grammar.
- The **"_process of analyzing_"** and **"_conforming to the rules of a_ [_thingy_]"** are crucial here. _Thingy_ is our schema and type, which in this instance may be thought of as forming our _formal grammar_ (don't worry if you don't know what it means). _Process of analyzing_ is the work our code does when trying to fit data to the schema & type. The reason why we are saying “schema & type” is that we want them somehow to be the same thing, instead of two separate things that may or may not be in sync.

### Examples in TypeScript with yup

#### Example

```ts
import * as yup from "yup";

let schema = yup.object().shape({
  name: yup.string().required(),
  age: yup.number().required().positive().integer(),
  email: yup.string().email(),
});
// data from an API, from user, etc. Note that the type would be `any`
// (or perhaps `unkown`) as we don't really know what it looks like
// if it comes from outside
const data: any = {
  name: "jimmy",
  age: 24,
};
// check validity
schema.isValid(data).then(function (valid) {
  console.log("isValid?", valid); // => true
  // do something with the data, however, it's still `any`/`unkown`....
});
```

We still don't have a _type_ for our 'data,' as you can see. It remains 'any/unknown'. Sure, we can typecast it, but it introduces a problem: we now have to maintain a'schema' and a 'type' separately, by hand, with nothing ensuring they match.

#### Example with Typecast

```ts
let userSchema = yup.object().shape({
  name: yup.string().required(),
  age: yup.number().required().positive().integer(),
  email: yup.string().email(),
});

type UserType = {
  name: string;
  age: number;
  email: string;
};
// check validity
schema.isValid(data).then(function (valid) {
  const user = data as UserType; // it's valid so let's cast!
});
```

Still, how can you ensure that 'userSchema' and 'UserType' are in sync? Do they even stand for the same thing?

#### Example with parsing function

```ts
// Let's use some custom type aliases for readability
type PositiveInteger = number;
type Email = string;
type URL = string;
// Type guards to validate invidiual values, fields
const isPositiveInteger = (x: any): x is PositiveInteger =>
  yup.number().required().positive().integer().isType(x);
const isEmail = (x: any): x is Email =>
  yup.string().required().email().isType(x);
const isString = (x: any): x is string => yup.string().required().isType(x);
// UserType again, now with our custom type aliases
type UserType = {
  name: string;
  age: PositiveInteger;
  email?: Email;
};
/**
parse, don't validate
compiler can help us quite a bit here to make sure the parsing
is actually correct
*/
const parseToUserType = (x: any): UserType | Error => {
  let { name, age, email, website, createdOn } = x;
  if (!isString(name)) return new Error("invalid name");
  if (!isPositiveInteger(age)) return new Error("invalid age");
  email = isEmail(email) ? email : undefined; // optional, silently drop invalid values
  return { age, name, createdOn, email, website };
};
// Business logic is pretty awesome now!
function myHandler(): Response {
  const userType: UserType | Error = parseToUserType(data);

  if (userType instanceof Error) return { error: "Ohh there was a 400 error" };
  // use UserType normally, do what ever you want
  return { message: `Welcome, ${userType.name}` };
}
```

- Business logic can now parse any data to `UserType`. \_Just remember to check whether there’s an Error or not.
- We are using more precise types than `string` or `number`\_ due to how type aliases work.
- The error-prone, dangerous, not-that-well-type-checked code is limited to type guards.
- TS compiler makes sure our parser actually works. _We can safely write our_`_(x: any) => UserType | Error` parser function with good support from the type checker.

### Reference

https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://en.wikipedia.org/wiki/Parsing https://itnext.io/parse-dont-validate-incoming-data-in-typescript-d6d5bfb092c8


The "parse, don't validate" approach is about processing incoming data and failing in a controlled manner if parsing fails.

Parse, don't validate in TypeScript


Before ES modules was supported in the browser, we have no native mechanism for authoring JavaScript modules in a modularized fashion. That is why the concept of **"bundling"** and tools like Webpack, Rollup, and Parcel exist to improve the development experience for frontend developers.

However, when our project started to expand more, the amount of modules might increase from a hundred to thousands of modules which lead to performance bottleneck for **JavaScript-based** toolings.

### Why Vite faster

Vite takes full advantage of the availability of native ES modules in the browser and the rise of JavaScript tools written in compile-to-native languages by introducing `pre-bundles dependancies` using `esbuild` which was written in Go which is 10-100x faster than JavaScript-based bundlers.

### Server built architecture

#### Bundle based dev server

Bundle-based dev server like Webpack built your application by combining all the source-code and modules into a JavaScript-based bundle, everything is done on the server-side and when you change something, the entire application has to build from the start.

#### Native ESM based dev server

Vite's approach was instead of bundling all everything on the server, it only bundles modules when the browser requires them through HTTP request.

This architecture provides a faster dev server by avoiding bundling all the application on the server and utilizing the power of modules handling of the browsers.

### Update when built

Rebuilding the whole bundle after making changes to your source code in a bundler-based build system is inefficient for the obvious reason that the update speed would degrade linearly with the app's size.

**HMR (Hot module replacement)** is applied to native ESM in Vite. Vite consistently performs HMR updates quickly regardless of the size of your application by only needing to precisely invalidate the chain between the updated module and its nearest HMR boundary when a file is changed.

### Why bundle for production

Despite the fact that native ESM is now generally supported, deploying unbundled ESM in production is still wasteful (even with HTTP/2) since nested imports require extra network round trips. It is still preferable to bundle your code with tree-shaking, lazy-loading, and common chunk splitting to get the best loading performance in production (for better caching).

### Why not bundle with ESBuild?

While `esbuild` is lightning-quick and a very capable bundler for libraries, some crucial features required for bundling apps, specifically code-splitting and CSS handling, are still **under development**. `Rollup` is currently more capable and adaptable in several areas and being used in production.

### References

- https://vitejs.dev/guide/why.html
- https://www.telerik.com/blogs/whats-vite-guide-modern-super-fast-project-tooling


ViteJS takes full advantage of the availability of native ES modules in the browser and the rise of JavaScript tools written in compile-to-native languages by introducing pre-bundles dependancies using esbuild.

ViteJS native modules

**Modules** have always been a part of JavaScript development and providing mechanisms for splitting JavaScript programs up into separate modules that can be imported when needed was the absolutely necessity for JavaScript developers.

> "Modules are like building blocks that we can create software by combining."

### So what is a module?

A module is just simply a file that exports its own code.

### Why do we need it?

- Modules gives our code **structure** and **boundaries**. One's code will be hard to organize and maintain if they don't use modules and no one wants all the codes mingling with each others.
- Modules also allow developers share code to the world through a package manager like NPM.

## History of JavaScript's modules

In order to understand about the development of JavaScipt's modules, we need to walk through 4 stages: Vanilla, IIFEs, CommonJS and ESM.

### Vanilla (1990s - early 2000s)

When JavaScript was first invented by Brendan Eich in 1995, it was known to have been created in 10 days and the creator himself doesn't think that his programing language would be as popular as today.

> “No one thought JavaScript would be used at the wide scale it is. Not just reaching lots of people on the Web, but large application like Gmail… To write large code, you don’t just want this little snippet language that I made for beginners…“ Bredan Eich (Creator of JavaScript)

So modules aren't a thing back then, developers would mostly used inline-scripting and script-tags and no one would think of scalability, maintaining a large code base would be a nightmare because there is no structures and organizations.

#### YAHOO manifesto

Around 2006, a global manifesto was raised by a team of UI developers from YAHOO which was **"Global Variable are dangerous"**. The point they trying to make is that using global variable is a risky practice and all the people back then are engaging in. Global variables can spark conflict between naming if there are many people involving in developing the same program and since everyone can access it, it is not very secure.

#### YAHOO Solution?

Create a huge Global namespace object and parse all the variables in that object.

> **Example**: YAHOO.value.getValue

### IIFEs (early to late 2000s)

IFFEs or Immediately invoked function expression was used with closures to keep the private data hidden, basically the ideal is that you only need to care of what the function returns and not what happen inside it.

#### Example

```js
var Dialogue = function () {
  //private variables
  var dialogue;
  //exposed functions
  return {
    hello: function () {
      dialog = "Hello Dwarves!";
      console.log(dialogue);
    },
    goodbye: function () {
      dialog = "Goodbye Dwarves!";
      console.log(dialogue);
    },
  };
};
```

At this stage we have solve the Global namespace pollution problem but we haven't got to the point that we can swapping modules with one another and copy/paste function happens all the time.

### CommonJS (early to mid 2010)

Around 2009, people are hype about the potential of JavaScript, you can now run JavaScript on the server-side. And come with that a proposal was made for JavaScript to have a standard way to include other modules. Node created a module implementations name CommonJS.

#### Implementation of CommonJS:

- **Import**: using `require()` method.
- **Export**: **module** object using `module.exports`.

This was design for server development.

#### Synchronus modules loading

- **MODULE.\_LOAD**: Node caches it's modules (Node check for cache files, if it not there it will create an instance and caches it).
- **MODULE.\_COMPILE**: Create a `require` function that speciffic for each modules and generate a wrapper function to scope variables the run the wrapper function.

#### Node module wrapper function

```js
(function (exports, require, module, __filename, __dirname) {
  // Module code actually lives in here
});
```

#### Example

```js
//dialogue.js
var getDialog (function (){
    console.log("Hello Dwarves!");
})
module.exports = getDialogue;
```

```js
//main.js
const sayHello = require("./dialogue.js");
```

At this time, CommonJs is a real noviation, organizing files and maintaining code has become much easier.

### ESM (2010s - present)

ESM or ES modules was supported by all major browsers and was the first **built-in module** in JavaScript and introduce top-level `await` functionality for module imports.

#### Top-level await

A feature accessible within modules is top level await. This implies that the await keyword is functional. It enables modules to function as sizable asynchronous functions, allowing code to be assessed before usage in parent modules without preventing the loading of siblings.

#### ESM Asynchronus ?

The loading and parsing for ESM modules is indeed asynchronous, but the execution of the code in them is synchronous and serialized based on the order they are imported.

#### Implementation ESM:

- **Import**: using `import` method.
- **Export**: using `export` method.

#### Example

```js
//Export syntax

//dialog.js
export default const dialog = "Hello Dwarves!";

//utils.js
export const getHours = () => //do something;
export const getMinutes = () => //do something;
```

```js
//Import syntax

import dialog from "./dialog.js";

import * as utility from "./utils.js";
import { getHours, getMinutes } from "./utils.js";
```

#### ESM in the browsers

ESM has a specfic module type in the browser which they are processed differently and create a fallback for older browsers using bundle.

```html

<script type="module" src="main.js"></script>

<script nomodule src="bundle.js"></script>
```

### CommonJS vs ESM

- Right now ESM was supported on all browsers and the latest version of Node except version below version 12.
- ESM waits to execute any code in a module until all of it's imports have been loaded and parsed, then does the binding/side-effects stuff in the relative order that they happen.
- ESM imports are asynchronous (which also allows for top-level `await`).
- CJS executes imports as it finds them, blocking until they finish.
- CJS works in Node but does **not** work in browsers.

### Conclusion

Although CommonJS can still be used for server development since synchronous wasn't an issue and it was built by Node, using ESM is still the better way to keep the syntax consistent if you were to develop client-side and server-side with JavaScript.

#### Reference

- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules
- https://dev.to/adamcoster/commonjs-and-esm-importexport-compatibility-by-simple-example-50pl
- https://www.w3schools.com/js/js_modules.asp
- https://nodejs.org/api/modules.html
- https://www.infoworld.com/article/2653798/javascript-creator-ponders-past--future.html

Modules have always been a part of JavaScript development and providing mechanisms for splitting JavaScript programs up into separate modules that can be imported when needed was the absolutely necessity for JavaScript developers.

JavaScript modules


## Atomic design pattern

Atomic design is a methodology for crafting design systems with five key fundamental building blocks, which, when combined, promote consistency, modularity, and scalability.

### Why use atomic design

- Atomic design provides frontend engineers with flexible and consistent designs from the beginning.
- We can move from the abstract to the concrete thanks to Atomic design. As a result, we can design systems that encourage consistency and scalability while also displaying information in its final context. Additionally, by putting a system together rather than taking it apart, we avoid picking out the best patterns later.
- The method fits incredibly well with component-based architectures like React, Vue,...

## How does it work?

There are 5 distinct levels of atomic design which are: atoms, molecules, organisms, templates, and pages.

![](assets/atomic-design-pattern_atom-design-structure.webp)

### Atoms

- Atoms are the basic building blocks of matter. When applied to web interfaces, they are our `HTML` tags like an `input` or a `button`.
- These are fairly abstract elements which are often not useful on their own but are good references in the context of a pattern if seen on a bigger picture.

![](assets/atomic-design-pattern_atom-atomic-design.webp)

**Molecules**

Just like in chemistry, molecules are a set of atoms combined. This could include a form input with a title and input standing next to each other or a header containing multiple atoms like icons, buttons, or inputs.

![](assets/atomic-design-pattern_molecule-atomic-design.webp)

### Organisms

Molecules give us some functional building blocks to work with, and they are a sub-set of organisms. Molecules when joined together create organisms which is a relatively complex and distinct section of an interface.

![](assets/atomic-design-pattern_organisms-atomic-design.webp)

### Templates

Templates consist mostly of groups of organisms to form pages, keep in mind that these template doesn't contain data and only contain props.

Templates begin their life as HTML wireframes, but over time become the final deliverable.

t this stage we can really see the design coming together and making more sense for the clients to see the layout of the interface before finalizing it.

![](assets/atomic-design-pattern_template-atomic-design.webp)

### Pages

Pages are specific instances of templates. Here, placeholder content is replaced with real representative content to give an accurate depiction of what a user will ultimately see.

![](assets/atomic-design-pattern_page-atomic-design.webp)

### Atomic design folder structure

This is an example of an application folder structure using atomic design, as you can see there are 5 distinct layers and you can organize them in anyway you want following your own preference.

![](assets/atomic-design-pattern_folder-structure-atomic-design.webp)

## Reference

- https://bradfrost.com/blog/post/atomic-web-design/#atoms
- https://andela.com/insights/structuring-your-react-application-atomic-design-principles/
- https://blog.ippon.tech/atomic-design-in-practice/


Atomic design is a methodology for crafting design systems with five key fundamental building blocks, which, when combined, promote consistency, modularity, and scalability.

Atomic design pattern


In the React 18 version, the `useEffect` hook has been updated to called twice compare to only one in the older version in StrictMode.

### What are the changes and why?

- Beginning with React 18, when in development mode, the components will be mounted, unmounted, and then mounted once again in StrictMode.
- In the future, React would support a functionality that allows React to add and remove sections of the UI while maintaining state in the future. For example, when a user back history from a screen and then revisit it, React should be able to show the previous screen right away. React would do this by un-mounting and re-mounting trees with the same component state as before.
- This functionality will improve the performance of React projects out of the box, but necessitate components to be resilient to effects being mounted and un-mounted several times. The majority of effects will operate as-is, however some will presume they are only mounted or destroyed once (which means the new behavior might cause trouble for the existing use of useEffect that intends to trigger mount and unmount once).
- React 18 adds a new development-only check in StrictMode to identify these issues. After a component mounts for the first time, this new check will immediately unmount and remount it, restoring the previous state on the second mount.

### What are the differences?

- In React 17 the useEffect hook gets call every time the component is mounted.
- In React 18 each component is mounted, then unmounted, and then remounted and an useEffect call with no dependencies will be run double-time in strict mode.

### Example of useEffect in React 18

We can confirm the behavior by using the cleanup function of the useEffect hook.

```js
useEffect(() => {
  console.log("Hello Dwarves!");
  return () => console.log("Cleanup..");
}, []);
```

The output to the console should look like this:

```sh
Hello Dwarves!
Cleanup..
Hello Dwarves!
```

**Solution**

Embrace the double-firing and make sure your clean up function works (so double-firing in development doesn't hurt).

**Get around (not recomended)**

You can create a custom hook so that the useEffect get called only once, although this approach can cause leaks and overall not the best practice in engineering.

```ts
export const useEffectOnce = (effect: () => void | (() => void)) => {
  const destroyFunc = useRef<void | (() => void)>();
  const effectCalled = useRef(false);
  const renderAfterCalled = useRef(false);
  const [val, setVal] = useState<number>(0);

  if (effectCalled.current) {
    renderAfterCalled.current = true;
  }

  useEffect(() => {
    // only execute the effect first time around
    if (!effectCalled.current) {
      destroyFunc.current = effect();
      effectCalled.current = true;
    }

    // this forces one render after the effect is run
    setVal((val) => val + 1);

    return () => {
      // if the comp didn't render since the useEffect was called,
      // we know it's the dummy React cycle
      if (!renderAfterCalled.current) {
        return;
      }
      if (destroyFunc.current) {
        destroyFunc.current();
      }
    };
  }, []);
};
```

#### Reference

- https://reactjs.org/blog/2022/03/29/react-v18.html#new-strict-mode-behaviors
- https://www.techiediaries.com/react-18-useeffect/
- https://dev.to/ag-grid/react-18-avoiding-use-effect-getting-called-twice-4i9e


In the React 18 version, the `useEffect` hook has been updated to called twice compare to only one in the older version in StrictMode.