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

时间 2019-11-05

原文原文链接

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

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

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

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

单从输入框的光标变化行为来看，这好像也不算是一种异常的变化，只是不响应值的变化跳到尾部而已。但引伸出来的问题是为何在 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 的表现和其余平台上表现一致，即表现为光标在从新渲染时跳到最后，示意代码以下。ui

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 (
            <input 
                value={this.state.value} 
                onChange={(e) => { this.handleChange(e); }}  
            />
        );
    }
}

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

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

从上面的图里能够看出，由于 React 不管何种修改都会将光标置尾，若是从中间进行修改，那么表现地又会很不符合用户预期，没有办法作到连续输入。这回却是两端行为保持一致，都是不指望的状态。。spa

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

在用户输入的过程当中，只存在两种状况，在结尾中追加和在中间修改。在结尾追加的 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 (
            <input 
                ref={(c) => { 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

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...