
The React `useReducer` hook is an alternative to the `useState` hook. The `useReducer` hook is preferable over the `useState` hook when dealing with more complex component state logic. Using the `useReducer` hook is similar to using reducers in *Redux*.

## useReducer versus useState

Using the `useState` hook to manage more complex state can result in a significant amount of code directly in your component body. An example of this is using `useState` to manage a list of items that needs to support the addition, modification, and deletion of items.

This complex state management logic should be managed separately from the component, who's main concern should only be to display the list of items. Mixing complex state management logic with presentation logic in the same component can make that component harder to test and to maintain over time.

The `useReducer` hook helps us to bring a greater separation of concerns to our component. It does this by allowing us to extract the state management logic outside of our component.

## useReducer

```javascript
const [state, dispatch] = useReducer(reducer, initialState);
```

The `useReducer` hook takes two arguments: 

- **A reducer**: a pure function that updates the state in an immutable way and returns the new state.
- **An initial state**: the value that the state is initialized with.

The `useReducer` hook then returns an array of two elements: 

- **The current state**
- **A dispatch function**: a special function that dispatches an action object.

## What is an action object?

An action object is an object that is used to describe how the state should be updated.

An action object usually has a *property type*, which is a string that identifies what kind of operation the reducer must perform.

To create an action object to increment a counter in the state, we can do the following:

```javascript
const action = {
  type: 'increment'
};
```

To create an action object to add a new item in a list, we can use the following action object:

```javascript
const action = {
  type: 'add',
  payload: {
    name: 'Mario',
  },
};
```

In this case, we needed to pass an additional property into our action object so that we can add a new item with a specific name to our list. This additional property that is passed into an action object is often referred to as a *payload*. We named the property `payload` in this example, but it could have been called anything else, as long as it's a valid JavaScript object property name. 

When we want to update the state, we call `dispatch(actionObject)` with the right action object. The action object will get forwarded to the *reducer* function which will update the state.

## What is a reducer function?

Here's an example of a reducer function that handles the incrementing and decrementing of a counter.

```javascript
function counterReducer(state, action) {
  const { type, payload } = action;

  switch (type) {
    case 'increment':
      return { 
        ...state,
        counter: state.counter + payload 
      };      
    case 'decrement':
      return { 
        ...state,
        counter: state.counter + payload 
      };
    default:
      return state;
  };
}
```

The *reducer* function is a *pure* function that does not directly modify the state using the `state` variable. Instead, it creates and returns a new state object. Avoid directly mutating the state using the `state` variable or things will end up not behaving as you might expect them to.

Here's an example of an action object for the `dispatch` function that will call the *reducer* function to increment the counter by 1.

```javascript
const incrementAction = {
  type: 'increment',
  payload: 1,
};
```

## Putting the reducer in its own file

We can create a new `CounterReducer.js` file and add our *reducer* function above in it. Within this file, we can also declare the initial state.

```javascript
const initialCounterState = {
  counter: 0,
};
```

Let's also add declarations for our *action objects* within this file.

```javascript
const incrementAction = {
  type: 'increment',
  payload: 1,
};

const decrementAction = {
  type: 'decrement',
  payload: 1,
};
```

## Using the useReducer hook

We can now make use of the `useReducer` hook in a React component, which will make use of our *reducer* function.

```javascript
import { useReducer } from "react";
import {
  counterReducer,
  initialCounterState,
  incrementAction,
  decrementAction,
} from '../reducers/CounterReducer.ts';

export const Counter = () => {
  const [state, dispatch] = useReducer(counterReducer, initialCounterState);

  return (
    <>
      <p>Counter: {state.counter}</p>
      <button onClick={() => dispatch(incrementAction)}>+</button>
      <button onClick={() => dispatch(decrementAction)}>-</button>
    </>
  );
}
```

When we use the `useReducer` hook within our `Counter` component, we provide it with two parameters:

- Our reducer function that we called `counterReducer`.
- The initial state that we called `initialCounterState`.

The `dispatch` function that we receive from the `useReducer` hook will allow us to forward our action objects to the *reducer* function. When the state is updated by the *reducer* function, the component will re-render, and the `state` variable that we get from `useReducer` will reflect the newly updated state.

## Using TypeScript

We can also use TypeScript to add types for our state and action objects. To do so, we can save our `CounterReducer.js` as `CounterReducer.ts` and use the following code.

```typescript
type State = {
  counter: number;
}

const initialCounterState: State = {
  counter: 0,
}

enum ActionType {
  Increment = 'INCREMENT',
  Decrement = 'DECREMENT',
}

type Action = {
  type: ActionType,
  payload: number,
}

const incrementAction: Action = {
  type: ActionType.Increment,
  payload: 1,
}

const decrementAction: Action = {
  type: ActionType.Decrement,
  payload: 1,
}

function counterReducer(state: State, action: Action): State {
  const { type, payload } = action;

  switch (type) {     
    case ActionType.Increment:
	    return { 
        ...state,
        counter: state.counter + payload 
      };
    case ActionType.Decrement:
      return { 
        ...state,
        counter: state.counter - payload 
      };
    default:
      return state;
  };
}
```

## Conclusion

`useReducer` makes it easier to manage more complex state. The simple example above, where `useReducer` is used to manage a counter's state, was a trivial example only meant to demonstrate how to make use of the `useReducer` hook.

For simple state management within your components, you can stick to using the `useState` hook.



The React `useEffect` hook is used to perform side-effects in function components. 

Here are some examples of common side effects:

- data fetching
- subscriptions
- manually changing the DOM

## Using the useEffect hook

The `useEffect` hook accepts 2 arguments:

```javascript
useEffect(callback, [dependencies]);
```

- **Callback:** The *callback* is the function that performs the logic for a side-effect. The *callback* is executed right after changes were being pushed to DOM.

- **Dependencies:** The *dependencies* array is an optional array of dependencies. When dependencies are specified, `useEffect` will executes its *callback* function only if the dependencies have changed between renderings. The *dependencies* argument is used to control when the side-effect should run.

## useEffect and the component lifecycle

We can configure the `useEffect` hook to perform side effects in a component at different times. These include:

- After every render/re-render
- After the first render
- After certain props or state variables change

```javascript
// This gets called after every render 
// (the first render, and every render after that)
useEffect(() => {    
  console.log('[useEffect] on every render');
});

// This gets called on the first render
useEffect(() => {    
  console.log('[useEffect] on first render');
}, []);

// This gets called on the first render 
// and when the prop or state variable 'name' changes
useEffect(() => {    
  console.log('[useEffect] on first render and name change');
}, [name]);
```

It's important that we configure `useEffect` to run at the right time and that we try to avoid unnecessarily re-running effects because they can affect performance.

## Organizing side-effects 

It's a good practice to avoid performing side-effects directly in the body of the component, which is where we return the HTML output that is displayed on the screen.

```javascript
const Greeting = ({ name }) => {
  const message = `Hi ${name}`;
  // Bad practice
  document.title = `Greetings ${name}`;
  return <div>{message}</div>;
}
```

The updating of the document title is a side-effect here because it's not part of the component output in the return statement. 

We should also avoid updating the document title every time the `Greeting` component renders. We should only set the document title when the `name` prop of the component changes.

```javascript
import { useEffect } from 'react';

const Greeting = ({ name }) => {
  const message = `Hi ${name}`;
  
  useEffect(() => {
    document.title = `Greetings ${name}`;
  }, [name]);

  return <div>{message}</div>;
};
```

We fixed the `Greeting` component by moving the updating of the document title in the callback of `useEffect`. We added `name` as a dependency to `useEffect` so that it doesn't run unnecessarily on every component render, but only when the `name` actually changes between renders.

## Asynchronous functions

The `useEffect` hook is a good place for fetching component data client-side. The `useEffect` hook itself cannot be an asynchronous function. However, it can invoke asynchronous functions.

```javascript
useEffect(() => {
  if (!url) {
    return;
  }

  const fetchData = async () => {
    const response = await fetch(url);
    const data = await response.json();
    console.log(data);
  };

  fetchData();
}, [url]);
```

Let's assume that we have a URL from where to fetch data from. We can add a `url` variable to the `useEffect` hook as a dependency. Within the `useEffect` callback function, if the `url` is not defined, we exit the function. However, if the `url` is defined, then we call the `fetchData()` function asynchronously. 

Notice that we do not need any `await` keyword before the call to `fetchData()`. The `useEffect` hook automatically handles this for us. 

Within the `fetchData()` function, we use the [Fetch API](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) to fetch data from the `url` and then output it to the console.

## Side-effect cleanup

Some side-effects performed by the `useEffect` hook need to be cleaned up. Here are some examples:

- Closing a web socket
- Clearing timers
 
We can create a side-effect cleanup by making the callback function of `useEffect` return a function.

```javascript
useEffect(() => {
  // side-effect
  return function cleanup() {
    // side-effect cleanup function
  };
}, [dependencies]);
```

After the component's first render, `useEffect` will invoke its callback that performs a side-effect. The cleanup function is not invoked at this point.

On subsequent component renderings, `useEffect` will invoke the cleanup function from the previous side-effect that was executed. It does this to clean up after the previous side-effect. Once the execution of the cleanup function is complete, `useEffect` will then run the current side-effect for the current rendering of the component.

When a component is unmounted, that is, removed from view on the screen, `useEffect` will also invoke its cleanup function to clean up after the latest side-effect.

## Side-effect cleanup example

Let's take a look at an example of cleaning up a side-effect.

```javascript
const Counter = () => {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const key = setInterval(() => {
      console.log(count);
      // triggers a component re-render      
      setCount((prevCount) => prevCount + 1);
    }, 1000);

    // cleanup function
    return () => clearInterval(key);
  }, [count]);

  return <span>{count}</span>;
};
```

This component increments a counter by one every second. The cleanup function is used to cancel the previous timer before starting a new one. This is to avoid spawning a new timer every second and having many of them running at the same time.

After 1 second, `setCount` updates `count` to 1. The state update triggered by `setCount` causes the component to re-render. When the component re-renders, it calls the `useEffect` cleanup function to stop the previous timer. Once the cleanup function is complete, `useEffect` proceeds by starting a new timer that waits 1 second before updating `count` to 2 with `setCount`.

What happens if we don't include a cleanup function as the last line of the `useEffect` function? The answer is that the `clearInterval` function will never be called and a new interval will start every second. This would cause multiple intervals to run simultaneously, making the count value jump uncontrollably in large increments all the way to infinity.

## The dependency pitfall

Here is an example of a common pitfall with the `useEffect` hook related to missing dependencies.

```javascript
const ChangeCounter = () => {
  const [value, setValue] = useState("");
  const [count, setCount] = useState(-1);

  // Danger!
  useEffect(() => setCount(prevCount => prevCount + 1));

  const onChange = ({ target }) => {
    setValue(target.value);
  };

  return (
    <div>
      <input type="text" value={value} onChange={onChange} />
      <div>{count} changes.</div>
    </div>
  );
};
```

This component counts the number of changes performed on a text box by the user. 

When this component loads, there is an immediate infinite loop problem. Why is that? Let's take a closer look at what's going on.

### The dependency pitfall problem

Since `useEffect` has no dependency provided, it will run on the first component render and every re-render after that. The callback of `useEffect` makes use of `setCount` which updates the state of `count` and causes a component re-render. The `useEffect` callback will run on every re-render and trigger a new re-render, creating an infinite loop where `count` increments quickly to infinity, without any changes to the text box.

### The dependency pitfall solution

We can fix this by providing the right dependencies for `useEffect`.

```javascript
useEffect(() => {
  setCount(prevCount => prevCount + 1);
}, [value, setCount]);
```

We provide `value` as a dependency, since we only want the counter to run when the value of the text box changes. We also provide `setCount` as a dependency, since the callback of `useEffect` makes use of this method to update the state of `count`.

In summary, the infinite loop of component renderings is caused by updating local state in useEffect without having any dependency argument. To avoid the infinite loop, we must properly manage useEffect’s dependencies. This allows us to control when the side-effect should run.

## The object pitfall

Another common pitfall with the `useEffect` hook is the object pitfall. It occurs when we use objects as dependencies.

```javascript
const ChangeCounter = () => {
  const [item, setItem] = useState({ value: "", count: -1 });

  useEffect(() => {
    // a new object for 'item' is created here
    setItem(prevItem => ({ ...prevItem, count: prevItem.count + 1 }));
  }, [item]);

  const onChange = ({ target }) => {
    setItem({ ...item, value: target.value });
  };

  return (
    <div>
      <input type="text" value={item.value} onChange={onChange} />
      <p>{item.count} changes.</p>
    </div>
  );
}
```

This component counts the number of changes performed on a text box by the user. Rather than just using local state to store the number of changes like the previous example, we now use an object to store the last value entered and the number of changes.

When this component loads, there is an immediate infinite loop problem. Why is that? Let's take a closer look at what's going on.

### The object pitfall problem

Remember that a `useEffect` hook with a dependency argument of `[]` or `[dependency]`, where dependency is a variable, will get called on the first component render. The `item` object is used as a dependency of `useEffect`. Inside the `useEffect`callback, `setItem` is called. It increments the counter by one but it also creates a new object for `item` within `setItem`. Since `item` is now a new object, `useEffect` detects that its `item` dependency has changed and re-runs its callback function. This causes another `setItem` invocation that again updates the state with a new `item` object. Thus, we have an infinite loop problem. 

### The object pitfall solution

We can solve the infinite loop problem by changing the dependency from `item` to `item.value`. We only want the side-effect to run and increment the `count` for us when the item's `value` is updated by a change made to the text box.

```javascript
useEffect(() => {
  setItem(prevItem => ({ ...prevItem, count: prevItem.count + 1 }));
}, [item.value]);
```

In summary, avoid using objects as `useEffect` dependencies. Use only a specific property of an object instead.

## Conclusion

The `useEffect` hook manages side-effects in React function components. The *callback* argument holds the side-effect logic. The *dependencies* arugment allows you to add *props* or *state* variables to `useEffect` as dependencies.

The `useEffect` hook will invoke its *callback* function after the component has first mounted (first initial render), and then on subsequent component re-renders, if any of its dependencies has changed.

The `useEffect` hook can be an effective way to run asynchronous operations within a component.

Remember to avoid the *dependency* and *object* pitfalls to make the most effective use of the `useEffect` hook.



The react `useRef` hook accepts one argument as the initial value and returns a reference.

- A reference is an object with a special property, called `current`.
- `ref.current` accesses the reference value.
- `ref.current = newValue` updates the reference value.

We can use `useRef` to store any value on its `.current` property. 

## References versus state

- **Persistence**: The value of a reference is persisted (does not change) between component
re-renders.
- **No re-renders triggered**: Updating a reference doesn’t trigger a component re-render.

## useRef to access DOM elements

The `useRef` hook is useful for accessing DOM elements. One use case for this is to add *focus* on an input field when a component mounts.

- **Step 1**: define the reference: `const inputRef = useRef(null)`
- **Step 2**: assign the reference to the element: `<input ref={inputRef} />`

Once a component is mounted, `inputRef.current` will point to the DOM element. We can then manipulate this DOM element via the `inputRef.current` reference.

```javascript
export const UserForm = () => {
  const inputRef = useRef(null);

  // inputRef.current is null upon initial render
  // There's no DOM structure created yet
  console.log("inputRef is", inputRef.current);

  // access useRef references inside useEffect
  useEffect(() => {
    inputRef?.current?.focus();
  }, []);

  return (
    <div>
      <label htmlFor="username">Username</label>
      <input id="username" ref={inputRef} type="text" />
    </div>
  );
};
```

It is important to note that `useRef` references must be referenced and used only once the DOM structure has been mounted. The `useEffect` hook allows us to run code once the DOM structure has been created. 

The first parameter passed to `useEffect` is a function containing the code we want to run after the DOM is mounted for this component. The second parameter is an empty array `[]`, which tells `useEffect` to run only once, after the component first renders. Not including the empty array would have `useEffect` run after every component render, that is, the initial render and every re-render. This is not what we need for this example, and it is also more expensive performance-wise.

## Managing state with useRef

The `useRef` hook can be used as a stateful React hook. We can use the `useRef` hook to manage component state without having to trigger a component re-render like `useState` does.

```javascript
const Counter = () => {
  const countRef = useRef(0);

  const handleClick = () => {
    countRef.current++;
    console.log(countRef.current);
  };

  return (
    <>
      <h1>Count: {countRef.current}</h1>
      <button onClick={handleClick}>Click</button>
    </>
  );
};
```

When clicking the button, the `current` property of `countRef` is incremented by 1 and the result of this is correctly logged to the screen. The value of `countRef.current` will be persisted no matter how many times this component re-renders due to prop or state changes.

Even if the `current` property of `countRef` has its value updated on every click, the component will not show the updated value in the HTML output of `Count: {countRef.current}`. It will continue displaying the initial value of `0`. This is because `useRef` does not trigger the re-rendering of a component. If a component does not re-render, it will not be able to display updates to values that occured after its initial render to the screen.

## Conclusion

Let's review some important `useRef` lessons that we learned in this article.

- `useRef` references can access DOM elements.
- The value of a a `useRef` reference is persisted across component re-renderings.
- Updating a reference with `ref.current = newValue`, is not like updating state with `useState`, it does not trigger a component re-render.


The React `useState` hook can be used many times to manage as many state variables as necessary in a given component. This is especially useful for forms, which often have several fields that need to be tracked in a component's local state.

## Manage form state independently

Let's take a look at an example of a basic form with two fields, an `email` and a `password` field. In this example, we will manage the `email` and `password` states separately as individual state variables.

```javascript
import React, { useState } from "react";

const Login = () => {
  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");

  const handleSubmit = (e) => {
    // prevent page reload submit behavior
    e.preventDefault();

    console.log(email, password);
  };

  return (
    <form onSubmit={handleSubmit}>
      <input
        name="email"
        type="email"
        placeholder="Email"
        onChange={(e) => setEmail(e.target.value)}
      />
      <input
        name="password"
        type="password"
        placeholder="Password"
        onChange={(e) => setPassword(e.target.value)}
      />
      <button type="submit">Submit</button>
    </form>
  );
}
```

