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.

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

Allow filtering branches no the stream.branches(...) query #1549

Open
gjedlicska opened this issue Apr 27, 2023 · 1 comment
Open

Allow filtering branches no the stream.branches(...) query #1549

gjedlicska opened this issue Apr 27, 2023 · 1 comment
Assignees
Labels
enhancement New feature or request question

Comments

@gjedlicska
Copy link
Contributor

We've seen multiple ppl having a very big amount of branches (500+)
Currently our graphql schema only allows a paginated query for branches on streams, but it doesn't allow filtering the branches on certain criteria ( name ).

This issue is spanning hacky workarounds like this

The end user experience should be, that we enable a filterable paginated infinite scroll type interaction in our DUI and or frontend.

@jsdbroughton
Copy link
Contributor

jsdbroughton commented Jul 8, 2023

Scoping around this, most functions handling cursor-based queries etc., already exist. As described in the Issue, the missing piece is a Filter resolver that could be added to branches that handles partial name matching.

The mega branch list requirement touches:

  • Frontend 1: Nested Branches in UI are limited to 10 children per header
  • Connectors: Current DUI only displays main + 99 branches but is still responsive to new branches being created
  • dotnet and specklepy SDKs don't have a resource query other than "get a list up to limit" (100)

Avalonia ComboBox has no support for being a ComboSearchBox. Branch Filtering would require either a custom component or a secondary filter textbox.:

image

dumb

I have the filtering interaction working like this, but it is repeated querying the server for all branches (with cursor) and then filtering. The only advantage to User is a smaller drop-down. No advantage in speed or server load. I didn't get as far as applying the filter as denounced because no server interaction required it.

Since DUI3 is an active initiative, the DUI2 with the custom component is not likely to gain steam, so the Apollo Resolver is needed until it is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question
Projects
None yet
Development

No branches or pull requests

3 participants