兼容IE流程回顾与痛点复盘

兼容IE对于2021年的前端开发工作来说。前端行业的快速发展与更新进程中， web兼容IE也慢慢成为被市场边缘化的一个特质。因为web前端常见的功能开发时，功能的复杂度提供，常见的处理策略就是使用社区内的开源依赖进行常规开发。由于很多的依赖的新版本或者所有版本都没有提供对IE的兼容处理（其实老一点的工具依赖还是有的，只是寻找比较麻烦）。所以这就给兼容IE带来了很大的难度。接下来就是个人对于兼容IE的一些方案总结与案例。最后还会有一个总结。

首先，当我们真正的在遇到这个问题的时候，应该从根源去思考为什么要兼容IE？是否真的有必要性？

1. 项目本身的面向用户就是医院或事业单位，公司的硬件设备就是比较古老的版本。那么兼容IE就是必要的且必须的。
2. 项目需要尽力的推广包括使用IE浏览器的用户。
3. 个人希望对前端发展的进程进行实践。
   如果是1，2 这种无法挽回的原因， 那么就需要参考文档进行实际检验。如果只是想了解， 建议读完这个文章，记录起来就好。

先说一下我为啥要兼容， 用我的Leader的话来说就是 政治任务！用我自己的话就是 发扬老一辈的不怕困难的精神（吐槽一下才有动力努力）。

其实在整个过程中， 我还是有收获的。

******************************************* 分割线，正文开始 **************************************************************

先说一下我们的项目技术栈 webpack@4.x + vue@2.x + elementui@2.x
需要兼容的IE版本为IE10以上

由于本文主要是提供一个思路，具体方案就不赘述了。只说痛点

第一步：如果确定要进行IE版本的兼容，就应该在技术选型阶段就进行IE兼容的思考。我们的项目是在最后阶段才定出来要兼容IE的， 所以在过程中只能针对所使用的技术栈进行兼容。如果想到需要兼容IE，我会选择jquery，而不是vue。不过还好vue2虽然官方没有提供兼容方案，但是社区的兼容IE的方案还是很多的。

第二步：本地运行项目进行查看。白屏，啥也没有！ 不用想， 你的框架最基本的vue与elementui都不兼容！
解决方案: 官方推荐使用babel-polyfill进行兼容。
babel引入， 配置loader，.balbelrc 文件配置preset。
这里注意，配置修改完，一定要重启项目！！！一定要重启项目！！！一定要重启项目！！！

第三步：运行项目发现还是白屏。 只能打开控制台进行排查， 发现有2个依赖内部使用了es6 的语法 Map 和 函数形参默认值。遇到这种不支持的，建议不要选择直接把依赖直接通过babel进行翻译。应去github与npm去查看包的版本和issue。一般情况旧一点的版本可能就是支持IE的， 可是也有特殊情况， 比如我们项目中用到g6。当我去g6的github去看的时候，发现他们社区在寻找兼容IE11的contributor。那么方案就只有俩， 自己拿到项目的源代码进行修改， 或者使用babel进行低版本的兼容， 但是使用babel很容易使你的项目出现更多的 问题，所以除非官方建议使用转低版本，最好不要直接使用，当然了你也可以尝试一下，欢迎来怼。
我的处理方案是， 先放下这种不好兼容的， 保证项目运行起来， 把基础功能跑起来。 无论如何先把项目运行起来， 然后在通过最后预留的时间把这种难啃的骨头啃下来。

把可以处理的兼容处理掉， 不好兼容的功能先舍弃掉，再次运行，终于把项目启动了！！！开心三秒。

第四步：登录账户。 咦？没反应。发现控制台又出现了一个它不认识的语法 - URLSearchParams 。打开MDN, 发现IE根本就不兼容。IE被唾弃的原因找到了， 只有它喜欢特立独行。 切换成 FormData 再次尝试， 用户校验成功。耶耶耶！开心三秒。

