• 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

Convention over Configuration

As you'll soon see, we now have all the code required to fetch tweets from the API. Lore accomplishes this using a design paradigm called convention over configuration.

In the simplest sense, what this means is that the framework makes some assumptions about what you want, and then provides you with the ability to override those assumptions if you need to.

If you'd like to see some of this functionality demonstrated now, and are comfortable using the console provided in the developer tools for your browser, feel free to follow along with the steps below.

If not, feel free to skip this step. It is entirely optional.

Console Demo: Actions

To get started, refresh the browser and open the developer console. Then enter this command into the console:

lore.actions.tweet.find()

When you created the tweet model Lore assumed you wanted a set of actions that could find, create, update and delete tweets. After creating these actions, it attached them to an object found at lore.actions.tweet.

The command you just entered invoked the find action to fetch tweets from the API, and if you examine the network tab, you'll see a GET request was sent to http://localhost:1337/tweets.

The URL for this API call was composed from a convention, which defaults to "pluralize the model name and append it to the apiRoot", but you can change this convention as needed by modifying the properties in the tweet model.

You can also fetch tweets by a specific user, by providing an object of query parameters to the find() method like this:

lore.actions.tweet.find({
  userId: 1
})

If you examine the network tab again, you'll see a GET request was sent to http://localhost:1337/tweets?userId=1.

Console Demo: Reducers & Store State

In addition to creating a set of actions, Lore also produces a set of reducers that store the tweets returned by the API. For example, to see a list of the tweets that have been returned, enter this command into the developer console:

lore.store.getState().tweet.byId

You should see a response that looks similar to like this:

1: {id: 1, cid: "c1", state: "RESOLVED", error: {…}, data: {…}}
2: {id: 2, cid: "c2", state: "RESOLVED", error: {…}, data: {…}}
3: {id: 3, cid: "c3", state: "RESOLVED", error: {…}, data: {…}}
4: {id: 4, cid: "c4", state: "RESOLVED", error: {…}, data: {…}}
5: {id: 5, cid: "c5", state: "RESOLVED", error: {…}, data: {…}}
6: {id: 6, cid: "c6", state: "RESOLVED", error: {…}, data: {…}}
7: {id: 7, cid: "c7", state: "RESOLVED", error: {…}, data: {…}}

What you're looking at in the example above is an object containing every tweet that's been returned from the API, stored using their id as the key.

And if you enter this command:

lore.store.getState().tweet.find

You'll be able to see an object containing the result of every query asked of the /tweets endpoint, using the query as the key:

{"where":{"userId":1},"pagination":{}}:{state: "RESOLVED", error: {…}, data: Array(1), query: {…}, meta: {…}}
{"where":{},"pagination":{}}:{state: "RESOLVED", error: {…}, data: Array(7), query: {…}, meta: {…}}

While this is certainly useful (we just got a lot of functionality by writing very little code), we can still do one better.

In the next section we'll learn how components can declare what data they need, and see how the framework can orchestrate calls to these actions and reducers to give us what we need automatically.

Next Steps

Next we're going to see these in actions, and connect our Feed to get real data.