I always imagined programming as a "struggle" to navigate and maintain a large possible spectrum of states. I have this image in my head where every update to the state of any application is transitioning from one node of a massive graph to another node. Some of these nodes are deadly and they will result in your application erroring out, making your customers unhappy, and potentially losing revenue for your business.
You can imagine one node representing the current state of a shopping cart on an e-commerce platform. Adding items, removing items and changing their quantities in the cart are all transitions from one node in the graph to another. What happens if we allow our users to decrease quantities of items in the cart to negative values? Some nodes in the graph are in the danger zone and they shouldn't be accessible.
Storing State:
This approach is useful when there is a need to maintain a record of past events or when the same data is required repeatedly. The advantages of storing state include:
Faster processing: Once data is stored, it can be retrieved quickly and without requiring any additional computations.
Accurate results: Storing state can ensure that calculations are consistent across different parts of the program, reducing the chance of errors.
However, there are also disadvantages to storing state, including:
Increased memory usage: As data is stored in memory, it can quickly become a bottleneck, especially when dealing with large amounts of data.
Increased complexity: Storing state requires additional code to manage the data, which can make the program more complex and harder to maintain.
Computing State:
This approach is useful when there is no need to maintain a record of past events, or when the same data is not required repeatedly. The advantages of computing state include:
Reduced memory usage: As data is computed on the fly, there is no need to store large amounts of data in memory.
Simpler code: Computing requires less code, making the program simpler and easier to maintain.
However, there are also disadvantages to computed state, including:
Slower processing: As data is computed on the fly, it can take longer to retrieve than if it was stored in memory.
Increased risk of errors: Computed data can be less consistent across different parts of the program, increasing the risk of errors.
I believe the distinction between storing state and computing state on-demand is one of the fundamentals of software engineering. There is no correct answer to this question. As an engineer becomes more senior, they should spend more time evaluating when to store state and represent it in memory or a database and when to compute it on-demand. As almost anything in software engineering, even this is a trade-off and it's our job to evaluate and decide when we should use one over the other.