什么时候最孤独？

周末的午后，一个人，一间房，躺着玩着手机然后一觉睡去。。

不知过了多久，你醒来的第一件事情还是打开手机，把所有社交软件都浏览了一个遍！是的，手机里的朋友们看起来都挺忙的，没有人找你。

这会儿，你发现房间内的光线已经变暗了，于是你关掉手机，开始盯着天花板发呆…

请求不存 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 个赞！

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