Make next/previous buttons a bit more robust #856
Conversation
Makes the nextPage/previousPage functions for the create event/series modals a bit more robust, by removing assumptions about how many hidden pages in a row are specified in the steps array.
|
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/856/2024-08-01_12-52-09/ . |
| let newPage = page; | ||
| do { | ||
| newPage = newPage + 1; | ||
| } while(steps[newPage] && steps[newPage]!.hidden); |
There was a problem hiding this comment.
This is more out of curiosity and the fact that I didn't know about the null assertion operator !. until now. What is the reasoning behind using it here? From what I read, the operator will add a runtime check ensuring (it would throw an error) that steps[newPage] is not null. If the assertion fails, I think this would break the UI. That is why you have the check that it can never be null as first part of the condition. But then… you don't need the assertion because it is already always guaranteed to pass, isn't it? I'm somewhat struggling to see where it would make sense to use this operator and don't know why it would make sense here.
There was a problem hiding this comment.
Nah you're right, the ! operator is a left-over that is not needed here anymore. I've removed it.
The null assertion operator is to be used in cases where you successfully determined that your variable is not null | undefined, but typescript fails to infer on that. You can then use ! to shut typescript up.
But more often than not using ! points to a problem in your code that you should fix instead of using !.
Also remove unused parameter
Makes the nextPage/previousPage functions for the create event/series modals a bit more robust, by removing assumptions about how many hidden pages in a row are specified in the steps array.