Gutenberg: API Fetch fetch-all middleware can not be prefetched.

[spacedmonkey]

The fetch-all middleware, loads all pages of an API request, if -1 is passed. To do this, it uses, parse: false to get headers and total page headers. However requested that are parse: false are not prefetched. See this line. It would be amazing if this change, so the something like users, could be prefeteched.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

[TimothyBJacobs]

Previously #22510. cc @epiqueras.

[epiqueras]

Didn't that PR fix it?

[spacedmonkey]

I don't see how it would.

See the all to get first 100.
https://github.com/WordPress/gutenberg/blob/5078c43a3d72eded68d94488dbe6093454815a0e/packages/api-fetch/src/middlewares/fetch-all-middleware.js#L61-L67

To see headers, parse: false, is passed.

But in the preload middleware, parse: true, is required.
https://github.com/WordPress/gutenberg/blob/5078c43a3d72eded68d94488dbe6093454815a0e/packages/api-fetch/src/middlewares/preloading.js#L48-L50

I think we can fix this issue with https://github.com/WordPress/gutenberg/issues/23674

[epiqueras]

What happens if we just change parse to true there?

[spacedmonkey]

What happens if we just change parse to true there?

The reason parse: false, is sent here, as to get the next page, you need to get the headers for the request that contain the next page link ( using a function called getNextPageUrl ). See this example.

See link field above ^

Using enveloping would simple fix this.
Adding ?_envelope=1 to a request, means that headers, status and body are returned in the body of the request. Take this example.

Meaning parse: true could be set and still get the next page url from the body of the request, instead of the header.

[epiqueras]

Got it, that makes sense.

[spacedmonkey]

@epiqueras Are you interesting working on a PR for this?

[epiqueras]

I can see other ways to make this work without making an envelope option. What are the third party use cases for envelope?

[TimothyBJacobs]

The main use case, AFAIK, for envelope is for scenarios where the user cannot access the headers of a response. If we can make preloading work with parse: false I think that would be ideal.

[epiqueras]

When would they need the headers to be preloaded like that?

[TimothyBJacobs]

For stock core, the pagination headers themselves. So you can preload how many items are in a list. In more custom use cases, the defacto way to add information to a collection response in the REST API is via headers.

[epiqueras]

Got it. So making preloading work with parse: false would remove the need for an envelope parameter.

[TimothyBJacobs]

Yep!

[epiqueras]

@TimothyBJacobs @spacedmonkey

I'm trying to implement this, but rest_preload_api_request is not returning headers as expected:

[TimothyBJacobs]

That looks right to me. Not all of the responses have additional headers, the types and taxonomies endpoints don't support pagination so they don't add any.

Were there other headers you were expecting?

[spacedmonkey]

Seem right to be also. Not all requests have headers. Like type, but I can see headers in wp/v2/themes for example.

[epiqueras]

The Fetch All Middleware needs the Link header.

[spacedmonkey]

The Fetch All Middleware needs the Link header.

Not all the requests are using Fetch All Middleware anyway. Types don't need those headers, are they are not paginated. Also, these requests would not be return headers currently.

[TimothyBJacobs]

Hm, I'm seeing the Link header in my tests.

rest_preload_api_request([], '/wp/v2/posts');
=> phar:///usr/local/Cellar/wp-cli/2.4.0/bin/wp/vendor/wp-cli/shell-command/src/WP_CLI/Shell/REPL.php:52:
array(1) {
  '/wp/v2/posts' =>
  array(2) {
    'body' =>
    array(10) {
      [0] =>
      array(24) {
        ...
      }
      [1] =>
      array(24) {
        ...
      }
      [2] =>
      array(24) {
        ...
      }
      [3] =>
      array(24) {
        ...
      }
      [4] =>
      array(24) {
        ...
      }
      [5] =>
      array(24) {
        ...
      }
      [6] =>
      array(24) {
        ...
      }
      [7] =>
      array(24) {
        ...
      }
      [8] =>
      array(24) {
        ...
      }
      [9] =>
      array(24) {
        ...
      }
    }
    'headers' =>
    array(3) {
      'X-WP-Total' =>
      int(269)
      'X-WP-TotalPages' =>
      int(27)
      'Link' =>
      string(58) "<http://trunk.test/wp-json/wp/v2/posts?page=2>; rel="next""
    }
  }
}

[epiqueras]

Not all the requests are using Fetch All Middleware anyway. Types don't need those headers, are they are not paginated. Also, these requests would not be return headers currently.

This issue is about supporting preloading for requests made by the Fetch All Middleware. To do this, we need the Link headers.

Hm, I'm seeing the Link header in my tests.

Try logging the preloaded data the editor is bootstrapped with.

[TimothyBJacobs]

There isn't a collection route in edit-form-blocks.php so I added one. It looks right to me:

Do you have less than one page of pages?

[epiqueras]

Do you have less than one page of pages?

That was it.