You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, the parent AllArchivedRecordingsTable holds all states (i.e. counts, directories and its recordings) and query back-end on listened notifications, which trigger the entire table re-rendering.
The new view works differently in that notifications refresh the entire page. This is done because the querying to the backend actually happens in the parent component AllArchivedRecordingsTable which contains multiple nested ArchivedRecordingsTables <- these normally update state by themselves but the new view has a entirely different set of api calls that don't depend on jvmIds and such so I would have to create a new ArchivedRecordingsTable-like component to properly handle notifications instead of just refreshing the page, which I haven't done. It is entirely possible to do, but I'm not sure if this the current state is okay enough since tomorrow is the deadline.
One way to go around this issue (i.e. similar to AllTargetArchive) is that the parent AllArchive can query only the list of directories and counts. Then, pass in an optional DirectoryOptions props including the directory info to the ArchiveTable. Then, the archive can check if this option is available, and make the api calls to fetch recordings for that directory. I think we should do the same for uploads. But this seems to require some refactoring and maybe backend supports :D
Right now, the parent
AllArchivedRecordingsTable
holds all states (i.e. counts, directories and its recordings) and query back-end on listened notifications, which trigger the entire table re-rendering.One way to go around this issue (i.e. similar to AllTargetArchive) is that the parent
AllArchive
can query only the list of directories and counts. Then, pass in an optionalDirectoryOptions
props including the directory info to the ArchiveTable. Then, the archive can check if this option is available, and make the api calls to fetch recordings for that directory. I think we should do the same for uploads. But this seems to require some refactoring and maybe backend supports :DOriginally posted by @tthvo in #550 (comment)
The text was updated successfully, but these errors were encountered: