4 ms·

> We love to hate state, but isn't caching data the key to performance at scale? It seems you're mixing things up. "State" in this context doesn't mean caching

> We love to hate state, but isn't caching data the key to performance at scale? It seems you're mixing things up. "State" in this context doesn't mean caching results. "State" in this case means that your code has internal state that you can't control, thus your components behave unpredictably depending on factors you can't control. Picking up your caching example, what would you say if your HTTP cache either returned your main page or some random noise in an apparently random way, even though you're always requesting the exact same URL?

smitty1e 4y ago
You may be correct vis-a-vis OP, but I'll stick to my guns as far as 'state' being any piece of information that has to managed. If I'm not writing pure functions, then there is some piece of information whose lifecycle suddenly requires care and feeding, especially if there are environmental factors making that state more 'interesting' than the code in view.
- rovolo 4y ago
  The advice is that state is hard to deal with, so you should try to isolate it from the rest of your program. You can even organize stateful components like a cache to isolate the stateful components. - Make your stateful components "dumb". The cache should just have dumb put,get,delete methods. - Make your "smart" components stateless. Your component deciding which items to cache or remove or invalidate should be passed all the state they need to make their decisions as immutable parameters. This will make your lifecycle management code much easier to test or log. - Keep the part gluing the dumb state and the smart functions small In the end you still have a stateful component, but as a whole it should be easier to work with. For example, it's much easier to test time-based lifecycle decisions if you pass in the current time than if the component grabs the current time from your system clock.

smitty1e 4y ago

You may be correct vis-a-vis OP, but I'll stick to my guns as far as 'state' being any piece of information that has to managed. If I'm not writing pure functions, then there is some piece of information whose lifecycle suddenly requires care and feeding, especially if there are environmental factors making that state more 'interesting' than the code in view.

rovolo 4y ago
The advice is that state is hard to deal with, so you should try to isolate it from the rest of your program. You can even organize stateful components like a cache to isolate the stateful components. - Make your stateful components "dumb". The cache should just have dumb put,get,delete methods. - Make your "smart" components stateless. Your component deciding which items to cache or remove or invalidate should be passed all the state they need to make their decisions as immutable parameters. This will make your lifecycle management code much easier to test or log. - Keep the part gluing the dumb state and the smart functions small In the end you still have a stateful component, but as a whole it should be easier to work with. For example, it's much easier to test time-based lifecycle decisions if you pass in the current time than if the component grabs the current time from your system clock.