请求不存 vuex 的数据这样写，感觉多此一举啊，贼鸡儿不好维护。单独开个 API 文件写接口不更好吗? - 知乎提问

目前我认为这种做法确实是多此一举。

vue 组件首先作为组件来说应当满足高内聚，低耦合。

不少回答都是在说设计的锅，我本身是前端开发，也说说我们的锅吧。

其实很多开发者即使代码水平不错但缺乏基本的人机交互思维，所以聊设计交付的时候总感觉不在一个频道上（只会推脱时间不够，那是产品、设计的活之类的

单拿还原设计稿来说，其实有一个很玄学的问题，就是即使交付的结果看起来没差，但有的人能够把握到设计的「主脉络」，而不是一味地追求所谓的像素级还原。

比如哪些元素应当同属于一个物料类，那它们边框，阴影，动效的表现就应当是绝对一致的，也就不至于发生照抄设计稿里某些只是由于设计师的不够严谨而出现的差异数值，这反而说明工程师不够严谨且懒……

也有些时候，设计师大概率会遗漏一些边界情况需要我们来补。举个例子，手指在按钮上按下按钮会出现点击态，然而如果保持按下再移动一定距离，在某些平台上，系统的触摸事件系统会使这次点击失效。交互思维较好的前端开发者就应当想到这种时候得让按钮回到正常态。因为显然点击态这个交互反馈的目的是告诉用户此时你松手了会发生事情。

基于以上，就会有一个很无力的事实，就是很多时候设计在 review 交付结果的时候，发现虽然哪哪看起来都差不多，但哪哪都差点意思，可是真要每个点都去吹毛求疵地去找开发撕，大家的 okr 都完成不了，那就这样吧……

就拿 axios 请求后台 api 来说吧 很多人喜欢把 api 专门写到一个文件里 然后每个页面里面请求的时候 import 导入。
这样确实可以统一管理 api 接口。但是用多了反而感觉很麻烦。一个 import 导入的时候麻烦。第二个是后期维护修改的时候并没有感觉到便利。 反而这个文件跳那个文件 那个再跳另一个。总感觉切换查看不同文件是一个很浪费时间的过程。当然坏处就是不能复用，真的用的很多的接口也提出来 - 知乎提问

先回答问题本身：当然有必要。

现在在用 vue 和 ui 框架做一个 xxx 管理系统，说实话在我看来就是增删改查贴数据，也会用到 echart 等常规插件。这些工作很多时候都十分重复，我个人觉得这样成长速度会很慢。所以想问一下，前端应该怎么做，才能做得深入，仅仅是做个 xxx 管理系统的页面，以及深入以后的前端，究竟是什么样子的。我想知道关于前端的一些。来吧大佬们，给我点知识和希望 – 知乎提问

现在市面上流行的组件库，其实严格来说还是偏底层的抽象，以组件为单元解决视觉交互和数据承载的问题，至于业务层它们是不去感知的。

而更复杂的情况反而是你说的增删改查这些偏业务的需求，而且就后台管理系统而言，其实很多公司，很多团队都想要把它做好，谁要是能作出一个公司级别的通用后台管理系统解决方案，那也是相当露脸的事情了。

很多朋友圈里打完又删掉的文字适合发在这里

1
2
3
4
5
6
7
8
9

function test() {
  return new Promise((resolve) => {
    throw Error('callback error')
  })
}

test()
  .then()
  .catch(() => console.log('catch!'))

其实原本我以为回调中的异常可能得这样捕获：

1
2
3
4
5

try {
  test()
} catch (e) {
  // catch!
}

想多了。。

吐槽一下当前版本的 AntMenu，对强迫症很不友好!

多级菜单需要自己实现视觉聚焦，即同一层级只允许唯一展开。

而自己实现了之后会发现菜单在 Collapsed 的时候，你展开的那一级菜单会自动弹出 popover，而且位置还没有对齐（相关 issues），这也需要你自己来用很不优雅的方式来解决（先收起展开的子菜单，再折叠整个菜单，同时你要记录一下你收起的，为了再展开整个菜单的时候再展开之前收起的子菜单）。

