• 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

Data Structure: Overview

In this section we'll learn about the data structure Lore uses and then create our Tweet component using mock data. At the end of this section your application will look like this:

Lore's Data Structure

Lore has a particular structure it uses to represent data in your application. To illustrate that, take a look at this example Tweet component.

import React from 'react';
import createReactClass from 'create-react-class';
import PropTypes from 'prop-types';

export default createReactClass({
  displayName: 'Tweet',

  propTypes: {
    tweet: PropTypes.object.isRequired
  },

  render() {
    const { tweet } = this.props;

    return (
      {/* render tweet */}
    );
  }
});

import React from 'react';
import PropTypes from 'prop-types';

class Tweet extends React.Component {
  render() {
    const { tweet } = this.props;

    return (
      {/* render tweet */}
    );
  }
}

Tweet.propTypes = {
  tweet: PropTypes.object.isRequired
};

export default Tweet;

import React from 'react';
import PropTypes from 'prop-types';

class Tweet extends React.Component {

  static propTypes = {
    tweet: PropTypes.object.isRequired
  }

  render() {
    const { tweet } = this.props;

    return (
      {/* render tweet */}
    );
  }
}

export default Tweet;

This component receives a prop called tweet and then renders that tweet. But before we can do that, we first need to know what the data structure of the tweet looks like.

In Lore, all resources have a data structure that looks like this:

{
  id: 1,
  cid: 'c1',
  state: 'RESOLVED',
  data: {
    id: 1,
    user: 4,
    text: "Where have they been keeping her!?",
    createdAt: "2016-10-17T23:13:07.249Z",
    updatedAt: "2016-10-23T23:13:07.281Z"
  },
  error: {}
}

When Lore retrieves data from an API endpoint, such as /tweets/1, it embeds the attributes from the API response in the data property, and then wraps those attributes in a structure that provides some metadata about that resource.

At first glance, this might seem a little verbose, but each property exists to solve a specific problem, which you can read more about here if you'd like.

For this Quickstart, all you need to know is that the data structure is designed to solve application concerns related to optimistic updates, visual communication, server errors, and detecting when resources have been created - all important elements for providing a good user experience.

For endpoints that return a list of resources, such as /tweets, Lore uses a similar data structure:

{
  state: 'RESOLVED',
  data: [
    {...data in structure displayed above...}
  ],
  query: {},
  meta: {},
  error: {},
}

In this structure, data is an array that contains a list of individual resources, each using the data structure we described previously.

Additionally, this structure also provides metadata about the list such as what query was made to the API, and what the state of that query is (such as whether the data is still being fetched or the query has been resolved).

Next Steps

In the next step, we'll use this structure to add some mock data as we build the Tweet component.