发布网友 发布时间:2022-04-22 21:55
共5个回答
懂视网 时间:2022-04-22 17:50
本篇文章给大家带来的内容是关于在数值格式化中React input 的光标的处理办法(详细),有一定的参考价值,有需要的朋友可以参考一下,希望对你有所帮助。今天要来说的是有关于有数值格式化的场景中,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 ( <input value={this.state.value} onChange={(e) => { 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 ( <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
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...
热心网友 时间:2022-04-22 14:58
“数值格式”是数字,“文本格式”是文本字符,数字可以直接参与计算,而文本字符大多数需进行数值处理后才能参与计算。
具体的使用上的区别:
1、首先选中单元格区域并点击鼠标右键,选择其中的”设置单元格格式“选项。
2、然后在打开的设置窗口中点击“数值”,可以根据需要设置小数位数。
3、然后在空白单元格中可以进行对输入的数字的计算操作,点击回车即可得到计算结果。
4、如果在设置窗口中选择“文本”类型。
5、在输入数字的时候会在单元格的左上角显示绿色三角形符号。
6、此时进行对单元格数据的取数并计算的话,点击回车无法直接得到计算结果。
热心网友 时间:2022-04-22 16:16
一、指代不同
1、文本型:指的是TXT等文本型的数据。
2、数值型:是表示数量、可以进行数值运算的数据类型。
二、处理方式不同
1、文本型:阿拉伯数字也可以作为文本型数据。例如在Excel2003单元格中输入“88本书”,阿拉伯数字88会被当作文本处理。
2、数值型:是按数字尺度测量的观察值,其结果表现为具体的数值。
三、特点不同
1、文本型:字符文本应逐字录入。
2、数值型:由数字、小数点、正负号和表示乘幂的字母E组成,数值精度达16位。
扩展资料:
1、在单元格中的对齐方式不同。
“文本”格式在输入单元格后是默认靠左对齐。
“数值”格式在输入单元格后是默认靠右对齐。
2、运算方式不同
“文本”格式不参于运算,如果要参与运算,可能会造成计算的错误或者不显示计算结果。
“数值”格式是为运算设置的,使用该格式计算更为准确。
3、单元格提示样式不同
“文本”格式在单元格中输入数字时,单元格左上角会显示绿色的三角符号。
“数值”格式在输入多于11位的数字时会变成科学计数法。
参考资料:百度百科-文本型数据
参考资料:百度百科-数值型数据
热心网友 时间:2022-04-22 17:51
“数值格式”与“文本格式”的区别就在于一个是数字,而后者是文本字符,数字可以直接参与计算,而文本字符大多数需进行数值处理后才能参与计算。
而数字格式如果输入大于11位数,则会显示为科学计数法。如果输入001,则显示为1。所以如果出现这两种情况,最好把它们设置为文本格式,才能正常显示。
Excel中,当你输入数字时,Excel默认的是当作数字处理,但当你输入数字时前面加英文输入状态下的单引号‘,如“ ‘2 ”时,则这个2就会当作文本处理,或者将单元格选设置为文本格式后再输入数字,这也会当作文本处理。
您可以操作试一下,可以看到数字和文本的显示会有所不同:
1、默认状态下,文本格式单元格是左对齐,数字单元格是右对齐;
2、文本格式的单元格左上角有一个绿色小三角形的提示符(若没有,可以设置:点击“工具——选项——错误检查”,在“数字以文本形式存储”前面打上勾,按确定),而数字单元格则没有绿色小三角形。
热心网友 时间:2022-04-22 19:42
Excel中,当你输入数字时,Excel默认的是当作数字处理,但当你输入数字时前面加英文输入状态下的单引号‘,如“ ‘2 ”时,则这个2就会当作文本处理,或者将单元格选设置为文本格式后再输入数字,这也会当作文本处理。