Quickstart

A quick dive into getting started with Lore

Step 2: Parse the Collection

In this step we’ll begin restoring functionality to our application.

You can view the finished code for this step by checking out the server.2 branch of the completed project.

Why is the application broken?

Our application is broken because the API response from the mock API is different than the response from the real API.

The mock API server had a response for /tweets that looked like this:

[
  {...tweet...},
  {...tweet...}
]

But the response from the real API looks like this:

{
  data: [
    {...tweet...},
    {...tweet...}
  ],
  meta: {
    paginate: {
      currentPage: 1,
      nextPage: 2,
      prevPage: null,
      totalPages: 11,
      totalCount: 51,
      perPage: 5
    }
  }
}

The reason for the change is a positive one, as we now have clear metadata that we can use for pagination, but it still breaks our application.

Not to worry though; Lore is designed to be able to adapt to these kinds of breaking API changes, it just needs a little help from you to understand how.

Parse the Collection Response

To fix the application, open config/connections.js. Towards the bottom of the file you'll see a property named collections.

Collections in Lore are the abstraction tier responsible for communicating with API endpoints like /tweets that return array of resources.

You can learn more about collections here.

Nested within that property is a commented out function called parse() that looks like this:

{
  apiRoot: 'http://localhost:1337',
  ...
  collections: {
    properties: {
      // parse: function(response) {
      //   return response;
      // }
    }
  }
}

Like the other config files, this method is commented out because it reflects the default behavior of the framework.

When the /tweets endpoint returns data, that data is passed to the parse() method as the response argument, and this method is expected to return an array of resources.

The default behavior is to return whatever data was provided, and when we were using our mock API, that wasn't a problem, because the original API response was an array of tweets.

But now the array we want is embedded inside the data property of the server response, so we need to override this function to have it return that part of the response.

To do that, modify the parse() method to look like this:

...
  collections: {
    properties: {
      parse: function(response) {
        return response.data;
      }
    }
  }
...

Visual Check-in

If you refresh the browser, you'll see the application is still broken, but now we have a different error in the console:

Invalid call to `getState('user.byId')`. Missing required attribute 'id'.

We'll fix this error in the next step.

Code Changes

Below is a list of files modified during this step.

config/connections.js

export default {

  default: {

    apiRoot: 'http://localhost:1337',

    collections: {
      properties: {
        parse: function(response) {
          return response.data;
        }
      }
    }

  }

}
export default {

  default: {

    apiRoot: 'http://localhost:1337',

    collections: {
      properties: {
        parse: function(response) {
          return response.data;
        }
      }
    }

  }

}
export default {

  default: {

    apiRoot: 'http://localhost:1337',

    collections: {
      properties: {
        parse: function(response) {
          return response.data;
        }
      }
    }

  }

}

Next Steps

Next we're going to continue restoring functionality to the application.