在格式化的场景下，React input 的光标的处理办法

cheng10 发布于2019-08-23 12:28 / 1579人阅读

摘要：具体表现是什么样的呢图安卓下不期望的输入行为可以看到，在安卓手机下每次格式化发生的时候，本来应该一直在最后的光标会错格一位，导致连续输入出现问题。

今天要来说的是有关于有数值格式化的场景中，React input 光标的一些异常的表现和对应的处理办法。故事要从一个 issue 说起，有用户反映在使用 NumberField 组件输入时安卓下会出现光标位置异常，导致连续输入会达不到期望的结果。具体表现是什么样的呢？

图1 安卓下不期望的输入行为

可以看到，在安卓手机下每次格式化发生的时候，本来应该一直在最后的光标会错格一位，导致连续输入出现问题。而这个问题在 PC Chrome 和 iOS 上都没有出现，于是可以判定是一个兼容性问题。但这个兼容性问题是如何产生的呢？

分析一下格式化的话的过程，如上面的情况，输入 18758 时，因为要做针对卡号的格式化，所以会将原有的值转变为 "1875 8"，从字符串长度上来看，从 5 位变成了 6 位，那么如果此时光标位置没有在值变化时跳到最后一位，则会停留在空格处，看起来就好像错格了一位，连续输入时就会有问题。

单从输入框的光标变化行为来看，这好像也不算是一种异常的变化，只是不响应值的变化跳到尾部而已。但引申出来的问题是为什么在 iOS 和 PC Chrome 下又会跳动到尾部呢。

图2： 相同的代码在 PC Chrome 下表现与安卓不同。

于是去网上搜索，辗转在 React 的 github 中找到这样一个 issue, Cursor jumps to end of controlled input。在这里 React 的主要维护者之一的 @sophiebits(spicyj) 给出了一个比较确切的答案。

图3 sophiebits 关于 React controlled input value 变化时光标行为的解释

原来因为 value 的变化具有非常大的不确定性，因此 React 无法使用一种可靠且通用的逻辑去保存光标的位置在一个合适的位置，因此 React 在受控模式下的重新渲染都会时光标移动到最后的位置。这个至少解释了PC Chrome 和 iOS 下光标跳动到结尾的原因，但安卓下为什么没有表现出同样的行为到目前位置我还没有找到合理的解释。

那有没有办法使安卓上的表现和 iOS 中一致呢？又是一阵翻阅和尝试，最后发现如果将重新渲染的过程和 input 的 onChange 置于前后两个 tick 中就可以使安卓中 input 的表现和其他平台上表现一致，即表现为光标在重新渲染时跳到最后，示意代码如下。

import React from "React";
class Demo extends React.Component {
    constructor(props) {
        super(props);
        this.state = {
            value: "xxx",
        };
    }
    
    handleChange(e) {
        const value = e.target.value;
        // 通过 setTimeout 异步
        // 使 re-render 和 onChange 处于两个 tick 中
        setTimeout(() => {
            this.setState({
                value,
            });
        });
    }
    
    render() {
        return (
             { this.handleChange(e); }}  
            />
        );
    }
}

这样终于使得表现的行为在安卓和 iOS 上表现一致，并且正常输入的情况下表现得比较符合期望了，然而等等，这样就可以了吗？从之前的 React issue 中得出的结论可以看出，无论是如何的修改都会跳至 input 的结尾，这样如果是从中间修改的话会变成什么样?

图4：中间编辑时又会出现问题

从上面的图里可以看出，因为 React 无论何种修改都会将光标置尾，如果从中间进行修改，那么表现地又会很不符合用户预期，没有办法做到连续输入。这回倒是两端行为保持一致，都是不期望的状态。。

但是都不正常也有好处，不需要根据平台去写一些 ifelse，可以统一地去做处理。从上面的讨论中我们可以知道 React 没有保存光标的位置是因为没有一个通用并且可靠的算法去支撑这一行为。这是因为 input 的变化可能是增加空格做格式化，也可能是过滤过些字符，也可能是触发某些条件直接变成了其他字符等各种无法预测的变化行为。但是细化到数字格式化这一单一场景时，光标位置的保存逻辑就变得简单和清晰的多了。

在用户输入的过程中，只存在两种情况，在结尾中追加和在中间修改。在结尾追加的 case 中，例如 18758^ 时，由于一直是在向后追加的状态，我们只要一直保持光标在最后即可（即默认状态 1875 8^ ），在中间编辑的 case 下，光标并不处于结尾，如 187^5 8，此时如果在 7 后面追加了一个 8，那么理想的图标应该维持在 8 之后（即 1878^ 58），此时就应该保存光标的位置在上次 format 之前的状态。

逻辑清楚了，接下来就是如何实现的问题了。那么如何探测和修改光标位置呢？这就涉及了 input 中选区相关的属性，我们知道我们可以通过一些方式（如鼠标拖拽和长按屏幕等）在 input 中完成对一段话的选区，因此光标的位置其实是由选区的开始点（selectionStart）和结束点（selectionEnd）决定的。那么其实我们就可以通过读取，储存和设置这两个属性来达到我们想要实现的目的，实例代码如下。

