Is there a better way to to make async API calls using the @wordpress/data module?

[aberkow]

Cross post from reddit, but I don't seem to be getting much response there.

I am working on understanding the @wordpress/data module. One of the tasks I set myself was to create a demo app that would (essentially) have two parts:

• a button a user could click on
• a list where articles would be displayed that are fetched from an external API

The list of articles would start out empty. Then when the user clicks the button, the list is populated. The project works, but I'm not sure I've written the functionality in the most efficient way and could use a double check. For reference, I used the official docs and Darren Ethier's series of articles on the subject.

After registering a working block, I wrote this small react app (I've merged everything into one file here for simplicity). I have a working example on codesandox.

I have the following questions that hopefully you all can help me understand better

• I understand that in the ArticleList component, useSelect starts with articles as an empty array from state and then updates when state changes. However, why is it not necessary to pass state into the getArticles selector?
• In the getArticles resolver, is it correct to use the hasFinishedResolution selector? This seemed to be the only way I could get the DEFAULT_STATE to update in the way I wanted.
• I would've thought that I should use some kind of dispatch on the click handler for the button. However, I couldn't seem to create an action creator that made sense (to me) which would work. Is using a select method in a click handler like this valid or an anti-pattern?

Thanks for any help you can give me!

import { render } from '@wordpress/element'

import { createReduxStore, register, useSelect, dispatch, select, } from '@wordpress/data'

const DEFAULT_STATE = {
  articles: [],
}

const actions = {
  fetchFromAPI(path) {
    return {
      type: 'FETCH_FROM_API',
      path
    }
  },
  setArticles(articles) {
    return {
      type: 'SET_ARTICLES',
      payload: articles
    }
  }
}

const store = createReduxStore('my/data-demo', {

  // these are action creators. they return an action object with a type and arbitrary state data
  // they help the app maintain an immutable state
  // they are determined by the dispatch method calls
  actions,

  controls: {
    FETCH_FROM_API: async (action) => {
      return await fetch(action.path).then(res => res.json()).catch(err => console.log({ err }))
    },
  },

  selectors: {
    // the state is implied. it doesn't need to be passed when the selector is called
    getArticles(state) {
      return state.articles
    }
  },

  resolvers: {
    /**
     * 
     * You can pass an arbitrary number of arguments here.
     * The first will always be the state. After that, you can use anything
     * The other arguments _do not_ need to be represented in the selector function. However, that selector must return state
     * 
     * See here for info on hasFinishedResolution - https://unfoldingneurons.com/2020/wordpress-data-store-properties-resolvers
     * 
     * @param {*} state 
     * @param {*} test 
     * @returns 
     */
    *getArticles(state, test) {
      const path = 'https://today.uconn.edu/wp-rest/wp/v2/posts'
      const articles = yield actions.fetchFromAPI(path)

      // wait for the resolver to finish before yielding
      const hasFinishedResolving = select('my/data-demo').hasFinishedResolution('getArticles')

      if (hasFinishedResolving) {
        yield actions.setArticles(articles)
      }

      return
    }
  },

  // the reducer function returns new immutable copies of the state
  // there should be no mutations
  // once the dispatch method is called, the reducer determines how to create a new state object
  reducer: (state = DEFAULT_STATE, action) => {
    switch (action.type) {
      case 'SET_ARTICLES': {
        return {
          ...state,
          articles: action.payload
        }
      }
      case 'FETCH_FROM_API':
        return {
          ...state,
          path: action.payload,
        }
      // if there is no matching action return the state
      default:
        return state
    }
  }
})

register(store)

const ArticleList = ({ state, ...props }) => {

  const { articles } = state

  // selected articles will update when the state changes from the button click
  const selectedArticles = useSelect((select) => {
    // don't pass the state here...
    return select('my/data-demo').getArticles()
  }, [ articles ])

  return (
    <>
      <h1>Latest Articles</h1>
      {
        selectedArticles && (
          <ul>
            {
              selectedArticles.map((article, index) => {
                return <li key={index}>{article.title.rendered}</li>
              })
            }
          </ul>
        )
      }
    </>
  )
}

const App = () => {
  return (
    <>
      <div>
          <button
            onClick={() => select('my/data-demo').getArticles(DEFAULT_STATE) }
          >GET Articles</button>
          <ArticleList state={DEFAULT_STATE} />
      </div>
    </>
  )
}

render(<App />, document.querySelector('#app'))

[Mamaduka]

@adamziel, maybe you can help with this question.

[adamziel]

@aberkow You don't need a custom store if your code is running on today.uconn.edu domain – you can lean on the built-in @wordpress/core-data utilities. Here's a few resources you may find helpful:

• Create your First App with Gutenberg Data.
• Thunks in Gutenberg
• Data layer overview draft
• useEntityRecord helper

I played with your code snippet and here's how the simplest version of these components could look like – note they don't rely on a custom store:

import { useEntityRecords } from '@wordpress/core-data';

const ArticleList = () => {
  const { records: selectedArticles } = useEntityRecords('postType', 'page');

  return (
    <>
      <h1>Latest Articles</h1>
      {
        selectedArticles && (
          <ul>
            {
              selectedArticles.map((article, index) => {
                return <li key={index}>{article.title.rendered}</li>
              })
            }
          </ul>
        )
      }
    </>
  )
}

const App = () => {
  return (
      <div>
          <ArticleList state={DEFAULT_STATE} />
      </div>
   )
}

There is no clickable button, though. Gutenberg will resolve the pages whenever the select() is called for the first time. If you'd like to have that button in place, you could lean on the hasEntityRecords selector that checks whether the data has already been resolved. In this case, your App could look as follows:

import { useState } from '@wordpress/element';

const App = () => {
  const [showArticles, setShowArticles] = useState(false);
  return (
    <>
      <div>
          <button
            onClick={() => setShowArticles(true) }
          >GET Articles</button>
          {showArticles && (
             <ArticleList state={DEFAULT_STATE} />
          )}
      </div>
    </>
  )
}

And if you'd like to use a custom store, here's how one would look like using Thunks:

const store = createReduxStore('my/data-demo', {

  // these are action creators. they return an action object with a type and arbitrary state data
  // they help the app maintain an immutable state
  // they are determined by the dispatch method calls
  actions,

  selectors: {
    // the state is implied. it doesn't need to be passed when the selector is called
    getArticles(state) {
      return state.articles
    }
  },

  resolvers: {
    /**
     * 
     * You can pass an arbitrary number of arguments here.
     * The first will always be the state. After that, you can use anything
     * The other arguments _do not_ need to be represented in the selector function. However, that selector must return state
     * 
     * See here for info on hasFinishedResolution - https://unfoldingneurons.com/2020/wordpress-data-store-properties-resolvers
     * 
     * @param {*} state 
     * @param {*} test 
     * @returns 
     */
    getArticles: (state, test) => async ({ dispatch }) => {
      const path = 'https://today.uconn.edu/wp-rest/wp/v2/posts'
      const articles = await fetch(action.path).then(res => res.json()).catch(err => console.log({ err }));
      dispatch.setArticles(articles)
    }
  },

  // the reducer function returns new immutable copies of the state
  // there should be no mutations
  // once the dispatch method is called, the reducer determines how to create a new state object
  reducer: (state = DEFAULT_STATE, action) => {
    switch (action.type) {
      case 'SET_ARTICLES': {
        return {
          ...state,
          articles: action.payload
        }
      }
      // if there is no matching action return the state
      default:
        return state
    }
  }
}

Regarding your questions:

I understand that in the ArticleList component, useSelect starts with articles as an empty array from state and then updates when state changes. However, why is it not necessary to pass state into the getArticles selector?

Once the store is registered, calling select passes the current state behind-the-scenes for you.

In the getArticles resolver, is it correct to use the hasFinishedResolution selector? This seemed to be the only way I could get the DEFAULT_STATE to update in the way I wanted.

No. hasFinishedResolution is set to true only after the resolver finishes running. The good news is that you may use async/await – see the code examples above.

I would've thought that I should use some kind of dispatch on the click handler for the button. However, I couldn't seem to create an action creator that made sense (to me) which would work. Is using a select method in a click handler like this valid or an anti-pattern?

In Gutenberg, fetching data via an action isn't a very popular pattern. In most cases we use a selector+resolver pair and allow the resolution to be triggered automatically when the selector is called for the first time.

I hope this helps!

[aberkow]

@adamziel Thank you very much! This is extremely helpful. I appreciate the examples where this code would be on the same site as the posts it's fetching. In retrospect, I should've clarified that my example would run on a different site.

That being said, it's the part about being able to use async thunks that clarifies this a lot for me. Clearly I missed this in the docs!