redux

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 当我走进现代前端开发行业的时候，我做了一个每位开发人员都要做的决策：选择一个合适的框架。当时正逢 jQuery 被淘汰，前端开发者们不再用它编写难看的、非结构化的老式 JavaScript 程序了。前端正在走向一个时髦的，流行的，模块化的 JavaScript 框架的新时代。所以我选择了 VueJS。 下面就是我热爱（现在还是爱着）VueJs 的原因所在。 1. 它将 HTML/CSS/JS 结构结合到一起 目前来看，这是 VueJS 最吸引人的优势。 Vue 文件对初学者非常有吸引力。它易于理解，而且我们很容易将整个 HTML 模板分解为许多 Vue 文件。我一眼就能看出来结构（模板）、行为（脚本）和外观（样式）。 <template> <div id="myComponent"> <Counter /> <span v-if="reading">Hello reader !</span> </div> </template> <script> import Counter from "@/components/Counter"; export default { name: "myComponent", components: { Counter } } </script>

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 前言 去年的某个时候就想写一篇关于接口的吐槽，当时后端提出了接口方案对于我来说调用起来非常难受，但又说不上为什么，没有论点论据所以也就作罢。最近因为写全栈的缘故，团队内部也遇到了一些关于接口设计的问题，于是开始思考实现接口的最佳实践是什么。在参考了许多资料之后，逐渐对这个问题有了自己的理解。同时回想起过去的经验，终于恍然大悟自己当时的痛点在哪里。 既然是吐槽，那么请原谅我接下来态度的不友善。本文中列举的所有例子都是我个人的亲身经历。 谁应该主导接口的设计 或者更直白一些，应该是接口的消费方还是提供方来决定接口的设计？ 当然是接口的消费方 「接口」最吊诡的地方在于提供方大费周章把它实现了，但它自己却（几乎）重来都不使用。于是这极易陷入一种自嗨的境地，因为他更本不知道接口的好坏。就好比一个从来不尝自己做的菜的厨子，你指望他的菜能好到哪里去，他的厨艺能好到哪里去。上面隐含的前提是（我认为）接口是有绝对好坏之分的，坏的接口消费者调用难受，提供者维护难受，还导致产品行为别扭体验变差。 然而接口的好坏与谁来主导设计有什么关系？因为坏接口产生的原因之一是提供方只站在开发者的角度解决问题： 例子一 (Chatty API) 某次需要实现允许用户创建仪表盘页面的功能

Hooks 是 React 16.8 的新增特性。它可以让你在不编写 class 的情况下使用 state 以及其他的 React 特性。 使用 React hooks 转化 class 的一些思考   Hooks 其实已经是大势所趋的一个技术了，作为一个可能是 React，甚至是 JS 史上都是一个比较伟大的发明，Hooks 已经被大部分中小型公司所接受并尝试使用，但是对于大中型公司来讲，从 class 组件移植 Hooks 的成本太高，不能像其他公司一样随心所欲地拥抱新技术，所以我们对于 Hooks 的讨论，应该考虑的比较全面，才能更好的了解这个技术，以及是否应该在项目中尝试这一新技术。   在论坛上我也有和一个小伙伴对此有一个讨论，感谢@无怨，前代 react 项目 class 转 hooks 的必要性。其实大家对 hook 都是认可的，但是对于重写 class 的成本方面还是望而却步的，react 官方也不希望因为这个使得新版本使用者剧减，所以暂时还是会兼容 class 组件的写法。   所以其实对于是重写部分还是只有新组件使用 hook，大家都还是比较犹豫的，对这种选择来看，我们必须实际考虑成本-产出比，所以我们这篇就具体讨论成本与产出，以及可行的方案吧~ 首先咱们来看看成本吧 修改成本   作为 React 16.8 新增特性，一些第三方的库可能还暂时无法兼容

自从我发过几篇关于面试经历的文章，由于我面试结果还不错，所有很多人来询问我一些面试相关的问题， 我这里给到 5 点建议，希望对大家有帮助。 1. 简历里应该惜字如金 简历简历，可以分为 简 和 历。 简，简单简洁之意，历，经历，总体就是 简单 的表达自己的经历。 我看到一些人的简历写了四、五页，甚至十来页的都有，每个项目把细节都写出来了，甚至还把项目截图给贴在了简历里面，生怕面试官不能理解需求，我建议最多不超过 2 页，亮点能写两页就已经很牛逼了。 我相信有很多人工作了很多年，经历的项目很多，其实不需要把所有的项目都列出来， 简历里是要展示自己的亮点，牛逼的点，这个亮点、牛逼的点事相对的，相对于自己所做的东西里面的，不是客观的牛逼(如果有当然更好，那必然也是你相对的里面的亮点，不冲突) 。 这句话意味着两层意思： 很多人觉得自己的项目没有亮点的问题，因为你是那这别人更高的标准来衡量自己，所以你相对于别人没有亮点，这样你就写不出一份简历。 多个亮点类似的项目合并，或者只写一个，因为都是为了给面试官展示这一个亮点，写多了就是浪费空间，简历上面的字很珍贵。 第一层让你的简历有东西可写(增加)，第二层是让你把简历写得更优质(减少)。 2. 简历应该是你设计过的 「设计简历」可能对这个词有点迷惑，可能你第一感觉是设计得好看一点，其实我想表达的设计是一种「圈套」，给面试设计的「圈套」

一、Angular，它两个版本都是强主张的，如果你用它，必须接受以下东西： 必须使用它的模块机制 必须使用它的依赖注入 必须使用它的特殊形式定义组件（这一点每个视图框架都有，难以避免） 所以Angular是带有比较强的排它性的，如果你的应用不是从头开始，而是要不断考虑是否跟其他东西集成，这些主张会带来一些困扰。 二、React 它也有一定程度的主张，它的主张主要是函数式编程的理念，比如说，你需要知道什么是副作用，什么是纯函数，如何隔离副作用。它的侵入性看似没有Angular那么强，主要因为它是软性侵入。你当然可以只用React的视图层，但几乎没有人这么用，为什么呢，因为你用了它，就会觉得其他东西都很别扭，于是你要引入Flux，Redux，Mobx之中的一个，于是你除了Redux，还要看saga，于是你要纠结业务开发过程中每个东西有没有副作用，纯不纯，甚至你连这个都可能不能忍： const getData = () => { // 如果不存在，就在缓存中创建一个并返回 // 如果存在，就从缓存中拿 } 因为你要纠结它有外部依赖，同样是不加参数调用，连续两次的结果是不一样的，于是不纯。为什么我一直不认同在中后台项目中使用React，原因就在这里，我反对的是整个业务应用的函数式倾向，很多人都是看到有很多好用的React组件，就会倾向于把它引入，然后

本系列将讲述 React Hooks 的使用方法，从 useState 开始，将包含如下内容： useState useEffect useContext useReducer useCallBack useMemo useRef custom hooks 掌握 React Hooks api 将更好的帮助你在工作中使用，对 React 的掌握更上一层楼。本系列将使用大量实例代码和效果展示，非常易于初学者和复习使用。 截止目前我们已经学习了3个hook api， useState , useEffect , useContext 。接下来我们学习下一个 hook api， useReducer 。首先我们将讲讲什么是 reducer，以及为什么使用 reducer。研究一下 JavaScript 中的 reducer 是什么，这将有助于理解 react hook 中的 useReducer 。好，现在开始吧。 什么是 useReducer useReducer 是一个用于状态管理的 hook api。是 useState 的替代方案。 那么 useReducer 和 useState 的区别是什么呢？答案是 useState 是使用 useReducer 构建的。 那么什么时候使用 useReducer 还是 useState 呢？我们完成本章的学习就能找到答案。 reducer