• Introduction
• Setup
• Overview
• 1. Install the CLI
• 2. Create the App
• 3. Run the App
• 4. Setup the API
• Layout
• Overview
• 1. Install Bootstrap
• 2. Add Custom Styles
• 3. Add the Header
• Routing
• Overview
• 1. Convert Title to a Link
• 2. Add Feed to Routes
• Data Structure
• Overview
• 1. Add Mock Data to Feed
• 2. Create Tweet Component
• 3. Add Mock User Data
• Fetching Data
• Overview
• 1. Set API Location
• 2. Create Tweet Model
• Convention over Configuration
• 3. Connect Feed Component
• 4. Display Loading Message
• 5. Fetch User for Tweet
• Authentication
• Overview
• 1. Add Profile to Layout
• 2. Add Auth0 Config
• 3. Add Login Page
• 4. Redirect to Login
• 5. Add Callback Route
• 6. Add Logout Page
• 7. Fetch Current User
• 8. Save User to Context
• Server
• Overview
• 1. Clone the API Server
• 2. Parse the Collection
• 3. Parse the Model
• 4. Add Unauthorized Experience
• 5. Add Authorization Header
• Pagination
• Overview
• 1. Add Pagination Metadata
• 2. Paginate the Tweets
• 3. Add Pagination Links
• 4. Improve User Experience
• Infinite Scrolling
• Overview
• 1. Create Load More Button
• 2. Create Infinite Scrolling List
• 3. Convert the Feed
• Cleanup
• Overview
• 1. Remove Unnecessary Code
• Dialogs
• Overview
• 1. Add Create Button
• 2. Mounting Dialogs
• 3. Add Create Dialog
• 4. Simplify the Dialog
• 5. Generate Dialog via Hook
• 6. Add Edit Dialog
• 7. Add Delete Dialog
• Authorization
• Overview
• 1. Hide Edit Link
• 2. Hide Delete Link
• 3. Alternative Approach
• Optimistic Updates
• Overview
• 1. Freeze Pagination Data
• 2. Display New Tweets
• 3. Display Optimistic Tweets
• 4. Add Optimistic Values
• 5. Show Optimistic Visual Cues
• 6. Hide Deleted Tweets
• Normalization
• Overview
• 1. Normalize Tweet Response
• Filtering
• Overview
• 1. Add Filter
• 2. Display User Tweets
• WebSockets
• Overview
• 1. Add WebSocket Support
• 2. Send Client ID to API
• Publishing
• Overview
• 1. Create Production Build
• 2. Deploy to Production
• 3. Create Production Config
• 2. Redeploy to Production
• Next Steps
• Overview
• Misc
• Installing Node
• Completed Project

Optimistic Updates: Overview

In this section we'll update our application to immediately display tweets that we create at the top of the feed, and we'll also address some of the challenges that we need to solve for when performing these types of optimistic updates.

At the end of this section your application will look like this (visually identical):

What are optimistic updates?

Optimistic updates are the act of displaying changes to data before the server has confirmed that the desired create, update or delete action was successful.

For example, when a user creates a tweet, it takes time for that request to be sent to the API server, get saved to the database, and make it back to the browser to confirm the tweet was created.

If an application chooses to wait until the server confirms the request before displaying the tweet, then it has a couple options for what type of experience to provide:

• One option is to display a "saving experience" to the user, and prevent them from interacting with the application further until the request comes back.

• Another is to submit the request, but make no changes to the application until the request comes back, at which point the data will suddenly "show up" in the application.

The first experience asks the user to wait, but makes it fairly straight forward to communicate and address errors if one occurs.

The second experience does not ask the user to wait, but it does makes error handling more difficult, and can also make the application feel unresponsive and "broken" depending on how long the request takes.

A third option is to display changes to data as soon as they're submitted, meaning that when the user creates data, you insert into the application immediately, and if they update or delete data, you show that change as if it's instantaneous.

This type of experience is referred to as an "optimistic update" because we're optimistic the request will be successful, and are comfortable showing the user an experience that assumes it will be.

It's not appropriate for all situations, and it doesn't necessarily make error handling any easier, but it can provide a feeling of responsiveness to the application. And that's what we'll be exploring in this section.

Next Steps

Ready? Let's get started!