Try migrate link suggestions to use Core Data

[getdave]

What?

Implements a selector for fetching link suggestions and utilises in <LinkControl>.

Why?

Currently LinkControl calls the fetchLinkSuggestions function directly. This means we don't get the benefits of caching and in Core Data so for each editor session the data is refetched for identical queries.

How?

Implements a Core Data selector which proxies to the original fetchLinkSuggstions under the hood. The benefit is now we get caching for free.

Alternatives Considered

Alternative approaches might be:

• don't do this at all - it might be fine as it is 🤷‍♂️
• implement a dedicated Block Editor REST API endpoint for "Link Suggestions". Then implement related Core Data selectors. This will avoid the need for multiple queries to the "search" endpoint and allow it to be customisable by extenders.

Testing Instructions

• Open devtools Network tab and filter by XHR and search.
• New Post
• Type text and select a portion of it
• CMD + K to make a link
• Now type Sample. You should see search results shown after a short loading delay in UI and network tab.
• Clear the search input.
• Type Sample again. This time there should be no loading delay and results should show instantly. Also no additional network requests should be dispatched.

Testing Instructions for Keyboard

Screenshots or screencast

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core.
• Labels found: [Package] Core data, [Feature] Link Editing.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[getdave]

We should make this private. But I wasn't sure how to unlock a resolveSelect.

[getdave]

This should be a private API.

[getdave]

If we make this private how do we unlock a resolveSelect?

[ellatrix]

Why not use a normal select call in a useSelect?

[getdave]

If we did this then we'd effectively pass something like getEntityRecords as a setting. We can't pass the result of a selector call because we need different args per invocation.

I think I tried doing this and found it didn't work. I could be wrong - would you expect it to?

[getdave]

I don't think this indexing strategy is good enough. A search is a simple string but the API allows for searching by different entities such as post, page...etc. So if we just index by the search you could accidentally receives results for the wrong content type.