• I am creating/developing a new plugin for which I am leveraging an external data source. I have created a custom store in support of this and have a resolver that does an api-fetch. I have discovered that the block is performing tens of thousands of renders during the await period and is predictably killing performance. I know this because I am counting my renders and are all occruing during that fetch period.

    I have used the same exact pattern for my store that is in the WordPress Core Data store. Note that I have created console.log messages to track both the current position of execution as well as to provide placeholders for additional functionality. The code follows:

    
    import { addQueryArgs } from "@wordpress/url";
    import apiFetch from "@wordpress/api-fetch";
    
    export const getTable =
        (id) =>
            async ({ dispatch }) => {
                console.log('            ...Resolver - Before fetch');
                try {
                    const path = addQueryArgs('dynamic-tables/v1/table?tableId=' + id);
                    console.log('            ...Resolver - API Call - ' + path);
                    const table = await apiFetch({ path });
                    console.log('            ...Resolver - After fetch - returned table - ' + JSON.stringify(table));
                    console.log(table);
                    dispatch.receiveTable(table, id);
                } catch (error) {
                    console.log('            ...Resolver - async error - ' + error);
                }
                console.log('            Resolver - async completed');
    
            }

    One thing I have noted is that some (but not all) core resolver definitions include a scheme to support “lock/unlock”. I have not included this because that code is marked not only as experimental, but labeled in such a way that suggests it is guaranteed to break on upgrades.

    I would be very appeciative of any help that can be provided, either by way of something to add OR in suggesting an alternate development pattern. Any changes I would make would be trying to find a needle in a haystack because I don’t know the cause of the renders. It could be that my code does not implement React/Redux properly. However, I think it more likely that there are things going on within the Editor that, when combined with my store, create unknown side effects.

    • This topic was modified 1 year, 1 month ago by Greg Schaub.
    • This topic was modified 1 year, 1 month ago by Greg Schaub.
Viewing 3 replies - 1 through 3 (of 3 total)
  • Thread Starter Greg Schaub

    (@glschaub)

    Hello – is anyone able to assist with this?

    Sorry you didn’t get an answer for so long. Unfortunately, there are only a few people here in the forum who are familiar with React in the block editor. Sometimes you have more success with stackoverflow.

    But I know your problem. Unfortunately, the call is not recognisable in your code. I suspect this is the cause.

    In my plugins, I call such API endpoints as follows (only a minimal example):

    useEffect(() => {
    			dispatch('core').addEntities([
    				{
    					name: 'example', // route name
    					kind: 'mycpt/v1', // namespace
    					baseURL: '/mycpt/v1/example' // API path without /wp-json
    				}
    			]);
    		}, []);
    		let result_array = useSelect((select) => {
    				return select('core').getEntityRecords('mycpt/v1', 'example') || [];
    			}
    		);

    Maybe this already helps you. If not, please show your entire source code so that it can be reconstructed if necessary.

    • This reply was modified 1 year, 1 month ago by threadi.
    Thread Starter Greg Schaub

    (@glschaub)

    @threadi, thanks so much for your reply. I was able to work this out. I had created a custom store to use in place of the core data store because I’m using a custom database table. With that said, I’m still having challenges running those stores side-by-side with mutual dependencies (i.e., the table and related block need to be aware of each other).

    I’d be interested if you have thoughts on a better architecture that makes it easier to synchronize the custom table with the native block.

    ps. That code was from a WP Redux resolver that calls an action creator. I’m new to thunks and I’m still trying to fully understand them.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘apiFetch async causing thousands of renders’ is closed to new replies.