Endlessly scrolling property filter

[mariusandra]

Is your feature request related to a problem?

This tool is great:

But with a lot of tabs and a few scattered results, it can get hard to find things:

Describe the solution you'd like

I'd like an endless list, which would dynamically update the tabs. Basically the four infinitely scrolling lists should be combined into one, with one extra item between sets to denote a new category.

If I click the tabs, the list just scrolls to the right location. Clicking tabs with "0" does nothing.

Describe alternatives you've considered

Clicking though all the tabs to find what I want.

Additional context

This will get more needed when we add other tabs to the filter. For example to separate posthog and other events, or when adding support for groups.

Thank you for your feature request – we love each and every one!

[Twixes]

This used to be the case, right? But we moved to tabs to make handling lots of options easier, while clarifying different filtering types. I don't think it's a good idea to keep tabs AND combine them in the search list at the same time, as then the separation becomes really confusing.

[paolodamico]

I think the right solution is #5381 and allowing users to switch with "tab" hotkey (or other simple key), thoughts? CC @clarkus

[clarkus]

There are other considerations here - group analytics is adding 1–5 extra items to this component. I think we're reaching the limit of tabs and need to explore other options here. Being able to switch easily makes this a bit less painful, but the component needs to be updated to account for the higher volume of events and the higher volume of categories / tabs.

Related discussion at #7073 (comment)

[clarkus]

Here's a concept for a flattened property list. The thing that's missing is the tab navigation that lets you quickly jump to a category.

This idea be very reliant on, related to:

• Allow cleaning up events and properties #7315
• Custom properties don't look clickable #5351
• Think through the Elements tab #5312

https://www.figma.com/file/gQBj9YnNgD8YW4nBwCVLZf/PostHog-App?node-id=5573%3A33304

[clarkus]

@mariusandra here's an alternative to tabs. As we discussed, it's a multi-line set of pills that summarizes the matching result count for each category. When there are 0 matching results, the category is grayed out and isn't actionable. When there is a matching result, the category can be clicked on to jump to that specific area of the list.

https://www.figma.com/file/gQBj9YnNgD8YW4nBwCVLZf?node-id=5597:35546#129608055

[mariusandra]

Beautiful! Assuming implementing a good multi-category vertical scroll will take a bit of effort, is there a quick change we can do to highlight one pill and show one scrolling list below?

[clarkus]

Beautiful! Assuming implementing a good multi-category vertical scroll will take a bit of effort, is there a quick change we can do to highlight one pill and show one scrolling list below?

Sure here are two ideas - I prefer the first option, but would want to balance the prominence of the pills with any inline actions shown in the list. Also updated in figma.

[paolodamico]

Love this approach!!! As a follow-up (separate issue), can we add the taxonomy (description, tags, ...) to events where available? I imagine it would appear when hovering as we have for PostHog events and actions?

[paolodamico]

With the new pills design, and implementation, can we close this @mariusandra @clarkus ?

[mariusandra]

The idea was still to have the list scroll endlessly as well. The pills already solve a big discoverability problem, but it'd still be faster to scroll through all the lists in one big list, especially if you have < 50 items overall.

[mariusandra]

@paolodamico @clarkus do you think the current implementation with pills + tabs is good enough?

We don't have the infinite scroll through all tabs. This means when you scroll to the end of "event properties" you won't automatically see a new list for "person properties", and so on.

We could add that, but it'll require a significant refactor (read: day of work?). Do we:

a) prioritise this now
b) pause until next year
c) close this issue, consider the current implementation good enough, and revisit once someone feels like we need an upgrade (e.g. users complain)

I'd go for C personally, though see some value in A.

[clarkus]

I agree we should go for C. I think this is a substantial enough improvement to close out for now and watch usage.

[paolodamico]

Perfect, let's do it!