第五步: 切换一下路由试一下？ 什么？ 有白屏？？ 打开控制台。uncautch err ？？？ 看到就头大， 根本不知道哪里报的错。 不过是从vue-router内抛出来， 且切换到其他路由可以执行。 可以确定是这个路由异步加载页面的时候遇到了无法使用的控件。最后是通过IE开发者工具调试中的遇到异常就断开的调试方式，终于定位到了问题的准确位置。是由于一个包的初始化除了问题。先去掉这个功能，看看是否可以跳转了。 果然可以了。 然后就是按照第三步提到的方案处理具体的兼容。完美解决！！开心3.5秒
这个问题排查的耗时是最久的，却也是必须的。刚开始也走了弯路，在那一行一行的 跟断点。 后来发现这个方法根本不可行。 不过这个过程也让我对vue-router跳转时加载并渲染组件的方式进行了细致的了解。可是也暴露出来找问题缺少方法的问题。
所以在这里给大家一个排查uncautch err 的思路:

1. 缩小范围。比如vue及vue-router，都提供了一系列的钩子进行数据状态的监控。不过一定要确定不同钩子的调用时机与机制。相信大家都有一定的了解。
2. 尝试使用类似IE开发者工具这种遇到断点就断开的调试方式， 其他浏览器的方案会在后面的文章中进行描述。

第六步： 项目中用到了window.open去打开新的tab。 尝试这个功能。 发现新开的页面又是默认白屏。 打开控制台发现报错的语法在IE10中是支持的。仔细观察发现。是在头部启动了IE10的兼容性视图。
兼容性视图作用：兼容性视图是微软IE浏览器独有的一个功能，这是因为微软以前不遵守W3C网页标准的恶果，现在微软开的发浏览器尽量在遵循W3C标准，但是又要兼容以前的IE浏览器版本，所以就出了一个兼容性视图的功能，简单的说如果你用lE浏览器打某一个网页，发现内容很乱时，启用兼容性视图试一试，也许会给你惊喜。
当你开启兼容性视图之后，此时的IE浏览器，就会向下支持旧版IE的语法，使得网页能够正常显示。

无奈了， 看来是有一些语法在IE看来是错误的情况下就会自动开启兼容性视图。解决方案， 先设置一下，把这个功能关掉。然后把电脑重启就好了。解决是解决了，但是好low啊。最后决定让我们的c语言同事使用C语言给IE写一个注册表去修改IE的配置。 运行一下这个注册表。作为产品的附属品。 但是还是不友好的。 最好的方案就是把所有的语法哪怕是异常全部按照IE的处理方案进行处理， 或者继续向下兼容。 其实我觉得自己总结的这些方案还是有问题的。欢迎大哥来怼！

到现在为止。项目中遇到的一些致命的兼容性问题基本就介绍完了。其实还会有一些样式啊语法的兼容性问题，例如flex布局及过渡属性等。 不过这些问题的解决也比较简单， 无非是通过文档和实践。 这里就不多赘述了。由于这些语法或者方案也都不是一两句话就可以说的完的。所以我打算后续进行持续的更新及思考。欢迎持续关注。

浏览器兼容思考：其实在做这个任务的时候我也跟同事朋友有过一些沟通。兼容IE如果跳出具体项目及公司等外界因素。对程序员本人有好处吗？ 大家的答案不太一致，有的觉得完全没有必要，有的觉得对自己是一个磨炼。但是我觉得， 这不是一件坏事。因为对我来说在接触IE兼容这个任务之前。我对于整个的前端的技术发展与生态并不是十分的了解， 包括对github 与 npm 的使用都不够深入。 可是通过这次实践， 对于工具的使用， 和对问题的排查方案有多了很多的思考与总结。看问题的速度也会有所提高。而且兼容IE需要了解的技术栈也更多。 也让我对整个的架构设计多了一份思考。尽管不是很多。可是我很知足。而且我相信下次我会做的更好。

有兴趣的小伙伴可以留言或私信我， 我想拉一个群，我们一起去讨论整合一个文档用于常见的浏览器兼容。欢迎加入！！！