Use modules organised by business logic features, not by underlying functionality

Good example

user/userSlice.ts user/userPage.ts user/userAvatarComponent.ts

Bad example

utils/userUtils.ts components/userAvatar.ts pages/userPage.ts

Business logic

Components should not have business logic, components should mount and call store methods, but should avoid doing any calculations, business logic and especially heavy computation.

Good example of using business logic while having local component logic

import { useBoundStore } from "@/store";
import { motion } from "motion/react";
import { RefObject } from "preact";
import { useState } from "preact/hooks";

export type SwapRotateButtonProps = {
  inputRef?: RefObject<HTMLInputElement>;
};

export const SwapRotateButton = ({ inputRef }: SwapRotateButtonProps) => {
  const [rotation, setRotation] = useState(0);
  const handleRotateClick = useBoundStore((state) => state.rotateSwapDirection);
  const handleClick = () => {
    setRotation(rotation + 180);
    handleRotateClick();
    if (inputRef) {
      inputRef.current?.focus();
    }
  };
  return (
    <button
      class={`bg-white`}
      onClick={handleClick}
    >
      <motion.div
        animate={{ rotate: rotation }}
        transition={{
          duration: 0.3,
          type: "spring",
          stiffness: 260,
          damping: 20,
        }}
      >
        <img src="rotate.svg" className={"mx-2 my-1.5"} />
      </motion.div>
    </button>
  );
};

export default SwapRotateButton

swapStore.ts -> rotateSwapDirection()

   rotateSwapDirection: () => {
      set((state) =>
        produce(state, (draft) => {
          const tokenFrom = draft.swapData.tokenFrom;
          draft.swapData.tokenFrom = draft.swapData.tokenTo;
          draft.swapData.tokenTo = tokenFrom;
          draft.swapData.amountFrom = "";
          draft.estimatedSwap = undefined;
        }),
      );
      // const tokenFrom = get().swapData.tokenFrom;
      get().fetchSwapDataTokenInfo()
      get().estimateSwap();
    },

Libraries and packages

When choosing a tech stack, first always analyze the requirements, do not try to build the best of the best for everything and do not rely on a default choice of Next.js and SSR.

Mostly apps are split in 2 categories

SPA - single page application

A lot of interactivity, heavy business logic on the front end. Requirements to maintain complicated local state. Good example is trading terminal like trade.xyz user is expecting first load to be slow, but subsequent navigation and interactions to be very fast. When building SPA rules are

Ship very little JS

Less packages, lightweight alternatives to established packages. If you can use preact instead of react for 99% of the use cases, when server side rendering is not involved Preact is a perfect choice, since most of the libraries are backported to preact, for example shadcn

zustand is lightweight alternative for redux and analogs wouter is a lightweight alternative to react-router Sometimes the default choice is already a good one, for example immer

But every single time you want to add a dependency, always look for minimal example, do not try to cover all the possible functionality in the future, instead try to look for what gets the job done right now, has the least amount of functionality and minimal bundle size

SSG - static site generation

When you don't need an interactive application, and instead need to work with something with maximal loading speed. Go with Astro and islands architecture.

Web3

If you are using any web3 related logic, meaning you have wallet connected and submit transaction to blochain of any sorts read this [[transactionsStore.md]]