这是一个创建于 660 天前的主题，其中的信息可能已经有所发展或是发生改变。
环境
vue3 + vite + js + css3 ； （学 VUE 2 周）
疑问 1 ；
假如我自定义一个组件 名字叫 MenuItem.vue 我在一个 Vue 文件里引入，那我使用这个组件 应该是？
1 <MenuItem /> 2 <MenuItem> <MenuItem/> 3<menu-item /> 4 <menu-item> <menu-item/>
ps： 我在 vue3 官网看到这段话 每太理解；
在单文件组件中，推荐为子组件使用 PascalCase 的标签名，以此来和原生的 HTML 元素作区分。虽然原生 HTML 标签名是不区分大小写的，但 Vue 单文件组件是可以在编译中区分大小写的。我们也可以使用 />来关闭一个标签. 如果你是直接在 DOM 中书写模板 (例如原生 <template> 元素的内容)，模板的编译需要遵从浏览器中 HTML 的解析行为。在这种情况下，你应该需要使用 kebab-case 形式并显式地关闭这些组件的标签. 疑问 2 ；
在写项目的时候，目录结构怎么算是标准的，如文件夹名称，文件名称，组件名称，样式名称，布局组件？
举例： 我的 vue3 项目,src 下有，api,assets,components,layout,style,router,views;
components 和 layout 下，新建组件，比如一个 MenuItem.vue ，是建一个 MenuItem 文件夹里创建 index.vue ，还是直接建文件？ 文件夹名称 和 文件名称 是否需要是驼峰 + 首字母大写？ components 和 layout 下 的组件命名有区别吗？
css 的布局的文件，是单独放到 style 里 还是放到 assets 下，怎么算是标准的，我看一些大佬的 vue3 项目，他们写有的 scss 是 _xxxx.scss 还有 xxxx_.scss 命名有什么标准吗？
ps: 就是想问问，vue3 有没有说像 Java 有阿里巴巴开发规范手册一样，来规范标准化这些东西？ 我参考了很多开源 基本都是按照自己的风格写的；
 | 1 vueli 2024 年 7 月 4 日 我的目录： views fileList components model index.vue / xxx.vue 至于 css 提取出来全看个人，这无所谓，你写在一个文件里面，也能开两屏。 如果是.tsx 就需要外部引入了。 终于你其他的问题，完全取决你接手的项目之前的人怎么写的。 你要是真想弄一套规范，直接去看开源的 github start 数量巨多的那种，抄规范就行了。 |
| 2 vueli 2024 年 7 月 4 日 views ---fileList ------components ------model ------index.vue / xxx.vue |
 | 3 zhhbstudio 2024 年 7 月 4 日  1 15 ，16 年开始写 Vue ，到目前自己也乱七八糟瞎写。。。 答疑问 1： 1: <MenuItem/>; 2:<MenuItem></MenuItem>; 3:<menu-item />. 4:<menu-item></menu-item>; 应该都是能正常用的。(注意 / 的位置，html 关闭标签 / 在前边。） 没有子元素时，可以使用 1 ，3 。但是 2 ，4 也是正常的。有子元素只能使用 2 ，4 。 第二段引用的意思应该是有运行时用到的模板（不经过 node 编译的），只能使用 4 这种。 答疑问 2： 我目前的习惯就是全项目统一就行，怎么开心怎么来。。。。 你要找到也分享给我一份吧。 有其他疑问也可以随时交流，正好我也回顾回顾忘记的或之前忽略的东西。 |
| 4 zhhbstudio 2024 年 7 月 4 日 |
 | 5 BruceXu 2024 年 7 月 4 日 回答第一个: 用<MenuItem> <MenuItem/>或者<MenuItem />.取决于有没有子元素. vue 已经支持 PascalCase 类型了,没必要再转一下.组件的属性同理. |
 | 6 jones2000 2024 年 7 月 4 日 关键是有注释， 需求文档，设计文档，每次提交代码备注的时候把改动内容写全。 |
 | 7 v21984 2024 年 7 月 4 日 1 不要用 <menu-item /> 这种写法，一点都不方便后续别人接手时搜索 |
 | 8 4Et5ShxMIq58n6Lr 2024 年 7 月 5 日 我一般保持和文件名一致，方便检索 |
 | 9 fusi 2024 年 7 月 5 日 规范的话，最简单的方式就是去 github 上找一些 vue 项目，看看他们怎么写的、怎么划分文件结构的，可以跑起来，然后给自己提几个需求，这样能最快帮助你深入，也能更好的理解为什么这样写 实际工作中，大多数时候都是 curd ，在现有的项目上改，所以我的理解是，你暂时不需要操心目录结构的事，见多了，写多了，就有自己的一套理解与规范了 |
 | 10 callv 2024 年 7 月 5 日 |
Select Language