Fix template part selection searches to use title/area instead of slug/theme. #31520
Conversation
|
Size Change: +2.11 kB (0%) Total Size: 1.31 MB
ℹ️ View Unchanged
|
Addison-Stavlo
changed the title
Addison-Stavlo
added
[Block] Template Part
Addison-Stavlo
requested review from
vindl,
jeyip,
mattwiebe,
david-szabo97,
Copons,
creativecoder and
jameskoster
|
Possible bug: I'm not seeing any TPs until I search:
|
Are you on the latest commit? (398fd8e) - I noticed this as well from the general placeholder and that most recent commit should have fixed it. |
|
Fixed :D |
packages/block-library/src/template-part/edit/selection/template-part-previews.js
Outdated
Show resolved
Hide resolved
|
It's acting a bit weird for me 🤔 Huge empty spaces and it only shows a single template part when the search input is empty. Screen.Recording.2021-05-07.at.11.06.59.mov |
…te-part-previews.js Co-authored-by: Dávid Szabó <[email protected]>
Im not sure I follow?
I assume this is because you inserted the general/uncategorized placeholder ("Template Part" in the inserter). This would then only show other template parts of the same area (general/uncat) before typing in the search input. So you are seeing your 1 template part that is of that area, which seems to have no content. Try inserting a "Header" or "Footer" variation block from the inserter, it should show those variations instead when opened. |
Oh, where the previews should be that disappear after a split second? I think thats a result of the useAsyncList implementation that renders placeholders (the blank items) while it loads in the previews in. That way the previews populate in an ordered manner as opposed to all trying to load in at the same time making a very jumpy and unordered experience. I don't think this PR has changed anything with that.
I wonder if the general/uncategorized case should show ALL areas by default instead of just other general/uncategorized ones. Maybe in just the placeholder state and not in the established block state? or both? Any thoughts on this @jameskoster ? |
|
Hmm, yes I think my expectation would be that a "Template Part" block would act as a base layer and provide access to all template parts as a default. So in the case of something like a Header, I could insert the "Header" block directly, or insert the Template Part block and choose Header. |
Makes sense to me! Updated. |
|
With the latest changes, it feels a lot better!
Gotcha, it's not a pleasant experience. Hopefully we can fix this somehow in the future. I'm not quite sure it's related, but I'd expect the Replace to not show (or disabled) the current template part in the list. This is the
|
Awesome!
Yeah, im not sure the solution in this specific circumstance. Maybe showing gray boxes instead of white space will help visually, although it will still be jumpy as they load in as we can't accurately predict the height of the preview before its loaded. 🤔 Moving this flow to a different type of component such as a modal or something else with fixed height may feel better. I would expect we need to re-design this interaction and UI overall at some point.
Good point. It has always been like this since its really the 'selection' component being used in a replacement context with no special case for it. Im not sure the best solution design wise. Not showing any results may feel odd, and showing a result that is disabled/not clickable might be a bit odd as well? I guess its 'kind of' disabled in that if you do select it nothing really happens. |
|
Good spot @david-szabo97, I agree that the selected template part should not appear in the replacement list at all. And if there are no replacement TPs available, the "Replace" button itself should also be hidden. |
|
@jameskoster - 👍 Il open a follow up for these: limiting this PR to more of a bug fix for the search input and the follow up to polishing its replace functionality a bit more. I think we can hide the currently used template part from the results. However, I have some concerns about disabling the 'replace' button (explained more below). Now, the combination of these could result in the user opening 'replace' to see zero options by default (but have the ability to search others via the input). Maybe the zero default results isn't an issue if we label things properly? 🤔 Hiding 'replace' if there are no other areas of that type: This will restrict capabilities since folks are able to use the search input to find template parts of any type. Imagine the user created a template part they wanted to be a header, but forgot to assign its Stepping back - what are your thoughts on this component in general? Does it seem like it needs a re-design at some point overall? I think it was tossed together about a year ago when FSE and template parts were a bit different, with little (or no) design input. It may make sense to rethink it from the ground up at some point? |
Good question. At a high level I'm inclined to say that easy swapping of But since the scope for That brings us to searching... it seems unlikely to me that a given site will have so many headers or footers that searching will be useful in any practical way. And if we say that All said and done, it is probably best if we can concentrate search activities around the existing affordances, IE the search input in the Inspector, and the slash command quick inserter. |
|
Yeah, while the search input can be useful for me at times (ive created TONs of blank or converted TPs just from PR testing), its unlikely that a user will have that many (but who knows? 😆 ). Id expect the end state of this component may not need that. And also remember, this component is not only about 'replacement'. Its also about 'selection' when we insert a Header/Footer/General block. Id expect the desired flow in the end would be something a bit different than a dropdown with a search input (whether thats finding the desired template part in the inserter somehow, or having a different component than this to preview/select.) |
Description
Currently, the template part selection search filters based off of
slugandthemevalues.slugis no longer appropriate as all custom template parts have a slug of the formtemplate-part-*, and only the title is editable and visible by the user. Therefore the search input should now work based off of the title instead of the slug.themeis also no longer appropriate as all results are returned for the active theme. Instead, we can replace this with the newareaterm which will allow both searching by area and label the results such that a user knows if the item corresponds to a different area.New behavior:
Note that the future of this selection interface is uncertain and may go through redesign or get scrapped altogether, so its probably not worth investing too much time into currently. However, it is important that it at least continues to work with the more recent changes in FSE.
How has this been tested?
Check the following through both the placeholder 'choose' button ( block inserter -> header, footer, or template part) and through the block toolbar's "replace" button.
areaare shown by default in the selection component.titleworks as expected and that search results are labeled by their area.areaworks as expected.Screenshots
Types of changes
Checklist:
*.native.jsfiles for terms that need renaming or removal).