265

前沿技术/204.精读《默认、命名导出的区别》.md

@@ -203,7 +203,7 @@ export default hello;
 
 为了保证导入的总是引用，一方面尽量用命名导入，另一方面要注意命名导出。如果这两点都做不到，可以尽量把需要维持引用的变量使用 `Object` 封装，而不要使用简单变量。
 
-最后对循环依赖而言，只有 `export default function` 存在申明提升的 Magic，可以保证循环依赖正常 Work，但其他情况都不支持。要避免这种问题，最好的办法是不要写出循环依赖，遇到循环依赖时使用第三个模块作中间人。
+最后对循环依赖而言，只有 `export default function` 存在声明提升的 Magic，可以保证循环依赖正常 Work，但其他情况都不支持。要避免这种问题，最好的办法是不要写出循环依赖，遇到循环依赖时使用第三个模块作中间人。
 
 ## 总结
 

前沿技术/263.精读《我们为何弃用 css-in-js》.md

@@ -27,7 +27,7 @@ css-in-js 作为一个理念较新的开发思路，拥有如下几个明显的
 除了上述缺点外，css-in-js 还有三点深度使用后才能察觉的坑：
 
 1. 多个不同（甚至是相同）版本的 css-in-js 库同时加载时可能导致错误。笔者用 styled-components 就遇到了类似问题，甚至语法会产生不兼容的情况，虽然这些问题都可以被解决，但花费的额外时间需要计算一样，相比 css-in-js 得到的收益是否值得。
-2. 样式插入优先级无法自定义，这就导致产生样式覆盖时，业务对样式覆盖的优先级无法产生稳定的预期。class 优先级由 header 定义顺序决定，而非 className 的字符顺序决定，而 header 定义顺序又由资源加载与 css-in-js 插入执行时机决定，导致业务几乎不可能有稳定的样式覆盖顺序。这里产生的问题就是业务代码不断增多的 `!impprtant` 定义。
+2. 样式插入优先级无法自定义，这就导致产生样式覆盖时，业务对样式覆盖的优先级无法产生稳定的预期。class 优先级由 header 定义顺序决定，而非 className 的字符顺序决定，而 header 定义顺序又由资源加载与 css-in-js 插入执行时机决定，导致业务几乎不可能有稳定的样式覆盖顺序。这里产生的问题就是业务代码不断增多的 `!important` 定义。
 3. 不同 React 版本的 SSR，css-in-js 需要适配不同的实现，这对框架作者不太友好。
 
 除了性能问题以外，其他问题都可以忍，但偏偏在性能问题上，css-in-js 遇到了无解的场景。