-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inserter search behavior - fuzzy? keywords? #464
Comments
The pattern we're mimicking is that of chat apps, for example Slack: In this case, the slash actually indicates the succeeding text is the search query. In the prototypes, the slash was simply a shortcut to invoke the inserter — neither the I don't think fuzzy text search is strictly necessary at this point. It could be a nice improvement in the future. You made a good point in chat:
I think "Not found" would be a good thing to show regardless of the literal typing out or the shortcut approach, so long as dismissing it (escape key or clicking outside) is easy. |
This is a great point to bring up @aduth! I agree with @jasmussen that the simple title search is a great starting point, with fuzzy search being the logical extension. Keyword can also be helpful but may also add to the clutter and people will kinda wonder why "ph" is returning results for a bunch of different seemingly random results. Category search adds a lot of complexity in my experience, as it's confusing for people to see a whole category of item without the category children, and even more confusing with category children since that adds a lot of additional clutter. The available block and category types in WP are simpler than what I was working on, but this could still be an issue and visual scanning should be a sufficient "category search" for the moment, and perhaps the long run. |
Closing as "settled". Feel free to reopen if this was in error. |
…cause the author didn't have 2FA enabled. I think that `npm` dependency was targeted because it's one of the more popular dependencies and the attacker was leveraging it for crypto mining and environment stealing. I noticed a few of our transitive dependencies depend on `"ua-parser-js": "^0.7.x"` in `gutenberg/trunk` (and probably other repositories). Luckily, it's currently locked to `0.7.[23|28]` in `package-lock.json`, but it may just be a matter of time before an `npm update` inadvertently updates the lock file. 0. If it is feasible, it looks like we may be able to leverage the `package.json` to only resolve `"resolutions": { "**/ua-parser-js": "0.7.28" }` from all transitive dependencies in the meantime. That is what is done in this commit. 1. It doesn't appear that `@types/ua-parser-js` is resolving to `0.7.28`. I'm unsure at the moment if it is even being used, and what dependency would even need the TypeScript types since presumably all of them should be exporting JavaScript modules that don't need compilation(?). Does someone else possibly know if the types are used, or if they even need to match the version of their counterpart JavaScript module? 2. Presumably, we'd want to remove the `resolutions` field from the `package.json` when `appium` and `fbjs` bump their, or transitive, `package.json`s to `^0.7.30`. **Having written all of this, it looks like [`npmjs.org` revoked `0.7.29`](https://www.npmjs.com/package/ua-parser-js) from even being available for download and `0.7.30` and `0.8.1` were both published on October 22, 2021. So it likely won't cause future issues because it won't even be possible to download the dependency, but some people may have had `0.7.29` on their machines and may have been compromised.** --- [Security issue: compromised npm packages of ua-parser-js (0.7.29, 0.8.0, 1.0.0) - Questions about deprecated npm package ua-parser-js WordPress#536](faisalman/ua-parser-js#536) [Issue Comment](faisalman/ua-parser-js#536 (comment)) [fbjs > [email protected]: this package has been hijacked WordPress#464](facebook/fbjs#464) ``` $ npm ls ua-parser-js [email protected] /Users/ttahmouch/Desktop/src/gutenberg ├─┬ @wordpress/[email protected] -> /Users/ttahmouch/Desktop/src/gutenberg/packages/react-native-editor │ ├─┬ UNMET PEER DEPENDENCY [email protected] │ │ └─┬ [email protected] │ │ └── [email protected] │ └─┬ [email protected] │ └─┬ [email protected] │ └── [email protected] deduped └─┬ [email protected] └─┬ [email protected] └─┬ [email protected] └─┬ [email protected] └── [email protected] ```
In order to decide whether additional functionality should be added to the blocks API, I'd like to nail down the expected behavior of the inserter search field.
Taking the Image block as an example:
The text was updated successfully, but these errors were encountered: