Use formik 'FastField' instead of 'Field' for performance reasons

[snoesberger]

On an Opencast system with a large number of series (>4,000), entering text in the create or edit event dialogue box is slow. Using the formik 'FastField' instead of 'Field' improves the performance.

Fixes #1406

[github-actions]

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-1408

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-1408

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.

[mtneug]

@snoesberger can you explain why the text inputs are slow when there are many series? This seems very strange to me, and I'm wondering if there is something else that should be optimized. The FastField documentation has a warning before use paragraph, but I don't know enough React to really comprehend this.

[snoesberger]

@snoesberger can you explain why the text inputs are slow when there are many series? This seems very strange to me, and I'm wondering if there is something else that should be optimized. The FastField documentation has a warning before use paragraph, but I don't know enough React to really comprehend this.

Each time you enter an additional character in one of the text fields, the entire form is rendered again. And the more series you have, the slower it gets. After searching the internet, I found a proposal to use 'FastField' instead of 'Field'. I also read the Formik documentation and saw the warning you mentioned. According to the explanations, using 'FastField' can cause problems if one field depends on another. Having checked the admin UI code, I found no such dependencies; the user password and password confirmation fields are also still working correctly. Or do you see maybe dependencies between fields that I have missed?

[mtneug]

Or do you see maybe dependencies between fields that I have missed?

I don't really dabble in frontend code. So others have to answer that. This issue was just surprising to me.

So the underlying problem seems to be that all series are loaded and the fields check for dependencies among each other during each update? I guess if fields don't depend on each other, this is a valid quickfix, but the real scaling problem is having all series in-memory / in the DOM instead of loading only a partial list based on the search term.

[Arnei]

I've not used FastField before, but it looks like it might be a valid band-aid solution for our problem here.

I do agree that the better long term solution would be to figure out why

Each time you enter an additional character in one of the text fields, the entire form is rendered again.

is happening, and then make it not do that. If a field is changed, only that field needs re-rendering should re-render, not the entire form. FastField achieves this, but in my mind we should not even need FastField for this behaviour and there is a more underlying issue in our code we should fix instead. I wrote opencast/editor#1608 to combat a similar issue in the editor, not sure how applicable this is to the admin ui though.

But maybe it's better to leave the long term solution stuff to a different PR, and just use FastField in the meantime (provided it does not break anything :D).

[lkiesow]

Tested this and it really helps quite a bit 🚀
If no one has a strong objection, I suggest merging this. We can always revert it if someone comes up with a better solution.

[snoesberger]

I agree. If someone sees a better solution, I'd love to see that. For now, though, the admin UI is hardly usable for admins on systems with many series. Therefore, I would greatly appreciate it if this PR could be merged.