本来只是个简单需求
这是一个elementUI的时间选择控件DatePicker，默认是以天为时间单位的。老板想在时间控件上加上小时的条件，即可以选择小时。 ok，很简单实现，上图，这是最终的效果图： 
老板发话了
我把这个效果给老板看，老板说，嗯，客户只想要小时，不要分钟。
这下好了，老板不想要这个分钟。本来以为10分钟可以解决的事情，突然发现需求升级了，甚至实现方案都没有现成的。成熟的程序员是不会在这个时候解释的，好的，直接就答应了！办它！
程序员的坑就这样来了
其实需求也很明确了，老板就是想把他手指指向的这个分钟这一列给隐藏掉，但是你翻遍了官方文档，它也没提供这个属性能达到这个目的。那好，我用样式隐藏可以不呢？可以是可以，这里面其实有两个难题或者说有两个大坑等着程序员：
- 如果你想用deep来定义一个组件局部样式你就试试吧！
- 如果你想用全局样式来达到目的你也试试吧！
为什么组件内的deep会失效
为什么deep在组件内这样使用会失效？f12打开控制台，然后选中这个下拉框试，你会惊讶地发现，原来你看见的下拉框部分是在body内作为第一层级子元素来展示的！ 
而我们的当前的这个组件很明显是处在body内N重孙级别的元素，deep的作用域是针对当前组件所有区域的，下拉框一出现就直接跳出了这个小圈子，所以不管你如何操作，这个deep也是无法作用到下拉框上面的。
全局样式的问题显而易见
前面我们已经明确了解决方案就是把分钟隐藏掉，但是用deep方案已经证明无效了。那就还有一条路，全局样式。不过全局样式问题也很明显，就是会导致其他的这个element组件被动应用这个样式，那很明显是不合理且错误的。
还好官方文档给了一个逃生阀
最后好在我又仔细阅读了官方文档，发现它提供了一个这样的属性cell-class-name： 这个属性非常关键，可以用它来设置自定义类名，正好可以解决我的难题！我直接把样式代码放出来吧：
css
<style>
.custom-popper .el-scrollbar.el-time-spinner__wrapper:nth-of-type(2) {
display: none !important;
}
.custom-popper .el-time-spinner__wrapper {
width: 100% !important;
}
</style>首先，style标签内没有scope，说明这是一个全局样式；然后，custom-popper是我给这个DatePicker组件定义的cell-class-name属性，通过这个属性值，相当于给这个全局样式套一个圈圈，这样就不会影响别的组件了，因为别的组件没这个样式。这个圈就像如来佛祖的手掌一样，直接就把飞出去的猴子压在了五指山下。它解决了两个问题：你飞多远我都能跟上你，虽然你跳出了局部组件，但我是全局样式；你想闹事改变别的组件也没办法，因为我把你压在了山下封印住了，最多也只能在我手底下撒尿。
最终效果就是这样，欣赏一下： 
老板说是这样
当我把做好的效果截图给老板看时，老板说，对，就是这样。然后就没了。他可能还在想，我就要一个小功能，居然搞这么久。除非你把你的研究过程告诉他，否则他是不会理解你的。
其实我想说的是
其实我想说的是，前端累死累活干的这些事，它重要吗？重要也不重要。
前端挺重要
说重要是因为前端是脸，是客户观注到的直观需求体验，一旦不能满足直观需求，你是怎么也哄不住客户的。这些特点在更加注重产品体验的产品或者项目上更加明显，比如游戏、音乐类、微信、视频app等互联网产品。你敢相像在有了QQ的基础上再做一个微信还会有这么多的用户吗？前端本质上是一种交互需求的具体呈现。微信之所以会成功，是因为它就是为手机而生的，相比pc端活跃的QQ，微信的简单反而更加符合用户需求。
前端可能不重要
再说回前端。为什么也说这些事不重要，因为一旦活干完了，谁还记得你是怎么干完的呢？客户最终的最终还是奔着业务去的。哪怕是你的微信某个按钮实现过程如何复杂，它终究是个按钮而已，它只是某个业务实现过程的一个小石子而已。没人关心你在实现过程中查了多少资料，做了多少次实验，强制冷静了多少次，你的领导只关心结果。公司高管只关心，这块业务谁最熟！谁最熟悉业务？难道是吭哧吭哧画按扭的前端？别开玩笑了吧！ 如果不够明白，你可以横向对比一下后端，后端大部分时间都在处理数据库，除了各类技术深度广度问题，后端的付出基本上能获得一些业务收获。
这里给一个表可以更直观的进行对比：
| 对比维度 | 前端开发 | 后端开发 |
|---|---|---|
| 核心职责 | UI 构建、交互实现、用户体验优化、对接 API、适配多端、解决兼容性问题等 | 接口设计与实现、数据库操作、业务逻辑处理、系统架构、性能优化、安全等 |
| 日常工作内容 | - 页面还原设计稿 - 写组件、调样式、处理交互逻辑 - 适配响应式 - 联调数据接口 - 解决浏览器/终端兼容问题 | - 设计数据库结构 - 编写并维护 API - 处理核心业务流程 - 系统性能调优 - 接口安全控制 |
| 可见性 | 高（客户一眼能看到页面细节，出错立马被发现） | 低（一般用户看不到后台逻辑，出错时才暴露） |
| 客户关注点 | 页面是否好看、是否顺畅、交互是否人性化、是否符合预期 | 功能是否能用、数据是否准确、接口是否稳定、业务是否跑得通 |
| 业务参与深度 | 较浅：参与业务落地的表现层，理解业务但通常不是业务规则制定者 | 较深：直接承载核心业务逻辑，对接多个系统，参与业务建模与设计 |
| 技术挑战 | 多端适配、性能优化、状态管理、动效实现、复杂组件抽象 | 业务复杂性、数据一致性、事务管理、并发处理、系统可扩展性 |
| 被认可程度 | 容易被忽略（"只是画页面的"、"样子货"） | 容易被重视（"懂业务的"、"系统核心"） |
| 话语权 | 相对较弱，容易被产品和后端牵着走 | 较强，经常参与系统设计决策、定义接口标准 |
| 最终成就体现 | 页面顺不顺眼、能不能"看得过去"、能不能"点得动" | 系统能否高效稳定地支撑业务运行 |
总结一下，前端重要，因为它是客户感知的第一线，你做得烂，客户直接不满意；你做得好，别人说"这系统用起来挺舒服的"，但很少追溯是谁干的。 说前端不重要，因为你干完了就完了，没人会去回顾你做一个按钮的努力，而业务沉淀和价值积累，往往偏向后端。
前端的出路，除非你是做游戏或者三维的，否则必须往 全栈 或 业务理解+产品思维 上靠，只有走出"只是画按钮"的刻板印象，才能打破职业天花板。
仅以此文，献给可爱的一线前端！