In flux, what is talking to the API?

react
1

Sooo many flux tutorials, but almost none of them show how to talk to an API with persistent database.

What part of flux is talking to the REST API?

I find it comical that something so simple seems to have been turned into something so complicated that nobody is exactly sure how to call a rest API:

For instance, what part of flux would talk to a Node/Express/Mongo back end?

2

When I first learned about Flux, I thought it was a complete data system, but it’s not. It’s simply a convention for how to manage state and state transitions in the client side of your application.

Think of Flux as a replacement for Tracker in Meteor. Tracker doesn’t help you load data - DDP, and Subscriptions do that. But Tracker is the way that all of those data changes are wired together.

It’s the same with flux. It doesn’t tell you how to get the data at all, but it tells you how to add it to your store: via actions.

So essentially the flow is like this:

  1. Send a request to the server
  2. Dispatch an action to let the store know that a request is pending, that sets the loading state
  3. Receive response
  4. Dispatch an action to let the store know there is new data, that unsets the loading state and adds the new information

The convenient thing here is, nothing changes in the store without an action being dispatched. This gives you a really nice log of all of the activity in your app, which means that you can always log the series of actions that got you into a certain client side state. In Meteor this is often a weak spot, since the reactive nature of everything means you can often get into some state without an easy way to know how you got there.

So you can think of Flux as a replacement for Minimongo and Tracker, which is why a lot of people in the community are excited about using Flux with Meteor methods and subscriptions, which gives you a bit more insight into your state transitions than Tracker does.

We’re adopting this architecture for Apollo, the new data stack we’re working on. It follows a lifecycle similar to the above, so that you can take advantage of really clear state transitions in your application. On the other hand, it also handles the data loading lifecycle for you, so you don’t have to worry about calling the API manually.

So I think Flux is a really helpful way to think about how state transitions work in your app (as an alternative to Tracker, RxJS, and similar) but it doesn’t have any opinion about how the data actually gets to the client.

1 Like
3

Basically, it’s the job of the action creators. Action creators is the which does. Let’s say you wanna call to a REST endpoint to get data.

Then from your one of the component, you call an action creator. Then this action creator, fires two actions. (number could be changed based on the app)

  1. loading action
  2. completed action with the data.

How you do this basically different with the flux library. In Redux, you can use something like redux-thunk middleware. (I didn’t check redux middlewares recently. This is could be changed).

1 Like