我們的認知:
當(dāng)我們?nèi)ヅ袛嗲岸薋orm表單有沒有變化的時候，通常會采用什么方法呢？相信框架是我們的本能，比如Angular，React。。。等前端框架都自帶判斷方法，那么這樣的方法是不是100%可信呢？
故事是這樣的：
我們的產(chǎn)品里，可以理解有一個個大表單。表單里面的內(nèi)容可以分為A部分和B部分。通過判斷表單里面值有變更的字段是屬于A部分還是B部分來進行不同的業(yè)務(wù)邏輯處理。
在測試中，我們發(fā)現(xiàn)在其實只動了B部分的字段，結(jié)果卻跑到了A部分被修改的業(yè)務(wù)流程里，what are you弄啥嘞？莫慌莫慌，我們來看看發(fā)生了什么：
1. 打開developer tool bar看一下請求是啥，咦，前端狀態(tài)發(fā)錯了，認為A變了，有理有據(jù)有截圖，直接去找了前端?
2. 在等待開發(fā)調(diào)查的過程中順手去chrome上測了一把，然后發(fā)現(xiàn):what? Chrome竟然沒有這個問題，請求的參數(shù)都是對的，就是這么神奇？這樣的bug還分瀏覽器，嚇到了我的三觀。
趕緊把這一消息告知前端說是IE的問題，前端著手調(diào)查，中間差不多等了有好幾個好幾千秒。前端說找到問題了！ 真棒~~?
問題的原因：
QA同學(xué)：我沒有修改A的內(nèi)容，前端頁面也不允許我修改，只是改了B，為什么我提交的時候卻影響了A呢？
開發(fā)同學(xué)：是的 ，你沒有動A里面的字段，但是IE替你動了。
QA同學(xué)：納尼？？？？
開發(fā)同學(xué)：ie會在API返回的數(shù)字上加上.0，比如API返回”45“，ie給你”45.0"，而前端渲染的時候刪掉了這個".0"，所以當(dāng)我們在提交表單的時候，我們的對比機制發(fā)現(xiàn)form表單數(shù)字的字段都發(fā)生了修改，因為A部分的優(yōu)先級更高，因為你修改了這個字段值，所以就會回到A階段。
QA同學(xué)：這個問題什么時候發(fā)生的？為什么以前沒有問題？
開發(fā)同學(xué)：????
在風(fēng)中凌亂。。。。
解決方案：
開發(fā)同學(xué)苦心調(diào)研，告訴我們說Angular判斷form表單有沒有變化有兩種姿勢，第一個是值有沒有變化(默認姿勢)，第二個是這個字段有沒有被touch。我們自然而然的使用了第一種方式，結(jié)果IE在這塊給我們挖了個坑。所以為了解決這個問題，我們的校驗規(guī)則會把兩個方式結(jié)合起來，就是說既被touch到值又發(fā)生變化的時候我們才認為字段有修改。
。。。。。。。。。。。。。中間省略掉幾個不成熟的方案。。。。。。。。。。。。。。。
學(xué)習(xí)和收獲：
IE可不是只有樣式問題，它讓你掛掉的姿勢有一萬種，有待我們繼續(xù)探索。而前端框架豐富多彩，自帶的很多方法也非常的高效好用。只是在愉快的寫代碼的過程中，我們需要思考一些細節(jié)，謹防各種瀏覽器挖坑。