class Demo extends React.Component {
    ...
    
    componentDidUpdate(prevProps) {
        const { value } = prevProps;
        const { inputSelection } = this;
        if (inputSelection) {
          // 在 didUpdate 时根据情况恢复光标的位置
          // 如果光标的位置小于值的长度，那么可以判定属于中间编辑的情况
          // 此时恢复光标的位置
          if (inputSelection.start < this.formatValue(value).length) {
            const input = this.input;
            input.selectionStart = inputSelection.start;
            input.selectionEnd = inputSelection.end;
            this.inputSelection = null;
          }
        }
    }
    
    handleChange(e) {
        // 在 onChange 时记录光标的位置
        if (this.input) {
          this.inputSelection = {
            start: this.input.selectionStart,
            end: this.input.selectionEnd,
          };
        }
        ...
    }
    
    render() {
        return (
             { this.input = c; }}
                value={this.state.value} 
                onChange={(e) => { this.handleChange(e); }}  
            />
        );
    }
}

至此，我们终于在追加和中间编辑的情况下都实现了我们想要的效果。这是一个比较小的技术点，但是由于里面涉及了一些 React 内部的处理逻辑及平台差异性问题，排查和解决起来并不是那么容易，希望可以给有类似问题的同学在处理时有所启发。

文中涉及的各端及浏览器信息

Android

Mozilla/5.0 (Linux; U; Android 8.1.0; zh-CN; CLT-AL00 Build/HUAWEICLT-AL00) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/57.0.2987.108 UCBrowser/11.9.4.974 UWS/2.13.1.48 Mobile Safari/537.36

iOS

Mozilla/5.0 (iPhone; CPU iPhone OS 11_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15F79

PC Chrome

Mozilla/5.0 (Linux; Android 5.0; SM-G900P Build/LRX21T) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Mobile Safari/537.36

文中涉及的组件库

SaltUI: https://github.com/salt-ui/sa...

服务器托管私有云 js处理json格式的数据电脑下的视频怎么转换格式 input光标 java的光标位置

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/98573.html

input 弹起数字键盘的那些坑

摘要：踩的大坑前言最近有个需求要将全平台的交易密码由原来的位复杂密码改为位纯数字交易密码，涉及到非常多的业务场景，但修改起来也无非两种设置交易密码，使用交易密码设置交易密码普通长条输入框弹起数字键盘支持明暗文切换查看使用交易密码显示六个格子弹起 input ios 踩的大坑前言：最近有个需求要将全平台的交易密码由原来的 6-16位复杂密码改为6位纯数字交易密码，涉及到非常多的业务场景，但...

imccl 2019-08-30 14:12 评论0 收藏0
基于uiwebview富文本编辑器实践

摘要：背景最近我们微信读书将写想法换成了基于的富文本编辑器，遇到了不少问题，这里我将简单的介绍一下我们在开发过程中踩到的坑。背景最近我们微信读书将写想法换成了基于webview的富文本编辑器，遇到了不少问题，这里我将简单的介绍一下我们在开发过程中踩到的坑。实现富文本编辑器有两个基本思路：基于native实现：比如coretext或者textkit 基于uiwebview实现第一...

luzhuqun 2019-08-21 14:29 评论0 收藏0
从 setState promise 化的探讨体会 React 团队设计思想

摘要：我们来从设计思想上，和官方团队的回应上，了解一下否决理由。此外，还有一个方法新的接口设计支持接收一个回调函数，当其子组件挂载时，这个回调函数就会相应触发。从 setState 那个众所周知的小秘密说起... 在 React 组件中，调用 this.setState() 是最基本的场景。这个方法描述了 state 的变化、触发了组件 re-rendering。但是，也许看似平常的 th...

caiyongji 2019-08-20 19:03 评论0 收藏0
从 setState promise 化的探讨体会 React 团队设计思想

摘要：我们来从设计思想上，和官方团队的回应上，了解一下否决理由。此外，还有一个方法新的接口设计支持接收一个回调函数，当其子组件挂载时，这个回调函数就会相应触发。从 setState 那个众所周知的小秘密说起... 在 React 组件中，调用 this.setState() 是最基本的场景。这个方法描述了 state 的变化、触发了组件 re-rendering。但是，也许看似平常的 th...

forrest23 2019-08-01 17:31 评论0 收藏0
Web聊天工具的富文本输入框

摘要：由于我们的富文本输入框比较简单，所以只需要处理两类数据即可，其一是普通的文本类型数据，包括表情其二则是图片类型数据。最近折腾 Websocket，打算开发一个聊天室应用练练手。在应用开发的过程中发现可以插入 emoji ，粘贴图片的富文本输入框其实蕴含着许多有趣的知识，于是便打算记录下来和大家分享。仓库地址：chat-input-box预览地址：https://codepen.io...

iKcamp 2019-08-23 15:36 评论0 收藏0