Reduce api requests #1121
Open
Reduce api requests #1121
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The main navigation component fetches information for the page it is loading. As far as I understand it, the idea is to prefetch data to have it ready on page load. This makes pages load slower. Furthermore, the page itself still has to fetch that information anyway, because it might be loaded by other means, meaning we are doing the same (potentially expensive) backend requests twice. Therefore, this patch removes all backend requests from the main navigation component.
Ensure the redux state for "table" is completely cleared when a page is loaded.
...which results in more lines of code, but also more readability.
When unmounting a page, dispatched actions will continue to run in the background. This could cause the wrong data being loaded into the table, because the dispatched actions from one page would complete later than the dispatched actions from another page. This is most obvious when switching from series to events and then quickly switching back to series. This patch adds an interrupting mechanism that should prevent the "loadIntoTable" action to be dispatched if the component was unmounted.
This should only be called if the filters were actually changed,
not every time the TableFilters component is loaded.
This could cause weird effects by sometimes loading the wrong data.
This patch should fix that.
Much like the main navigation component, the navigation bar component has no business fetching information from the backend that the component would fetch by itself anyway.
Fetching data for a page would sometimes use the sorting params from the previous page, as the "resource" variable had not yet updated in the tableSlice. This could lead to wrong requests which then had to be corrected by subsequent requests. So instead of relying on the "resource" variable in the tableSlice, the fetching functions now hardcode their respective resource.
When fetching events, we would then make subsequent backend calls and await on each of them before returning. This would cause the response time to be several seconds instead of milliseconds even for a low number of events. This moves the subsequent backend calls into the component that actually requires the information so it can make the calls itself without delaying the table loading.
Apparently we can't just reset the whole tableSlice as we store non-temporary information (sorting parameters for all tables) in there. Therefore, this patch changes the reset function so that only removes actual table contents.
The stats are not needed in the events component, and the stats component is perfectly capable of fetching its own information.
No need to set an interval for every published cell, when we could just make the call dependent on the row passed to it.
The events component repeatedly fetched stats before, so now that the stats component is responsibly for it it should do that as well.
Includes opencast#980, supersedes opencast#1083. Should achieve the same thing as opencast#1083, but without reverting to older dependency versions. Meaning clicking on a series name in the series table should bring up the events table with the series filter set. Including opencast#980 as it helps in achieving this.
They don't need to be dispatching all that. The components will do it themselves when necessary. Also only fetch filter information if we don't already have an applicable filter in our redux store to save on loading times.
Some components are trying to set filters before loading a new table. However, the react-router link will have loaded the new page before the filters are actually set, leading to the display of unfiltered data. This hopes to fix that by properly awaiting before navigating.
|
Use Run test server using develop.opencast.org as backend: Specify a different backend like stable.opencast.org: It may take a few seconds for the interface to spin up. |
|
This pull request is deployed at test.admin-interface.opencast.org/1121/2025-02-27_14-48-18/ . |
The table limit (how many table entries should be shown) should not be reset when swichting between tables apparently.
|
This pull request has conflicts ☹ |
|
This pull request has conflicts ☹ |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reduce the overall number of api requests we send to the backend when loading a new page/table. In particular, we were sending the same requests twice or more which should not be necessary. This cuts down on the number of requests in an attempt to reduce overall loading times. The guiding principle was that each component should be responsible for fetching its own data.
Should fix #940.
How to test this
Can be tested as usual. Switch between tables and modify the tables (filters, change page, change columns). Also check the requests in the network tab of your browser. (Note that if you test in development mode, due to React StrictMode being enabled requests will still be send twice).