Chapter 4. Consuming an API
If you’ve kept up so far with the book, or completed a few of the more basic tutorials online, you know that we’ve reached a point where things traditionally start to get a little trickier. Here’s where you are: a user interacts with the app and actions get dispatched to reflect certain events, such as creating a new task or editing an existing task. The data lives directly in the browser, which means you lose any progress if the user refreshes the page.
Perhaps without realizing, every action you’ve dispatched so far has been synchronous. When an action is dispatched, the store receives it immediately. These kinds of actions are straightforward, and synchronous code is generally easier to work with and think about. You know exactly the order things will execute based on where the code is defined. You execute line one and then line two, and so on. But you’d be hard-pressed to find any real-world JavaScript application that didn’t involve any asynchronous code. It’s fundamental to the language and required to do what this chapter is all about: talking with a server.
- Actions are objects that describe an event, such as CREATE_TASK.
- Actions must be dispatched to apply any updates.