Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Inserter search behavior - fuzzy? keywords? #464

Closed
aduth opened this issue Apr 20, 2017 · 3 comments
Closed

Inserter search behavior - fuzzy? keywords? #464

aduth opened this issue Apr 20, 2017 · 3 comments
Labels
[Feature] Inserter The main way to insert blocks using the + button in the editing interface [Type] Question Questions about the design or development of the editor.

Comments

@aduth
Copy link
Member

aduth commented Apr 20, 2017

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:

  • If I type "ima", should it appear?
    • Title search, already implemented
  • If I type "common", should it appear?
    • Search by category
  • If I type "imge", should it appear?
    • Fuzzy search
  • If I type "picture", should it appear?
    • Keyword search
@aduth aduth added the [Type] Question Questions about the design or development of the editor. label Apr 20, 2017
@jasmussen
Copy link
Contributor

The pattern we're mimicking is that of chat apps, for example Slack:

slash commands

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 / nor the succeeding search text was actually literally output on the new line. But the end result was the same, you could type /, type image, press enter, and have an image block. Though I have a preference for fully embracing the commandline and showing the literal text, the other approach is fine too.

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:

“Not found” is easy enough. I’m fine without a mockup if you want to tinker with my styling judgment directly in the PR

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.

@inhll
Copy link

inhll commented Apr 20, 2017

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.

@mtias mtias added the Framework Issues related to broader framework topics, especially as it relates to javascript label Apr 28, 2017
@mtias mtias added [Feature] Inserter The main way to insert blocks using the + button in the editing interface and removed Framework Issues related to broader framework topics, especially as it relates to javascript labels May 3, 2017
@jasmussen
Copy link
Contributor

Closing as "settled". Feel free to reopen if this was in error.

ttahmouch pushed a commit to ttahmouch/gutenberg that referenced this issue Oct 23, 2021
[email protected] was compromised yesterday, October 22, 2021, be…
4d1250c 
…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]
```
@Verdinjoshua26 Verdinjoshua26 mentioned this issue Nov 5, 2022
Open
@Verdinjoshua26 Verdinjoshua26 mentioned this issue Dec 25, 2022
Open
@Verdinjoshua26 Verdinjoshua26 mentioned this issue Oct 1, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
[Feature] Inserter The main way to insert blocks using the + button in the editing interface [Type] Question Questions about the design or development of the editor.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@inhll @mtias @jasmussen @aduth