Why does the preview filter ignore the path/folder structure?

[Fred Boyle]

Describe the bug

Given the following folder structure of previews (also see screenshot):

• Button
• Inputs
  • Checkbox
  • Checkbox Group
    • Checkbox Group
  • Radio Group
    • Base

Entering "group" in the filter field ignores the "Radio Group" folder.

Unfiltered

Filtered results

• Inputs
  • Checkbox Group
    • Checkbox Group

To Reproduce

Steps to reproduce the behavior:

1. Create a preview structure with nested folders via @logical_path and @label usage
2. Search on a term that exists in labels and folders
3. See issue similar to described scenario above

Expected behavior

Filtering should include all labels/values in the preview tree structure.

Screenshots

If applicable, add screenshots to help explain your problem.

Version numbers

Please complete the following information:

• Lookbook: 2.0.5
• ViewComponent: 3.2.0
• Rails: 7.0.5
• Ruby: 3.2.2

[Mark Perkins]

Hey @fredboyle 👋

So, this is actually the intended behaviour :) The filter matches against scenario and preview labels (only), and then displays the tree of folders/modules down to those the matched previews/scenarios. The placeholder text "Filter previews by name..." is supposed to hint at that behaviour although I'm not sure it really helps much!

The idea behind this was to reduce the number of matches and so be able to filter quickly down to specific previews without lots of noise from matching path segments. This obviously works well if you have a specific preview/scenario name in mind, but if you are looking for a folder of previews then it doesn't work at all, which is clearly not great - and actually something I've personally been getting caught out with a lot recently too.

So whilst this isn't really a bug (from my point of view anyway) it's definitely something that could and should be improved. So there are a few options:

1. Replace the existing filter behaviour with one that matches against path segments as well as preview/scenario names
2. Provide a config setting to optionally include path segments in the filter
3. Add a checkbox (or some other control) in the UI somewhere close to the filter box to allow users to toggle on/off the path matching behaviour

Options 2) and 3) would require deciding what should be the default setting.

I'm probably most in favour of option 3 personally (with the default to include path segments) but I'm going to do a bit of testing on a few of my projects to see how much additional 'noise' is actually generated with the path matching enabled - it was an assumption I made when first implementing the search without much evidence so it may well be that just keeping it simple and going with option 1 is actually fine.

I think some highlighting of the matched letters in the sidebar labels would also be nice although when I last had a stab at implementing that it proved to be a bit of a headache...

I'll have a bit of a play to see how best to improve the experience and let you know as/when I have something to test out. And if you have any other suggestions in the meantime just let me know :)

[Hans Lemuet]

I'm wondering if we could try replicating the fuzzy-matching behavior of Github "go to file" feature or VS Code's Ctrl+P / "search file by name" feature. Maybe as a separate UI that opens a floating search bar at the top of the screen:

I quite like being able to launch a search from a keyboard shortcut instead of having to click in a search box.

[Mark Perkins]

Hey @fredboyle @Spone, sorry for the ridiculously slow progress on this, life has been a bit mad recently.

I've had a bit of a play with adding in the full path lookup to the filter matching and testing it in a few projects. Even in really big nested directory structures it doesn't feel like it adds a lot of noise to the results at all. In fact it just feels a lot more intuitive - it should probably just have been like this all along!

So I've made the change and will get it out in the next release, hopefully today. I am not going to go down the route of adding a checkbox or config setting because honestly I think it's just better this way. @fredboyle thank you for prompting me to take another look at it :)

I'm wondering if we could try replicating the fuzzy-matching behavior of Github "go to file" feature or VS Code's Ctrl+P / "search file by name" feature. Maybe as a separate UI that opens a floating search bar at the top of the screen:

@Spone yeah that would be a nice addition, although would be more of a 'search' rather than a 'filter' (i.e. for finding one very specific item rather than just filtering out surrounding items) so I don't think it would be a direct replacement. But some sort of command/search box thing would be great in the future.

[Mark Perkins]

This change has just been released in v2.1.0 so I'm going to go ahead and close this issue down. But if you run into any issues with it just let me know.