Experimental Link creation interface#17846
Conversation
|
Cool PR ❤️ |
Previously it wasn’t possible to customise the render of the search suggestions. By providing an optional render prop we now have full control over this if required.
…s render Previously we relied on our own render of suggestions but this wasn’t hooked up to all the accessibility enhancements afforded by URLInput. By utilising the render prop exposed by URLInput to customise the rendering of suggestions, we can have the best of both worlds.
This is required to display the type of entitity in the search results for LinkControl
Previously when using the `renderSuggestions` render prop the user had to know how to put together the correct props on the correct elements in their custom render. By passing the default props for the listing element and the item element we can relieve the user of this burden by allowing them to spread the props onto the appropriate elements in their render without having to know how they are created.
Previously when a URL was entered it was deemed that no suggestions should or could be found and so the process of fetching suggestions was short circuited. Add additional prop to optionally allow developers to have URL-like values handled as suggestions.
…tcher If the current value of the input is a URL then we conditionally pass a different handler for search results to the URLInput component. For URL based values we immediately return a “suggestion” object with values matching those entered by the user. Non URL based values are handled as previously.
We cannot assume the suggestion `id` will be unique. This is because at the moment the search results are `Post`s. However in the future we may also need to include `Category` terms and the term IDs could easily clash with the Post IDs as they are in different DB tables. Using the `type` to differentiate the key. Addresses #17846 (comment)
Previously `buildSuggestionItemProps` was including a key. However the implementation of `LinkControl` changed so that this was not required. However we forgot to reinstate on `URLInput`. This update ensures a key prop is set on the default output. Note that disabling of the autofocus linting was already in place: https://github.com/WordPress/gutenberg/blob/04e142e9cbd06a45c4ea297ec573d389955c13be/packages/block-editor/src/components/url-input/index.js#L239 Addresses #17846 (comment)
Also fixes eslint errors that kept me from committing the original changes
Props @talldan I really hope those changes I had to make in `search-input.js` don't break anything.
talldan
left a comment
There was a problem hiding this comment.
Thanks for all the hard work on this @getdave, @marekhrabe, @obenland, @retrofox!
I think it's in a good state to merge now. Any additional changes can be handled in separate smaller PRs.
|
Seems to be an issue with Travis/Github. The check says 'Canceled', but when you click into it everything (required) has passed. Merging this in spite of the weird status check.
|
|
Thanks @talldan and thanks for all your efforts and patience on this one 🎉🎉 🎉 🎉 🎉 🎉 |
| isFullWidth, | ||
| hasBorder, | ||
| __experimentalRenderSuggestions: renderSuggestions, | ||
| placeholder = __( 'Paste URL or type to search' ), |
There was a problem hiding this comment.
These new props should be documented.
See also: #11852
| id: '-1', | ||
| title: value, | ||
| url: type === 'URL' ? prependHTTP( value ) : value, | ||
| type, |
There was a problem hiding this comment.
Was there any planned usage for the various types associated with manual entry? As part of the ongoing discussion in #18061, I've been considering whether this is something where the explicit absence of the type could be a reasonably good indicator on its own for marking a value as "manual entry". The sorts of things that someone might want to do with type should be equally achievable with the @wordpress/url utilities, if a developer were so inclined. One of the issues I encountered in #19827 was trying to decide what the best complete set of these "subtypes" should be, where we would probably be better off to just not have to answer that.
There was a problem hiding this comment.
Was there any planned usage for the various
types associated with manual entry? As part of the ongoing discussion in #18061, I've been considering whether this is something where the explicit absence of the type could be a reasonably good indicator on its own for marking a value as "manual entry". The sorts of things that someone might want to do withtypeshould be equally achievable with the@wordpress/urlutilities, if a developer were so inclined. One of the issues I encountered in #19827 was trying to decide what the best complete set of these "subtypes" should be, where we would probably be better off to just not have to answer that.
Follow-up: #20051
This PR is a working prototype for a potential new UI for adding/editing links.
It is a WIP and is not ready for review.Closes #17557
How has this been tested?
Screenshots
Todo
URLInputtestsURLInput.LinkControl.mailtoandtelprotocol plus internal anchors.ENTERkey when the text input has a value and is focused.Add publish date information to data fetch calls for search - currently, we only get bare-bones info about the found posts (see also above as may be related). Could we add publish date to the REST API in Core?Decided this was not required.aria-hiddento the appropriate elements for entity-based results to avoid URL being read out to screen-readers.httporhttps.(Experimental Link creation interface #17846 (comment)).
line-heightup a little onurlwithin search suggestion items.URLInputtests and check existing implementations across UI to ensure we haven't broken anything.URLInput.URLin the search results.<button>s for each result.(Link interface iteration #17557 (comment)).
Determine whether it's feasible (for an MVP) to have URL search do a lookup of the entered site'sWe agreed this wasn't a hard requirement for an MVP.<title>and favicon.Foobar Pageshould be formatted as "Foobar Page")Testing Instructions
You can test this by
npm run dev- leave this running and switch to a new terminal tabnpm run playground:devfrom the Gutenberg repo root.http://localhost:1234Types of changes
New feature (non-breaking change which adds functionality).
Checklist: