Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

提几个问题。 #8

Open
lsqswl opened this issue Dec 27, 2017 · 3 comments
Open

提几个问题。 #8

lsqswl opened this issue Dec 27, 2017 · 3 comments

Comments

@lsqswl
Copy link

lsqswl commented Dec 27, 2017

尝试着将这个作为小工具集成到项目中,集成过程中发现存在如下问题:

1.每个vue的布局不独立,互相影响,这个是封装大忌,最好每个子vue的布局都需要用一个大括号包进去,且不能被外部影响。
2.使用全局的toast不好。
3.App.vue中存在影响子vue样式的css,如button。

总体来说还是挺好的,稍微修改了一下,完成了集成。作为小工具使用使用挺不错。

@lin-xin
Copy link
Owner

lin-xin commented Dec 27, 2017

@lsqswl 提得很好,谢谢

@slkk
Copy link

slkk commented Jan 10, 2018

@lsqswl 请问下为什么使用全局toast不好啊?

@lsqswl
Copy link
Author

lsqswl commented Jan 11, 2018

@slkk 我上面的问题是针对他这个封装提的。如果你是一个大工程,有自己的toast,集成他这个项目的时候,你需要改动才能完成集成。如果他全部的东西都是用到才加载,然后外面弄个appvue demo简单调用一下,对集成会非常方便。

举个例子, 比如nprogress这个库,你要使用他的时候,无需改动他一行代码即可完成集成。这个库你就需要改toast,改成你自己的。这就是区别。 不是说全局toast一定不好,如果工程及其浩大,还是希望能够懒加载,用时才加载。 各个模块各司其职,不跟其他模块有高度耦合,工程功能的拼装与拆减都会变得及其容易。

封装的目的在于让使用方便,与工程模块划分清晰,用全局的,大家都不知道自己跟谁耦合,也不利于维护。当然也可以统一一个common组件库,所有的功能都去依赖它,这思路也是可以的。common太大首次界面加载的时间就会很长,用户体验不好。懒加载,懒加载,懒加载,O(∩_∩)O~

个人意见,仅供参考。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants