Chrome: Load more than 10 tags/categories

[youknowriad]

closes #1338 #1431

The REST API can't return all the tags/categories in one request, this makes writing selectors very hard. So here are the fixed proposed in this branch:

• When loading the tags selector, trigger a request for the selected tags
• When typing, trigger a throttled request with the search parameter
• Load 100 categories

For the categories selector, we'd have to rewrite completely (maybe with virtual scroll, something like Calypso) to load paginated categories but I think this is sufficient for now.

[jasmussen]

Experience wise, I think this works nice enough 👍

But I got a few errors in the console by making a whole slew of new tags:

[youknowriad]

@jasmussen weird, I can't reproduce these errors. Any particular step to follow?

[jasmussen]

I suspect this may be one of them docker/nginx rest api issues like I had with publishing back in the day. Recorded this video:

https://cloudup.com/c1Q_OGpo0K1

[youknowriad]

@jasmussen mmm right, did you try to permalink trick?

[jasmussen]

This is my setting, unchanged since I applied that trick initially:

[youknowriad]

@jasmussen can I ask you to expand these failing network responses to see the full response?

[jasmussen]

Here's a video showing me looking at some network stuff:

https://cloudup.com/cSAEwSl9XI5

Looks like two request types were failing.

1. tags?per_page=100&orderby=count&order=desc&search=f

Request Headers
Provisional headers are shown
Accept:application/json, text/javascript, */*; q=0.01
Referer:http://localhost/wp-admin/admin.php?page=gutenberg-demo
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
X-Requested-With:XMLHttpRequest
X-WP-Nonce:336df89cac

Request URL:http://localhost/wp-json/wp/v2/tags?per_page=100&orderby=count&order=desc&search=f
Referrer Policy:no-referrer-when-downgrade

2. tags

Request URL:http://localhost/wp-json/wp/v2/tags
Request Method:POST
Status Code:500 Internal Server Error
Remote Address:127.0.0.1:80
Referrer Policy:no-referrer-when-downgrade

Request headers:

POST /wp-json/wp/v2/tags HTTP/1.1
Host: localhost
Connection: keep-alive
Content-Length: 16
Pragma: no-cache
Cache-Control: no-cache
Origin: http://localhost
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Content-Type: application/json
Accept: application/json, text/javascript, */*; q=0.01
X-Requested-With: XMLHttpRequest
X-WP-Nonce: 336df89cac
Referer: http://localhost/wp-admin/admin.php?page=gutenberg-demo
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8
Cookie: wordpress_test_cookie=WP+Cookie+check; wordpress_logged_in_86a9106ae65537651a8e456835b316ab=joen%7C1499248543%7CLZhFHBuJHWu7e9crdjL5OALq8di8lpX1WvM1CrcQi4m%7C0951cd0003f04c09f3223db235fa3b91f8af90996b99c68ae23f1c57edf11bd1; _pk_id.1.1fff=1d85fee6ffa42e96.1494189314.10.1498058942.1498058580.; wp-settings-1=unfold%3D1%26mfold%3Do%26libraryContent%3Dbrowse; wp-settings-time-1=1498554750

Response headers:

HTTP/1.1 500 Internal Server Error
Server: nginx/1.13.0
Date: Wed, 28 Jun 2017 08:18:39 GMT
Content-Type: application/json; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/7.0.18
X-Robots-Tag: noindex
Link: <http://localhost/wp-json/>; rel="https://api.w.org/"
X-Content-Type-Options: nosniff
Access-Control-Expose-Headers: X-WP-Total, X-WP-TotalPages
Access-Control-Allow-Headers: Authorization, Content-Type
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
X-WP-Nonce: 336df89cac
Allow: GET, POST
Access-Control-Allow-Origin: http://localhost
Access-Control-Allow-Methods: OPTIONS, GET, POST, PUT, PATCH, DELETE
Access-Control-Allow-Credentials: true
Vary: Origin

Not sure how helpful that is, but hope it helps a bit. Let me know if I can help in any other way.

[youknowriad]

I see some cancelled requests on the recording. These are not bugs, I explicitly cancel "search" requests if the user types something else.

But the 500 errors while creating tags, that's an issue, could you hit the response tab after selecting the request to see the response body?

[jasmussen]

Checked. Here's the response:

{"code":"term_exists","message":"A term with the name provided already exists in this taxonomy.","data":55}

Video:

https://cloudup.com/ccYPcpcmkva

So yeah, looks like my monkey fingers tapping in the same tags over and over again is causing headaches. But that shouldn't cause 500s and js errors should it?

[youknowriad]

@jasmussen ok Got it now, Thanks for the details. I'll try a fix :)

[youknowriad]

So the issue is hard to reproduce, you need to try to add an existing tag than hasn't been fetched yet. I pushed a fix, you may still see failing requests but they are correctly handled now, if the term already exists we fetch it instead of creating it.

[jasmussen]

It seems to be working better, but I'm still seeing a bunch of console errors:

Edit: Got the same response for the failing "tags" request: {"code":"term_exists","message":"A term with the name provided already exists in this taxonomy.","data":70}

[youknowriad]

@jasmussen Yes this is normal.

If you add tags manually we trigger a request to create these tags, if they already exist the network request will fail, but it's caught properly and we trigger a "fetch tag" request to retrieve the existing corresponding tag.

We can't do the alternative (fetching by name and creating if it doesn't exist because the API is not suited for it).

[jasmussen]

If the js errors don't break anything and we're okay with them, then I'm okay with them too 😉

[ellatrix]

Is there no way we can not let it error?

[youknowriad]

@iseulde I'm catching the failed promise, I guess browsers display all failing network calls. Open to suggestions

[youknowriad]

Anyway, I think we should merge this since it resolves several problems.

[nylen]

A couple of things here:

• This term_exists error definitely should not be a 500. This is a core issue. Fixing this might also cause the error messages in the console to go away, I'm not sure.
• Should we optimize for the case where a tag already exists instead? (e.g. GET /wp/v2/tags?slug=whatever, then create the tag if that request fails) This seems like a more common situation, though I am not sure under what circumstances an existing tag would not be loaded.

[youknowriad]

Should we optimize for the case where a tag already exists instead? (e.g. GET /wp/v2/tags?slug=whatever,

• I thought about this but the user types the name of the tag, not its slug. We'd need /wp/v2/tags?name=whatever

I am not sure under what circumstances an existing tag would not be loaded.

• A tag won't be loaded if it's not in the first page (100 first tags) and if the search request triggered is still in flight

[nylen]

OK, sounds like it's not a big deal either way. We can get the HTTP 500 fixed though - please let me know if you see any more of those.

More generally, there is a lot of AJAX logic in these components already, and the logic here isn't very ____able. It looks like we're ready to implement a more generic data layer/strategy and refactor this.

[youknowriad]

It looks like we're ready to implement a more generic data layer/strategy and refactor this.

I totally agree. we'd need to settle on an approach for the Data Layer, Maybe QueryComponents and effects is the most logical approach even if I'd love GraphQL (not battle tested yet). Let's make a decision in #902

[nylen]

I reported the HTTP 500 error here at https://core.trac.wordpress.org/ticket/41370