[TextareaAutosize] Improve implementation

[ZeeshanTamboli]

• I have followed (at least) the PR section of the contributing guide.

Fixes #40557

I was investigating #40557 and noticed related issues (#33081 and #20106). A React 18 compatibility issue was also addressed in #33253 using ReactDOM.flushSync. However, the problem persists in the latest version, as evident in #40557 and a PR attempt in #38453.

---

Problem:

The current implementation sets a re-render limit of 20 in order to prevent infinite rendering errors caused by React. However, this limit also disrupts the synchronization of height beyond 20 re-renders, leading to incorrect layout and the warning described in #40557. The primary questions to address are: Why is the infinite re-render occurring, and what is the root cause?

Potential Cause of Too Many Re-renders / infinite loop:

The issue arises from using React state to store height and overflow, which are then passed to the inline style prop of the textarea. The syncHeight function calculates the height, updates the state using setState, triggering a re-render. The new re-render causes another call to syncHeight and a subsequent state update. Even if there are no layout changes or the constraint is not passed, the new reference of the object returned by prevState causes repeated re-renders. Additionally, the absence of a dependency array in the useEffect for syncHeight triggers it on every component re-render, leading to an infinite loop.

Solution:

It's correct that we have to call syncHeight on every render. This PR proposes avoiding the use of React state and instead directly setting the calculated HTML textarea's height and overflow properties on the component DOM using a ref.

---

Before and After for #40557 can be viewed here: (Make sure to also test by clicking on Show/Hide button)

• Before: CodeSandbox Before
• After: CodeSandbox After

---

Closes #38453 (Stale PR)

[mui-bot]

Netlify deploy preview

https://deploy-preview-40789--material-ui.netlify.app/

@material-ui/core: parsed: -0.06% 😍, gzip: -0.07% 😍
@material-ui/unstyled: parsed: -0.21% 😍, gzip: -0.25% 😍
@mui/material-next: parsed: -0.10% 😍, gzip: -0.11% 😍
@mui/joy: parsed: -0.07% 😍, gzip: -0.09% 😍

Bundle size report

Details of bundle changes (Toolpad)
Details of bundle changes

Generated by 🚫 dangerJS against 8490135

[michaldudak]

It seems to do the trick. Impressive!

[oliviertassinari]

I believe we still need a failsafe for unstable layouts (unrelated to React). This happens when the CSS values are unstable, this warning is also meant to invite developers to create issues so we can debug and fix the logic. Typically you would see the height flicker up and down as you type in the input. Or freeze the app because the resize observer logic run in a loop.

[ZeeshanTamboli]

for unstable layouts (unrelated to React). This happens when the CSS values are unstable,

Can you provide reproductions of layout instability not related to React? I'm open to debugging it.

this warning is also meant to invite developers to create issues so we can debug and fix the logic

Sure, but since we're not relying on React state anymore, there's no need for warnings about excessive re-renders caused by state.

Typically you would see the height flicker up and down as you type in the input. Or freeze the app because the resize observer logic run in a loop.

Again, can you provide reproductions using this PR build?

[oliviertassinari]

We need a regression test for #40557.

[ZeeshanTamboli]

We need a regression test for #40557.

I don't see #40557 as a regression. Do you think the existing tests not cover it adequately? Also, the warning has been removed. Could you share your thought on what additional test case might be needed?

[ZeeshanTamboli]

@oliviertassinari Could you review further?

[megatron-hoa-tran]

I was blocked by this issue
#38453
@oliviertassinari please help to review 🙏

[ZeeshanTamboli]

Olivier hasn't responded yet (since past two weeks), but since Michał has approved it, I think I can merge it.