re-render performance issue

[ghoshorn]

Hi, @guidone hope everything goes well!

Recently when I use the form, say about 100 fields, with half of them having a script. With empty defaultValues, the re-render is evidently slower(more than 5s and makes the browser hang) than the initial rendering.

Here I have a demo, on the top I have a button, which will do nothing but change a state and makes the page rerender. You can see the page got stucked for seconds and after a while you can finally see the clicking makes the selection button changed. Please refer to the demo below:

form-performance.mov.zip

[guidone]

I see the problem.

Questions:

• is the slowness happening only with empty defaultValues (this is ringing me a bell in the past while I was searching for a bug related to unintended re-renders)
• can you share the form (I understand you may not want to share it here, can you send it to guido.bellomo@gmail.com?)

[ghoshorn]

@guidone Hi, actually I have not yet tested the form with data, but I can share the form with you first, and will try it with data later and share the result with you.
Glad if this can help a little to find the bug, sent to your gmail ;-)

[ghoshorn]

@guidone Hi, sorry for the late response.

Tried the form with data, it will have the same performance problem when re-rendering.

[guidone]

Got it, I'll check this today or tomorrow, I'm on it

[guidone]

Ok, I've replicated the error, now I've to understand where is going this rendering time.
Curiosly it's not happening with the first render, the first render is always quick

Note:

• definitely due to the amouts of scripts, every script causes additional re-renders (on re-renders)

[ghoshorn]

Yes, the first rendering is always fast! No matter there is initial data or not. I'm also curious about it. Unluckily, sometimes in the situation, re-rendering is necessary for some certain functionalities.
Curious and looking forward to know the root cause which only makes the re-render slow~

[guidone]

I suspect it's this setFormFields here

It's causing a re-render at every script, it should not be necessary since there's a general setFormFields later in the code, commenting out the re-render time turns normale, I've to check with some other tests if some other corner case breaks

[guidone]

As suspected removing this line is breaking a lot of tests (one of those is about a bug you've found previously about cascading changes).

So this line cannot be removed, the reason why at first re-render is quick, it's because the DOM is empty and React is smart enough to transfer all changes from the virtual dom to the dom in one shot, while when the form already exists, it apply every change one by one (and it slows down).

Did some test and even if the component container re-renders, LetsForm doesn't re-render unless properties like form and formContext changes, you mentioned that you generate programmatically the form, are you sure that the variable you pass down to form property of LetsForm is referential stable? Means the instance doesn't change if the structure doesn't change, for example if you create it like

const form = {
  version: 2,
  name: 'my_form',
  fields: // some fields coming from somewhere and modified
};

<LetsForm form={form} />

then the component re-renders, the form variable is a different instance compared to the previous render even if the structure is identical, this causes LetsForm to re-render.

Put in a state instead (or a using a useRef)

const [form, setForm] = useState({
  version: 2,
  name: 'my_form',
  fields: // some fields coming from somewhere and modified
});

<LetsForm form={form} />

[ghoshorn]

Actually I'm not using the useState, because what I want to do is that: there is a list A: A1, A2, A3... and a list B: B1, B2, B3... And I have a button to let the user choose if want to show A or B or combination of A & B. Without useState, it's also leading to 1 time re-rendering.
Initial rendering is fast, but re-rendering is slow, and you mentioned the virtual dom, wondering if currently letsform have keys for each component? Which can help the react to identify items and changes and improve performance

[guidone]

Hi, do yopu still have the issue or did you find a way to mitigate it?

[ghoshorn]

Hi @guidone , I have tried some method, like directly change a React Key to force render another new component, but it's still very slow. Will try your new build today to see if this still exist~

[ghoshorn]

Hi @guidone Thanks for the response!
Justed tried 0.12.17 but unluckily the re-rendering is still evidently slower than the first rendering.
If the re-rendering is slow but not blocking the UI, I can maybe add a loading curtain and wait for the re-rendering done. But currently feel like the re-rendering blocks the UI and, like if clicking on a toggle button, the toggle status will change only after the re-rendering done.

[ghoshorn]

@guidone Hi, please help check if this is right, thanks.

Root Cause: Cascading Transformer Execution Chain

In form-fields.js:179-187, there's a cascading execution pattern that creates a chain
reaction:

  // When a transformer changes field values:
  if (changes) {
    for(idx = 0; idx < changedFields.length; idx++) {
      const fieldToChange = changedFields[idx];
      setValue(changedFields[idx], changes[changedFields[idx]]);
      // THIS IS THE PROBLEM: Each changed field triggers its transformer
      if (hasTransformer(fieldToChange) && followTransformers) {
        await executeTransformer(
          transformers.onChange[fieldToChange],
          { ...values, ...changes }
        );
      }
    }
  }

Why This Causes 50x Execution

Initial Render (1x):

• All 50 field scripts execute once in a batch during useEffect
• No cascading because it's the initial state setup

Re-render (50x):

1. One field changes → triggers handleChange
2. handleChange executes both:
   - Form-level transformer (lines 284-285) - may modify multiple fields
   - Field-specific transformer (lines 288-289)
3. Cascading begins: Each field modified by step 2 triggers its own transformer
4. Chain reaction: All 50 fields with scripts get executed individually

The Multiplier Effect

• Form-level transformer affects multiple fields → each affected field runs its script
• No deduplication - same field's script runs multiple times if changed by different
  transformers
• Individual execution vs batched execution during initial render

The combination of form-level transformers + cascading field execution creates an
exponential execution pattern where:

1 field change → form transformer → modifies 10 fields → each of 10 fields runs its
transformer → each modifies other fields → cascade continues through all 50 scripted fields

This explains the 5000ms+ re-render time vs 50ms initial render time.

[guidone]

Thank you for this analysis, I’ll be back from my vacation in a couple of days and then full steam again on letsform

…

-- Guido Bellomo 📞 +393473561058 @***@***.*** Il 15 ago 2025, 12:10 +0200, ghoshorn ***@***.***>, ha scritto:

ghoshorn left a comment (guidone/lets-form#70) @guidone Hi, please help check if this is right, thanks. Root Cause: Cascading Transformer Execution Chain In form-fields.js:179-187, there's a cascading execution pattern that creates a chain reaction: // When a transformer changes field values: if (changes) { for(idx = 0; idx < changedFields.length; idx++) { const fieldToChange = changedFields[idx]; setValue(changedFields[idx], changes[changedFields[idx]]); // THIS IS THE PROBLEM: Each changed field triggers its transformer if (hasTransformer(fieldToChange) && followTransformers) { await executeTransformer( transformers.onChange[fieldToChange], { ...values, ...changes } ); } } } Why This Causes 50x Execution Initial Render (1x): • All 50 field scripts execute once in a batch during useEffect • No cascading because it's the initial state setup Re-render (50x): 1. One field changes → triggers handleChange 2. handleChange executes both: - Form-level transformer (lines 284-285) - may modify multiple fields - Field-specific transformer (lines 288-289) 3. Cascading begins: Each field modified by step 2 triggers its own transformer 4. Chain reaction: All 50 fields with scripts get executed individually The Multiplier Effect • Form-level transformer affects multiple fields → each affected field runs its script • No deduplication - same field's script runs multiple times if changed by different transformers • Individual execution vs batched execution during initial render The combination of form-level transformers + cascading field execution creates an exponential execution pattern where: 1 field change → form transformer → modifies 10 fields → each of 10 fields runs its transformer → each modifies other fields → cascade continues through all 50 scripted fields This explains the 5000ms+ re-render time vs 50ms initial render time. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>