Skip to content

Filtering from events cells in pages other than first page now works! #1258

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

ferishili
Copy link
Contributor

@ferishili ferishili commented May 14, 2025

This PR fixes #1229,

Applying a debouncing mechanism when the filtering should be applied in order to fetch the events and load them into the table. Using debounce helps reduce unwanted redundent calls.
In addition, we use useState and useEffect in order to use the advantage of async and watcher properties!

The main problem also was the fact that by applying filters no matter which page the table is set to, it has to be set to first page, so here we use goToPage(0)

TESTING

Please make sure to test all event cells that are filterable, by clicking on the values! don't hesitate to ask if you have any question. Thanks in advance!

@ferishili ferishili self-assigned this May 14, 2025
@ferishili ferishili added type:bug Something isn't working priority:medium labels May 14, 2025
Copy link
Contributor

Use docker or podman to test this pull request locally.

Run test server using develop.opencast.org as backend:

podman run --rm -it -p 127.0.0.1:3000:3000 ghcr.io/opencast/opencast-admin-interface:pr-1258

Specify a different backend like stable.opencast.org:

podman run --rm -it -p 127.0.0.1:3000:3000 -e PROXY_TARGET=https://stable.opencast.org ghcr.io/opencast/opencast-admin-interface:pr-1258

It may take a few seconds for the interface to spin up.
It will then be available at http://127.0.0.1:3000.
For more options you can pass on to the proxy, take a look at the README.md.

Copy link
Contributor

This pull request is deployed at test.admin-interface.opencast.org/1258/2025-05-14_07-19-00/ .
It might take a few minutes for it to become available.

@wsmirnow wsmirnow self-requested a review May 14, 2025 08:45
Copy link
Contributor

@wsmirnow wsmirnow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works as expected. My knowledge to the code is limited. Maybe someone else can look into the code, too. For me it's fine.

Good job, thank you @ferishili

Copy link
Member

@Arnei Arnei left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you explain in more detail what the debounce is supposed to achieve? What requests are you debouncing? My understanding of the code is that all the debounce does is delaying code execution by 500 ms for no particular reason.

@Arnei
Copy link
Member

Arnei commented May 15, 2025

As an aside, this PR also nicely illustrates that we have code duplication in our table cells which we should get rid of at some point :D. Not necessarily in this PR though, no worries.

@ferishili
Copy link
Contributor Author

You are 100% right about the code duplication! And I can bring this to the /Util and reuse them!
About debouncing, the first advantage is to make sure an unwanted (unintentional) double click does not clutter the processing! And secondly, it would give a nice waiting touch in order for React to do its thing and make the changes more feelable to the users (IMHO)!

@ferishili
Copy link
Contributor Author

If you are convinced with having the debounce and my proposed way! I can make it reusable

@Arnei
Copy link
Member

Arnei commented May 15, 2025

the first advantage is to make sure an unwanted (unintentional) double click does not clutter the processing!

I did not think about that users double- or even multi-clicking would trigger multiple backend requests. I agree that ideally we want to prevent this from happening. I feel like preventing double clicks should be easier to solve though. I worry that have this much code just for debouncing makes the component as a whole unnecessarily harder to understand. I don't know of a better solution off the top my head though.

waiting touch in order for React to do its thing

I don't think this really achieves that. If understand the code correctly, we first wait 500ms and only then we fetch events and load them into the table. So React is only doing its thing after waiting for 500ms for no reason. Am I getting this wrong?

make the changes more feelable to the users (IMHO)

Yeah, that is very much a matter of design opinions :D. Personally, I don't like introducing artificial lag when avoidable, due to lag making the app feel less responsive. But I'm likely also way more sensitive about lag then the average user ^^.

Suggestion: All this talk about debouncing is only tangentially related to the issue this PR is supposed to solve. I think it would be better to factor debouncing out of this PR and continue the discussion about debouncing in another PR or issue.

@ferishili
Copy link
Contributor Author

In this case, and for the favor of keeping the code base simple, we should close this and go for the PR: #1266 from Carolina, which is a simpler version of this and resolves the main problem by adding setPage to 0 when cell filtering!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority:medium type:bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Filtering for specific properties works on first page only
3 participants