Resource List

Resource lists show a collection of objects of the same type in a list, such as a list of products. Resource lists are made up of individual resource items. Each item provides a summary of the object and normally links to a detail page.


Can be used to display a list of simple resources.

Drag to resize example
class ResourceListExample extends React.Component {
  render() {
    return (
              url: '#',
              attributeOne: 'How to Get Value from Wireframes',
              attributeTwo: 'by Jonathan Mangrove',
              attributeThree: <TextStyle variation="subdued">Today, 7:14pm</TextStyle>,
              url: '#',
              attributeOne: 'Test blog post',
              attributeTwo: 'by Jonathan Mangrove',
              attributeThree: <TextStyle variation="subdued">Jan 14, 2016, 8:24am</TextStyle>,
              badges: [
                {content: 'Hidden'},

  renderItem = (item, index) => {
    return (
      <ResourceList.Item key={index} {...item} />
Item data; each item is passed to renderItem
(item: any, index: number) => undefined
Function to render each item
(item: any, index: number) => React.ReactNode
Function to generate unique identifier for each item passed

Resource list details

Resource items contain 3 main elements: attributes, exceptions, and secondary actions:

  • Attributes are the consistent pieces of content that merchants need to see on each resource item. The standard resource item takes three text attributes and a status badge.
  • Exceptions are a list of out-of-the-ordinary states or attributes. Use them to bring awareness to important information at the level of the list view. Merchants should still navigate to a detail page get full context and actually deal with any issues.
  • Secondary actions allow merchants to perform up to two actions on the object directly from the list, without navigating to a detail page.

Best practices

Resource lists should:

  • Present objects of the same type

Resource list items should:

  • Provide enough attributes to identify a particular item among the others.
  • Link to a detail page for the item.
  • Present a status badge only when the object state requires action. Don’t show a status badge if the object has a “normal” status. For example, show a status badge of Hidden only on unpublished blog posts.
  • Only use subdued text for empty attributes (e.g. “No supplier”, “No expected date”) or on timestamps.
  • Surface key exceptions on items at the level of the list view. Merchants should still navigate to a detail page for full context and to act on exceptional circumstances.
  • Only provide secondary actions if they represent common actions. Don’t provide more than two secondary actions.
  • If a detail page can’t be provided:
    • Make sure secondary actions are set to be persistent so the actions are available to people on mobile devices.
    • Don’t show any exceptions.

Content guidelines


Attributes should:

  • Be as short as possible.

On a list of orders, the order number alone provides enough context.

  • #1234

  • Order number #1234

  • Use additional text to clarify their meaning when their value isn’t obvious on its own.

On a list of gift cards with an initial value and a balance:

  • Value $200.00
    Balance $128.34

  • $200.00

On a list of blog posts:

  • by John Doe

  • John Doe

  • When adding additional text to clarify what an attribute means, don’t use colons if the text is equally clear without. Only use a colon when necessary.
  • By John Doe

  • Author: John Doe

  • Category: News

  • Category News

  • News category


Each exception entry is composed of a short title and an optional description.

Exception titles should:

  • Be short and convey the key information about the exception (e.g.“High fraud risk”, “Not published on 2 channels”).

Exception descriptions should:

  • Provide additional detail and are truncated on small screens.
  • Separate lists of phrases with commas (e.g. “Suspicious bank, high order value, unverified shipping address”).

Secondary actions

Secondary actions should:

  • Follow the same guidelines as the button component.
  • Use a single verb as their label, since the object on which they act should be the list item itself (e.g. “Edit”, “Delete”). Secondary actions should use the {noun} + {verb} format when necessary to avoid ambiguity (e.g. “View listing”).