Doesn't work with CSSTransitionGroup animations about react-textarea-autosize HOT 20 OPEN

Not sure if this will be helpful for others, but I was running into this issue when using Transition from headlessui. The TextArea in my case was deeply nested. I

Setting the cache prop did not do it for me. I was able to get this work by activating the transition (setting show to true in my case, with unmount equal to false) only after a setTimeout of 0. This waits a tick, which allows the text area to do its initial setup.

from react-textarea-autosize.

Do you have a repro? Would useful to debug.

from react-textarea-autosize.

Run into the same issue. I have a parent container with CSSTransitionGroup using transform: translate3d to animate a page slide in from right.

from react-textarea-autosize.

@muntamala would be good to have a gh repo I can debug against.

from react-textarea-autosize.

Having the same issue @muntamala , tested on a local project. The animation becomes 'jittery' when transitioning a component (that contains this Textarea component within) using CSSTransitionGroup. Removing the _resizeComponent() call in componentDidMount solved the issue as @eriklovdahl mentioned.

from react-textarea-autosize.

Wrapping textarea component with https://github.com/reactjs/react-static-container and setting shouldUpdate={false} during animation could help probably.

from react-textarea-autosize.

@andreypopp unfortunately wrapping it with the static container doesnt seem to have any effect. While I dont quite understand the intricacies of the problem we know its from the call to _resizeComponent on mount. Could a possible solution be the just pass a prop to which we could disable this initial call to that function (defaults true)?

from react-textarea-autosize.

@deep-c can you provide a repo or jsfiddle with repro?

from react-textarea-autosize.

I had similar issue: Textarea occupied all height when its parent was changing size with css transitions. Setting useCacheForDOMMeasurements seems to fix it

from react-textarea-autosize.

@asquet could u share a reproduced issue on something like https://codesandbox.io/ ? I would love to take a quick look on how it is behaving during the transitions.

from react-textarea-autosize.

I tried to, but could not import react-textarea-autosize properly. Could you make base fiddle that I can extend?

from react-textarea-autosize.

https://codesandbox.io/s/M8pJnJ185

from react-textarea-autosize.

Heres what Ive managed to put together
https://codesandbox.io/s/pYyzv0Jjr
It's a rather messy, sorry about that. I hope it can help you to get the idea.
Click "toggle" to change sizes. After second change textarea will get higher than it should

from react-textarea-autosize.

Thanks! I'll definitely look into this when I have some spare time and provide at least explanation why this happens, although hopefully it will be fixable ;)

from react-textarea-autosize.

Heh, I couldnt resist and had to check this out :D So unfortunately its kinda a non-fixable issue on our side, certainly not in a performant way.

This happens because we hook into componentWillReceiveProps and schedule there a measurement to determine what height should be set on the textarea. And at the time when the measurement occurs ur UI is in pre-animation state, so your textarea's width is 0 and based on that value the height is getting determined and ofc its too high, because it thinks its the only way that the text is being able to fill into that width.

So really the best shot at it is in fact using the cache property, which is advised anyway - it will skip unnecessary recomputations inside the lib.

Ideally somebody could prepare a PR with a documentation note about this.

PS. I also really appreciate simpler demo you have put together (without CSSTransitionGroup involved)

from react-textarea-autosize.

@Andarist you beat me to it!

Thanks for the example, I looked into it.

We schedule a rAF callback with resizeComponent() when we start the animation but because rAF callback executes before the animation completed it measures the wrong height.

The current implementation only calls resizeComponent() when a. resize event fires on window or b. component is being rendered with new props. Neither of a. and b. happens when animation ends.

So for that exact case my advice above to use react-static-container is the partial solution as you'd want to disable rerendering textarea and thus trigger its resizeComponent().

See updated codesandbox: https://codesandbox.io/s/1rN0XgGRj (btw love this service!)

Why partially? Because if you resize browser window when animation is in progress or textarea is hidden — it trigger resizeComponent() method due the resize listener firing.

Maybe we should add skipUpdate prop to <TextareaAutosize />? So that we can cut calls to resizeComponent() completely when it's not needed (during the animation and/or other edge cases).

from react-textarea-autosize.

hey @andreypopp ! Im glad you are still around and checking out :)

skipUpdate
im wondering if thats in any way helpful more than existing useCache~, it can also be steered with props quite granulary, but maybe i didnt think of something

from react-textarea-autosize.

Hi,
Did someone find solution for that problem?
I found a solution (or workaround) by attaching to 'animationend' event which trigger prop change (by prop change I mean provide some kind of updateHash in my case is Date.now().toString()) in textarea-autosize so in the same time it leads to height recalculate.

What do you think about it?

from react-textarea-autosize.

If it works then it works 😉be pragmatic - from what I understand you force the rerender in onAnimationEnd, right? Seems that can indeed solve a problem, we just can't do anything like this in the library itself, because it's a leaf node and we can't know in what way it is used.

When I have last looked into the code it seemed to me that rAF scheduling might not be needed nowadays (issue #216), maybe it was needed once, but at the moment it's used only for controlled mode (and for uncontrolled mode when props change, but it seems to me that the only relevant part are value changes, so this case in uncontrolled mode can be disregarded).

So if we do not have any perf reports for uncontrolled mode, maybe this scheduling used in controlled mode is an overkill and could be just removed? Which has potential of alleviating your issue altogether.

Problem with such changes is that we don't really have any tests :s so any change is a risk. I'll try to prepare a beta release without that scheduling in a moment for testing purposes.

from react-textarea-autosize.

You can try npm install react-textarea-autosize@beta

from react-textarea-autosize.