用 hooks 模式的时候，setState 以外的方法能够修改到真正的 state 吗？

说实话我觉得没必要纠结这一点，setState 之后就变成了新的 state

我感觉说这话的是根本没从上古时代开始干过复杂前端项目的

在 js 和 jq 时代我不止一次造过乱七八糟但是功能和现代前端框架类似的轮子

你觉得现在的前端太复杂了，是因为复杂度本来就摆在那里

不就是一个自定义比较器吗？把你的逻辑写在里面传给排序不就好了

排序本质就是 2 个元素如何比较

不过你这个逻辑感觉描述的很混乱，A 值=0 ，指的是比较的 2 个对象的值 A 都是 0 还是有一个为 0 ？

如果你能精确的明白你哪些 dom 操作会触发重绘，所以能够合并这些操作，那肯定是有性能优势的

问题是没人能做得到

哈哈，在这种社会达尔文+自利主义横行的地方，谈到牺牲权益来保护弱势群体，就跟粪坑里扔了块石头一样。

境外诈骗横行监管不力？关我吊事我又不会被骗

境内严格风控保护弱势群体？我 CNM 侵犯我隐私……大棒……调教……

现在的科技程度还不足以让人理性的作出不生孩子的决定

真到了脑内科技发达，护理机制完善的时候，一个人也能够体面的度过晚年，丁克才能变成一个可选择的项

我都不想从道义上谴责百度

就说说百度贴吧吧，中文 bbs 的始祖吧，无数人的网络初始记忆，汇聚所有论坛入口于一处，这在移动时代是多么恐怖的事情？

而百度在远古时代就做到了，不比 QQ 开局差吧？

结果天胡开局整成了这样……

真的太蠢了……

遍历有啥不优雅的……直接用 array 的 api 呗

说实话我不是很明白一边觉得遍历不合适一边想着反复序列化反序列化……序列化的开销和不优雅程度可比遍历大多了……

建议看看 github 的

@james2013 你这说法就不太对了，显然在现代前端里 promise 广泛使用的情况下，catch 比 if(res.code ==200)的语义化和代码结构更佳。

@daimubai 同意，真不知道搞技术的也这么多一根筋的。

拿 400 和 422 举例，422 可以很容易的覆盖一部分业务错误，所有参数上的不合法都可以归到 422 里，对监控更容易，跟别的合作伙伴做对接也更简单。

比如 request 定义是
{ n:int, s: string}
而 n 要求大于 0 ，s 要求不能为''，那么
{'1'}
就会对应到 400
{n:'1',s:1}
{n:-1,s:''}
对应到 422
而 n:1998 会造成业务上出错，那自然是以 200+message 返回

界限很清楚也很好用，422 我就去检查参数值，400 就检查参数格式，而 4 开头的都会被浏览器认定为 client 错误，事实上也确实是作为 client 的调用方有错误，不挺好吗？

rest 规范你觉得不合理就选择使用就完了，全盘否定或者全盘肯定都是不现实的。

没有这种感觉，关键的代码几年了我都能想起来，不关键的想不起来也无所谓，只能说是记忆方式的不同，我回想一个很久以前的代码是通过上下文联系回忆的，当时遇到的问题，解决的思路，遇到的困难，最后的方案，总能有线索让你抽丝剥茧的想起来。

如果纯靠心智去记忆代码片段那肯定是做不到的。

个人一个最简单的模式

`function useApiQuery<T>(endpoint: string): [T | undefined, any, boolean, (parameter?: any) => void] {
const env = useEnv();
const [data, setData] = useState<T>();
const [error, setError] = useState();
const [loading, setLoading] = useState(true);
const trigger = (parameter: any | ((parameter: any) => any)) => {
const parameters = parameter instanceof Function ? parameter() : parameter;
setLoading(true);
axios.get(endpoint, { params: parameters })
.then(res => {
setData(res.data);
setLoading(false);
}).catch(err => {
setError(err);
setLoading(false);
});
};
return [data, error, loading, trigger];
}`

hooks 里自带状态，所以如果你真的需要管理请求数据的状态可以在这个 hook 里管理，或者再用另一个 hook 来专门管理并且协调 query 的 hook

毕设整那些架构概念简直是搞笑，导师都不见得懂，自己也不见得明白，加上又不直观，属于是大力给自己挖坑

还是推荐从直观方面入手

1. 用高大上的 UI 框架和页面设计让系统高级化，非常容易，很多现成的
2. 可视化，各种图表不管有没有用，先塞进去，最好再整个 dashboard 做首页
3. 增加客户端和管理端的交互，比如某个页面需要看 1 分钟才达标之类的

看团队水平

都还处于原始人阶段的话大力推荐 flex 和 grid ，flex 可以解决 80%以上以前 CSS 的疑难杂症，包括不仅限于什么居中对齐自适应等等……

现在写 css 还不用 flex 布局简直是犯罪

就一本 CLR via C#感觉最有用
比他深度深的很难用的上
比他浅的不如 MSDN

我觉得不太可能

我面试一般会对着简历问，如果是能力很强的不可能对着简历上的内容少加引导还说不出来个啥的

纯问八股那类的我不认为是面试，人家压根不准备招你