Home>Article>WeChat Applet> Summary of issues with textarea and input in WeChat mini programs
This article brings you relevant knowledge aboutWeChat Mini Program, which mainly introduces a summary of the problems of textarea and input in the mini program. When only one of these two components is used, There is no problem, but when the two of them appear together, problems come one after another. Let’s take a look at them together. I hope it will be helpful to everyone.
[Related learning recommendations:小program learning tutorial]
In the WeChat applet, there are two native components textarea and input , there is no problem when using only one of these two components, but when they appear together, problems come one after another, and they are all very metaphysical problems. I encountered these metaphysics during development. The problem is that a simple form filling page is just to implement a manual page push function. It took several days to complete it!
Rendering:
Thinking
After I solved these metaphysical problems in a special way, I thought a lot
Why are there these metaphysical problems when textarea and input are used together?
I obviously wrote it the normal way, why can it work on iOS phones but not on Android phones?
Why is it possible sometimes and not sometimes?
...and so on
In order not to take detours on these issues in the future, I decided to explore the love between textarea and input Kill
Test machine
The machines used in this exploration are
Android machines: Honor 20, Xiaomi 10s;
ios machine: iPhone13
Here comes the metaphysical question!
Problem: only bind the bindkeyboardheightchange event for textarea, input will also trigger the bindkeyboardheightchange event of textarea, and The parameters carried by the trigger are all the parameters above the textarea
Model: Android must appear
Example:
Solution: Not available Found the solution
Problem: When the hold-keyboaed attribute of textarea and input is set to true, and the input is When a type is not text, continuous switching will jam the completion above the keyboard, and the textarea will no longer be focused.
Model: Android must appear
Example gif:
Solution: 1. Do not display the completion button above the textarea when the keyboard is raised through show-confirm-bar, 2. Set the input type to text, 3. Do not set hold- keyboaed is true
Problem: When there is a fixed element, no matter how many z-index values are set, the textarea component will penetrate the fixed Element
Model: Android Occasionally appears
Metaphysical point: Sometimes it does not appear, but when I recompile and scan the code to preview, the textarea penetration problem will occur, and then It will always appear, but when I delete the mini program on my phone and recompile and scan the code, there is a chance that the problem will not occur
Example gif:
Solution: When you need a fixed element to cover the textarea, you can hide the textarea or turn it into a view element when the fixed element appears
Problem: When only bindfocus event is bound to textarea, after entering the page, click textarea first, and then click input immediately, the focus event of textarea will be triggered
Model: Android Occasionally
Example gif:
Solution: You can dynamically control the focus of the textarea through focus, and try not to set the input type to number type
Problem: If you manually lift the page through bottom or translateY during the keyboard lifting process, and set the transition animation attribute, it will cause the placeholder of the textarea to flash.
Model: Android must appear
Example gif:
Solution: Determine the model, add transition attribute for ios, Android machine Do not add transition attribute
Problem: textarea binds bindkeyboardheightchange event, and uses its own completion, the bindkeyboardheightchange event will not be triggered when clicking to complete
Model: Android Occasionally
Example gif:
Solution: No solution found
Problem with auto-height: When the auto-height attribute of textarea is true, it will cause problems when using selectComponet to obtain the height. Sometimes it is the initial height of a row without content, and sometimes it is the height of the textarea. Default height
Models: ios and Android
Solution: Dynamically control the value of auto-height, or use a timer to delay obtaining the height
Problem: The bindkeyboardchange event is triggered multiple times, and the keyboardHeight height obtained from the event is inconsistent. Sometimes it has the completed height, sometimes it does not.
Model: Android Occasionally
Solution: No solution found
Problem: Obtaining the element through selectComponet When setting the height, width or position, all decimals will be retained by default, which is about 16 digits, which may cause confusion in the animation
Model: ios and Android Occasionally
Solution: The js language itself There is a precision problem, so after obtaining the data through selectComponent, it is best to only keep two decimal places for processing
[Related learning recommendations:小program learning tutorial]
The above is the detailed content of Summary of issues with textarea and input in WeChat mini programs. For more information, please follow other related articles on the PHP Chinese website!