Each field has its own *setter* function and each field has its own state reference. The email field is referenced by `email` and is updated by `setEmail`. The password field is referenced by `password` and is updated by `setPassword`.

## Manage form state in one object

We can also use `useState` to manage form state within one single object. This approach only needs one `useState` call. Rather than `email` and `password` being managed by separate state variables, they become properties of one state object.

The tricky part with this approach is properly updating the state, which is now an object.

When using `useState` with an object, we must remember to spread in the previous state when performing updates to this object. This allows the object to be updated properly without any unexpected results. It is not done automatically for us. Therefore, we must be sure to manually merge the previous state object's properties with the new state changes.

```javascript
import React, { useState } from "react";

const Login = () => {
  const [state, setState] = useState({
    email: '',
    password: ''
  });

  const handleChange = (e) => {
    setState({
      // spread in the previous state
      ...state,
      [e.target.name]: e.target.value,
    });
  };

  const handleSubmit = (e) => {
    // prevent page reload submit behavior
    e.preventDefault();

    console.log(state);
  };

  return (
    <form onSubmit={handleSubmit}>
      <input
        name="email"
        type="email"
        placeholder="Email"
        onChange={handleChange}
      />
      <input
        name="password"
        type="password"
        placeholder="Password"
        onChange={handleChange}
      />
      <button type="submit">Submit</button>
    </form>
  );
}
export default Login;
```

We could have also used an updater function for our `setState` *setter* function.

```javascript
const handleChange = (e) => {  
  setState((prevState) => ({
    ...prevState,
    [e.target.name]: e.target.value,
  }));
};
```

Though it's a bit more verbose, it's best to go with this updater function approach when the next state of a variable depends on its previous state.

## Conclusion

We've looked at two different approaches to effectively using `useState` for managing form state in React. If your form consists of many fields, consider managing the form's state in one object. If your form consists of just a few fields, managing form state as independent fields should be fine.


The React `useState` hook is used to add local state to a component. When `useState` is used, React will preserve the component's local state between re-renders of that component. 

```javascript
const [state, setState] = useState(initialState);
```

The `useState` hook returns a pair: a stateful value, and a function to update it. During the initial render, the returned state referenced by the variable `state` is the same as the value passed as the first argument, which is `initialState`. The one argument that `useState` supports is used to provide an initial value.

The `setState` function above is used to update the state. It accepts a new state value and enqueues a re-render of the component. More on this later.

## A useState counter example

```javascript
const StateCounter = () => {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>{count} clicks.</p>      
      <button onClick={() => setCount(prevCount => prevCount + 1)}>
        Count
      </button>
    </div>
  );
}
```

In this example, the `count` variable is incremented by one every time the button is clicked. `useState(0)` initializes `count` to zero when the component first renders. `count` holds the current number of clicks, while `setCount` is used to update `count`.

We could have written `setCount` in one of two ways: 

- Basic usage: `setCount(count + 1)`
- Using an updater function: `setCount(prevCount => prevCount + 1)`

We went with the second approach because in this example, the next state of `count` depends on its previous state. If the next state depends on the previous state, it is recommended to use the updater function that makes reference to the previous state.

## Why not use a local variable instead?

Could we have used a local variable instead of `useState`? Let's find out.

```javascript
const NoStateCounter = () => {
  let count = 0;

  const onClick = () => {
    count += 1;
  }  

  return (
    <div>
      <p>{count} clicks.</p>
      <button onClick={onClick}>
        Count
      </button>
    </div>
  );
}
```

The `NoStateCounter` component has a first initial render but it never re-renders because no component props or state ever changes. As a result, the `count` value changes when the button is clicked, but only when `useState` is used will the component re-render to show the current value of `count`. As a result, the component always displays `0 clicks` even when the value of `count` is incremented.

Another pitfall to keep in mind when using local variables is that they get reset to their initial value on each component re-render, while `useState` variables do not. `useState` variables persist across re-renders.

## Props and useState

If the data for a component is coming from *props*, we can use a local variable for it. If no computations are needed on a *prop*, we can also just reference the *prop* directly.

Using `useState` to put the *prop* in the state causes an unnecessary re-render. One re-render happens when the *prop* changes, and another re-render happens when the state is changed by the *setter* for `useState`.

```javascript
import { useEffect, useState } from "react";

const ValueDisplay = ({ value }) => {
  const [countValue, setCountValue] = useState(0);

  // runs when the value prop changes
  useEffect(() => {
    // save latest value to state
    setCountValue(value);
  }, [value]);

  // for logging - runs on every component re-render
  useEffect(() => {
    console.log(`Rendered with value ${value}`);
  });

  return <p>{countValue}</p>;
};

const ValueChanger = () => {
  const [value, setValue] = useState(0);

  return (
    <div>
      <ValueDisplay value={value} />
      <button onClick={() => setValue(Math.random())}>Change Value</button>
    </div>
  );
}
```

In this example, we will get two lines of output in the console for every click of the "Change Value" button. This is because the `ValueDisplay` component will re-render twice. The first re-render will happen because the `value` prop changes due to new data passed along from `ValueChanger`. The second re-render will happen because there is a change to the component's state using `setCountValue(value)`.

We actually do not need any `useState` for the `ValueDisplay` component. We can display the `value` prop directly. Since components re-render when a *prop* changes, the data displayed by `ValueDisplay` will always be in sync with the latest *prop* data.

Here's how we can fix and simplify the above example.

```javascript
import { useState } from "react";

const ValueDisplay = ({ value }) => {
  return (
    <p>{value}</p>
  );
}

const ValueChanger = () => {
  const [value, setValue] = useState(0);

  return (
    <div>
      <ValueDisplay value={value} />
      <button onClick={() => setValue(Math.random())}>Change Value</button>
    </div>
  );
}
```

## useState is asynchronous

React component state updates are not performed immediately when we call the setter function provided by `useState`. The setter function does not actually perform an immediate state update. Instead, it schedules a state update for some unknown time in the future. This means that we can't just look at the code to find out exactly when the state update occurred or will occur. 

The `useState` setter function accepts a new state value and *enqueues* a re-render of the component.
What does it mean to *enqueue* a re-render? It means that it doesn't re-render the component immediately. `useState` is asynchronous for performance reasons. This is why state changes with `useState` don't feel immediate.

```javascript
const DoubleCount = () => {
  const [count, setCount] = useState(0);
  const [doubleCount, setDoubleCount] = useState(0);
  
  const handleCount = () => {
    setCount(count + 1);
    // this line won't use the latest value of count
    setDoubleCount(count * 2);    
  };

  return (
    <div>
      <p>Count: {count}</p>
      <p>Double Count: {doubleCount}</p>
      <button onClick={handleCount}>Count</button>
    </div>
  );
};
```

In this example, pressing the click button will update two local state variables. However, the `doubleCount` state is  dependent on the `count` state. The value for `doubleCount` will always be one step behind `count`.

- When `count` **1**, `doubleCount` will be **0**
- When `count` is **2**, `doubleCount` will be **2**
- When `count` is **3**, `doubleCount` will be **4**
- When `count` is **4**, `doubleCount` will be **6**

By calling `setDoubleCount` right after `setCount`, we may have thought that `setDoubleCount` would use the latest value of `count` that was updated by `setCount(count + 1)`. However, the value of `count` in `setDoubleCount(count * 2)`, and in the entire `handleCount` function, will always be the `count` value **before** it has been incremented by `setCount(count + 1)`. 

The `count` references in the component will reflect the latest value of `count` only **after** the component has re-rendered by the state changes done in the `handleCount` function.

We can fix the above example by making use of the `useEffect` React hook with a dependency on `count`. This allows us to be sure that we are executing `setDoubleCount(count * 2)` only after `count` has actually been updated.

```javascript
const DoubleCount = () => {
  const [count, setCount] = useState(0);
  const [doubleCount, setDoubleCount] = useState(0);

  useEffect(() => {
    setDoubleCount(count * 2);
  }, [count]);

  return (
    <div>
      <p>Count: {count}</p>
      <p>Count * 2: {doubleCount}</p>
      <button onClick={() => setCount(count + 1)}>Count</button>
    </div>
  );
};
```

## Component re-renders

Whenever a React component uses any state via `useState`, it will need to be rendered again, or re-rendered, in response to any state change.

If a component does not re-render whenever state is updated, it will not be able to display any state updates to the user.

> React schedules a component re-render every time the local state of a component changes. When a component re-renders, it will also cause all of its child components to re-render. This can make re-renders expensive computations that we may want to keep to a minimum.

## Conclusion

In this post, we gained a solid understanding of `useState`, one of the most important hooks that every React developer must understand. State is a fundamental concept used by many React components and React applications. By knowing what state is, how to manage state with the `useState` hook, and how to avoid common `useState` pitfalls, we can write better React components.



In React, we can write components using the `function` keyword or the `const` keyword and an *arrow* function.

## Using const and an arrow function

```javascript
const MyComponent = () => {
  return(
    <p>My component</p>
  )
}
```

## Using the function keyword

```javascript
function MyComponent() {
  return (
    <p>My component</p>
  );
}
```

The first approach creates a function using the JavaScript arrow function syntax and stores it in a constant variable. The second approach with the `function` keyword creates a plain function that most of us are used to.

Both are functions that will perform the exact same task, which is to return the React component's JSX code for rendering.

Using `const` and arrow functions has become more popular lately. Many developers find the `function` keyword syntax more verbose.

Is there a difference between the two approaches or can we always use either approach interchangeably? There is one important difference between the two. That difference is related to *hoisting*. 

## Hoisting

Hoisting is something that JavaScript does during its compile phase, just microseconds before code is executed. That code is scanned for function and variable declarations. All functions and variable declarations are added to memory inside a JavaScript data structure. This is so that they can be used even before they are actually declared in the source code.

```javascript
helloWorld();  
// prints 'Hello World' to the console

function helloWorld(){
  console.log('Hello World');
}
```

Since function declarations are added to memory during the compile stage, we are able to access the `helloWorld()` function even before it is declared.

## Hoisting with let

Using a `let` variable before it is declared will result in a `ReferenceError`. The variable `username` is in a "Temporal Dead Zone" from the start of the code block until it is actually declared using `let username = "Mario"`.

```javascript
try {
  username = "Luigi";
  let username = "Mario";
}
catch(err) {
  console.log(err);
  // ReferenceError: Cannot access 'username' before initialization
}
```

## Hoisting with const

Using an uninitialized `const` variable before it is declared is a syntax errror. The code will throw an error.

```javascript
try {
  username = "Luigi";
  const username;
}
catch(err) {
  console.log(err);
  // Uncaught SyntaxError: Missing initializer in const declaration
}
```

If we do initialize the `const` declaration, like we did with `let`, we will get the same error as we got with `let` above.

```javascript
try {
  username = "Luigi";
  const username = "Mario";
}
catch(err) {
  console.log(err);
  // ReferenceError: Cannot access 'username' before initialization
}
```

The `function`, `let`, and `const` declarations are all hoisted. However, the `let` and `const` declarations remain unitialized. They are only initialized when the variable assignment is evaluated at runtime by the JavaScript engine. This means that we cannot access `let` and `const` variables before the JavaScript engine evaluates their values at the place where they were declared. This is what is referred to as a "Temporal Dead Zone." It is a time span between variable creation and variable initialization where variables cannot be accessed.

## Hoisting and React components

Let's apply what we learned from the hosting of `const` variables to React components.

```javascript
const App = () => (
  <>
    <MyComponent />
    <MyOtherComponent />
  </>
);
export default App;

const MyComponent = () => {}

const MyOtherComponent = () => {}
```

In this example, the linter will throw an error because `MyComponent` and `MyOtherComponent` are used before they are declared. 

We can fix the error by moving the component declarations to the top of the file.

```javascript
const MyComponent = () => {}

const MyOtherComponent = () => {}

const App = () => (
  <>
    <MyComponent />
    <MyOtherComponent />
  </>
);
export default App;
```

If we want to keep our component declarations at the bottom of a file and then use them before they are declared, we should use the `function` syntax. This will allow them to be hoisted to the top of the file.

Here is the same example re-written with the `function` syntax in order to keep component declarations at the bottom of the file and fix the error.

```javascript
 const App = () => (
  <>
    <MyComponent />
    <MyOtherComponent />
  </>
)

function MyComponent() {}

function MyOtherComponent() {}
```

## Conclusion

React components declared with the `function` keyword can be called even if their function definition is further down in the code. React components declared with `const` and arrow functions will still get hoisted, but they cannot be called until after they are defined.



Iterating over the string values of a TypeScript Enum can be easily accomplished by converting that Enum into an array. Let's say we have the following Enum called `Categories` that contains different names for its keys and values.

```javascript
enum Categories {
  AllCategories = 'All',
  ActionAdventure = 'Action/Adventure',  
  Comedy = 'Comedy',
}
```

## Get the keys

We can get the Enum's keys by using the `Object.keys()` JavaScript method.

```javascript
const categoryKeys: Array<string> = Object.keys(Categories);

console.log(categoryKeys);
// ["AllCategories", "ActionAdventure", "Comedy"]  
```

This will give us the Enum's key values as an array of strings that we can iterate over.

## Get the values with the keys

We can iterate over the Enum's keys that we got above in order to get the Enum's values.

```javascript
const categoryKeys: Array<string> = Object.keys(Categories);

const values: Array<Categories> = categoryKeys.map(categoryKey => Categories[categoryKey]);
// with 'noImplicitAny' disabled in tsconfig.json

console.log(values);
// ["All", "Action/Adventure", "Comedy"] 
```

If the `noImplicitAny` rule is not disabled in `tsconfig.json`, the `Categories[categoryKey]` reference will throw an error because we are trying to access a `Categories` property using a `string` key. TypeScript warns that since `key` is a `string`, it can be equal to anything, not just the key names in `Categories`. 

We can fix this error by defining a new `key` variable with `keyof typeof Categories` and casting `categoryKey` to the same type using the `as` keyword. The possible values of `key` will now be limited to only the names of the `Categories` keys. TypeScript will be fine with this adjustment that we've made. We won't have to make adjustments to the `noImplicitAny` TypeScript rule with this approach.

```javascript
const values: Array<Categories> = categoryKeys.map(categoryKey => {
  const key: keyof typeof Categories = categoryKey as keyof typeof Categories;
  return Categories[key];
});

console.log(values);
// ["All", "Action/Adventure", "Comedy"] 
```

This will give us an array of strings that we can iterate over.

## Get the values

We can also get the Enum's values by using the `Object.values()` JavaScript method. This will give us an array of strings that we can iterate over.

```javascript
const values: Array<Categories> = Object.values(Categories);

console.log(values);
// ["All", "Action/Adventure", "Comedy"] 
```

## Conclusion

We can use the `Object.values()` JavaScript method to iterate over the string values of a TypeScript Enum.
We can also use the `Object.keys()` JavaScript method and then iterate over the Enum's keys to get its values.

