Query and Search blocks: support for Instant Search via query_loop_block_query_vars filter
#67181
+784
−45
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
michalczaplinski
added
[Block] Search
|
Size Change: +442 B (+0.02%) Total Size: 1.83 MB
ℹ️ View Unchanged
|
michalczaplinski
removed
the
[Type] Feature
michalczaplinski
changed the title
query_loop_block_query_vars filterquery_loop_block_query_vars filter
This was referenced Nov 25, 2024
michalczaplinski
requested review from
spacedmonkey and
ajitbohra
as code owners
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
michalczaplinski
requested review from
ObliviousHarmony,
t-hamano,
desrosj,
ellatrix,
gziolo,
adamsilverstein,
talldan,
swissspidy,
peterwilsoncc,
ntwb and
nerrad
as code owners
michalczaplinski
removed request for
nerrad,
adamsilverstein,
luisherranz,
ellatrix,
ndiego,
artemiomorales,
dmsnell,
ObliviousHarmony,
DAreRodz,
kevin940726,
tellthemachines,
fabiankaegy and
t-hamano
|
This is cool to see in core :) To me this highlights the need for a more customizable loading state though. By the nature of search being unpredictable we cannot really preload anything. So the amount of time it takes after each keystroke to get the results loaded more often than not is uncomfortably long. Yes we have the global navigation router loading bar. But that seems inappropriate here as it isn't a full page relead but instead is just updating this interactive region 🤔 This is totally not blocking here but I wonder if there is a way for us to make it much more obvious by either having a sort of spinner in the search bar itself or some overlayed spinner on the post list on a much shorter timer that appears when the router is fetching something. |
That makes a lot of sense. In the pagination navigation, we couldn't add a spinner because it wasn't clear where to put it, so we went with the top loading bar as a general solution. But here, it would be easier to find a place for it in the search bar. |
40 tasks
|
@luisherranz I just attempted to do this in a custom block of mine. Here are my findings:
This here is how I did it: store('example/namespace', {
context: {
isActive: false,
},
state: {
get isLoading() {
const { state: routerState } = store('core/router');
const { isActive } = getContext();
return isActive && routerState.navigation.hasStarted;
},
},
actions: {
*search(event) {
const context = getContext();
const { actions } = yield import('@wordpress/interactivity-router');
{...}
context.isActive = true; // We need to somehow know that we are the reason for the loading state
yield actions.navigate(url.toString());
context.isActive = false; // and then reset it after
},
},
});I think what could solve this if we added a new (I created a PR for this here #67680) |
|
Thank you, Fabian. I've added it to the iteration of WordPress 6.8. There's also this old discussion. To avoid blocking this work, for now we can use an internal state to display the spinner, like the one you show there. |
@fabiankaegy Do you have an example of what the UI could look like for the loading state? |
|
@michalczaplinski I was thinking maybe starting with a simple inline spinner that gets shown absolutely positioned on the right of the search input next to the X (native clear button) 🤔 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Implementation of Instant Search using the Search and Query Loop blocks. Added as a new experiment on the Gutenberg Experiments page.
Related to #63053
output_62afd8.mp4
How does it work?
Instant Search and Query BlockGutenberg experiment.Force Page Reloadi.e. use "enhanced pagination" in that Query block.When the Search block is inside of the Query block using "enhanced pagination", it automatically gets "updated" to an Instant Search block.
Any search input in the Instant Search block gets passed as the
?instant-search-<queryId>=<search-term>query search param in the URL.Multiple Query + Search blocks
It's possible to have multiple Instant Search blocks in a page/post/template. In such a case, ensuring their functionality is isolated is essential. For this to work, the
queryIdis part of the param syntax:instant-search-<queryId>=<search-term>Search button
The search block can contain a search button (in some configurations). However, when using the Instant Search functionality, the button is redundant because the list of posts updates as you type. For this reason, in the editor, when the Search block is placed inside the Query Loop block with enhanced pagination ON, the Block Controls related to the Search button are removed. The displayed name of the block (via
label) is changed toInstant Search (Search).On the frontend, the Search button is also always removed for each (Instant) Search block.
output_70b3a0.mp4
Pagination
The instant search functionality respects the pagination of the Query block, which uses the
query-<queryId>-pagesyntax.Limitations
Customquery types are supported in the current experiment. TheDefaultquery types are currently not supported but will be in the future version. This is prototyped already in Search and Query blocks: Add support for Default queries viapre_get_postsfilter #67289.Alternatives
Alternative approaches have been explored:
render_block_contextfilter #67013 - using therender_block_contextfilter.Further work
This is an initial prototype and the following features is intentionally not yet implemented:
Defaultqueries, including multipleDefaultqueries on a single page/post/template. Those have been prototyped already in Search and Query blocks: Add support for Default queries viapre_get_postsfilter #67289.