import { useReducer } from "react";

const ADD_PRODUCT = 'ADD_PRODUCT';
const UPDATE_PRODUCT_STATUS = 'UPDATE_PRODUCT_STATUS';

const INITIAL_PRODUCTS_STATE = { products: {} };

// this does not scale, is difficult to track and is very bug prone...
const reducer = (state = INITIAL_PRODUCTS_STATE, action) => {
  switch (action.type) {
    case ADD_PRODUCT:
      return {
        ...state,
        products: {
          ...state.products,
          [action.key]: action.product,
        },
      };
    case UPDATE_PRODUCT_STATUS:
      return {
        ...state,
        products: {
          ...state.products,
          [action.key]: {
            ...state.products[action.key],
            status: action.newStatus,
          },
        },
      };
    default:
      return state;
  }
};

/*
It might seem that our component is super easy, pretty and has hardly any lines of code, but it really hides a dark secret that can make us cry and pull our hair out in the near future...

What would happen if tomorrow we want to change the name of our action in the reducer? 🤔
And what happens if a component makes a mistake in dispatching the wrong action? 🤔
And what happens if we change the component that manages the products? 🤔
And if I have to make a change in the state in which I have to access a very deep property which has a nesting level that is more than 3 levels? 🤔
*/
function Example_withBadReducer() {
  const [state, dispatch] = useReducer(reducer, initialState);

  return (
    <div>
      <p>Current products are {JSON.stringify(state.products)}</p>
      <ProductHandler dispatch={dispatch} />
    </div>
  );
}

/*
 In the context of ProductHandler, what is the value of the "dispatch" property? What can I do with that prop? This component is highly coupled to the internal logic of the parent component, which is a bad thing.
*/
function ProductHandler({ dispatch }) {
  return (
    <>
      <button
        onClick={() =>
          dispatch({
            type: "ADD_PRODUCT",
            payload: {
              key: "my_permission",
              status: "PENDING",
            },
          })
        }
      >
        Initialize permission
      </button>
      <button
        onClick={() =>
          dispatch({
            type: "UPDATE_PRODUCT_STATUS",
            payload: { key: "my_permission", newStatus: "FULL" },
          })
        }
      >
        Change permission status
      </button>
    </>
  );
}

import { useMemo } from "react";
import { useImmerReducer } from "use-immer";

/* 
Maybe this reminds us of Redux, but it is a mistake to link this only with Redux, since this is a pattern within the paradigm of functional languages, but that's another topic that we will not deal with now 🤪
*/
function useSelectors([state], mapStateToSelectors) {
  return useMemo(
    () => mapStateToSelectors(state),
    [state, mapStateToSelectors]
  );
}

function useActions([, dispatch], mapDispatchToActions) {
  return useMemo(
    () => mapDispatchToActions(dispatch),
    [dispatch, mapDispatchToActions]
  );
}

/*
Pure functions that can be unit tested without any difficulty 🥰

The only drawback we have here is that our functions are coupled to exist within the context of immer, but under my point of view this is a lesser evil
*/
const ACTION_HANDLERS = {
  ADD_PRODUCT: (state, { payload }) => {
    state.products[payload.key] = payload.status;
  },
  UPDATE_PRODUCT_STATUS: (state, { payload }) => {
    state.products[payload.key] = payload.newStatus;
  },
};

const initialState = { products: {} };
function reducer(state = initialState, action) {
  const handler = ACTION_HANDLERS[action.type];

  return handler ? handler(state, action) : state;
}

function Example_withImmer() {
  const productsReducer = useImmerReducer(reducer, initialState);
  // May seem a bit verbose, but, if it does, perhaps you should not use a reducer 🥵
  const { addProduct, changeProductStatus } = useActions(
    productsReducer,
    (dispatch) => ({
      addProduct: (product) =>
        dispatch({ type: "ADD_PRODUCT", payload: product }),
      changeProductStatus: ({ key, newStatus }) =>
        dispatch({
          type: "UPDATE_PRODUCT_STATUS",
          payload: { key, newStatus },
        }),
    })
  );
  const { getProducts } = useSelectors(productsReducer, (state) => ({
    // here is where we should use `reselect`, `useCallback`/`useMemo` or a stable reference to our custom selectors function
    getProducts: () => state,
    // getProductById: (id) => state.products?.[id]
  }));

  return (
    <div>
      <p>Current products are {JSON.stringify(getProducts())}</p>
      <ProductHandler
        addProduct={addProduct}
        changeProductStatus={changeProductStatus}
      />
    </div>
  );
}

/*
 > Is an example to compare with the case we have been analyzing 🤓

 Instead of prop drilling the dispatch function, here we can see how our code now has a semantic relationship with our action, instead of making an act of faith and interpreting without certainty that the dispatch type is correct (e.g: a typo)*.

 Another problem of using the dispatch in a child component, is that this component should not necessarily know anything about the parent, it should only execute without taking into account the logic that its ancestor is handling.

 > * if we use TypeScript, many of these problems would disappear in dev/build time, since the compiler will tell us that something is wrong. 
*/
function ProductHandler({ addProduct, changeProductStatus }) {
  return (
    <>
      <button
        onClick={() => addProduct({ key: "my_permission", status: "PENDING" })}
      >
        Initialize permission
      </button>
      <button
        onClick={() =>
          changeProductStatus({ key: "my_permission", newStatus: "FULL" })
        }
      >
        Change permission status
      </button>
    </>
  );
}