
![](assets/observer-pattern.webp)

## Problem

Imagine that you have two types of objects: a Customer and a Store. The customer is very interested in a particular brand of product (say, it’s a new model of the iPhone) which should become available in the store very soon.

The customer could visit the store every day and check product availability. But while the product is still en route, most of these trips would be pointless.

![](assets/observer-pattern-problem.webp)

On the other hand, the store could send tons of emails (which might be considered spam) to all customers each time a new product becomes available. This would save some customers from endless trips to the store. At the same time, it’d upset other customers who aren’t interested in new products.

It looks like we’ve got a conflict. Either the customer wastes time checking product availability or the store wastes resources notifying the wrong customers.

## Concept of the observer pattern

### Definition

The Observer pattern is a design pattern where an object, known as the subject, maintains a list of its dependents, called observers, and notifies them of state changes.

### Real-world analogy

If you subscribe to a newspaper or magazine, you no longer need to go to the store to check if the next issue is available. Instead, the publisher sends new issues directly to your mailbox right after publication or even in advance.

The publisher maintains a list of subscribers and knows which magazines they’re interested in. Subscribers can leave the list at any time when they wish to stop the publisher sending new magazine issues to them.

## Examples

### DOM events and event listeners

In the browser, we use the Observer pattern through DOM events. The DOM element is the subject, and event listeners are the observers.

```js
button.addEventListener("click", () => {
  console.log("Button clicked!");
});
```

### Custom event emitters

We can create our custom event emitters to decouple code and enhance modularity.

```js
const EventEmitter = require("events");
const emitter = new EventEmitter();

emitter.on("event", () => {
  console.log("An event occurred!");
});

emitter.emit("event");
```

In this example, `emitter` is the subject. When we emit the event, all registered observers get notified.

### Redux: leveraging the observer pattern

Redux is a state management library that uses the Observer pattern under the hood.
The Redux store is the subject, and components that subscribe to the store are the observers.

```js
const { createStore } = require("redux");

const reducer = (state = {}, action) => {
  switch (action.type) {
    case "UPDATE":
      return { ...state, data: action.payload };
    default:
      return state;
  }
};

const store = createStore(reducer);

store.subscribe(() => {
  console.log("State changed:", store.getState());
});

store.dispatch({ type: "UPDATE", payload: "new data" });
```

Here, the store dispatches actions, and subscribed components get notified to update their state.

## Pros & cons

Pros:

- Loose Coupling: Reduces dependencies between subject and observers, making the system easier to maintain and extend.
- Automatic Updates: Observers are automatically notified and updated when the subject's state changes, keeping them in sync.
- Reusability and Flexibility: Observers and subjects can be reused independently. New observers can be added without modifying the subject.
- Event Handling: Provides a structured way to handle events and notify interested parties.
- Simplifies Communication: Abstracts the notification mechanism, simplifying communication between objects.

Cons:

- Potential for Memory Leaks: If observers are not properly unregistered, they can lead to memory leaks.
- Unexpected Updates: Observers may receive updates at unexpected times, leading to potential race conditions or inconsistent state.
- Performance Overhead: Notifying all observers can introduce performance overhead, especially if there are many observers or complex notifications.
- Complexity in Simple Scenarios: Can introduce unnecessary complexity for simple applications.
- Difficulty in Debugging: Tracking the flow of notifications and understanding the sequence of updates can be challenging.

## Reference

- https://refactoring.guru/design-patterns/observer


Concept of the observer pattern with its pros and cons.

Introduce the observer pattern and its use cases


Imagine we have a component with multiple states. It is simple enough not to use state management libraries. `useState` is surely a choice for the sake of brevity and clarity. But are there any issues we have to deal with? In this article, I want to make some improvements on `useState` hook and how we can replace it with `useReducer` as an alternative solution.

## The problem

Let's take a look at the code below:

```jsx
function EditCalendarEvent() {
  const [startDate, setStartDate] = useState();
  const [endDate, setEndDate] = useState();
  const [title, setTitle] = useState("");
  const [description, setDescription] = useState("");
  const [location, setLocation] = useState();
  const [attendees, setAttendees] = useState([]);

  return (
    <>
      <input value={title} onChange={(e) => setTitle(e.target.value)} />
      {/* ... */}
    </>
  );
}
```

The component is used to update a calendar event. Sadly, it has several problems:

- Using too many `useState` hooks make your code look like a mess, especially when the list of state grows longer and longer.
- No safeguards. In other words, you may not guarantee that state is updated accurately. There’s nothing preventing you from choosing an end date that’s before the start date. You can validate other related states first but only if you remember (or even know) they exist.

## An improvement of `useState`

To improve the code above, we can gather all states in one big object:

```jsx
function EditCalendarEvent() {
  const [event, setEvent] = useState({
    title: "",
    description: "",
    attendees: [],
  });

  return (
    <>
      <input
        value={event.title}
        onChange={(e) => setEvent({ ...event, title: e.target.value })}
      />
      {/* ... */}
    </>
  );
}
```

