Building Features, a Revisit

Some thoughts as I have come back to building a production feature of fair complexity lately.

I think principles we discovered earlier still hold, with clearer understanding and therefore more refined execution. This is a retrospective summary.

  • building features have become a bit more complex
    • SSR is a norm -> mainly concerns data fetching
    • involves creating multiple packages in a monorepo
      -> matters how we organize code
  • redux store
    • normalized store shape, tailored to the need of each individual features
    • the meat of the redux store is data indexed on normalized query strings
    • parse data once when they come in, save them directly in format directly consumable by FE app later on
      -> types normally have a "raw type" and a "finalized" type -> processResponse in redux actions
    • async calls that change parts of store state that are independent of each other should use separate actions, even though they may call the same back end API
  • hooks
    • unlike actions, which should be dispatched sparingly, we should expect hooks to be called repeatedly and likely at rapid intervals
    • hook call to action call is mostly controlled by dependency arrays
    • use a skip async call predicate at action (which has direct access to store) to prevent repeated async calls, this decouples the complexity of async call control to 1 single function
  • when all the above is done properly, component implementation is almost trivial (subject to availability of reusable UI components)
    • for feature / business UI, prefer copying and pasting
    • for shared component UI, identified by 1) ignorant of feature logic and 2) complex logic with user interaction, prefer shared component done once and done right