自定义指令控制权限的弊端
本期风娃:
你这个说法有点问题吧，不是弊端，而是设计上怎么落地问题，一般权限方面对于不同的落地有不同的方案。你的例子是一个大的组件，而有些地方是组件必须显示，但是内部可能是个操作有五个操作需要根据权限显示或者隐藏！有些是路由不显示到导航菜单，并且不允许地址访问。不同场景不同落地实现，你这套用上面有些没有考虑全面
【回复】那你的需求用指令不也是一样的么，100个不也要用100个指令么，我在视频里也说了，在用的时候考虑一下自己的场景
【回复】回复 @远方os : 有些组件仅仅只是显示或者隐藏的区别，有些组件必须显示，内部根据权限再去显示不同的按钮，区别就在这里了。
大的组件可以用权限组件包裹一下，组件内部的dom元素或者其他组件难道又继续无限用权限组件包裹么？
有些设计上都得显示，但是根据权限做不同显示状态，比如说没权限就禁用什么的，这个就没法单独用组件包裹了吧。
组件和内部的状态范围不一样，具体处理逻辑不一样，没法通用所有场景，这是我的理解！
【回复】回复 @本期风娃 :按钮不是组件吗？我认为权限分为页面级和页面中的组件级，可能我们理解的不一样
大唬名城-欠薪高地:
直接写个全局方法然后v-if省事，模板也能用，js中也能用，而且自定义指令这玩意在某些ui框架的某些组件上不生效，比如el-table-column
【回复】而且还能类型限制，可以将权限全局注册管理
叨逼刀:
弊端1 对于没有权限的组件按钮 会不必要的创建dom再销毁 重绘重排 浪费资源
弊端2 对于没权限的组件 仍然会进入生命周期 如果mounted有请求实际会发送请求 有不必要的风险 及消耗服务器资源 组件上暴露的方法属性会缓存虽然没有dom但组件实例仍然存在
弊端3 代码统一管理相权限组件的方式不够优雅 直观
大佬 这样总结对吗
【回复】12正确，3的话，每个人理解不同，哈哈。
弦動我心:
这个场景和日常普遍的需求对不上吧
通常我们所谓细粒度的权限一般是按钮级别 指令能够完美解决 无类似问题
在视频里的举例，比如图片：常见的情况是a用户显示一张图，b用户显示另一张图，而不是完全不显示这个组件。
通常的做法是这个组件代token请求后端，返回对应用户该展示的图片；即使退一步不展示图片，返回空一类的状况，也是组件内部展示一个占位图片。
直接不显示该组件的情况，至少在我所经历的项目里面是很罕见的
【回复】跟你的日常需求对不上而已，就算你放在按钮上，这个按钮从常理上说也是不应该被创建，而不是创建了组件删除了元素，如果我某一个表格要控制权限呢？虽然权限一般以后台为主，但是后台会在这个请求中报错，前端会弹出错误，但是如果使用指令，那么用户根本看不到这个组件，但是请求报错是会被用户看到的，这样不是很诡异吗？虽然大部分场景下都是在控制按钮类的权限，可能觉得无所谓，但是如果将这个概念引用到内部逻辑复杂的组件中，那就是错误的。
非物质文化学继承人:
我司，还有个更狗的。他们要按钮即要根据身份来，又要根据当前业务状态来。实际上，2者 底层没有任何关联性，就是这么烂的需求
是大枫树呦:
没毛病。指令方式和组件方式就是控制的层次不同。
我的理解组件的方式相当于对控制对象又封装了一次。
具体怎么实现还是看功能和场景把。
年迈的老父亲i:
好像自定义质量是能拿到当前组件实例的吧，那在mount的时候销户组件不就行了吗
【回复】回复 @年迈的老父亲i :vif是编译时，你cp过来试一下，看看运行时可以吗？
【回复】回复 @远方os :所以说源码cv过来改改啊
【回复】回复 @年迈的老父亲i :视频里说过了，vif条件不成立的情况下不会创建组件，自定义指令是在组件创建的过程中触发的，不是一个概念
雨翼195:
我选择将方法扩展vue全局属性，结合v-if或v-show使用，或者有些组件支持disabled属性。在普通js代码中也能import进来使用
【回复】回复 @雨翼195 :这就看你业务需求了
【回复】回复 @远方os :耦合度不高啊，而且我这种方式更加灵活，也不需要再包一层，我知道v-show只是隐藏，但它也有应用场景
【回复】vif本来就可以，但是会提高耦合度，vshow就更不行了，它只是css层面隐藏，dom都还在dom树里面。