Look better. However, there are still potential pitfalls:

- Always remember to spread on `...event` so you don’t mess up by mutating the object directly and subsequently causing React to not rerender as expected.

- You can validate before updating states but the validations are separated and somehow hard to control all of them.

One solution is using a curried function:

```jsx
function EditCalendarEvent() {
  const [event, setEvent] = useState({
    title: "",
    description: "",
    attendees: [],
  });

  const handleChange = (field) => (e) => {
    // Validate and transform event to ensure state is always valid
    // in a centralized way
    // ...
    setEvent({ ...event, [field]: e.target.value });
  };

  return (
    <>
      <input value={event.title} onChange={handleChange("title")} />
      {/* ... */}
    </>
  );
}
```

Do not forget that there are two ways to update state now and make sure you pick the right one or else the curried function will be meaningless.

## Adopting `useReducer` as an alternative to `useState`

Many people know `useReducer`, but a small number of them actually want to use it. With `useReducer`, we could rewrite the code to be like this:

```jsx
function EditCalendarEvent() {
  const [event, updateEvent] = useReducer(
    (prev, next) => {
      return { ...prev, ...next };
    },
    { title: "", description: "", attendees: [] },
  );

  return (
    <>
      <input
        value={event.title}
        onChange={(e) => updateEvent({ title: e.target.value })}
      />
      {/* ... */}
    </>
  );
}
```

The `useReducer` hook helps you control transformations from state A to state B. This guarantees your states are always valid, in a fully **centralized** way. So with this model, even if the code becomes more complex, new states are added, we can still manage and maintain them without so much effort.

```jsx
function EditCalendarEvent() {
  const [event, updateEvent] = useReducer(
    (prev, next) => {
      const newEvent = { ...prev, ...next };

      // Ensure that the start date is never after the end date
      if (newEvent.startDate > newEvent.endDate) {
        newEvent.endDate = newEvent.startDate;
      }

      // Ensure that the title is never more than 100 chars
      if (newEvent.title.length > 100) {
        newEvent.title = newEvent.title.substring(0, 100);
      }
      return newEvent;
    },
    { title: "", description: "", attendees: [] },
  );

  return (
    <>
      <input
        value={event.title}
        onChange={(e) => updateEvent({ title: e.target.value })}
      />
      {/* ... */}
    </>
  );
}
```

## Other use cases for `useReducer`

As can be seen from code above, `useReducer` might replace `useState` for "complex state", and moreover we do not need to follow the redux style. I still believe `useReducer` is underestimated.

Here is an example of toggling state with `useReducer`:

```jsx
function EditCalendarEvent() {
  const [value, toggleValue] = useReducer((prev) => !prev, false);

  return (
    <>
      <button onClick={toggleValue}>Toggle</button>
    </>
  );
}
```

The implementation is simple, and it really shows the flexibility of `useReducer`.

If you love Redux, sure, you can adhere the action-based pattern as well. It is important to keep in mind that you must always treat the state value of the `useReducer` hook as immutable. To avoid running into this problem, `Immer` is one of the best choice.

## The conclusion

In general, developers prefer `useState` to `useReducer`. It is not their fault since `useState` is more familiar and introduced from the very first tutorial of hooks. However, the ability to supply a function that controls state transitions of `useReducer` is great and surely worth your consideration.

## Reference

- https://dev.to/builderio/a-cure-for-react-usestate-hell-1ldi


Imagine we have a component with multiple states. It is simple enough not to use state management libraries. `useState` is surely a choice for the sake of brevity and clarity. But are there any issues we have to deal with? In this article, I want to make some improvements on `useState` hook and how we can replace it with `useReducer` as an alternative solution.

When should we use useReducer instead of useState?


## 1. What is a Liquidity Pool?

Basically, a liquidity pool is a pool of tokens that are locked in a smart contract. Liquidity refers to the ease with which a token can be swapped with another. Anybody can provide liquidity into this single giant pool and earn a share of the trading fees based on their stake in it.

The process could be illustrated by the picture below:

![](assets/liquidity-pool_pasted-image-20220322220453.webp)

## 2. How do Liquidity Pools work?

Liquidity pools form the backbone of DEX by applying the automated market maker (AMM) system. Here’s the main formula that mathematically determines what the market price of the token in the pool should be:


$$
x * y = k
$$


Where x and y represent the respective token balance of a pairing and **k is a constant that will never change**.

Let's use the ETH-DAI pair as an example, with 10 ETH and 1,000 DAI in the liquidity pool. What happens when someone wants to buy 1 ETH from this pool? How much does he need to pay?

The k constant is 10,000 since there are 10 ETH and 1,000 DAI.


$$
10 \text{ ETH} * 1,000 \text{ DAI} = 10,000
$$


If the buyer withdraws 1 ETH, he has to deposit some DAI into the pool so that k remains constant.


$$
(10 - 1) \text{ ETH} * (1,000 - y) = 10,000
$$



