Where should caching logic go in a flux app?

Question

In a previous question I asked who is responsible for sending updates to the server in a Flux app. People told me that Actions should do this. So I'm assuming that the same goes for fetching data from the server; you have a FetchData action, which fetches the data and dispatches the data for the store to hold onto. But in such a case, how would the caching logic work?

I think I would have to store the last time the list was requested, and the list's TTL within the StreamsStore and the fetchStreams action would retrieve the TTL and last fetch time to determine whether the server needs to be consulted.

Is this the correct way to go? It seems strange to me to spread the caching logic between the store and the action, but I can't think of a better way to do it.

Prettify

Answer 1

This is a great question, and one that I've encountered before as well.

Remember that the most important thing about Flux is that data flows one way, always. You already know this — I'm bringing it up because that one statement has a lot of clarifying power, and holds the answer pretty much any question you might have about Flux.

Actions send data to stores, so if you add logic to your actions that checks the value of something in your store, you're sending data in the wrong direction, against the flow.

So which part of a Flux app receives data from stores? The views. There's your answer.

The idea of your views holding caching logic may feel weird, but think about what caching is:

1. I need some data.
2. Do I already have that data? If not...
3. Go get it.

Views handle #1. That's pretty straightforward. And #3 is obviously handled by your actions. But it turns out #2, at least in a Flux app, is also something that should be dealt with in your views — or more specifically, your controller-views. Controller-views are an oft-overlooked part of Flux, probably because the idea of controllers is so heavily associated with MVC. But Flux has them, too! From the Flux website:

Controllers do exist in a Flux application, but they are controller-views — views often found at the top of the hierarchy that retrieve data from the stores and pass this data down to their children.

Assuming you're using React, this idea should sound familiar. Higher level React components are controller-y, while lower level components are more "pure."

Another way of thinking about this is to note that actions are merely dispatcher helpers. (If I remember correctly, when Facebook first introduced Flux, they didn't even mention actions.) By the time you've called an action, you've already made the decision to dispatch: the only question is what, not if.

Reading this back, I realize this may all seem like distinctions without differences, but the main takeaway is that no, actions cannot inspect the state of a store. They can only communicate with them via the dispatcher. You may find a way to make it work in practice (which shouldn't be discounted!), but it's not idiomatic Flux.

I hope this makes sense!

Interrex

This seems to make sense at a high level, but then what if you have many many components that share a common store? Are you suggesting to replicate this caching type logic in every single component? That doesn't seem to make sense to me either. – Boutwell

If all your components are doing this same caching logic, you may want to redesign your components. Possibly have a base component that has this logic that all your other components that rely on this store extend. – Artiodactyl