Open gnprice opened 6 years ago
But also scary. I tried to make sure there were no behavior changes when I rewrote it
Here's hoping you don't restore the previous behavior 😄
Perhaps what was changed is that there was previously many unneeded renders on each key press, while with hooks you somehow avoided that?
It also seems to be fixed on 0.61.5. Can anyone else confirm?
not 100% sure but seems it works good on 0.61.5, checked locally
That's great to hear! Given that we sort of have a 3-way confirmation on this not being an issue in latest versions, I'll be optimistic and close this issue.
If someone can repro this with latest 0.61.x AND 0.62 RC please link it below and we can reopen this.
I think closing this is a little premature. This is a major issue that has affected the entire user base for several years. This issue alone has caused several developers i know personally to abandon react native due to frustration and hundreds of hours of lost productivity. I think it deserves some more thorough testing. And if it is fixed, maybe we can find the commit that fixed it and the reason it was broken in case it turns up again in the future.
Given that 3 different developers confirmed separately that the issue is fixed for them I thought it would be good to close it to signal to the other developers in the issue that there has been "an evolution" on this subject (as probably many people don't open the notification about it when simply new comments are added). But I see your point @rspenc29 so I'll reopen.
I think it deserves some more thorough testing. And if it is fixed, maybe we can find the commit that fixed it and the reason it was broken in case it turns up again in the future.
If you could help with that it would be great, as my bandwidth is quite limited.
Seems it's finally gone. Tested on 0.61.5 and it is working fine
Just tested on 0.62.0-rc.2 works perfect!!! TextInput now not freeze UI and onChangeText() setState() not lagging anymore, not need to make workaround like: this.inputRef.current._lastNativeText;
Cool - thanks everyone. When 0.62.0 is out I'll close this then.
@kelset Are you sure? I thought this was an architectural issue as mentioned by @axe-fb here: https://youtu.be/83ffAY-CmL4?t=1366
On 0.62 I am still experiencing the issue on real low end devices. In the emulator its fast. Is there a way I can provide more debugging info?
@kelset Are you sure? I thought this was an architectural issue as mentioned by @axe-fb here: https://youtu.be/83ffAY-CmL4?t=1366
This is the current problem (slides from infinite-red video and the solution is from @nparashuram)
You type R and you set value of R to the field.
You add E to R (RE) and another call to onChangeText is triggered, at the same time callback setText('R')
is called
and now setText('RE')
is called again while the user keeps updating that field and adding callback that are slowing down the app
WORKAROUND from @nparashuram
Add a debounce function, that delays calling onChangeText
every 100 milleseconds
SOLUTION from @nparashuram
The solution that he proposes at minutes 24:55 (for the new react-native versions) is to use syncronous calls instead of asyncronous.
You type R --> syncronous call setValue('R')
--> you type E --> syncronous call setValue('RE')
https://formidable.com/blog/2019/fabric-turbomodules-part-3/
I am experiencing this issue on RN 0.63.2
and it appears to be exactly what @fabriziobertoglio1987 is pointing to. If I remove value
then TextInput is super fast. Many users on Android 8/9 phones (a little old, but not walkie talkies) are reporting that it is buggy to use the TextInput.
I am using a workaround where I remove the value
prop. I set a defaultValue
and use onChangeText
to listen to changes. This stops the bugginess since it doesn't have to make the round trip explained above.
Even in the react-native docs they mention this flicker (I guess) https://reactnative.dev/docs/textinput#value
value
: The value to show for the text input. TextInput is a controlled component, which means the native value will be forced to match this value prop if provided. For most uses, this works great, but in some cases this may cause flickering
Has anyone had bad experiences from using defaultValue
and onChangeText
?
@wmonecke, we are considering using your technique. Did you find any drawbacks to it eventually?
I found a way to make the delay go away, without workarounds that avoid using the TextInput value or debouncing onChangeText() (and I'm stressing it quite a bit, using a barcode scanner that creates 13 chars within 0.5s).
I've completely bypassed the SpannableStringBuilder and I don't know if that creates other problems (I don't see any styling going away, even with properties that seem to want to use spans (e.g. letterSpacing)). All I know is that the delay has gone away, I see no issue in my app and after looking into this for days, I'm too tired to care about anything else. If anyone wants to test it out, you can use this in your package.json:
"react-native": "github:bdokimakis/react-native.git#0.63-stable-with-fix-for-20119"
Any feedback would be appreciated.
Text input is also slow on iOS because of the value. That's a very bad experience while using battery saving mode Can I get the native value temporarily without set value?
We didn't set value on multi-line textinput for years, it was, well... "okay". Until lately after upgrading to 0.63, we started getting reports from users that after editing a while the whole phone became laggy and they have to restart the phone to go back normal.
We're still investigating and I couldn't reproduce the problem on my android devices as well.
For anyone having doubts about my workaround:
I have been using my solution posted above in my app with 40k MAU and I haven't seen a single report or issue.
Happy coding!
I am still receiving reports on this issue (without setting the value attribute). If anyone could help fixing this issue or building a standalone simplified textInput module ( maybe like this one? ) please PM.
I'm encountering this issue on RN 0.63.2, TextInput becomes extremely laggy after a while if applying any of the following to the component
the solution for this issue is create a method that uses the RNBridge syncronously instead asyncronously as explained in https://github.com/facebook/react-native/issues/20119#issuecomment-639482512
not worth it creating a pr as the react native team is working on the new architecture which should solve all the limitation from the react native bridge
the solution for this issue is create a method that uses the RNBridge syncronously instead asyncronously as explained in #20119 (comment)
not worth it creating a pr as the react native team is working on the new architecture which should solve all the limitation from the react native bridge
@fabriziobertoglio1987 This didn't resolve the issue for me
the solution for this issue is create a method that uses the RNBridge syncronously instead asyncronously as explained in #20119 (comment)
not worth it creating a pr as the react native team is working on the new architecture which should solve all the limitation from the react native bridge
As I mentioned, I did not set the value attribute and also with a debounced onChange ( so no async callback I suppose? ), but the performance drop remains. I have received more than 10 reports mentioning it will cause the keyboard lag with serious delay, even after quitting the app. They will have to restart the device to back to normal.
For me, I could easily reproduce the performance drop even with flagship devices by pasting around 15-20k characters into the textInput. Maybe it's a rare case in most the app but for a diary or note-taking app it's quite normal.
If anyone could provide any workaround or a temp fix, I am willing to donate.
Thanks.
the solution for this issue is create a method that uses the RNBridge syncronously instead asyncronously as explained in #20119 (comment) not worth it creating a pr as the react native team is working on the new architecture which should solve all the limitation from the react native bridge
As I mentioned, I did not set the value attribute and also with a debounced onChange ( so no async callback I suppose? ), but the performance drop remains. I have received more than 10 reports mentioning it will cause the keyboard lag with serious delay, even after quitting the app. They will have to restart the device to back to normal.
For me, I could easily reproduce the performance drop even with flagship devices by pasting around 15-20k characters into the textInput. Maybe it's a rare case in most the app but for a diary or note-taking app it's quite normal.
If anyone could provide any workaround or a temp fix, I am willing to donate.
Thanks.
Same experience here, and I don't need to put that many characters in, putting in a few sentences and removing it by holding the backspace button a few times does it on iPhone X.
In 2018 (I think it was RN 0.52 or some version around that) we could fix it completely by uninstalling the Gboard app. That's the native google keyboard, which, I guess, is installed on every Android device. Then the lags are gone. So if it's no publicly available app, like some kind of corporate app where you have access and control over all devices, that's at least an option. Just be sure to install some other keyboard app like swift, or have at least a hardware keyboard at hand, before you uninstall/disable it. Else you are left with the voice keyboard (which we also uninstalled because for our app only hardware keyboards were used and the voice keyboard confused our users).
I found a way to make the delay go away, without workarounds that avoid using the TextInput value or debouncing onChangeText() (and I'm stressing it quite a bit, using a barcode scanner that creates 13 chars within 0.5s).
I've completely bypassed the SpannableStringBuilder and I don't know if that creates other problems (I don't see any styling going away, even with properties that seem to want to use spans (e.g. letterSpacing)). All I know is that the delay has gone away, I see no issue in my app and after looking into this for days, I'm too tired to care about anything else. If anyone wants to test it out, you can use this in your package.json:
"react-native": "github:bdokimakis/react-native.git#0.63-stable-with-fix-for-20119"
Any feedback would be appreciated.
Thank you @bdokimakis I can confirm that in my case ( https://github.com/facebook/react-native/issues/20119#issuecomment-777945896 ) removing the SpannableStringBuilder works pretty well, the lag is totally gone even with 100k+ characters. However there are still some text selection / typing problems to solve. If anyone could help investigate in this way it might be really helpful.
Here's my mod in a package https://www.npmjs.com/package/react-native-no-lag-text-input for easier testing.
@tarouboy if you could let me know what text selection / typing problems you're facing, I will take a look.
Here's my mod in a package https://www.npmjs.com/package/react-native-no-lag-text-input for easier testing.
@tarouboy if you could let me know what text selection / typing problems you're facing, I will take a look.
I tried this, but still have the issue.
Here's my mod in a package https://www.npmjs.com/package/react-native-no-lag-text-input for easier testing. @tarouboy if you could let me know what text selection / typing problems you're facing, I will take a look.
I tried this, but still have the issue.
@HadiModarres try v.1.1.0 please and let me know exactly what issue you're having, if still there. Also, please confirm that you're checking text inputs where you've replaced RN's TextInput with NoLagTextInput that you've imported from my package.
@bdokimakis Your component is behaving the same as the original TextInput for me. I used your component like:
<NoLagTextInput defaultValue={'hello'} />
And then typed a few sentences, and removed it by holding down the backspace key. The issue is that the component becomes slower and slower to enter each character and to delete them. Note that the issue isn't about flickering or anything like that, it seems like there's something weird going on in the component like some sort of leak or accumulating callbacks.
Only way this slowdown doesn't happen is to not use any of defaultValue
, value
, or onChangeText
, which makes the text input useless at that point.
@HadiModarres thanks for testing. I just tried to reproduce the issue you described, but it seems to be working fine.
package.json: "react-native-no-lag-text-input": "^1.1.0" and "react-native": "0.63.3"
code:
test result: https://user-images.githubusercontent.com/12087618/108032499-405ab580-703b-11eb-8ec6-d31d4d683a69.mp4
Let me know if you're testing in a different manner so I can try to reproduce.
In my case, the TextInput becomes slow when starting typing. I noticed that autocorrect takes some time to suggest words on the keyboard and so I turned it off. Now it works better. I know it's not the best solution, but ... ¯ \ (ツ) / ¯
autoCorrect={false}
This has gotten worse recently since we've upgraded to RN 67 and we've begun receiving reports of more lag and even crashing ("App isn't responding...") . None of the fixes suggested above seem to work. Any updates on RN core side @kelset @bvaughn, etc?
Not the ideal solution, but I've also found that turning off autoCorrect as suggested above has a significant positive performance impact with large text.
Device: Samsung Galaxy S10 Android Version: 12 React-Native Version: 0.64.0
This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.
There's no reason to believe this has been fixed. Stale-bot please go away.
We are having similar issues on React Native 0.67 and Android 13 users.
We have a chat screen with a TextInput at the bottom. Removing everything but style
, multiline
and scrollEnabled
results in the app suddenly slowing down after about one minute of doing nothing or typing a few letters. Dismounting the input by leaving the screen restores any slowdown. The TextInput
simply seems to implode even without reading or writing to it via the onChangeText
, defaultValue
or value
props.
We are having similar issues on React Native 0.67 and Android 13 users.
We have a chat screen with a TextInput at the bottom. Removing everything but
style
,multiline
andscrollEnabled
results in the app suddenly slowing down after about one minute of doing nothing or typing a few letters. Dismounting the input by leaving the screen restores any slowdown. TheTextInput
simply seems to implode even without reading or writing to it via theonChangeText
,defaultValue
orvalue
props.
Did you find any solution for this?
How can such an essential component be buggy since 5 years? Not asking to annoy somebody, just questioning, if there's something wrong with notifications, some missing label, or whatever is needed that this issue is seen by some maintainer.
we had to rewrite the input component in our app 4 years ago! it wonders me that I get a notification from this topic once in a while and seems like the original issue has not been fixed yet!
we had to rewrite the input component in our app 4 years ago! it wonders me that I get a notification from this topic once in a while and seems like the original issue has not been fixed yet!
Would you be willing to share the fixed component?
we had to rewrite the input component in our app 4 years ago! it wonders me that I get a notification from this topic once in a while and seems like the original issue has not been fixed yet!
Would you be willing to share the fixed component?
unfortunately, I don't have access to the code since I left the company 3 years age
The problem seems to solve for me (but I'll still test a lot more). Solved when I added: scrollEnabled={false} autoCorrect={false} to the TextInput
If you want to understand the app and the problem I had:
In my app I have a component named Exercise with View, several Text and a TextInput. Each one with its styles and TextInput with also onFocus and onBlur. In the Exercises page you choose how many exercises you want. It means several or many Exercise components will be rendered in the Exercises page. And when input the answers in the TextInputs of each Exercise you can check if the answers are right or not and generate new exercises. When you generate new it means what you generated before will be removed and the new ones will be rendered.
before scrollEnabled={false} and autoCorrect={false} I stopped using state and tried ref but did not work. Now I'm using scrollEnabled={false} autoCorrect={false} and ref. But did not test with scrollEnabled={false} autoCorrect={false} and state.
The problem: You could generate just 3 exercises and you input the answer in TextInputs. At the beginning the text digits fast but after some time generating more 3 exercises it became very slow and did not come back to normal. And it affects other apps. Going to Whatsapp became very slow to digit. I had to restart cellphone.
I've still seen this in RN 0.70 (within an expo app on Android).
I took a few approaches:
I'll see how this goes, but I've had good reports so far.
See more info in this comment https://github.com/facebook/react-native/issues/20119#issuecomment-639482512 It is caused by TextInput controlled components.
Possible solution: When we reach a lot of update and consequential slow down in the performance, instead of batching 1 update for each letter we type (onChangeText triggers every time we type a character), we send multiple characters all at once
For example
1) User types in the TextInput "Hello World"
Now react-native does like this:
2) JS TextInput sends "H" to Java EditText 3) Java EditText shows H in the TextInput 4) Java notifies JS TextInput that H was added on the EditText 5) JS repeats 2-4 for every character
Instead we could add logic in the TextInput API, in case user types 5 characters per second:
2) JS TextInput sends "Hello"
to Java EditText
3) Java EditText shows Hello
in the TextInput
4) Java notifies JS TextInput that Hello
was added on the EditText
5) JS repeats 2-4 for the second word "World"
It could enabled by default or disabled by default with a prop batchWordsToOptimizePerformanced
.
The batching of words instead of characters would be used ONLY when the user types extremely fast and the TextInput is very laggy.
The issue was opened 6 years ago. It should have been resolved with the new architecture. Does somebody experience this with new architecture? Should I prepare a fix or nobody is interested in this anymore? Thanks
1) I would not take into consideration implementing the above solution. Rendering words instead of characters, when TextInput performances are degraded, may not be a good option. 2) Implementing a setTextSync is not possible on the old architecture (see my comment above)
Does it reproduce on the new architecture?
This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.
Stale-bot please go away — there's no reason to think this has been fixed.
Environment
(*) In my test app, actually v0.55.4 plus the patch from #19645 . Others on #19126 report the same symptoms using v0.56.
Description
After typing a lot of text into a controlled TextInput, like ~500 char on a recent fast phone, we start dropping frames. It gets worse the more you type; at ~1000 char, we very frequently drop frames and the app looks noticeably laggy.
Reproducible Demo
The original repro is by @s-nel: https://github.com/s-nel/rn19126
Originally reported at https://github.com/facebook/react-native/issues/19126#issuecomment-402904164; more discussion in subsequent comments in that thread.
In particular, here's the video from that repro:![video](https://github.com/s-nel/rn19126/raw/master/frameloss.gif)
Here's a video by @s-nel on my test app, with this description:
Here's my description of replicating that repro, again in my test app:
That was on a Pixel 2 XL; the numbers will probably vary with hardware.
Background from previous bug
This bug seems closely related to #19126; the repro steps and symptoms seem to be exactly the same, except quantitatively much less severe. (The original reports of #19126 describe clearing the input as part of the repro; I now think that was probably a red herring.)
The extreme symptoms of #19126 were absent in v0.54, introduced in v0.55, and fixed in v0.56 by #19645 . As I wrote when I figured out the cause of that (leading to the one-line fix in #19645):
I think we're now looking at exactly that underlying bug. It may well have been present in v0.54 and earlier releases; I don't think we have any data on that. [EDIT: @piotrpazola finds below that the bug is present in v0.50, and absent in v0.49.]
I don't know anything more about what causes it; even the hypothesis that we're ending up with large numbers of text shadow nodes is just an inference from how it interacts with the line fixed in #19645. So, more debugging is required.
I don't expect to do that debugging myself, because these remaining symptoms are no longer one of the top issues in our own app. But I hope somebody else will!