diff --git a/content/2.articles/_fourty-two/1.dark-room.md b/content/2.articles/_fourty-two/1.dark-room.md
index 495d53fd..988ece36 100644
--- a/content/2.articles/_fourty-two/1.dark-room.md
+++ b/content/2.articles/_fourty-two/1.dark-room.md
@@ -25,7 +25,7 @@ description: 《四十二篇系列 · 第一》
 
 讨论数据的时候，就应该讨论数据，而不是状态，所以我们也许应该更多地看齐函数式编程，而不是用上各种状态管理。应用程序本身可能有各种状态，比如“黑暗模式的开启或关闭、侧边栏的打开或否”，但业务数据中的状态就少的可怜。
 
-前端业界一流的状态管理框架可能加以百计，他们有着针对状态的，不同的管理模式。如 Vuex，将应用程序的状态封装到框架内部，用可预测的规则保证状态只在有限范围内变化。可以想象，如果你把业务数据（通常繁杂、晦涩、深奥）放到 Vuex 这种状态机中，会带来额外多倍的代码量和更多心智负担。尽管状态管理框架本身是函数式的，这并不意味着在 JS 与其跛脚的函数式的上下文中，使用 Vuex 能更好的管理业务数据。写页面时，很多时候我们需要的只是数据管理框架，而不是状态管理框架。至于数据管理框架是什么，我也没有一个定论，可能他们并不是非此即彼的关系，二十有一定程度的耦合。
+前端业界一流的状态管理框架可能加以百计，他们有着针对状态的，不同的管理模式。如 Vuex，将应用程序的状态封装到框架内部，用可预测的规则保证状态只在有限范围内变化。可以想象，如果你把业务数据（通常繁杂、晦涩、深奥）放到 Vuex 这种状态机中，会带来额外多倍的代码量和更多心智负担。尽管状态管理框架本身是函数式的，这并不意味着在 JS 与其跛脚的函数式的上下文中，使用 Vuex 能更好的管理业务数据。写页面时，很多时候我们需要的只是数据管理框架，而不是状态管理框架。至于数据管理框架是什么，我也没有一个定论，可能他们并不是非此即彼的关系，而是有一定程度的耦合。
 
 在更深入探索之前，我也许应该更多接触一些“函数式”的东西。函数式声称它能减少甚至消除程序中的状态，降低状态维护网络状地状态变化带来的心智成本，这是好的。