$$
1,000 - y =\frac{10000}{10 - 1}
$$



$$
 y = 111.11
$$


And because we have no limit orders in AMM, the smart contract would automatically compute y to determine the price to pay and that is approximately 111.11 DAI.

Now the liquidity pool would have 9 ETH and 1,111.11 DAI after someone buys 1 ETH.

### 2.1. Roles of arbitragers in AMM

Arbitragers play an important role in AMM. They are used in order to take advantage of the price differences and drive the price back towards market equilibrium.

If the price of ETH in the pool is higher than it is on Coinbase, arbitragers would sell ETH into this pool and make a profit on the price discrepancies. Thus, the price of ETH in the pool would always be incentivized towards the market price as closely as possible.

### 2.2. Depth of pool and slippage

The price difference between the pool and market is known as slippage. How big your slippage is depends on the size of your trade relative to the size or depth of the pool.

The depth of the pool is measured by that k constant. The bigger your k, the deeper the pool and the less likely a slippage is going to occur.

In the earlier example, buying 1 ETH from a pool that only has 10 ETH makes up 10% of the pool size. Hence there is such a big difference in price. ETH price costs $100 but you are buying it from the pool at $111.11. That’s about an 11% price slippage.

In reality, the pool will be much deeper and bigger as there will be hundreds and thousands of liquidity providers from all around the world.

Suppose we use a pool that has 100 ETH and 10,000 DAI and someone wants to buy 1 ETH from this pool, how much would it cost? Plugging in the same equation would give you $101, a 1% price slippage.

## 3. How to provide Liquidity into a Pool?

Anyone can provide liquidity and become a Liquidity Provider (LP). When supplying a pair of tokens into the pool, the ratio price of both tokens must be 50-50. So if you want to provide $5,000 of ETH-DAI pair, you will need $2,500 DAI and $2,500 worth of ETH.

Every liquidity provider has to follow this standard so that the liquidity pool would always maintain a 50-50 mix of token A and token B.

When you provide liquidity into a pool, you typically receive an LP token in exchange. This LP token represents your share in the liquidity pool. Every time when a trade is made on the liquidity pool, users have to pay a fee. These fees are then aggregated and re-distributed back to all liquidity providers on a pro-rata basis based on the amount of LP tokens you hold.

However, you may not get back the exact amount of tokens you deposited initially. That is to say, if you started out with some ETH-DAI tokens, you would get back more ETH and less DAI, or more DAI and less ETH depending on the markets.

In a bull market, more people would want ETH as prices are rising. Hence the supply of ETH in the pool would drop while DAI would increase since more people are exchanging their dollars for ETH. When you withdraw out your LP, you would end up with less ETH than you started out with and more DAI. The reverse holds true in a bear market.

## 4. What is Impermanent Loss?

Impermanent loss refers to the situation where you could have made more if you have done nothing and hold on for dear life rather than providing LP.

Suppose the price of ETH in our LP is $100. What if the price of ETH on Coinbase rises to $120 in the market? Arbitragers will come in and buy ETH from the pool and sell it on Coinbase to profit from that difference.

Let’s use a pool that has 100 ETH and 10,000 DAI. The relation between x, y, k, and ETH price could be shown by:


$$
x * y = k
$$



$$
x = \frac{k}{\text{ETH price}}
$$


We could easily calculate x and y by k and ETH price:


$$
x = \sqrt{\frac{k}{\text{ETH price}}}
$$



$$
y = \sqrt{k * \text{ETH price}}
$$


Assume someone supplies 1 ETH and 100 DAI into the pool. How much ETH and DAI he could get back if the ETH price pumps to $120?


$$
k = 100 * 10,000 = 1,000,000
$$



$$
x = \sqrt{\frac{1,000,000}{120}} = 91.29
$$



$$
y = \sqrt{1,000,000 * 120} = 10,954.45
$$


Since his share in the pool is 1%, the LP gets back 0.9129 ETH and 109.5445 DAI if he wants to withdraw his stake in the pool. The total value of his stake would be 0.9129 ETH \* $120 + $109.54, which totals up to be $219.09.

If he did not provide his liquidity into the pool and held on for dear life instead, his initial asset would be worth 1 ETH \* $120 + $100 = $220, which also means he would have made an extra $0.91.

That is what we call impermanent loss. It is impermanent because it only becomes permanent when you withdraw out your LP.

---

#### Reference

- https://www.jumpstartmag.com/how-do-crypto-liquidity-pools-work/
- https://www.theancientbabylonians.com/what-is-liquidity-pool-lp-in-defi/#:~:text=To%20sum%20up%20what%20liquidity,%3A%20x%20*%20y%20%3D%20k


A comprehensive guide to understanding liquidity pools in blockchain, covering their definition, functionality, the role of automated market makers (AMM), arbitrage, pool depth, slippage, how to provide liquidity, and the concept of impermanent loss. This article provides insights for both beginners and experienced users in decentralized finance (DeFi)