Hi @jsonforms team,
first of all thank you for this great solution that you provide as open source project!
I have a question about guidelines regarding performance when forms have lots of fields and many of them are dropdowns. Going from tab to tab is real pain for the user experience, it might take 10 seconds to transition the screens.
Any feedback is highly appreciated!
Best regards,
Evgeni
[original thread by Evgeni Atanasov]
[Alexandr Sashin]
Custom renderers are a good solution for many cases. You can manage component rendering and optimize it.
[Evgeni Atanasov]
Thanks Alexandr for the answer.
I already developed custom renderer set but my observation is that if form has > 50 fields with some dependecies and effects taking place there is some delay in the initial render.
As far as I understand the performance of jsonforms/core is good enough, and place for optimization is in the components that render?
[Alexandr Sashin]
I think the delay can be connected with ajv and json-schema-ref-resolver work at form initializing. Did you check this idea?
Hi @evgeni, from our experience rendering is usually not the issue. However as @alexandrsashin mentioned, we noticed performance problems with certain schemas in regards of ref resolving. These typically occur with recursive refs.
@evgeni Can you share your used JSON schema? If not can you reproduce the performance problem with a small example and share that one? Which renderer set are you using?
[Evgeni Atanasov]
Hi @sdirix ,
first of all I am extremely grateful that you joined this conversation.
Here you can see two examples, Person and ScrollableLayout.
The Person example uses simpler schemas, while the ScrollableLayout has really advanced schemas.
https://jsonforms-example-performance.netlify.com/
In the lower section there are 3 buttons, which can show you the Schema, UiSchema and Data of the current form.
The renderer set that is used is completely custom but my belief is it performs quite ok.
In React Profiler I can see that most of the time taken to render the form is consumed by JsonFormsDispatchRenderer.
I am avaiable for any further discussion.
[Alexandr Sashin]
If you exclude enums from the schema and get them from backend in custom renderer the app will render faster. It’s not a hack, it’s one of solutions.
[Evgeni Atanasov]
Do you mean only leaving them as type: “string” without enup property and validation of the allowed values?
@evgeni Thanks for providing the detailed example, that’s very helpful. On a first look I didn’t see any $ref in the schema, so it doesn’t look like a ref resolving issue. So it’s either the custom renderers or something I’m currently unaware of in JSON Forms, especially as you indicated that most of the time is spent in the JsonFormsDispatchRenderer.
@alexandrsashin What makes you think the enums pose the performance problem? On a first glance it seems to be worse to fetch them only once you want to render them as you’ll have to additionally wait for the fetch. Of course when all of them have to be fetched beforehand and the schema is only generated after all of them are fetched there might be a difference in first time to render, but I don’t think this is what’s happening here, or is it @evgeni ?
@evgeni I’ll have more time next week to look at this issue, I’ll let you know when I took a closer look.
[Evgeni Atanasov]
Hi @sdirix ,
thank you for looking in this issue.
I have prepared code where enum values are prefetched in redux store and dropdowns get their values from the store.
Only value I can see in what @alexandrsashin is proposing is that there will be no validation done by AJV on the allowed value for the dropdown, because this way it is going to be just a “string” in the jsonschema description.
[Alexandr Sashin]
Yes, I mean to leave for such fields type: “string” and store data with enums separately:
As static files inside project that are imported into custom renderers (like hardcode approach).
or
Use get-requests to backend after focus on custom renderers. (We don’t need to load all options at jsonforms initial rendering)
In both solutions we don’t validate enums options, but we can create renderer in the way where we can’t choose unappropriate value.
I looked a bit at the example but it’s hard to debug it properly with the deployed production build. A developer build would make the investigation easier 