但在折叠之后，如果点击 popover 中的菜单项，理论上在你重新展开整个菜单的时候，应当展开的子菜单是你 popover 时候点击的那个层级或者是关闭所有子菜单，而不能是你记录的那个了，这也得你自己实现。。（监听 onSelect，修改记录值）。

不过和路由地址的联动感觉怎么都得自己实现的才最能符合预期，这个功能没有提供就不吐槽了。（可以通过 PathToRegex 或 react router 4.x 中的 matchPath 来实现）。

顺便放出从 WithRouterProps.routes 中拿到当前匹配到的路由路径的方法：

1
2
3
4
5
6
7

withRouterProps.routes
  .map(({ path }) => path)
  .join('/')
  .replace(/\/\//g, '/')
  .replace(/\/$/, '')

// 返回的诸如 '/user/:id', '/profile' 等你定义在路由配置中的路径可以拿来和当前页面的路径来匹配，如果匹配成功则激活当前菜单项

不过也不要忽略了某些不在菜单中的页面，比如 /users/create 指向的是创建用户的页面，但是菜单中并没有，但是希望指向 /users 的那个菜单项被激活，这种时候可以简单地通过 includes 来匹配。

React 17 这个特性真是坑人。。。（被坑过的都懂 😡

来欣赏一下社区的骂声：https://github.com/facebook/react/issues/21783

简单说，现在大部分项目会开启严格模式：https://zh-hans.reactjs.org/docs/strict-mode.html

但严格模式下组件会故意 render 两次，然而如果你在组件里 console 只会 log 一次，这会让你在排查某些多次调用问题的时候陷入迷茫。。。

某天上班，偶然打开网页版的喜马拉雅，随手点了首推荐音频。。。于是伴随着动词大词，动词大词，继续逛着它的首页。

一个不小心，又点进了老郭的相声，哎，还是木有更新，不过老段子也可以再听听，正当老夫要点播的时候，突然！哎呀！卧槽！卧槽！牛逼啊！我都逛了这么多页面了，耳机里的”动词大词”竟然连顿都没打，当时还打开了一下本地播放器，以为是它播放的音乐。

详细情形是这样的：我在喜马拉雅的 a 页面播放了音乐，然后又去 b 页面，c 页面，音乐却并没有卡顿现象，稳如死狗！注意，这里说的是连卡顿都没有，不是说跳到别的页面会继续播放。

国内的在线音乐平台有很多，实现喜马拉雅的这种哥还是头一回见啊。大部分都是采取的本地缓存音乐进度，跳到别的页面再读取进度，继续播放，但切页面的时候肯定是会有卡顿的。所以这里给喜马拉雅的用户体验 32 个赞！

那么问题来了，这种网页播放器是如何实现的？

发现有人写东西喜欢引用一大堆概念，然后一篇文章的大部分篇幅就用来解释各种概念的意思了。。

我来模仿一下：个人认为判断黄焖鸡的好坏可以通过使用迈克尔•伊犁嘎啦的无上真味螺旋品鉴法。说到迈克尔•伊犁嘎啦，大家可能不太熟悉，他来自于 21 世纪某著名空想家 MC•阿伟 的臆想中，他著名的无上真味螺旋品鉴法主要包含如下内容：
balabala 小魔仙……不过个人觉得第三，四点可以修改为吃俺老孙一棒，这样更适用于黄焖鸡的品鉴。好，那么我们先来看第一点。。又是 一顿 balabala 小魔仙。最后得出结论：黄焖鸡好不好吃和鸡的肉质，烹饪水平，吃的人有关系！！（观众：cnm！）

是的，很多情况下用一些简洁或高级的词来代指某些复杂事物有助于行文的顺畅和专业性，不过滥用就会让人觉得你这个人要不是为了秀就是表达能力有问题：说一件很简单的事情要绕半天，很多人会 太长不看 的。