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

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

EditorConfig

基本上目前所有编辑器都支持地很完善,拿 vscode 来说,prettier 的配置文件是需要装插件 + 做一定的编辑器设置的。而 editorconfig,装完 EditorConfig for VS Code 就可以了(WebStorm 默认支持),能够很方便地覆盖编辑器的默认格式化。所以它的主要好处其实就在这里,编辑器的默认格式化不同于通过快捷键调用类似 prettier 的三方格式化工具,它能够在比如新建文件,回车换行的阶段就保持正确的代码格式。

这是一个 Web 需求,内容是让用户在列表里「更容易地访问」自己想要访问的资源,类似让网页收藏夹更方便地找到自己收藏的网页这种需求。

首先很容易想到的一个方案是提供一个模糊搜索功能,该方案在列表条目比较多的时候,无疑能带来很高的收益,遂保留之。不过如果用户经常访问的某个页面恰好不在可视区域内,那意味着该用户每次都要滚动视图,或者执行搜索才能访问到它,所以只靠该方案是没办法很好地解决这类用户「更容易地访问」需求的。

那么再思考一下需求本身,对于这类列表数据,什么是「更容易地访问」?

最近帮中台团队面试了很多前端,有些想法不吐不快:发现现在很多前端都喜欢去 ToC 的业务团队,认为 ToB 的业务不就是去 XX 组件库里复制粘贴代码,然后增删改查吗?

但我想说,你那样产出的内容是没有灵魂的!你要说复制粘贴组件库可以帮助你来快速开发我信,但要是指望这种来输出一个好用的管理端我是不信的。

不同的数据用什么组件来承载?不同的操作用什么交互来实现?为什么用的同一套组件库我做的东西就总感觉差点意思?当然了,有的人会说:反正都是给内部人用的东西,能用就得了呗。好吧,只能说人各有志,这种心态来做前端,我是劝不了你的!

吐槽一下当前版本的 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 来匹配。