For more help with TypeScript Enums, I have a blog post on how to [Get the keys of a numeric TypeScript Enum](https://lumin8media.com/typescript/get-the-keys-of-a-numeric-typescript-enum).



If you've ever tried getting the keys from a numeric TypeScript Enum, you've probably noticed that it returned both the keys and values of that Enum.

## The problem

Here is an example of what happens when we apply `Object.keys()` on an Enum with implicit numeric values.

```javascript
enum Players { 
  Mario,
  Luigi,
  Peach,
  Toad,
}

console.log(Object.keys(Players));
// ["0", "1", "2", "3", "Mario", "Luigi", "Peach", "Toad"]
```

The same thing happens when we define explicit numeric values for a similar Enum and apply `Object.keys()` to it as well.

```javascript
enum Characters { 
  Mario = 101,
  Luigi = 102,
  Peach = 103,
  Toad = 104,
}

console.log(Object.keys(Characters));
// ["101", "102", "103", "104", "Mario", "Luigi", "Peach", "Toad"] 
```

## The explanation

If we output the contents of the `Players` Enum above using `console.log(Players)`, we will see the following.

```json
{
  "0": "Mario",
  "1": "Luigi",
  "2": "Peach",
  "3": "Toad",
  "Mario": 0,
  "Luigi": 1,
  "Peach": 2,
  "Toad": 3
} 
```

Notice that both the left and right sides of the Enum are defined as keys. Both the numeric values and the names that they are assigned to, are output as keys.

If we take a look at how the `Players` Enum is complied from TypeScript to JavaScript, we'll see something like this.

```javascript
var Players;
(function (Players) {
  Players[Players["Mario"] = 0] = "Mario";
  Players[Players["Luigi"] = 1] = "Luigi";
  Players[Players["Peach"] = 2] = "Peach";
  Players[Players["Toad"] = 3] = "Toad";
})(Players || (Players = {}));
```

The `Players["Mario"] = 0` variable assignment creates a property `Mario` that is assigned a value `0`. However, that is not the only variable assignment taking place here. Notice that there is also a `Players[Players["Mario"] = 0] = "Mario"` variable assignment that creates a property of `0` with the value of `Mario`.

## The solution

In order to get only the actual keys from a numeric TypeScript Enum, we will have to use `Object.keys()` in combination with the array `filter` method.

```javascript
enum Players { 
  Mario,
  Luigi,
  Peach,
  Toad,
}

const keys = Object.keys(Players).filter(player => {
  return !(parseInt(player) >= 0);
});
console.log(keys);
// ["Mario", "Luigi", "Peach", "Toad"] 
```

In the example above, we are using the bang `!`, or logical "not", operator within the `filter` method to retrieve the `Player` values that fail the `parseInt(player) >= 0` test. The values `0`, `1`, `2`, `3` will pass the `parseInt(player) >= 0` test, but the bang operator will end up excluding them. 

The values `Mario`, `Luigi`, `Peach`, and `Toad` will result in `NaN` after `parseInt(player)` is applied to them. `NaN` is not greater than or equal to `0`, so this test will be `false`. However, the bang operator will make it `true` and end up including these values in the result.

We can also use another approach to get the same result.

```javascript
let keys = Object.keys(Players).filter(player => isNaN(+player));
console.log(keys);
// ["Mario", "Luigi", "Peach", "Toad"] 
```

In this case, we are also filtering out only the non-numeric values from the Enum to get the actual keys.

Without the unary plus operator (`+`), we would get a TypeScript error. We used the unary plus operator to make the `player` values compatible with the definitions in TypeScript for the `isNaN()` function, which expects a `number` value. The unary plus operator attempts to convert each `player` value into a number, if it is not already a number. The iteration for `Mario` will be `+Mario`, which results in `NaN`, thus causing the `isNaN()` test to pass.

## Conclusion

TypeScript Enums can be tricky, especially when numeric values are used. We looked at why `Object.keys()` does not behave as we would expect it to on these types of Enums. We then looked at a simple solution to get the non-numeric keys from these types of Enums. You are now well-equipped to handle TypeScript Enums with numeric values.

For more help with TypeScript Enums, I have a blog post on how to [Iterate over a TypeScript Enum](https://lumin8media.com/typescript/iterate-over-a-typescript-enum) that contains `string` values.


Here's how you can add [Google Analytics](https://developers.google.com/analytics) to an Angular app using Google's Tag Manager.

## Environment variable

We'll start by adding the Google Analytics Property ID to the Angular application's environment variables.

Open the `environment.ts` and add the following.

```javascript
export const environment = {
  production: false,
  googleAnalyticsId: undefined,
};
```

Now, open the `environment.prod.ts` and add the following.

```javascript
export const environment = {
  production: true,
  googleAnalyticsId: '[G-YOUR-KEY-HERE]',
};
```

## Service class

Let's create a `GoogleAnalyticsService` in a file called `googleAnalytics.service.ts`. This file can be placed in an `analytics` folder within the Angular `app` folder. Add the following code to this new file.

```javascript
import { Injectable } from '@angular/core';
import { NavigationEnd, Router } from '@angular/router';
import { environment } from '../../environments/environment';

declare var gtag: Function;

@Injectable({
  providedIn: 'root',
})
export class GoogleAnalyticsService {
  constructor(private router: Router) {}

  public initialize() {
    this.onRouteChange();

    // dynamically add analytics scripts to document head
    try {
      const url = 'https://www.googletagmanager.com/gtag/js?id=';
      const gTagScript = document.createElement('script');      
      gTagScript.async = true;
      gTagScript.src = `${url}${environment.googleAnalyticsId}`;
      document.head.appendChild(gTagScript);

      const dataLayerScript = document.createElement('script');
      dataLayerScript.innerHTML = `
        window.dataLayer = window.dataLayer || [];
        function gtag(){dataLayer.push(arguments);}
        gtag('js', new Date());
        gtag('config', '${environment.googleAnalyticsId}', {'send_page_view': false});`;
      document.head.appendChild(dataLayerScript);
    } catch (e) {
      console.error('Error adding Google Analytics', e);
    }
  }

  // track visited routes
  private onRouteChange() {    
    this.router.events.subscribe((event) => {
      if (event instanceof NavigationEnd) {
        gtag('config', environment.googleAnalyticsId, {
          page_path: event.urlAfterRedirects,
        });
      }
    });
  }

  // use gtag.js to send Google Analytics Events
  public event(action: string, eventCategory?: string, eventLabel?: string, value?: string) {
    gtag('event', action, {
      ...(eventCategory && { event_category: eventCategory }),
      ...(eventLabel && { event_label: eventLabel }),
      ...(value && { value: value }),
    });
  }
}
```

## Invoke the service

We'll now modify the `AppComponent` in the `app.component.ts` file. We'll assume that `AppComponent` is the component in the application that contains the `<router-outlet>` tag in its template. If that's not the case, then you can modify the corresponding component and template instead.

```javascript
import { Component, OnInit } from '@angular/core';
import { environment } from '../environments/environment';
import { GoogleAnalyticsService } from './analytics/google-analytics.service';

@Component({
  selector: 'app',
  template: '<router-outlet></router-outlet>',
})
export class AppComponent implements OnInit {
  constructor(private readonly googleAnalyticsService: GoogleAnalyticsService) {}

  ngOnInit() {
    if (environment.production) {
      this.googleAnalyticsService.initialize();
    }
  }
}
```

In this component, we are calling the `initialize` function as early as possible within `ngOnInit`. In this example, we make sure to add analytics tracking only to the `production` environment of the application.

## Testing it out

To test that Google Analytics has been added properly, we can add `console.log` statements in the `GoogleAnalyticsService` class.

```javascript
private onRouteChange() {
  this.router.events.subscribe(event => {
    if (event instanceof NavigationEnd) {
      gtag('config', environment.googleAnalyticsKey, {
        'page_path': event.urlAfterRedirects,
      });
      console.log('Sending Google Analytics tracking for: ', event.urlAfterRedirects);
      console.log('Google Analytics property ID: ', environment.googleAnalyticsKey);
    }
  });
}
```

We should now see the two statements being logged to our console every time that we navigate to a new route within the Angular application.



[Planning for Unpredictability](https://www.youtube.com/watch?v=bQ3PkRWg__Y) is episode 16 of [The Gumroad Podcast](https://gumroad.com/podcast), featuring Independent Creator and Gumroad's Head of Product, [Daniel Vassallo](https://twitter.com/dvassallo). I found it very informative so I decided to take notes. This blog post contains my notes on the episode.

> Daniel Vassallo created Userbase and launched several very successful Gumroad products, including "The Good Parts of AWS" and "Everyone Can Build a Twitter Audience". In 2019, he left a job paying $500,000 at Amazon to work for himself.

## The unpredictable world

When jumping from the predictable world of employment to self-employment and being a creator on the Internet, there is much more uncertainty and unpredictability involved.

Working very hard on one thing works well in the predictable world, but working hard is not enough in the unpredictable world. Randomness, chance, and unpredictable events play such a big role in the unpredictable world. Therefore, succeeding in the unpredictable world requires a different strategy.

[Nassim Taleb](https://twitter.com/nntaleb), [Tim Ferriss](https://twitter.com/tferriss), and [Art De Vany](https://twitter.com/artdevany) speak of the role of chance in life and business. Thinking in this way has been beneficial for Daniel.

Daniel found that diversifying his income has helped to increase his odds of success. It has also given Daniel the psychological benefits of motivation and productivity.

Daniel actually had no concrete work plans for November 2021. There were a few things he had to get done, but then he had the freedom to jump into a few random things. This allowed him to take advantage of spontaneous opportunities that presented themselves.

Two and a half years ago, Daniel had no social media experience. He hated social media. Today, he finds it extremely useful and even has products available that teach people how to use social media. This shows how life can take you down unexpected, yet amazing roads if you're available and willing to go down them when they present themselves. 

Unpredictability scares us, but Daniel suggests that we can use it to our benefit to find the right work-life balance, as well as new sources of energy and inspiration.

## Dealing with uncertainty

As humans, our natural tendency is to fight uncertainty. Daniel suggests that the right strategy is to embrace uncertainty rather than to fight it. Negative uncertainties can harm us and we want to be well-prepared for those. However, there are also good uncertainties. We need to put ourselves out there to be ready for the good opportunities that life can throw at us.

Daniel finds that having a specific goal can be blinding. It stops us from seeing opportunities that appear right in front of us. When we focus on one thing, our brain is no longer able to see any other opportunities, even if they are there. It's similar to the metaphor of tunnel vision, which is the reluctance to consider any alternatives to one's preferred point of view.

Daniel says that to benefit from luck, you have to recognize it. To recognize luck, you need availability, free time, and an attitude that sees unpredictability as a good thing.

## Stressors are signals

At the beginning of Daniel's unpredictable journey, the unpredictability of his income made him uncomfortable. Not knowing what he would make as income in three months or in six months was not pleasant at first. Now, Daniel is learning how to take advantage of the stressors and the ups and downs. 

Daniel treats the stressors as signals. When stressors dropped, Daniel took it easy and rode the momentum, enjoying a vacation. When the low income months come, Daniel likes to think that constraints breed creativity. Daniel finds that when the stressor of a dip in income happens, something activates in your brain. You get more energy. You get more productive, and you start thinking of new ideas.

The stressor of a dip in income got Daniel thinking of new projects. He started wood-working and created a portfolio of cutting boards. So far, he's made $3600 from this project. It's been a small win so far. It may not be a major income stream unless he finds new marketing channels to explore. However, Daniel is happy with it even if it remains a small win. 

A few weeks after the wood-working project, Daniel got the idea to create a cohort-based course. The fact that he had the stressor of a dip in income helped him find the right 20% to the 80/20 rule. This comes from the *Pareto Principle* which states that 20 percent of your activities will account for 80 percent of your results.

Daniel had no material prepared for the cohort-based course that he wanted to create. He had a few things in mind, some tweets, and some material scattered on the Internet. He spent a few weeks thinking about it before it began to materialize. Daniel articulated the ideas that he had for his course on forums and in conversations in order to test them out. He also stress-tested his ideas on Twitter and on podcasts.

> Keep in mind that there needs to be a certain level of rigor under the surface to create a course. It's very hard to just jump into building a course without any knowledge on a topic or any material prepared whatsoever.

## Daniel's successful products

Daniel perceives procrastination as a signal that he's not ready yet. If he has no free energy available to create a brain dump, where the idea can almost create itself, then he considers that he needs to wait a bit more before starting. Procrastination is a signal that there are some gaps in his knowledge that are too hard for him to articulate at the moment.

Looking back two years ago, Daniel had a very small audience of under 10,000 Twitter followers. At that time, he started writing and releasing books. Since then, he had three successful info products.

Here's how Daniel's three successful info products came to be.

1. **The Good Parts of AWS**: This was a technical book about programming and AWS. It was a brain dump of fifteen years of Daniel's experience with the technology. The brain dump didn't take very long. It required some editing to condense the information and it was done.

2. **How To Build A Twitter Audience**: For this info product, Daniel prepared a one hour recording and some slides to walk people through real-life examples. He tweeted about it and answered people's questions for free on Twitter.
 
3. **The cohort-based course**: This was the most elaborate thing that Daniel has prepared so far. It contains around nine hours worth of content. He had to work harder to figure out how to present the ideas in his mind. He learned that what works as a tweet does not work as a live presentation.

One of the best ways to start writing is to do a brain dump of what you already know. When it comes to marketing your work, don't try to put yourself at the right place at the right time. Put yourself in *all the right places all the time*. 

## Doing what Daniel did

Justin asked Daniel a very good question. He asked, **"How does one go about doing what Daniel did without some significant amount of cash in the bank?"**.

When Daniel left Amazon, he had saved up for five years of expenses. He had no need to change his lifestyle when he left. You can't jump into this unpredictable world if you are living paycheck to paycheck. You need a cash cushion of at least six months to a year. However, worry about the right cushion should not stop people from taking the plunge because the stressor to have to make it work can help you.

Knowing where to start was a challenge. Daniel took a look at himself and realized that he had all this knowledge and experience in a particular domain. The biggest mistake that he made was that he thought he would increase his odds for success by focusing on something that he knew a lot about. 

Daniel had been programming since he was five years old, the age that he created his first "Hello, world" application. Therefore, he thought he needed to build a software business around databases and programming. He thought this was his ideal business. The problem was that he was too idealistic. He underestimated the role of chance and unpredictability. Daniel's subconscious nagged him to open his eyes. He would ask himself questions like, *"Are you sure you want to put all your eggs in one basket?"*, and *"Are you sure this will work out?"*.

## The variable income stressor

The lower your safety net is, the greater your sense of urgency will be. In this case, go for the low-hanging fruit. You don't need to create the perfect business. Go with what you have and try to gain the freedom and flexibility that you'd like. That may mean compromising on certain things.

Your first step can be to change from full-time employment to freelance work. You can maybe even arrange this with your current employer. Your income might drop, but you will have more freedom. You can then look for a few clients to do work for on the side, without having to ask your employer for permission. It will cost you something but you will gain what is necessary to arrange your life in a way that better matches your preferences and goals.

## Adjusting to the unpredictable world

Daniel had two panic attacks, or crisis moments, since embarking on this journey. The first one was during his first week. He was unknown to the world. The only reputation he had was with his previous employers. He thought, *"who will listen if I put something out in the world? Why will people trust me?"*. The biggest piece he was missing was the fact that he was unknown and had no marketing experience.

Daniel started with a portfolio of small bets, but didn't even realize it at the time. He tried a few different things, such as blogging, posting on Reddit, Hacker News, Twitter, LinkedIn, and Quora.

He monitored each channel to see if there was something there. Some channels took too much energy without any returns. Twitter stuck because Daniel liked it and got feedback that it was working. He continued trying his other channels for months but then stopped due to the lack of feedback and results. He's also been experimenting with Instagram but with less intensity.

## Stack your assets

Daniel recommends having assets that you can stack. Writing, programming, and marketing are all assets or skills that can be stacked and combined. Realize your missing piece and find ways to acquire it. For many, that missing piece is marketing.

In order to gain visibility, explore personal networks, improve your rankings in Search Engines, and even paid marketing via Facebook Ads and Google Ads.

## The creator economy

There are two types of careers out there. The first type of career is based on predictable success. Plumbers, architects, doctors, are all examples of this first type. The second type of career is based on chance success. Musicians, authors, startup founders, and YouTubers all fall under this second type. 

This second type of career based on chance success is extremely competitive and very unpredictable. That's why there is the popular notion of the starving artist. There seems to be no room in the economy for every artist to succeed. We see the same on the Internet. There are runaway successes for some, and then a long line of unsuccessful individuals.

The counterargument is that the Internet is huge. There is plenty of room for people to make a living on the Internet, or at least a significant side income. Perhaps exploring different niches can help.

Jason asked Daniel a great question at this point. He asked, **"This podcast may lead you to believe that you should quit your job and take risks. It may make you think that if you make enough small bets, one of them will hit. Is the creator economy capable of supporting many independent creators?"**

To answer this question, Daniel makes reference to the economist Art De Vaney who examined the Hollywood industry and determined that it is impossible to predict which Hollywood movies will succeed. There are so many variables at play. The creator economy is much like that. It's impossible to determine who will make a living in such an economy and who won't.

## Adding some predictability

Daniel advises to not focus only on the unpredictable world. Include predictable activities in the unpredictable to gain peace of mind.

During his second anxiety crisis, Daniel found some freelance work. It was a small gig of about ten hours a month. It didn't even cover his mortgage, but it was a good motivator for him. It gave him the confidence to write his book. He figured that if the book didn't work out, he would do more freelance hours.

Daniel left that freelancing gig and now has a [Gumroad](https://gumroad.com/) job as the predictable part of his portfolio at ten hours a week.

Daniel's current cohort-based class is an unpredictable project where he gets paid by the hour. It's different from the info products that he is used to, which make money when he is away from the screen.

Looking back at his own products, his Twitter course was very successful. It made over a quarter of a million dollars in just over a year. What caused it? Retweets and endorsements from influential people that Daniel didn't even know. It was a coincidence. When Daniel tweeted about it, they bought it and recommended it. This snowballed into other people buying it and recommending it.

If Daniel were to go back in time and re-do the launch of his Twitter course, the outcome would be different. It could end up making more or less than the income it made. We cannot rely on the predictability of outcomes with projects like these.

## How to get started

Go for the low-hanging fruit. Try to do something small. Don't optimize it too much. Once you have something working, even if you don't know what made it work, you can replicate it and do something similar.

The world is complex. We don't always know what causes something to work. Was it the price, the landing page, or the cover? There are many variables at play. 

## Aim for small wins

We over-glorify failures. "I failed but I learned a lot" is a popular phrase nowadays. Sure, we learn from failures. However, there is so much more that we learn from a small win. There is a different kind of knowledge that we get from small wins that failure cannot give us. Small wins give us a knowledge of what works in the unpredictable world. Once you see something working, you can do similar things to build on your successes.

In this unpredictable world, success tends to bring with it other successes. Once you get a small win, other things you do tend to succeed even more.

## Have a portfolio of small bets

Build a portfolio of small bets. Mix predictable projects to gain a greater peace of mind. For unpredictable bets, ignore the big upside projects. Go for small, limited upside projects that have a greater chance of working. Target niches. Lower your prices to create small wins.

Do not optimize too early. It's one mistake that Daniel sees a lot of people making. We all want to get the most out of what we work on. However, over-optimizing can lead to failure. If you charge too much for something and your reputation does not justify that price point, it can end up costing you. Always remember that reputation justifies price-point. Do not overprice your products.

When it comes to price optimization, Daniel suggests following [Adam Wathan](https://twitter.com/adamwathan)'s advice:

> "Giving your work away for free is like compressing a spring that releases when you put something up for sale" - Adam wathan

Adam and his partner gave things away for free on the Internet for years. Then, when they put a product for sale, they made a million dollars in a month. Don't focus so much on the profit that they made. Even they may not be able to replicate these profits if they were to re-do their launch today. They didn't know what kind of success it would become at the time of their launch in 2018.

Focus on writing, programming, and getting attention online. Build your own online reputation. Give things away for free to the community. It will pay off like it did for Adam.

## Lifestyle design

Daniel is a proponent for lifestyle design. He optimizes on what he wants his life to look like rather than optimizing on income. Though he may not know what he will be working on this time next year, he knows what he won't do.

Daniel won't do things like a full-time 9-to-5 job. He doesn't want the office cubicle life. He doesn't want to work on someone else's terms. He doesn't want to commute to work. He wants to spend more time with his kids. He doesn't want to be an absent father. He doesn't want to work on purposeless things.

Figuring out what you don't want to do is important. We tend to improve our lives more reliably by eliminating things that we know we dislike, rather than trying to go after things that we think we will like.



The JavaScript reduce method is one of the more challenging JavaScript methods to understand. This article will simplify it for you and provide you with several examples.

The `reduce` method is performed on arrays. It allows us to reduce an array using a *reducer* function. The reducer function performs an *accumulation* of an array's values in order to reduce that array to a single result.

## The reduce method

The reduce method accepts two arguments.

```javascript
const result = array.reduce(callback, initialValue);
```

The first argument is a *callback function* that performs the reduce operation. The second argument is an optional argument for the initial value of the operation. 

When applied to an array, the *callback function* is called for each item of the array.

Four optional arguments are available to the *callback function*.

```javascript
array.reduce((accumulator, item, index, array) => {
  // ...
})
```

The first argument is the *accumulator* value that collects the function's accumulated result. The second argument is the current array item of the iteration. The third argument is the current array item's index, and the last argument is the array itself. The first two arguments are most commonly used. The third and fourth arguments are often omitted.

The `reduce` method will not change the original array that it executes on. Also, the reduce function won't run if the array has no elements.

## Calculating the sum of an array

Calculating the sum of an array is the easiest example of a reduce operation. The array `[1, 2, 3]` will get reduced to a sum of `6`. 

```javascript
const numbers = [1, 2, 3];
const sum = numbers.reduce((sum, number) => {
  return sum + number;
}, 0);
console.log(sum); // 6
```

### The callback function

```javascript
(sum, number) => {
  return sum + number;
}
```

The arrow function above is the *callback* function that gets invoked for every item in the array. 

### The accumulator

Notice that the second argument of `reduce` is set to `0`. This initializes the *accumulator* with an initial value.

`sum` is the *accumulator*. It starts with the initial value of `0`. The return value of each `reduce` call is used as the new accumulator value for the next iteration. 

```javascript
const numbers = [1, 2, 3];
const sum = numbers.reduce((sum, number) => {
  console.log(sum); // 0, then 1, then 3, then 6
  return sum + number;
}, 0);
```

### Without an initial value

The second argument of `reduce`, the initial value, is optional. This means we can omit it. 

```javascript
const numbers = [1, 2, 3];
const sum = numbers.reduce((sum, number) => {
  return sum + number;
});
console.log(sum); // 6
```

When we omit the initial value, the `reduce` method will initialize the *accumulator* with the first item of the array instead. Iteration will then start with the second item of the array. In this case, the *accumulator* was initialized with the array item `1` and iteration started with the array item `2`.

## Finding the maximum value

The `reduce` method can be used to find the max value in an array.

```javascript
const numbers = [1, 2, 3];
const sum = numbers.reduce((max, item) => {
  return item > max ? item : max;
});
console.log(sum);
```

`max` is the *accumulator*. It starts with the first array item of `1` since no initial value was provided to the `reduce` method for the accumulator. The return value of each `reduce` call will be the new accumulator value for the next iteration. 

For the first iteration, `max` will be `1` and `item` will be `2`, since iteration starts with the second array item when no initial value is provided for `reduce`. `2` is greater than `1`, so `2` is returned as the new *accumulator* value. For the last iteration on the `numbers` array, `max` is `2` and `item` is `3`. `3` is greater than `2`, so `3` is returned as the final reduced value.

## The sum of an array of objects

The `reduce` method can also help with finding the sum of an array of objects.

```javascript
const items = [{ n: 1 }, { n: 2 }, { n: 3 }];
const sum = items.reduce((accumulator, currentItem) => {
    return accumulator + currentItem.n;
}, 0);
console.log(sum); // 6
```

## Flattening an array of arrays

The `reduce` method can also help with flatting an array of arrays so that a flat, one-dimensional array is returned as the result.

```javascript
const items = [[0, 1], [2, 3], [4, 5]];
const result = items.reduce((accumulator, currentItem) => {
  // concat() merges two or more arrays
  return accumulator.concat(currentItem);
}, []); 
console.log(result); // [0, 1, 2, 3, 4, 5]
```

The initial value for the *accumulator* of `reduce` is set to an empty array and the `concat` method is used to merge the *accumulator* array and the current array per iteration.

## Removing duplicates in an array

The `reduce` method can also help with removing duplicate entries from an array. 

```javascript
const items = [1, 2, 1, 2, 3, 4];
const result = items.reduce((accumulator, current) => {
  if (accumulator.indexOf(current) === -1) {
    accumulator.push(current)
  }
  return accumulator;
}, []);
console.log(result); // [1, 2, 3, 4]
```

The *accumulator* is used as the array that groups unique items. If the array item for the current iteration is not in the accumulating array, then and only then, does it get added. The accumulating array is then returned after each iteration to serve as the accumulator value for the next iteration.

## Counting occurences

The `reduce` method can also help with counting the occurence of values. 

```javascript
const items = [1, 2, 1, 2, 3];
const result = items.reduce((accumulator, current) => {
  if (current in accumulator) {
    accumulator[current]++;
  } else {
    accumulator[current] = 1;
  }
  return accumulator;
}, {});
console.log(result); // { 1: 2, 2: 2, 3: 1 }
```

The *accumulator* is initialized as an empty object `{}`. Each unique array value becomes a *key* of that object in order to track the number of occurences of each. For the first iteration, `current` will not be found as a key of the accumulator object, so execution will enter the `else` clause and set the current value's occurences to `1`. When the current array value is found as a key in the accumulator, then that value's occurences is incremented by one.

## Grouping objects

The `reduce` method can also help with grouping objects in an array of objects.

```javascript
const items = [
  { name: 'Mario', gender: 'M' },
  { name: 'Luigi', gender: 'M' },
  { name: 'Peach', gender: 'F' },
];

const result = items.reduce((acc, item) => {
    const key = item['gender'];
    if (!acc[key]) {
      acc[key] = [];
    }
    acc[key].push(item);
    return acc;
}, {});
console.log(result);
```

The *accumulator* is initialized as an empty object `{}`. During each iteration of the `reduce` method, the *gender* value is retrieved from each object in the array. If the accumulator object does not contain the gender value as a key, it is added to it and initialized with an empty array. In the following iterations, if the current `items` array object's *gender* key is found in the accumulator object, then its corresponding array gets the current object added to it.

The result is: 

```json
{
  F: [
    {
      gender: "F",
      name: "Peach"
    }
  ],
  M: [
    {
      gender: "M",
      name: "Mario"
    }, 
    {
      gender: "M",
      name: "Luigi"
    }
  ]
}
```

## Conclusion

We saw how to use the JavaScript `reduce` method to apply a *reducer* callback function to each element of an array. After working through the examples that we covered, you will be able to use the `reduce` method with confidence.


Object-Oriented Programming (OOP) is a programming paradigm based on classes as blueprints for objects. An application built with OOP principles is organized into classes. Classes are used to create class instances, called objects.

There are many popular object-oriented programming languages such as JavaScript, TypeScript, PHP, Python, Ruby, C++, and Java. 

## Classes and objects

A class is a blueprint that is used to create specific objects. We can create an `Employee` class. This class can have objects for each employee in a company.

Classes usually have functions. They are called methods and they are only available to objects of that specific class type. Methods perform an action on an object. The `Employee` class might have methods to get the name of an employee, or change the employee's address. These methods will only be used on objects of type `Employee`. The `Employee` class can be reused to represent any number of employees.

Classes also have attributes. Attributes store data for each object. The `Employee` class can have attributes such as `firstName`, `lastName`, `dateOfBirth`, and more. 

The value of these attributes can be set for each individual object without affecting other objects of the class `Employee`. The object that represents employee John Smith can have attribute values that are different from the object that represents employee Jane Doe.

The class `Employee` is nothing other than a template for modeling an employee in a software application. An object is instantiated from the class to represent one real-world employee, such as John Smith.

## The building blocks of OOP

The building blocks of Object-Oriented Programming are:

- **Classes**: the blueprints for individual objects. They are data types defined by the programmer.

- **Objects**: instances of a specific class created with specific data.

- **Methods**: actions that can be performed on objects. Methods can return data for an object or update an object's data.

- **Attributes**: the data that describes an object is stored as attributes. Attributes represent the current state of an object.

## The principles of OOP

- **Encapsulation**: important information is self-contained in an object and only select information is exposed and accessible. It is a data-hiding strategy to achieve greater application security. Learn more about [Encapsulation](https://lumin8media.com/programming/what-is-encapsulation).

- **Abstraction**: helps to represent complexity by making only select attributes and methods of an object available. It also helps to generalize one definition of data and to make it applicable to different, but somewhat related, types of data. Learn more about [Abstraction](https://lumin8media.com/programming/what-is-abstraction).

- **Inheritance**: makes code more reusable by having parent classes extend attributes and methods to child classes. Learn more about [Inheritance](https://lumin8media.com/programming/what-is-inheritance).

- **Polymorphism**: allows different types of objects to make use of the same interface, reducing duplicate code. Learn more about [Polymorphism](https://lumin8media.com/programming/what-is-polymorphism).

## The benefits of OOP

The benefits of Object-Oriented Programming are:

- **Simplicity**: complex real-world entities can be modeled with simple classes.

- **Modularity**: the self-contained nature of objects makes the process of collaborative development smoother.

- **Reusability**: encapsulation, inheritance, abstraction, and polymorphism make code more reusable.

- **Security**: encapsulation and abstraction allow complex code to be hidden.

- **Flexibility**: polymorphism allows different objects to share the same interface.



In Greek, "poly" means "many". For example, polygon means a many sided shape. Also in Greek, "morph" means "form". Morphology is the study of how words are "formed". Thus, polymorphism means "many forms". 

In Computer Science, polymorphism is presenting the same interface for differing underlying forms (data types).

## Polymorphism with Shapes

An example of Polymorphism is a `Shape` class and all the classes that can inherit from this Shape class - classes like `Point`, `Square`, `Circle`, `Rectangle`, etc. 

Polymorphism allows each of these classes to have different underlying data even though they inherit from the Shape class. A `Point` shape only needs two co-ordinates as data. A `Circle` shape needs a center and radius as data. `Square` and `Rectangle` shapes need four co-ordinates as data for the corners. Each of these shape classes will have different functionality while sharing a common interface.

Each class would have its own `draw()` function that can be invoked on a shape object by doing `cicle.draw()` or `rectangle.draw()` to get the right draw behavior for each type of shape. 

polymorphism makes applications more modular. It saves us from having to create functions like `drawRectangle()` and `drawCircle()` all in one class. It also saves us from having many conditional statements in one `draw()` function describing different behaviors per shape.

## Polymorphism with Vehicles

Another example is that of a `Vehicle` class with a `wheels`  property. A `Bicycle` class can inherit from the `Vehicle` class and override `wheels` to be 2. A `Car` class can inherit from the `Vehicle` class and override `wheels` to be 4. Each subclass is responsible for knowing how many wheels it has. The base class `Vehicle` does not know about how many wheels its sub-classes have.

The `Car` and `Bicycle` classes are both of type `Vehicle`, which means that we can add objects of both to an array/list of type `Vehicle`. Then, we can loop over this array/list and treat each object the same way by referencing it's `wheels` property. When we do reference each vehicle's `wheels` property, the `Vehicle` class will delegate that reference to it's corresponding sub-class. 

The code that will be executed will be determined by the actual sub-class of the object being referenced at runtime, whether it's a `Car` or a `Bicycle` object.


A real-world example of inheritance is a father and child relationship. The child inherits attributes from its father, such as height, eye color, and hair color, but at the same time that child has its own personality.

Inheritance lets one class adopt the properties of another class. The inheriting class is called a **sub-class** or a **child** class. The original class is called the **superclass** or the **parent** class. 

Depending on the programming language used, a keyword such as `extends` is used on a class, along with the parent class name, in order to make it become a sub-class of another class.

## An example of inheritance

Inheritance is all about the *relationship* between classes. An example of inheritance is `Manager` and `Clerk` classes that inherit from an `Employee` class. `Manager` and `Clerk` classes will have access to all of the `Employee` class properties, such as `firstName`, `lastName`, and `employeeNumber`. The child classes of the `Employee` class can then have their own properties and methods that are exclusive to either Managers or Clerks. For example, the `Manager` class may have a `numberOfEmployees` property.

## The benefits of inheritance

Inheritance helps with the *separation of concerns*. Each child class manages its own logic rather than expecting the parent class to handle the logic for all of its children. 

Inheritance also helps with code *reusability*. Multiple child classes can inherit the same attributes from their parent class without having to repeat them.


Abstraction is an object-oriented programming concept about hiding unnecessary details and only focusing on those details that are necessary. Abstraction helps to reduce the complexity of programming code.

A car is an example of abstraction. You start a car by pressing the start button. You don’t need to know how the engine actually starts. The inner workings of the car are completely hidden from the driver. A car is seen as a car, rather than a sum of parts and functionalities. 

We can use abstraction to abstract away the specifics of whether a car is automatic or manual, and just expose the essential functionalities of a car to the program.

## Abstract classes

Abstraction is also about generalization. With abstraction, we can take one definition of data and make it applicable to different, but somewhat related, types of data. An example is taking Car blueprints and making them applicable to both manual and automatic cars.

Abstraction can be achieved via abstract classes. An abstract class creates a contract for the classes that will implement it. Abstract classes are defined using the `abstract` keyword.

`Car` can be an abstract class, with methods such as `turnOff()`, `turnOn()`, `accelerate()`, `brake()`, `getCarType()`, etc. We can then implement this abstract class using classes such as `ManualCar` and `AutomaticCar`. Each of these classes will need all the functionality that the abstract `Car` class provides.

With abstract classes, the program only needs to know about the `Car` class and the functions that it provides. The internal implementation details of automatic or manual cars are kept hidden.

## Abstraction vs encapsulation

While they seem very similar, encapsulation is about information hiding while abstraction is about providing general features but hiding the implementation details.


The React `useCallback` hook is meant to be used for performance reasons. The React docs state that `useCallback` returns a memoized callback. What does this mean?

## Memoization

Memoization is like caching. It's a type of cache for the value that is returned from a function. 

How does memoization come into play with `useCallback`? Let's take a closer look. When you run a function for a second time using the same arguments as the first time, memoization will immediately return the result that it remembers from the first time that function ran. The function doesn't end up having to be run the second time, because it's been cached. This is where the performance benefit is found.

The memoization of `useCallback` is similar to storing the result of a function call into a variable and then using the variable rather than calling the function every time.

Our brains also do *memoization*. When someone asks you, "What's 2 plus 2?", you don't compute it, you already know the answer is 4. The same goes for `useCallback` and *memoization*.

## The function equality problem

Functions in JavaScript are actually objects. Take a look at the following example where a `sum()` function returns a function that sums two numbers.

```javascript
function sum() {
  return (a, b) => a + b;
}

const sumA = sum();
const sumB = sum();

sumA(1, 2); // 3
sumB(1, 2); // 3

sumA === sumB; // false
sumA === sumA; // true
```

`sumA` and `sumB` are both functions that sum two numbers. They were both created using the `sum()` function but they represent different function objects. That's why when we compare them using `sumA === sumB`, it evaluates to `false`.

Remember that in JavaScript, functions are objects, and an object is only equal to itself. This means that every time a React component re-renders, its functions are re-created as brand new functions. When re-created, these brand new functions re-run, even if we already know their result from the previous component render.

As we will see, `useCallback` allows us to tell React not to re-run a function every time a component re-renders.

## The problem useCallback solves

Take a look at this simple component.

```javascript
import { useCallback } from 'react';
function SimpleComponent() {

  const handleClick = () => {
    console.log('Clicked');
  };
}
```

Every time the above component re-renders, the `handleClick` function is re-created. It is a different function object every time that will re-run and output "Clicked" to the console.

The re-creation of functions on each component re-render is usually not a problem. Having a few inline functions per component is fine. However, in some cases, preventing the re-running of functions during component re-renderings is important for performance reasons.

The `useCallback` hook returns a memoized (or cached) instance of the function provided to it. This function instance will only change and re-run if one of the dependencies of the `useCallback` hook has changed. If not, it won't re-run between component re-renders. Instead of recreating a function object on every component re-render, `useCallback` allows us to use the same function object across component re-renders.

## How to use the useCallback hook

```javascript
useCallback(callbackFunction, [dependencies])
```

When the `dependencies` have the same values, the `useCallback` hook will return the same `callbackFunction` instance between re-renderings. When the dependencies change, the `useCallback` will 

```javascript
const startValue = 0;
const increment = useCallback(() => startValue + 1, [startValue])
```

In this example, the `useCallback` hook has memoized/cached the function `() => startValue + 1`. It will remember this function until the value of the dependency `startValue` changes. When `starValue` changes, then a new function instance will be created.





https://www.robinwieruch.de/react-usecallback-hook/









import { useCallback } from 'react';
function MyComponent() {
  // handleClick is the same function object
  const handleClick = useCallback(() => {
    console.log('Clicked!');
  }, []);
  // ...
}
handleClick variable has always the same callback function object between renderings of MyComponent.

## When to use the useCallback hook



/////////////////////
● However, parent components can end up
having child components that get
re-rendered again and again unnecessarily









## Why do we need useCallback?

The reason we sometimes need to use `useCallback` is because in React, components render and re-render.

This means that if we have a function in our component, when that component re-renders, the result of that function is lost. We will need to re-run the function to get its result, unless we cache it for the next render.

So if you have created a function or a variable in your component, the second it gets rerendered all the values will be lost unless you persist it into the next render, which is exactly what react state does.

useMemo and useCallback both use this so that the results and functions you pass them do not constantly get called again and again.




If you need a function to persist between renders then you would need useCallback so it remembers that instance of the function. You can think of this a bit like creating a function outside the scope of your react component, so the function persists even when your code is rerendered.

When I say computationally expensive, all it really means is anything that is going to be resource heavy and take a lot of time or space to run.

For example a nested loop (O(n²) in Big O notation) over a moderate to large array might be something that you would consider to be “computationally expensive”.



Receives a function as a parameter, and an array of dependencies (similar to useEffect).
useCallback return a memoized version of the callback function.
it returns a cached version of a function.
It receives an inline callback function and an array of dependencies.

It will return a memoized version of the callback that only changes if one of the dependencies has changed

accept a function and an array of dependencies.






## dependencies

The idea is that you provide the array with values/variables that you want to use inside the function that you also provide to the hook.

export default function MyReactComponent({ myNumber }) {
  useEffect(() => {
    // I will be run every time myNumber changes
    console.log(myNumber)
  }, [myNumber])

  const calculation = useMemo(() => {
    // I will also be run every time myNumber changes
    return myNumber * 2
  }, [myNumber])

  const calculate = useCallback(() => {
    // I will also be run every time myNumber changes
    return myNumber * 2
  }, [myNumber])

  return <div />
}
If “myNumber” changes then the functions will be run again with the new value.

This ensures that you will always have up to date values in your code when you use these hooks so you don’t need to worry about stale (old values) variables whenever the hook gets run again.



## Should I use useCallback for all functions?
● This hook has to compare the dependencies from the dependency array for every re-render to
decide whether it should re-define the function.
● The computation for this comparison can be more expensive than just re-defining the function.
● useCallback() can increase code complexity.
● Use it only where it actually improves performance.
● Note: the useCallback() hook is still called every time a component re-renders.
○ It just returns the same cached function reference.


## Conclusion

, useMemo and useCallback, are probably one of the biggest causes of confusion when you come across them compared to any other hook.

Re-rendering lists of items, which can grow to be very large, can create
performance issues.
● Re-renderings of this lightweight component won't create performance issues.


Every line of code which is executed comes with a cost.
do not use `useCallback` everywhere
can cause perf prob.

the useCallback version is doing more work. Not only do we have to define the function, but we also have to define an array ([]) and call the React.useCallback which itself is setting properties/running through logical expressions etc.

So in both cases JavaScript must allocate memory for the function definition on every render and depending on how useCallback is implemented, you may get more allocation for function definitions (this is actually not the case, but the point still stands). 



Performance optimizations are not free. They ALWAYS come with a cost but do NOT always come with a benefit to offset that cost.

Therefore, optimize responsibly.






MOST OF THE TIME YOU SHOULD NOT BOTHER OPTIMIZING UNNECESSARY RERENDERS. React is VERY fast and there are so many things I can think of for you to do with your time that would be better than optimizing things like this. 


Encapsulation is like a protective shield that prevents the data from being accessed by any code outside that shield.

Encapsulation is also known as data-hiding. We can implement encapsulation by declaring the variables in a class as private and using public methods to set and get the values of these variables.

We can also use encapsulation to hide the internal implementation of the different methods involved in an operation. An example of this is a `Car` class that has private methods such as `applyBrakePads()` and `changePistonSpeed()` which are used by public methods such as `brake()` and `accelerate()`.

## The benefits of encapsulation

Encapsulation minimizes a code block's dependencies to code outside of that block in order to reduce the likelihood of unexpected changes when the dependencies change. When code is hidden and self-contained, we can easily change it without breaking other parts of the application that made use of it or depended on it.

## An example of encapsulation

An example of encapsulation is a section of code that is responsible for fetching data from a database or API. Encapsulation can be implemented to hide the internal details of this code and make it reusable with various types of databases or APIs.



When creating services to be used with Angular's *Dependency Injection* system, a provider is needed for each service. 

## Providers in AppModule

By adding services as `providers` in the `AppModule`, the build tools and compilers are unable to know
if that code is actually used in the application. They will always make these services available throughout the application even if they are never used. These services will not be able to take advantage of *tree-shaking*. More on *tree-shaking* down below.

```javascript
@NgModule({
  declarations: [
    AppComponent,
  ],
  imports: [],
  providers: [
    UserService,
    PostService,
    CategoryService, 
  ],
  bootstrap: [AppComponent]
})
export class AppModule { }
```

Rather than adding all of your services into the `providers` array of `AppModule`, as seen above, Angular recommends setting the `providedIn` property of a service's `@Injectable()` decorator. This will make such services *tree-shakable*. The service will still need to be injected where it is used.

## Root application injector

```javascript
import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root',
})
export class UserService { } 
```

By using `root`, we specify that Angular should provide the `UserService` in the root injector. It will be available throughout the application. We've just created a *singleton* service, which is a service for which only one instance exists in an application. 

When using `providedIn` on services, they will only be bundled in the application if they get used. These are called *tree-shakable providers*.

## What is tree-shaking?

Tree shaking is a build process operation that helps with removing unused code from a code base. It's like shaking a a tree and having the dead leaves fall off the tree. Tree shaking only includes the code that is needed for the app to run.

## Feature modules

We can also specify that a service should be provided in a particular `@NgModule`. If we don't want `UserService` to be available unless a `UserModule` is imported, then we can specify that the service should be provided only in the module.

```javascript
import { Injectable } from '@angular/core';
import { UserModule } from './user.module';

@Injectable({
  providedIn: UserModule,
})
export class UserService { }
```

This is the recommended way to provide a service in a feature module. This method enables tree-shaking of the service if nothing ends up injecting it. 



Laravel uses Eloquent, an object-relational mapper (ORM) that makes it very easy to interact with the database to determine if a record exists.

## Using first()

If you need to use the object if it exists and is returned by the database query, you can use `first()`.

```php
$user = User::where('email', $request->email)->first();
if ($user === null) {
  // user does not exist
}
```

## Using count()

If you don't need to use the object, and only need to check if such a record exists in the database, you can use `count()`.

```php
if (User::where('email', $request->email)->count() > 0) {
  // user exists
}
```

## Using exists()

There is also an `exists()` function that can be used to further simplify the query.

```php
if (User::where('email', $request->email)->exists()) {
  // user exists
}
```


I was attempting to install [Storybook](https://storybook.js.org/docs/angular/) on an Angular 9 application and kept getting the following error when running the `build-storybook` command-line utility: `92% chunk asset optimization TerserPlugin previousExtractedCommentsSource.replace is not a function`.

I tried upgrading the Angular application from Angular 9 to Angular 11 but I noticed that the `build-storybook` error was still occuring on Angular 11.

When I had first used `npx sb init` to install Storybook, I got the following version installed in the `package.json` file of my Angular application. I was not able to get `build-storybook` to work with this version.

```json
"@storybook/angular": "^6.2.9",
```

I then decided to try upgrading my Storybook installation with the latest pre-release version of Storybook by using `npx sb upgrade --prerelease`. This gave me the following version.

```json
"@storybook/angular": "^6.3.0-beta.14",
```

I'm now able to run `build-storybook` from the command-line of the Angular 9 app successfully with this prerelease version of Storybook. I hope this can help anyone else struggling with the same error.



In this post, we'll look at quick and easy ways to remove duplicates in JavaScript from:

- arrays
- arrays of objects

## Removing duplicates from arrays

### Using Set

```javascript
const brands = ['Wilson', 'Babolat', 'Wilson'];

console.log([...new Set(brands)]);
// ["Wilson", "Babolat"] 
```

### Using Filter

```javascript
const brands = ['Wilson', 'Babolat', 'Wilson'];

const filtered = brands.filter((item, index) => brands.indexOf(item) === index);

console.log(filtered);
// ["Wilson", "Babolat"] 
```

The `filter` method will create a new array of elements that meet the boolean condition that we provide to it. If the condition for an element returns true, it will be included in the filtered array. If the condition for an element returns false, it will not be in the filtered array.

The `indexOf` method finds the first index position of the `item`. If the array contains duplicates for an item, the first index position returned by `indexOf` will not match the current (duplicate) item's index position.

We can also get back the duplicates from the array if we need them by switching the condition on `indexOf` to an inequality one rather than an equality one.

```javascript
const brands = ['Wilson', 'Babolat', 'Wilson'];

const filtered = brands.filter((item, index) => brands.indexOf(item) !== index);

console.log(filtered);
// ["Wilson"] 
```

### Using Reduce

The `reduce` function might be one of the hardest to understand in JavaScript. 

`reduce` applies a reducer function to the elments of the array. The `reduce` function's first two parameters are a function and an initial value. The reducer function is called on each element of the array with the `accumulator` as the first parameter. The accumulator starts with the initial value. The return value of each reducer function call becomes the new accumulator.

```javascript
const brands = ['Wilson', 'Babolat', 'Wilson'];

const result = brands.reduce((accumulator, current) => {
  if (accumulator.includes(current)) {
    return accumulator;
  } 
  return [...accumulator, current];
}, []);

console.log(result);
// ["Wilson", "Babolat"] 
```

The initial value for `reduce()` is an empty array `[]`. This is the initial value of the `accumulator`. If the accumulator does not contain the current item, then the current item gets returned along with any items in the accumulator as a new array. If the accumulator already contains the current item, then only the accumulator is returned for the next iteration of the `reduce` function. 

Here is a look at the values of the accumulator during the `reduce()` operation on the brands array.

```javascript
[LOG]: [] 
[LOG]: ["Wilson"] 
[LOG]: ["Wilson", "Babolat"] 
```

## Removing duplicates from arrays of objects

Removing duplicate objects from an array of objects is a bit more complex. 

### Set and filter

We can use a `Set` and the array `filter` method to remove duplicate objects from an array of objects.

```javascript
const brands = [
  { name: 'Wilson' },
  { name: 'Babolat' },  
  { name: 'Wilson' },
];

// a Set to track seen brands
const seen = new Set();

const filtered = brands.filter(brand => {
  // check if the current brand is a duplicate
  const isDuplicate: boolean = seen.has(brand.name);
  // add the current brand to the Set
  seen.add(brand.name);
  // filter() returns the brand when isDuplicate is false
  return !isDuplicate;
});

console.log(filtered);
// [{ "name": "Wilson" }, { "name": "Babolat" }] 
```

### Map

We can also use the JavaScript `Map` object to remove duplicates from an array of objects. `Map` holds key-value pairs and remembers the original order that keys were inserted. `Map` is similar to an `Object`, but the difference is that `Map` allows keys of any type, not just strings.

```javascript
const myMap = new Map();

myMap.set(1, 'foo');
myMap.set(1, 'bar');

console.log(map1.get(1)); 
// bar
```

As we can see from the example above, keys must be unique. The `bar` value replaces `foo` because `Map` can only hold one pair with the key `1`.

Now, let's use `Map` to help us remove duplicates from an array of objects.

```javascript
const brands = [
  { name: 'Wilson' },
  { name: 'Babolat' },  
  { name: 'Wilson' },
];

// brand name is the key for the Map
const map = new Map(brands.map(brand => [brand.name, brand]));
// put unique brand objects in an array
const uniques = [....map.values()];

console.log(uniques);
// [{ "name": "Wilson" }, { "name": "Babolat" }] 
```


Here is how object destructuring is done in JavaScript.

```javascript
const player = {
  firstName: 'Roger',
  lastName: 'Federer',
  age: 36,
};

const { firstName, lastName } = player;

console.log(firstName); // Roger
console.log(lastName); // Federer
```

What about if we want to apply types to this for use in TypeScript? 

```javascript
const { firstName, lastName }: { firstName: string; lastName: string } = player;

console.log(firstName); // Roger
console.log(lastName); // Federer
```

We can shorten and simplify this by creating a `type` or `interface` for what we are destructuring, which are the `firstName` and `lastName` in this case.

```javascript
const player = {
  firstName: 'Roger',
  lastName: 'Federer',
  age: 36,
};

interface PlayerName {
  firstName: string;
  lastName: string;
}

const { firstName, lastName }: PlayerName = player;

console.log(firstName); // Roger
console.log(lastName); // Federer
```



If you'd like to run only one test file with Jest to see the result of that file's tests, here is how you can do that.

Make sure your `package.json` file contains the following.

```json
"scripts": {
  "test": "jest --runInBand --forceExit",
}
```

Then, run the following command.

```bash
npm test -- user.service.spec.ts
```

The `--` marks the end of options. Anything entered after the `--` is passed to the command being run, which is `jest` in this case. Thus, the file `user.service.spec.ts` is passed to the `jest` command to run that file's tests.



The traditional way to delete an object property from a JavaScript object is to use the `delete` command, as seen below.

```javascript
const driver = {
  name: 'Mario',
  color: 'red',
  kart: 'bike',
};

delete driver.color;
```

If we try to `console.log(driver);` after the `delete` command, the result is:

```javascript
{
  kart: "bike",
  name: "Mario"
}
```

Given the `driver` object, we can also delete the `color` property from this object using the following. The result is the same.

```javascript
delete driver['color'];
```

# The Immutable Way

The `delete` command *mutates* or changes the initial object. This is not the best approach when it comes to *functional programming* in JavaScript.

**Immutability** is an important design pattern of *functional programming*. Immutability states that something cannot be modified after it is instantiated. If the value of something needs to change, it should be re-created with the new value.

We can remove a property from an object in an *immutable* way by creating a completely new object that contains copies of all the properties from the old object, except the one property that we want to remove. 

```javascript
const driver = {
  name: 'Mario',
  color: 'red',
  kart: 'bike',
};

const propertyToRemove = 'color';

const newDriver = Object.keys(driver).reduce((newObject, currentKey) => {
  if (currentKey !== propertyToRemove) {
    newObject[currentKey] = driver[currentKey];
  }
  return newObject;
}, {});

console.log(newDriver);
```

By using `reduce` on the result of `Object.keys(driver)`, we are iterating over all the keys of our `driver` object. As long as the current `key` of the iteration is not equal to `color`, that property is copied to a new object, called `newObject`. The object returned will not have the property that contains the key that we want to remove, which is `color`.

```javascript
{
  kart: "bike",
  name: "Mario"
}
```

As you can see, the result is the same as the result we obtained earlier with `delete driver.color`. However, we have now enforced the principle of *immutability*, since the `driver` object is no longer directly modified after being instantiated.

If you are using *React* or *Angular*, the *immutable* way is the proper way to remove a property from an object in a component's state, or in *Redux* or *ngRx* state.

By applying the *immutability* design pattern, we now have programming code that follows the functional programming paradigm more closely.



The **nullish coalescing** operator `??` is a logical operator that allows you to fall back to a default value when dealing with `null` or `undefined`. It returns the right-hand side operand when the left-hand side operand is `null` or `undefined`. Otherwise, it returns the left-hand side operand.

The **nullish coalescing** operator `??` is available in TypeScript as of version 3.7.

## Nullish coalescing example

```javascript
const value = user.value ?? 0;
```

This expression is equivalent to:

```javascript
const value = user.value !== null && user.value !== undefined ? user.value : 0;
```

## When using a default value

The **nullish coalescing** `??` operator is recommended over `||` when using a default value. Consider the following example.

```javascript
const value = user.value || 0.5;
```

When `user.value` is set to `0`, the value from this expression will be `0.5`, which may not be intended. `??` avoids some unintended behavior with `||` where `0`, `NaN` and `""` are treated as falsy values.



The **optional chaining** operator `?.` is for optional property access. Optional chaining allows us to write code that will immediately stop running some expressions if a `null` or `undefined` is found.

The **optional chaining** operator `?.` is available in TypeScript as of version 3.7.

## Cannot read property of undefined

Consider the following example demonstrating object property access on an `undefined` object.

```javascript
let user;
const name = user.firstName;
```

This code will throw a JavaScript error that will say *"Cannot read property 'firstName' of undefined."* Since `user` is `undefined`, no properties can be accessed from the `user` object. The **optional chaining** operator helps us to avoid this error during object property access.

## Optional chaining to the rescue

Let's re-visit this same example, but this time with the **optional chaining** operator.

```javascript
const name = user?.firstName;
```

When `user` is defined, `user?.firstName` will be computed and `firstName` will be accessed from the `user` object. However, when `user` is `null` or `undefined`, the **optional chaining** operator will stop execution and just return `undefined` as the `name`.

```javascript
const user = undefined;
const name = user?.firstName;
console.log(name); // undefined

const user = { firstName: 'John', lastName: 'Smith' };
const name = user?.firstName;
console.log(name); // John
```

## How optional chaining works

Consider the following example to see the same line of code with and without the **optional chaining** operator to gain a better understanding of how it works.

```javascript
// with optional chaining
const name = user?.firstName;
// without optional chaining
const name = (user === null || user === undefined) ? undefined : user.firstName;
```

## Left side checks only

The **optional chaining** operator will only check if the value on the left of it is `null` or `undefined`. It will not check any properties to the right of it.

```javascript
const user = {};
const zip = user?.address.zip;
console.log(zip);
```

This code block throws an error saying *"Cannot read property 'zip' of undefined."* This is because there is no `address` property in the `user` object. Thus, it is `undefined` and a `zip` property cannot be accessed from `undefined`. The **optional chaining** operator only helped us with `null` and `undefined` checks on the `user` object appearing to the ***left*** of it.

## Nested object property access

The **optional chaining** operator can be used several nested levels deep.

```javascript
const user = {};
const zip = user?.address?.zip;
console.log(zip); // undefined
```

This example will not throw the error we saw in the previous example because we have added the **optional chaining** operator to the `address` property. If `address` is found to be `null` or `undefined`, then `undefined` is returned without throwing an error.



If you're looking for a *dictionary* data structure in JavaScript, you can use the `Map` object. It was introduced in ECMAScript 6. It is very similar to the implementation of a dictionary data structure that you would find in other programming languages.

## Getting a value from a Map

A `Map` doesn't contain any keys upon creation. It will only contain what we explicitly put into it using the `set` function.

```javascript
const dictionary = new Map();
dictionary.set("Apple", "A fruit and a brand.");

console.log(dictionary.get("Apple")); // outputs "A fruit and a brand."
```

## Map size

The number of items in a Map can be retrieved from its `size` property.

```javascript
console.log(dictionary.size); // 1
```

## Map entry checking

We can check if a `Map` contains a key using the `has` function.

```javascript
console.log(dictionary.has("Apple")); // true
```

## Deleting from a Map

We can delete an entry from a `Map` using the `delete` function.

```javascript
dictionary.delete("Apple")
console.log(dictionary.size); // 0
```

## Adding objects and arrays to a Map

We can add objects or arrays to a `Map` entry.

```javascript
dictionary.set('Mario', { color: "Red", sibling: "Luigi" });
console.log(dictionary.get("Mario")); // { color: "Red", sibling: "Luigi" }

dictionary.set('Toad', ['Rainbow Road', 'Shy Guy Falls', 'Yoshi Circuit']);
console.log(dictionary.get("Toad")); // ['Rainbow Road', 'Shy Guy Falls', 'Yoshi Circuit']
```

## Map versus regular objects

A `Map` is a JavaScript object with special properties. It tends to perform better in situations that involve the frequent addition and deletion of key-value pairs. Regular objects are not optimized for this.

### Map keys versus object keys

One of the `Map` object's special properties is that the keys of a `Map` can be any type of value, including functions and objects. This is unlike regular objects in JavaScript which cannot have any object as a key. Regular objects can only have string, number, or symbol keys.

```javascript
const driver = { name: "Luigi", color: "Green" };
const kart = { type: "Sport Bike", tires: "Sport" };

const dictionary = new Map();
dictionary.set(driver, "1st place");
dictionary.set(kart, "No damage");

console.log(dictionary.get(driver)); // 1st place
console.log(dictionary.get(kart)); // No damage
console.log(dictionary.get({})); // undefined
```

The last output will return undefined because the empty object `{}` does not reference the `driver` or `kart` object keys that are in the `Map`.

### Map iteration versus object iteration

A `Map` is directly iterable. The `Map` object will iterate entries, keys, and values in the order that they were entered. The items in the `Map` will be output in the order that they were inserted.

```javascript
const dictionary = new Map();
dictionary.set("Yoshi", "2nd Place");
dictionary.set("Toad", "3rd Place");
dictionary.set("Luigi", "1st Place");

dictionary.forEach((value, key) => {
  console.log(`${key}: ${value}`);
});

// Yoshi: 2nd Place
// Toad: 3rd Place
// Luigi: 1st Place
```

You can also iterate over the `Map` using a `for...of` loop to get the same output.

```javascript
for (let [key, value] of dictionary) {
 console.log(`${key}: ${value}`);
}
```

Regular JavaScript objects do not implement an iteration protocol. Therefore, they are not directly iterable using the `forEach` or the `for...of` loops. You could use `Object.keys()`, `Object.values()`, or `Object.entries()` to iterate over a regular object's keys, values, or entries. However, the object itself is not directly iterable like the `Map` is.

## Keys and values of a Map

Just as with regular objects, you can also get the `keys` and `values` of a `Map`.

```javascript
const dictionary = new Map();
dictionary.set("Yoshi", "2nd");
dictionary.set("Toad", "3rd");
dictionary.set("Luigi", "1st");

for (let key of dictionary.keys()) {
	console.log(key); // Yoshi, Toad, Luigi
}

for (let value of dictionary.values()){
	console.log(value); // 2nd, 3rd, 1st
}
```

## Conclusion

You can now confidently use the `Map` object and data structure in JavaScript. If you are using a regular object for the frequent addition and deletion of key-value pairs, you will get better performance by converting that object into a `Map`.



JavaScript allows developers to mix between object-oriented, procedural, and functional programming paradigms. The growing trend lately has been toward functional programming. In JavaScript frameworks such as Angular and React, using functional programming can even result in performance improvements.

Functional programming is about programming with very small and reusable pure functions.

## Pure functions

Just because a program contains functions, it does not mean that the program uses functional programming. Functional programming is based on the concepts of pure and impure functions. Functional programming encourages you to write pure functions. 

Pure functions are functions that accept an input and return a value, without producing any side-effects. No side-effects means that the function does not modify any data outside of its scope. A pure function must return a value. The return value of a pure function must depend on the arguments that are passed to the parameters of the function.

## Properties of pure functions

A pure function must satisfy the following properties to be considered pure:

- **Idempotence:** Given the same inputs, a pure function will always return the same value, regardless of how many times the function is called. This means that a pure function does not depend on any external state that can be mutated during execution.

- **Side-effect free:** A pure function cannot cause any side-effects. Side effects may include I/O (writing to the console or to a log file), modifying a mutable object, reassigning a variable, etc. Pure functions do not mutate any shared state or function arguments. Pure function calls don't result in any observable output, don't throw exceptions, and don't trigger events. They just return a value.

Pure functions are not very likely to cause bugs in other unrelated parts of a program because they do not operate on a shared state, not do they produce side-effects.

If a function is using `void` (it has no return value), it is an impure function. If a function has no return value, then either it's not doing any operations or it's causing some side-effect, and thus, is an impure function. If a function is called but its return value is not used, it may be relied on to do some side-effect, making it an impure function.

## Examples

```javascript
function impure(arg) {
  myObject.key = 90;
  return arg * myObject.key;
}
```

The above function is not a pure function because it modified the state of `myObject.key` outside of its scope.

```javascript
function impure(arg) {
  let f = arg * myObject.key;
}
```

Though it didn’t modify any external state, the above function is also not a pure function because it did not return a value.

```javascript
function impure(arg) {
  return myObject.key * 3;
}
```

Though it didn’t affect any external state of `myObject.key`, the above function is impure because the returned value is not dependent on the input `arg`. Not only must pure function return a value but that returned value must depend on the input.

```javascript
function pure(arg) {
  return arg * 4;
}
```

The above function is a pure function. It returned an output based on the input and did not create side-effects on any any external state.

## Benefits of pure functions

- They are easier to work with and debug because they don't depend on a mutable external state.
- The return value can be *cached* or *memoized* to avoid recomputing it in the future.
- They make it easier to write *unit tests* because there's no dependencies that need to be mocked (such as for logging, database transactions, API calls, etc).
- Replacing procedural loops with pure functions increases code readability.

## Encapsulation

Pure functions provide the same benefits that **encapsulation** does in **Object-Oriented Programming**. Encapsulation is about data-hiding. It's about minimizing connections with outside code to reduce the likelihood of unexpected changes. What can be hidden and self-contained, can be easily changed.

Pure functions follow the encapsulation principles of: 

- Being independent from outside code.
- Allowing the function implementation to change without impacting the rest of the program.
- Allowing the code to be easily moved between files, modules, projects, etc.
- Having a self-documenting public interface (the function signature).
 
## Conclusion

Complex programs usually need to produce an output. Therefore, they cannot be built with only pure functions. However, it is a good programming practice to make functions pure whenever possible. Adhering to functional programming principles can help to achieve this.

Functional programming may require a learning curve if you are coming from an Object-Oriented Programming background. You would need to look out for cases where objects get mutated, where state is shared, where logic extends beyond the function scope, and where side-effects are caused by function calls.



When speaking about functions in programming, it is common to confuse the terms `parameters` and `arguments`. What does each term refer to and which one should you use? Let's find out.

- Function parameters are the names that are listed in a function's definition.
- Function arguments are the real values that get passed to the function.

Parameters are initialized to the values of the arguments supplied. Parameter variables are used to import arguments into functions.

## Example of parameters and arguments

Let's use JavaScript to create a simple example that will help to better understand the difference between parameters and arguments.

```javascript
function divide(numerator, denominator) {
  return denominator > 0 ? numerator / denominator : 0;
}

console.log(divide(10, 5)); // 2
```

The parameters of this function are `numerator` and `denominator` seen in the function definition of `function divide(numerator, denominator)`. The arguments are the values of `10` and `5` that get passed to the function in the function call of `divide(10, 5)`.



When building a React application, iterating over data to display it is a common need. When we know what our data items will be in advance, we can easily hard-code them directly into the HTML like in the example below.

```javascript
export class MyList extends React.Component {
  render() {
    return (
      <ul>
        <li>Mario</li>
        <li>Luigi</li>
        <li>Bowser</li>
      </ul>
    );
  }
}
```

However, when we are dealing with dynamic data, we don't know in advance what the value of our data items will be and so we cannot hard-code them. This dynamic data could be returned from an API that we are fetching from. Let's look at two approaches for iterating over and rendering dynamic data.

## 1. Iterate and render in the return statement

When dealing with dynamic data, the first approach is to use the JavaScript `map` method to render the data items directly in the return statement of the *render* function.

```javascript
export class MyList extends React.Component {
  render() {
    const usernames = ['Mario', 'Luigi', 'Bowser']; // let's mock data from an API
    
    return (
      <ul>
        {usernames.map(username => {
          return <li key={username}>{username}</li>
        })}
      </ul>
    );
  }
}
```

>  Use the *key* attribute to ensure that each looped element is uniquely identified. This helps React to identify which items have changed in the list. Always add keys when rendering items in an iterable list. A key should [uniquely identify a list item](https://reactjs.org/docs/lists-and-keys.html) from other list items.

## 2. Iterate and render an array of JSX elements

When dealing with dynamic data, the better approach is to loop over that data to add *JSX* elements to an array that can then be rendered separately. The first approach that we saw above is fine for a simple component. However, as components grow in size, it's best to keep return statements as simple as possible.

```javascript
export class MyList extends React.Component {
  render() {
    const usernames = ['Mario', 'Luigi', 'Bowser']; // let's mock data from an API
    const listItems = [];

    for (const username of usernames) {
      listItems.push(<li key={username}>{username}</li>)
    }

    return (
      <div>
        {listItems}
      </div>
    );
  }
}
```

With the looping code that builds the *listItems* now out of the *return* statement, we can easily extract this logic to a separate file that can be re-used across multiple components.

## Conclusion

The two strategies we covered in this article will help you iterate and render data in React. Go forward iterating and rendering in React with confidence!



JavaScript array and object destructuring allows us to break up arrays and objects into their individual pieces. Arrays and objects are the two most used data structures in JavaScript. Therefore, it will be very useful to know how to destructure them.

JavaScript objects make it easy for us to create a single entity that stores our data by key. JavaScript arrays help us to gather data into an ordered collection. The destructuring assignment syntax is useful for *unpacking* arrays or objects into the variables that we need from them. 

## Array Destructuring

Here is an example of a function that destructures an array into variables.

```javascript
function printName(fullName) {
  const [firstName, lastName] = fullName;
  console.log(firstName); // John
  console.log(lastName);  // Smith
}

printName(['John', 'Smith']);
```

The destructuring assignment does not modify the original array. It just copies the array items into variables. It provides us with a quicker way of writing the following:

```javascript
function printName(fullName) {
  const firstName = fullName[0];
  const lastName = fullName[1];
}

printName(['John', 'Smith']);
```

### Skipping over elements 

We can skip over elements that are not needed during destructuring.

```javascript
const [firstName, , title] = ["John", "Smith", "President"];

console.log(firstName); // John
console.log(title); // President
```

### Object properties on the left side

We can use object properties for the left-hand side of the destructuring syntax.

```javascript
const person = {};
[person.firstName, person.lastName] = "John Smith".split(' ');
console.log(person.firstName); // John
console.log(person.lastName); // Smith
```

The `split` function broke up our string wherever a space was found. Since there was a space between *John* and *Smith&*, the string was broken up into an array of two elements containing *John* and *Smith*.

### Array Destructuring with Sets

Array destructuring also works with JavaScript sets.

```javascript
const [firstName, middleName, lastName] = new Set(['John', 'James', 'Smith']);
console.log(firstName); // John
console.log(middleName); // James
console.log(lastName); // Smith
```

### Array Destructuring with the spread operator

We can use JavaScript spread syntax to get the remaining values of an array while destructuring.

```javascript
const [firstName, middleName, ...data] = ['John', 'James', 'Smith', 'President'];

console.log(firstName); // John
console.log(middleName); // CaJamesesar
console.log(data[0]); // Smith
console.log(data[1]); // President
console.log(Array.isArray(data)); // true
console.log(data.length); // 2
```

### Array Destructuring with default values

We can set a default value for any missing elements during destructuring.

```javascript
const [firstName, lastName, title = 'No Title'] = ['John', 'Smith'];
console.log(firstName); // John
console.log(lastName); // Smith
console.log(title); // No Title
```

## Object Destructuring

The destructuring assignment also works with objects. On the right side will be an existing object and on the left side will be the properties that we want to extract from it.

```javascript
const car = {
  brand: 'Ford',
  model: 'Mustang',
  year: 1967
};

const { brand, model, year } = car;

console.log(brand); // Ford
console.log(model); // Mustang
console.log(year); // 1967
```

### Object Destructuring with default values

We can also set default values while destructuring objects. It's similar to what we did while destructuring arrays.

```javascript
const car = {
  brand: 'Ford',
  model: 'Mustang',
};

const { brand, model, year = 1995 } = car;

console.log(brand); // Ford
console.log(model); // Mustang
console.log(year); // 1995
```

If we have a complex object, we can destructure it into only the specific property that we need from the object.

```javascript
const car = {
  brand: 'Ford',
  model: 'Mustang',
  color: 'Red',
  year: 1999,
};

const { brand } = car;

console.log(brand); // Ford
```

The default values can also be function calls. This also works for destructuring arrays.

```javascript
const car = {
  brand: 'Ford',
};

let { brand = prompt("Enter Brand:"), model = prompt("Enter Model:") } = car;

console.log(brand); // Ford
console.log(model); // (Whatever the user enters in the model prompt)
```

### Customizing destructured names

If we want to assign a property to a variable with a name other than the name of the object property, we can set a new name with the colon operator.

```javascript
const car = {
  brand: 'Chevrolet',
  model: 'Corvette',
  year: 1967
};

const { brand: b, model: m, year } = car;

console.log(b); // Chevrolet
console.log(m); // Corvette
console.log(year); // 1967
```

The colon tells us what value goes where. For example, it allows the value for the variable `brand` to go into variable `b`.

### Object Destructuring with the spread operator

If an object has more properties than we need variables, then we can assign the *rest* of the properties using the spread syntax. This is similar to what we did while destructuring arrays.

```javascript
const options = {
  brand: 'Ferrari',
  model: 'Testarossa',
  year: 1984
};

const { brand, ...data } = options;

console.log(brand); // Ferrari
console.log(data.model);  // Testarossa
console.log(data.year);   // 1984
```

### Abbreviated Destructuring

We can shorten the destructuring assignment syntax by not using `let` on the left-hand side and wrapping the expression in round brackets.

```javascript
({ brand, model } = { brand: 'Ford', model: 'Mustang' });

console.log(brand); // Ford
console.log(model); // Mustang

model = 'Taurus';
console.log(model); // Taurus
```

Notice that `brand` and `model` will not be read-only references like we get with `const`.

## Nested Destructuring

In this last example, the `car` object is comprised of other nested objects and arrays. We can use more complex left-side destructuring patterns to extract the deeper properties of the `car` object that we need.

```javascript
const car = {
  type: {
    brand: 'Ford',
    model: 'Mustang',
    year: 1990,
  },
  attributes: {
    doors: 2,
    horsepower: 400,
  }
  features: ['Sunroof', 'Mags'],
  sold: true,
};

const {
  type: {
    brand,
    model,
  }, // get only the needed properties
  features: [featureOne, featureTwo], // assign features individually
  owner = 'John Smith' // not present in car (set a default value)
} = car;

console.log(brand);  // Ford
console.log(model);  // Mustang
console.log(featureOne); // Sunroof
console.log(featureTwo);  // Mags
console.log(owner);  // John Smith
```


With the arrival of ES6 came the addition of `let` and `const`. These are useful for variable declaration. In this post, we'll see why they are different from `var`.

## Variable declaration with var

Before ES6 arrived, `var` declarations were the way to go in JavaScript. Variables declared with `var` can have problems. This is why ES6 introduced new ways to declare variables. It will help to know more about `var`, we'll get a better understand of why `let` and `const` were created to replace `var`.

### Var declarations

Variables declared with `var` can be re-declared and updated without an error. This can make `var` messy to work with. 

With `var`, we can redeclare a variable by repeating the `var` keyword right before it. No error will be thrown.

```javascript
var car = "Toyota";
var car = "Ford";
console.log(car); // Ford
```

We can also update the variable that we declared with `var`.

```javascript
var car = "Toyota";
car = "Ford";
console.log(car); // Ford
```

Variable re-declaration with `var` can be problematic. If we deliberately want to redefine a variable defined with `var`, this is not a problem. However, if we do not realize that a variable has already been defined with `var`, and we redefine it, we can get unexpected results when our code runs. Here is an example of this problematic scenario.

```javascript
var car = "Impreza WRX";
var horsepower = 350;

if (horsepower >= 350) {
  var car = "Corvette"; 
}

console.log(car) // Corvette
```

When we get to the `if` statement scope, we can forget that `car` was already previously defined with `var`. We can end up using the same variable name `car` with `var` in this scope. It will not throw an error, but instead quietly redefine our original `car` variable. While we may be expecting to see `Impreza WRX` as the output of the `console.log()` statement, we will actually get `Corvette` due to the accidental `var` re-declaration.

> When a `var` variable is declared outside of a function, its scope is global. The outer `car` and `horsepower` variables are globally-scoped since they exist outside of a function. 

### Var Hoisting 

JavaScript does something called hoisting. Hoisting is the behavior of moving variable and function declarations to the top of their current scope before execution. The current scope can be the top of a script or the top of a function. Declarations are *hoisted* to the top. `var` variables are hoisted to the top of their scope and are then initialized with an `undefined` value.

```javascript
console.log (car); // undefined
var car = "Porsche";
```

Hoisting actually causes these lines to be interpreted as:

```javascript
var car;
console.log(car); // undefined
car = "Porsche";
```

Variables that are defined with `let` and `const` solve the hoisting problem that exists with `var`. `let` and `const` variables are hoisted to the top of a code block, but they are not initialized. The code block knows about these variables but cannot use them until they are declared.

```javascript
car = "Acura"; // variable usage
let car; // variable declaration
```

In the example above, using a `let` variable above before it has been declared results in the following console error: `Uncaught ReferenceError: Cannot access 'car' before initialization`.

```javascript
car = "Nissan"; // variable usage
const car; // variable declaration
```

In the example above, using a `const` variable above before it has been declared results in a syntax error in the console that says `error: unknown: Unexpected token`. 

## Variable declaration with let

`let` is meant for variables that we want to re-assign a value to. We `let` that variable be re-assignable. There are some instances where this is helpful. Let's look at a simple case.

```javascript
let total = 0;

[{ total: 1}, { total: 2}].forEach(item => {
  total += item.total; // reassign a new value to 'total'
});

console.log(total); // 3
```

`let` variables can be re-assigned but they cannot be re-declared, which helps us to avoid the re-declaration issue that we encountered with `var`.

```javascript
let car = "Maserati";
car = "Lotus"; // this is fine
    
let car = "Mazda";
let car = "Hyundai"; // error: unknown: Identifier 'car' has already been declared
```

Since `let` is block-scoped, you can define the same variable name in different scopes and not encounter an error for doing so.

```javascript
let car = "Opel";
if (car) {
  let car = "Mitsubishi";
  console.log(car); // Mitsubishi
}
console.log(car); // Opel
```

There is no issue with this because both instances of `car` are seen as different variables because they have different scopes. 

## Variable declaration with const

`const` is meant for variables that will maintain a constant value. The value of a variable declared with `const` will not be allowed to change within its scope.

Every `const` variable declaration needs to be initialized at the time it is declared.

```javascript
const car; // error: unknown: Unexpected token
const car = "Car"; // this is fine
```

Variables declared with `const` cannot be updated or re-declared.

```javascript
const car = "Buick";
car = "BMW"; // error: Uncaught TypeError: Assignment to constant variable.

const car = "Mercedes";
const car = "Renault"; // error: unknown: Identifier 'car' has already been declared
```

Objects that are declared with `const` cannot be updated, but their properties can be updated.    

```javascript
const car = {
  brand: "Honda",
  model: "Civic",
  year: 2020
};

car = {
  horsepower: 200,
} // error: Uncaught TypeError: Assignment to constant variable.

car.horsepower = 300; // this is fine
```

We can add or update a property within a `const` object, such as `horsepower`, but we cannot update the `car` object itself.

## Conclusion

### var

- `var` variables can be updated and re-declared 
- `var` variables are automatically initialized with undefined. 
- `var` variables can be declared without being initialized. 
- Don't use `var`.

### let

- `let` variables can be updated but not re-declared
- `let` variables are not automatically initialized.
- `let` variables can be declared without being initialized.
- Use `let`if you want the variable to be reassignable.

### const 

- `const` variables cannot be updated or re-declared.
- `const` variables are not automatically initialized.
- `const` variables need to be initialized when declared.
- Use `const` whenever possible. It's added protection in your code since it guarantees that a value cannot be reassigned to it.



In JavaScript, we can use the *spread* operator combined with *short-circuit evaluation* to conditionally add keys to an object.

Let's say that we wanted to build a JavaScript object for querying based on some filtering parameters that don't always exist. We would usually write something like this.

```javascript
function buildQuery(filters) {
  const queryObject = {};

  if (filters.firstName) {
    queryObject.firstName = filters.firstName;
  }

  if (filters.lastName) {
    queryObject.lastName = filters.lastName;
  }

  if (filters.age) {
    queryObject.age = filters.age;
  }
  
  return queryObject;
}
```

The *spread* operator combined with *short-circuit evaluation* help us to simplify our `buildQuery` function.

```javascript
function buildQuery(filters) {
  return {
    ...filters.firstName && { firstName: filters.firstName },
    ...filters.lastName && { lastName: filters.lastName },
    ...filters.age && { age: filters.age },
  };
};
```

We could also write the `buildQuery` function using an *arrow function*.

```javascript
const buildQuery = query => ({
  ...filters.firstName && { firstName: filters.firstName },
  ...filters.lastName && { lastName: filters.lastName },
  ...filters.age && { age: filters.age },
});
```

This technique can also be used outside of a function. Let's say we wanted to conditionally gather **React** `props` into an object. We can achieve this quite easily using the *spread* operator combined with *short-circuit evaluation*.

```javascript
const filters = { 
  city: this.props.city, 
  ...this.props.cuisine && { cuisine: this.props.cuisine },
  ...this.props.category && { category: this.props.category },
};
```

This technique can help to simplify your **JavaScript** or **TypeScript** code for conditionally building and manipulating objects.



Let's say we have an array of objects in JavaScript and we would like to sum the values of similar keys. What would be a simple way to do that? Let's take a look.

```javascript
const kartRacers = [
  { name: 'Toad', score: 150 },
  { name: 'Mario', score: 100 },
  { name: 'Luigi', score: 50 },
  { name: 'Wario', score: 250 },
  { name: 'Mario', score: 50 },
];
```

## Using the JavaScript reduce function

Now that we've defined our array of Mario Kart racer objects, we can use the `reduce` function. JavaScript's `reduce` function
applies a reducer function that we give it, to each element of the array.

```javascript
const racerScores = kartRacers.reduce((acc, { name, score }) => {
  acc[name] = acc[name] || { name, score: 0 };
  acc[name].score += score;
  return acc;  
}, {});
```

The first reducer function parameter is a *callback* function. This is the function that we want to execute on each element of the array. The first parameter of our callback function is the `accumulator`. The second parameter is the `currentValue`. It is the current element that is being processed in an iterative manner from the array.

The second reducer function parameter is the *initialValue*. It is the value that we want to use as the `accumulator` for the first call of the callback function. If we supply no *initialValue*, the first element in the array will be used as the initial accumulator value and *currentValue* will skip it.

We will use the *initialValue* of the `reduce` function to set our `accumulator` to an empty object. 

```javascript
acc[name] = (acc[name]  || { name, score: 0 });
```

With the first line of the callback function, we will accumulate elements by the `name` key. 

For the first iteration of the callback function, `acc[name]` will be set to `{ name, score: 0 }`. 

```javascript
acc[name] = { name: 'Toad', score: 0 };
```

The same will happen for iterations two through four because the left side of the logical OR clause `||` will be `undefined`. Thus, the right side will be used.


For the fifth iteration of the callback function, `acc[name]` will be set to `acc[name]` because we have already iterated over an element with the name `'Mario'`.

```javascript
acc[name] = { name: 'Mario', score: 100 };
```

With the second line of the callback function, `acc[name].score += score`, we will sum the score of a `name` that we already iterated over with the *currentValue* of a new element with the same `name`.

The `reduce` function that executes our callback function will give us the following object structure containing a sum of Mario's scores. Mario's score is now `100 + 50`.

```javascript
{
  Toad: {
    name: "Toad",
    score: 150
  },
  Mario: {
    name: "Mario",
    score: 150
  },
  Luigi: {
    name: "Luigi",
    score: 50
  },
  Wario: {
    name: "Wario",
    score: 250
  }
}
```

## The result

We can then use `Object.values` to extract only the *value* portion from the nested objects.

```javascript
const result = Object.values(racerScores);
```

The result can be seen below. This gives us the original structure we started with, but with one `Mario` entry containing the sum of both scores present in the original array of objects.

```javascript
[
  { name: 'Toad', score: 150 },
  { name: 'Mario', score: 150 },
  { name: 'Luigi', score: 50 },
  { name: 'Wario', score: 250 },
];
```



In JavaScript, the spread syntax is an ellipsis of three dots `...` used to expand an iterable object into a list of its arguments. The spread syntax ***spreads*** array and objects into separate arguments.

The spread operator is quick and easy to use for adding items to arrays, combining arrays or objects, and spreading an array or object out. The spread operator was added to JavaScript in ES6 (ES2015), just like the rest parameters, which have the same syntax - an ellipsis of three dots.

## Spreading an array

Let's look at an example use case of the spread operator using the `Math.max()` function. This function expects separate numbers. Trying to pass an array to it will give us a `NaN` (not a number) error.

```typescript
Math.max(1, 3, 5); // 5
Math.max([1, 3, 5]); // NaN
```

Let's fix this `NaN` error by using the spread operator.

```typescript
Math.max(...[1, 3, 5]); // 5
```

The spread operator placed before the array has spread out our `[1, 3, 5]` array into separate values of `1`, `3`, and `5`.

## Copying an array

The spread operator makes it easy to copy an array.

```typescript
const brands = ['honda', 'audi', 'toyota', 'mazda'];
const brandsCopy = [...brands];

brands[0] = 'nissan'; // only element 0 of the brands array is changed
console.log(brands); // ['nissan', 'audi', 'toyota', 'mazda'] 
console.log(brandsCopy); // ['honda', 'audi', 'toyota', 'mazda'] 
```

## Combining an array

The spread operator makes it easy to combine or concatenate arrays.

```typescript
const brands = ['honda', 'toyota', 'nissan'];
const luxuryBrands = ['acura', 'lexus', 'infinity'];

console.log([...brands, ...luxuryBrands]); // ["honda", "toyota", "nissan", "acura", "lexus", "infinity"]
```

## Adding items to an array

The spread operator makes it easy to add items to an array.

```typescript
const techBrands = ['apple', 'microsoft', 'google'];
const allBrands = ['sony', 'samsung', ...techBrands];

console.log(allBrands) // ["sony", "samsung", "apple", "microsoft", "google"]
```

## Combining objects

The spread operator makes it easy to combine objects.

```typescript
const product = { name: 'apple', color: 'red' };
const cost = { price: 1.99, sale: 0.99 };
const item = { ...product, ...cost, quantity: 10 };

console.log(item); // {name: "apple", color: "red", price: 1.99, sale: 0.99, quantity: 10}
```



The rest parameters syntax provides an easy way to pass an indefinite number of arguments to a function as an array. Rest parameters syntax allows a function to be called with any number of arguments, no matter how it was defined. Rest parameters syntax was added in ES2015 or ES6.

Let's define a function that uses rest parameters.

```typescript
function sum(...values) { 
  let sum = 0; 
  for (let value of values) { 
    sum += value; 
  } 
  return sum; 
}

console.log(sum(1)); // result is 1
console.log(fun(1, 2)); // result is 3
console.log(fun(1, 2, 3)); // result is 6
```

## Rest parameters at the end

A function can have its first parameters as variables, and gather only the rest using the rest parameters syntax. The rest parameters must be the last entry in a function's parameters because they gather all remaining arguments.

```typescript
function getFullName(firstName, lastName, ...titles) {
  console.log(titles[0]); // CEO
  console.log(titles[1]); // CIO
  console.log(titles[2]); // COO
  console.log(titles[3]); // undefined
  console.log(titles.length); // 3

  return `${firstName} ${lastName} - ${titles.join(', ')}`;
}

const fullName = getFullName('John', 'Smith', 'CEO', 'CIO', 'COO');
console.log(fullName); // John Smith - CEO, CIO, COO
```



One of a developer's duties is to manage a project's technical debt. Technical debt, also known as tech debt, refers to the amount of technical work remaining on a project. 

## Quantifying tech debt

Technical debt is hard to quantify. Developers working on a codebase are able to identify the technical debt. They must figure out how to communicate this technical debt to management. Management will likely ask for an estimate of how long it will take to eliminate the technical debt. 

A codebase is never really technical debt-free. Every technical decision that's made comes with some sort of tech debt that gets created. Deadlines don't always coincide with the amount of time that is needed to complete a task. Thus, technical compromises must be made made along the way, leaving traces of tech debt.

## Short-term and Long-term solutions

There is a short-term solution and a long-term solution to every problem or feature request. There is a tradeoff that is made for every short-term solution. Short-term solutions have a limited lifespan. Developers must keep in mind that they will have to re-visit the short-term solution and modify it into a more long-term solution.

Some may consider short-term solutions to be the result of laziness or sloppy coding. While short-term solutions are what cause tech debt to accumulate, they are also what allow products and features to be released by their deadlines.

## Tech debt and product roadmaps

Tech debt does not show up on product roadmaps. Product roadmaps show stakeholders a timeline of the delivery of new user-related features. Managers don't exactly want their stakeholders to know about tech debt. Also, most managers don't like the idea of spending time on tech debt because, in their mind, it does not result in any new features for the end user. Good managers know the importance of addressing tech debt and will buy the developers time for it. 

## Accumulation of tech debt

The lack of planning for tech debt causes developers to try to address it as they are working on features. It's difficult to juggle between features and tech debt without delaying the feature. The typical result is that tech debt is put on the back burner while the feature is developed.  

Tech debt can accumulate to the point where the codebase becomes unmaintainable. Just like financial debt, tech debt must be dealt with before it gets out of hand. 

## Code hygiene

Every codebase needs good code hygiene. If we don’t go to the dentist for five years and then finally decide to go, we will probably be in for an unpleasant surprise. Tech debt is like tartar. Left unaddressed, it builds up like plaque and creates problems. Keeping on top of tech debt is like going to the dentist regularly. It means regularly going into the codebase to address issues with the time that is available. 

Good code hygiene can consist of:

### 1. Removing unused code

If a developer suspects that a block of code is not being used, they should verify this assumption and then delete it if their assumption is correct. Adding it as a to-do item for later will only create more tech debt. If you have the time to do it now, do it now. We should always aim for having the least amount of code possible within a codebase. Less code means there is less to go wrong with the application. It also meansfaster build times and faster deployments.

### 2. Refactoring/restructuring code

When is the best time to refactor code? As soon as you notice it needs refactoring! Bad code has a way of spreading throughout a codebase without notice. When new developers join the team, they will end up copying the bad code and the practices that come with that bad code. You will then have more tech debt than you had initially. If a new feature will be built off of existing code, be sure to account for the time needed for refactoring when you estimate that new feature.

### 3. Rewriting code

Re-writing something from scratch sounds painful, but sometimes it is necessary. When refactoring a code block is not working out well, it means that this code block needs to be re-written. 

Good code can last for years without needing to be re-written. Bad code should be re-written as soon as possible.

## Tech debt and features

Always try tying in good code hygiene practices to a new feature. This will allow tech debt to be addressed sooner rather than later and make for more robust feature deliveries. It will also provide everyone with more realistic estimates. More realistic estimates can get you the time that you need from management to spend on code hygiene.

## Conclusion

Technical debt is a part of every codebase. Everyone involved with a codebase, managers included, needs to better understand tech debt and how it impacts the product. With a better understanding of it, there are greater chances tech debt will be addressed sooner rather than later.

In every release, take the time to apply good code hygiene practices so that tech debt does not get out of hand. 

If you're working in an Agile environment, create tasks and/or stories that address tech debt. Come to an agreement with your team on how many tech debt tasks or stories should be taken during each sprint.


> "They should have spent more time dogfooding that app! It's so bad!" - Techies

The term "dogfooding" is slang in the world of Information Technology (I.T.) for a company using its own products to find and resolve bugs.

## History of dogfooding

The term originated from a popular 1976 TV spot for Alpo dog food, starring Lorne Greene. Lorne fed Alpo dog food to his own dog in the commercial. Since then, "dogfooding" or “eating your own dog food” was adopted as the term that refers to trying a product internally before it goes to market. It is a widely accepted practice of most organizations.

## First use of dogfooding

The first use of "dogfooding" was in 1988, when Microsoft executive Paul Maritz was desperately searching for users to test a new product. Paul e-mailed a colleague saying, “We are going to have to eat our own dogfood and test the product ourselves.” They then created an internal server called “dogfood” and sent the product out to staff.

## A recent example

A more recent example of "dogfooding" comes from the on-demand ride app, Lyft. They take their dogfooding efforts seriously. All corporate employees, including executives, are required to spend at least 4 hours as a Lyft driver every quarter. This puts them in the driver's seat and allows them to test out the Lyft app as if they were an actual user of it.

## Benefits of dogfooding

Teams that don't engage in "dogfooding" may end up building a product that they only think a user wants. The product can become a solution that was looking for a problem to solve rather than a solution to an actual user need. If a solution solves a real user need, employees should naturally want to use it. 

Dogfooding shows that a team or company is confident about its products. Dogfooding is a good opportunity to view your own product from the perspective of an end user, allowing you to validate that the user experience is exactly what you want it to be.


Tools like React, Angular, and Vue provide us with a component-based architecture. We can build complex user interfaces from smaller pieces called components which are easier to manage. If we design our components properly, we can take advantage of the benefits of components. One of those benefits is reusability.

When building components, they should be decoupled, focused on a single responsibility, and well-tested. This can be difficult when we hurry to meet deadlines.

We should avoid doing the following:
- building big components with many responsibilities
- building tightly coupled components
- building components with no unit tests. 

Avoiding these bad practices will help us reduce technical debt. Once technical debt accumulates, it makes it hard to modify existing functionalities or create new functionalities.

Good components should apply the following principles:

1. Single Responsibility
2. Loose Coupling
3. Encapsulation
4. Composition
5. Reusability
6. Testability
7. Categorization
8. Readability

## 1. Single Responsibility

The single-responsibility principle (SRP) is a programming principle that states that every module, class or function in an application should have responsibility over only a single part of that application's functionality.

For web components, this means that a component has a single responsibility when it implements one responsibility, or  when it does one thing. This gives the component only one reason to change.

Some examples of a component's responsibility could be to render a list of items, to make a HTTP request, or to draw a chart. A component should pick only one responsibility and implement it. When modifying the way a component implements its responsibility, it has only one reason to change. If the component's responsibility is to render a list of items, then it's one reason to change could be when the limit to the number of items rendered needs to change.

When a component has only one responsibility, it makes it easier to code, modify, reuse, and test. The size of the component is reduced and the component is given a laser focus.

Components with many responsibilities should be split by individual responsibility into separate components.

When a component has multiple responsibilities, it is fragile, and has many reasons to change. This is risky because changing the component for one reason can affect how other responsibilities are handled by that same component. We want to avoid unintentional side effects because they are hard to predict and handle. We want the modification of our component to happen in isolation so that it doesn't inadvertently affect anything else.

The worst case scenario of building a component with multiple responsibilities is creating a God component. This is an anti-pattern (a counterproductive pattern). God components tend to know too much and do too much. God components should be broken down by their individual responsibilities into separate easy to manage components.

## 2. Loose Coupling

Coupling defines the degree of dependency between two or more components. Loose coupling happens when an application's components have very little or no knowledge about other components. 

On the contrary, tight coupling happens when an application's components know many details about each other and depend on each other. Tight coupling makes it difficult to modify a component because it is highly dependent on other components. Just one small change in one component could break several other components or require that they also be updated. Therefore, we want the relationships between our components to be loosely coupled.  

The benefits of loose coupling are:

- Making changes to one component does not affect the other.
- Components can be replaced without impacting other components.
- Components are reusable across the application.
- Testing is made easier.

## 3. Encapsulation

A components should not know about or rely on another component's internal implementation details. Components that are well encapsulated hide their internal structure from other components. This isolates the component. However, components still need to communicate with each other. To accomplish this in React, we can provide props to change the behavior of a component. To accomplish this in Angular, we can provide inputs. Inputs and props should be as plain and raw as possible.

An example of broken encapsulation is when a component's internal structure spreads across an application. If a child component is permitted to directly update the state of the parent component, encapsulation is broken. This is because the child component knows too many details about its parent. 

What details does the child know about its parent in this example?

- The child knows that its parent is a stateful component.
- The child knows the parent's state object structure.
- The child knows how to update the parent's state.

## 4. Composition

Composition refers to combining components to create a bigger component. Composition is like playing with Legos. It refers to taking a set of small pieces, combining them, and creating something bigger. 

The Single Responsibility Principle we saw earlier described how to split responsibilities into components. The Encapsulation Principle that we just saw described how to organize components in isolation. The Composition Principle describes how to glue the whole system of components back together.

An example is having an `<App>` component that has had its responsibilities divided into four sub-responsibilities, creating four new components: `<AppHeader>`, `<AppFooter>`, `<MainContent>` and `<Sidebar>`.

Composition then glues back `<App>` from these four specific components. The `<App>` component becomes responsible for rendering the `<AppHeader>`, `<AppFooter>`, `<MainContent>` and `<Sidebar>` components. Composition has helped us to make the `<App>` component adhere to the Single Responsibility Principle by allowing each of its children implement  sub-responsibilities.

Composition has helped us build our application with a very clean and simple organization. Components that are built with composition in mind are able to reuse common logic. This helps us to achieve the next principle, reusability.

## 5. Reusability

The Reusability Principle allows us to write a component once and use it many times. We want to make things work and reuse their functionality, not reinvent how they work.

The **Don't repeat yourself (DRY)** principle can help us achieve reusability. It states that every piece of information should have one single representation within an application.

A lack of reusable components will make the application harder to maintain without providing any benefits. Without reusability in place, a piece of application logic will not be self-contained in one place. This means that an update to that logic will mean updates to many parts of the application.

Components that have only one responsibility are the most reusable ones. However, when a component has many responsibilities, reusing it becomes complicated. You may want to reuse only one of its responsibilities, but you will be forced to accept all of its other responsibilities along with what you need.

## 6. Categorization

Part of having a good component architecture involves properly categorizing components. Our application should make a distinction between Smart and Dumb components, or Container and View components. Smart or Container components focus on how things work. Dumb or View components focus on how things look.

Smart components:

- Manipulate data: fetching, manipulating, and passing down data.
- Are stateful: managing application state (Redux, etc) and re-rendering needs.
- Do not include styling.

Dumb components:

- Focus solely on the styling and presentation of elements.
- Accept inputs/props to allow them to be dynamic and reusable.
- Have no dependencies.
- Have no application state.

Examples of dumb components are inputs, modals, buttons, dropdowns, etc. A dumb component may have local state for handling user interactions, but it will not know about the state of the application's data.

By making this distinction between smart and dumb components evident in how we name them and organize them within our file hierarchy, we will have a better designed application. Presentation responsibilities will be organized in dumb components. Stateful and business logic responsibilities will be organized in smart components.

## 7. Testability

A testable component is one that is easy to test. We should test that a component returns the expected output for a given input. We should aim for component purity because it makes components easier it is to test. A pure component is like a pure function, it will always return the same same output for the same input.

It's very difficult and time-consuming to manually verify that each component is working as expected every time we make a change. Bugs are inevitable without proper unit tests for each component. Unit tests allow us to automate the tedious task of component testing. Every time we modify a component, we can re-run it's unit tests to verify that they still pass.

Unit tests don't only help us reduce bugs, they also help us to have a good component architecture. If a component in our application is not testable or difficult to test, it means that the component has not been designed properly. 

One of the main reasons that developers do not write tests for their components is because their components are not testable. When a component does not adhere to the principles mentioned in this article, testing it becomes very difficult and frustrating. As a result, the developer gives up writing unit tests for it.

## 8. Readability

A readable component is one in which it is easy to understand what it does. A readable component has readable code within that component. This allows developrs to quickly understand the responsibility of a component when looking at its code.

- Aim for clarity over brevity when naming things.
- Name components by their responsibility.
- Include code comments in components.

When naming components, be specific. Consider what their responsibility is. Instead of `<Posts>`, consider `<FetchPosts>`, `<FeaturedPosts>`, `<PostsContainer>`, `<PostsPage>`, etc.

## Conclusion

In conclusion, the eight principles for a good component architecture that we covered are: single responsibility, loose coupling, encapsulation, composition, reusability, testability, categorization, and readability. By applying these principles when designing components, you can ensure a robust and effective component architecture in your applications.



Single-page Apps (SPAs) are named this way because there is only one single HTML document that is served to a client via the browser. While you may be navigating away from a particular page and the link in the address bar is updated accordingly, you are still on the same root page (index.html). The  browser doesn’t refresh the page and there’s no actual new page that gets loaded. 

When a user navigates to a new page in a Single-page App, the DOM is used to update portions of the current page, as specified by the JavaScript code of the SPA. SPAs do not require page reloading during use. Examples of SPAs are Gmail, Google Maps, Facebook, Twitter, or GitHub. 

SPAs request a page's markup and data independently and render the page directly to the browser. JavaScript frameworks such as Angular, and JavaScript libraries such as React and Vue allow us to easily build a SPA.

SPAs are different from Multi-page applications (MPAs) which use a client-server architecture. With MPAs, a server needs to re-serve a page's resources (Ex: HTML, CSS, scripts, data) with every page refresh or page navigation. When loading a new page, the browser will need to download all resources for that page from the server, even if the page contains components that are repeated on several pages (Ex" header, footer). This can decrease a website's speed and performance.

## Pros of SPAs

- Since SPAs don’t update the entire page, but only specific sections of a page, they improve a website’s speed.
- They are fast. Most resources (HTML, CSS, Scripts) are typically only loaded once during the user's session. 
- Development is simpler because you don't need to use a server or write server-side code in the front-end application.
- They are easy to debug with modern browsers like Chrome. Network operations can be monitored for data retrieval, and web components injected in the DOM can be inspected.
- A SPA serves as a good base for future mobile app development. Example: If you build a SPA in React, you can easily transition it over to React Native for a mobile app.

## Cons of SPAs

- The first launch of a SPA takes a bit longer to load compared to traditional multi-page applications (MPAs). The SPA typically downloads all the HTML, CSS and JavaScript files on first page load. After this initial load, the following actions occur almost instantly.
- Dealing with browser history in a SPA can be difficult due to soft navigation, where a URL changes in the browser but it doesn't actually re-load an entire page. The History API in HTML 5 (ex: pushState) helps to solve this.
- SPAs aren’t search engine friendly by nature. Most search engines don’t like JavaScript. 

## SPAs and Search Engines

Googlebot, Google's crawler has gotten better at indexing JavaScript-based websites and SPAs. Search engine crawlers typically visit a URL and parse the HTML response, expecting it to contain all the content of a page. With SPAs, the initial HTML does not contain the actual content. Googlebot needs to execute JavaScript before being able to see the actual page content that JavaScript generates. 

With Server-Side rendering (SSR), all of the HTML content of a page is present in its source code. This means that the search engine can request, crawl, and index it immediately. SSR can be achieved with [Next.js](https://nextjs.org), [Angular Universal](https://angular.io/guide/universal), and others.

> Keep in mind that not all search engine bots today can run JavaScript effectively to properly index a  SPA without Server-Side rendering (SSR). 

Let's take a brief look at the traditional rendering approach of SPAs called Client-Side > Rendering (CSR) and then compare it with Server-Side Rendering (SSR).

## Client-Side Rendering (CSR) steps

Here are the steps taken when a SPA is rendered on the Client-Side.

1. User's browser sends a request to a URL.
2. Browser receives the `index.html` file from the server as a response.
3. Browser sends requests to download any remote links or scripts.
4. Browser waits for any scripts to be downloaded.
5. Browser makes any API requests via AJAX to fetch a site's dynamic content and processes it.
6. SPA library/framework renders the component passed to it and its content in the client's browser.

Because of the fetching and processing data on the Client-Side, this form of rendering is called Client-Side Rendering. 
Until the above piece of code executes, the user will just see a blank screen. This is not a problem but can be frustrating when a web server is experiencing latency or for users with a slower internet connection.

## Server-Side Rendering (SSR) steps

Here are the steps taken when a SPA is rendered on the Server-Side.

1. User's browser sends a request to a URL.
2. A node server responds by running code that rendering the requested component into a string.
3. The rendered component is injected into `index.html`.
4. The `index.html` file is sent back to the browser.
5. The browser renders the `index.html` file and downloads all the site's dependencies.
6. Once all the site's scripts are loaded, the component is rendered to the DOM of the client's browser and any needed event handlers are added.

This type of rendering is called Server-Side because all the work of getting dynamic content, converting it to HTML, and sending it to the browser is done on the server. SSR renders the complete HTML in advance. This uses memory and processing power on the server. This can increases page load times compared to Client-Side Rendering.


Have you ever written Angular code like this?

```typescript
<div *ngIf="movies">
  <div *ngFor="let movie of movies">
    <h2>
      {{ movie.title }}
    </h2>
  </div>
</div>
```

Or, like this?

```typescript
<div *ngFor="let movie of movies">
  <h2 *ngIf="movie.id">{{ movie.title }}<h2>
</div>
```

The reason the code is written this way is because we cannot combine `*ngIf` and `*ngFor` on one `<div>` element in Angular. We are unable to use multiple structural directives on a single host element in Angular. 
Thus, we need to introduce a hierarchy of `<div>` tags. 

The code blocks above work fine but they introduces several extra empty `<div>` tags in the DOM. As the elements in the DOM start to grow, this can get problematic. Elements might have event listeners attached to them which will still be there in the DOM listening to events even when they are not needed.

The worst part of these code blocks is the level of nesting that you will have to deal with when applying CSS styling to elements.

## ng-container to the rescue

Angular's `<ng-container>` is a grouping element that Angular does not put in the DOM. This means that it will not interfere with styling or layouts. 

If you simply need to apply multiple structural directives, such as `*ngIf` and `*ngFor` to a code block, use `<ng-container>` to avoid introducing an extra element in the DOM.

```typescript
<ng-container *ngIf="movies">
  <div *ngFor="let movie of movies">
    <h2>
      {{ movie.title }}
    </h2>
  </div>
</ng-container>
```

The `<ng-container>` element will not render to the page. The only content that will be added to the DOM will be what is inside of the `<ng-container>` element.



Though these are both comparison equality operators, the triple equals, `===`, is what is called a strict equality operator, while the double equals is a loose equality operator.

## Strict equality

Strict equality compares both the value and type of the values on both sides of the `===` operator. 
If the value is the same but the type is not, the equality check will evaluate to false. The values will be considered unequal if one of the values has a different type. With `===`, you are ensure that the values are strictly equal or identically equal because it never does type conversion.

```typescript
4 === "4" // false
```

This expression will evaluate to `false`. Though they appear to be of the same value, the left operand is of type `number` while right operand is of type `string`.

## Loose equality

The double equals operator `==` performs type conversion on values if their types differ and then compares them for equality. If the types differ, either or both operands are first converted to a common type. The conversion rules are complex and depend on the types of the values compared. 

```typescript
4 == "4" // true
```

Why are these two deemed to be equal? This is because the `==` operator first converts the values before comparing them for equality.

```typescript
4.toString() = "4" // first step: conversion
"4" == "4" // second step: comparison
```

Here is another example.

```typescript
"0" == 0  // true because ToNumber("0") === 0
```

Using `==` can seem easier because type conversion is built-in, but be aware that it can give you unwanted results.

```typescript
console.log(11 == "11"); // true
console.log(0 == false); // true
console.log(' \n\n' == 0); // true...really?
console.log(' ' == 0); // true...really?
```

## Inequality

When writing a not-equals-to expression, the same rules above apply. However, instead of triple-equals (`===`) versus double-equals (`==`), it's a double-equals (`!==`) versus a single equal (`!=`).

Here are some examples with `!=`.

```typescript
console.log(11 != "11"); // false
console.log(0 != false); // false
console.log(' \n\n' != 0); // false (misleading)
console.log(' ' != 0); // false (misleading)
```

Here are some examples with `!==`.

```typescript
console.log(11 !== "11"); // true
console.log(0 !== false); // true
console.log(' \n\n' !== 0); // true
console.log(' ' !== 0); // true
```

## Conclusion

The recommended approach is to stick to the Strict Equality operator `===` when possible. This will help maintain data type integrity throughout the project's codebase.

Keep in mind that these comparison operators are only for comparing primitive types. For comparing the deep equality of objects or arrays, a different approach will be needed.



`null` and `undefined` may seem to be the same value, but they actually have subtle differences in JavaScript.

## JavaScript primitive values

In JavaScript, there are six primitive values. Both null and undefined are two of them. The primitive values are:

- Boolean
- Null
- Undefined
- Number
- String
- Symbol

All other values besides these are objects (objects, functions, arrays, etc.).

## Falsy values

In JavaScript, there are six falsy values. Both null and undefined are two of the six. The list of falsy values are:

- false
- 0 (zero)
- "" (empty string)
- null
- undefined
- NaN (Not A Number)

All other values in JavaScript are considered truthy.

## What is null?

null is an empty or non-existent value. It literally means nothing.

```typescript
const a = null;

console.log(a); // null
```

Null must be assigned. If `const a` was not assigned to null, it would be `undefined` and not `null` when we `console.log()` it.

## What is undefined?

Undefined usually means that a variable has been declared, but not defined.

```typescript
let b;

console.log(b); // undefined
```

We can also declare a variable to be undefined.

```typescript
let c = undefined;

console.log(c); // undefined
```

If we try looking up the non-existent properties in an object, we will receive undefined.

```typescript
const user = {};

console.log(user.name); // undefined
```

## Equality checks

`null` does not strictly equal `undefined` because they are not of the same type. As we saw above, they are two different types of primitive values in JavaScript.

```typescript
console.log(null !== undefined); // false
```

However, `null` loosely equals `undefined`.

```typescript
console.log(null == undefined); // true
```

### Triple Equals

Triple equals `===` tests for strict equality. This means that both the type and the value that we are comparing have to be the same.

### Double Equals

Double equals `==` tests for loose equality and preforms type coercion. It compares two values after converting them to a common type.

## Function parameters

Consider the following function that prints out the name that is passed to it as a paramter.

```typescript
function sayHello(name = 'John') {
  console.log(`Hi ${name}!`);
}
```

Passing `undefined` will cause the function to use the default value of the parameter.

```typescript
sayHello(undefined); // Hi John!
```

Passing `null` will not make use the default value of the parameter.

```typescript
sayHello(null); // Hi null!
```



Here are three JavaScript functions that can help you check for a value in an array. Keep in mind that they are all case-sensitive. 

## Using includes()

```javascript
const fruits = ['apple', 'banana', 'peach'];

fruits.includes('apple'); // true

fruits.includes('mango'); // false
```

## Using indexOf()

`indexOf()` will return `-1` when the item is not found. 

```javascript
const fruits = ['apple', 'banana', 'peach'];

fruits.indexOf('apple'); // 0

fruits.indexOf('apple') !== -1; // true

fruits.indexOf('rasberry'); // -1
```

## Using some()

```javascript
const foods = ['pasta', 'pizza', 'chicken'];

foods.some(food => food === 'pasta'); // true

foods.some(food => food === 'fish'); // false
```

`some()` can also be used with an array of objects.

```javascript
const foods = [{ name: 'beef' }, { name: 'chicken' }];

foods.some(item => item.name === 'beef'); // true

foods.some(item => item.name === 'fish'); // false
```


In JavaScript, there are three ways to create strings, or string literals.

We can use single quotes:

```typescript
const hello = 'Hello, World!';
```

We can use double quotes:

```typescript
const hello = "Hello, World";
```

We can use a pair of backticks, which permits string interpolation.

```typescript
const hello = `Hello, World!`;
```

## String Interpolation

String interpolation consists of replacing placeholders with values in a string.

String interpolation in JavaScript is done by using template literals or template strings. These are strings with placeholders within the backticks.

```typescript
const value = 10;
const message = `The value is ${value}.`;
console.log(message); // The value is 10.
```

## The Placeholder

The placeholder can contain string variables.

```typescript
const hello = 'Hello';
const world = 'World';
const message = `${hello}, ${world}!`;
console.log(message); // Hello, World!
```

The placeholder can contain operators.

```typescript
const first = 2;
const second = 3;
const message = `The sum of ${first} and ${second} is ${first + second}.`;
console.log(message); // The sum of 2 and 3 is 5.
```

The placeholder can contain function calls.

```typescript
function sum(first, second) {
  return first + second;
}

const first = 2;
const second = 3;
const message = `Sum: ${sum(first, second)}.`;
console.log(message); // Sum: 5.
```

## Placeholder String Conversion

The expression in a placeholder is implicitly converted to a string.

A number in a placeholder is transformed into a string:

```typescript
const value = 11.2;
const message = `Number is ${value}.`;
console.log(message); // Number is 11.2.
```

The expression in the placeholder `${value}` is transformed into a string and inserted into the interpolation. 

If the placeholder contains an object, the object is converted to a string as well. The `toString()` method of the object is called to get the string representation of the object.

What if we insert an array into a template string?

```typescript
const myArray = [2, 4, 6];
const message = `The array values are ${myArray}.`;
console.log(message); // The array values are 2,4,6.
```
The `toString()` method on an array will do a `join(',')` on the array when it is converted to a string.

## Escaping placeholders

Since the placeholder `${}` holds a special meaning in interpolated strings, if we want to use a sequence of characters with `${}`, they must be escaped.

```typescript
const mySymbol = `Symbol ${xyz}`;
console.log(mySymbol); // ReferenceError: xyz is not defined
```

Using `${xyz}` directly will throw an error because `${xyz}` is expected to be a placeholder. Adding a backslash `\` before the placeholder will treat it as a sequence of characters instead.

```typescript
const mySymbol = `Symbol \${xyz}`;
console.log(mySymbol); // Symbol ${xyz}
```

The same is true for the following sequences of characters.

```typescript
const mySymbols = `Symbols \${xyz} \${xyz \${`;
console.log(mySymbols); // Symbols ${xyz} ${xyz ${
```
