
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.


Hi, I'm Steven 👋

Latest Blog Posts

The React useReducer hook

The React useEffect hook

The React useRef hook

Using the React useState hook for forms

The React useState hook

function versus const for React components

Iterating or looping over a TypeScript Enum

Get the keys of a numeric TypeScript Enum

Add Google Analytics to an Angular app

Planning for Unpredictability with Daniel Vassallo