浅谈vuejs

npm包管理

    一般来说，Multirepo架构是适用多数包开发管理的，不过对于vuejs这种框架级的工程，可能会根据不同的运行平台做单独的包拆分，比如，专用于ssr的server-renderer包

    此时出于统一配置、方便管理等考虑，Monorepo应更为推荐

命令式与声明式

    概念

        jquery应当是命令式的典型，强调过程，而vue则强调结果，过程对用户不可见，是为声明式

    对比

        命令式的代码更加符合用户直觉，理论上性能也更高，因为它省略了转换的过程，但是却增加了用户的维护成本和代码量

        声明式下，用户只需要关注最终的结果，这能够大大提高用户的开发效率并降低维护成本，但是由于框架内部仍然需要将声明式ui转化成命令式代码逻辑，故其性能损耗可能更大

    结论

        显然，虚拟dom技术能够很好的抹平声明式ui转换过程带来的性能损耗问题

运行时与编译时

    概念

        所谓运行时，即从a到b，即输入数据-执行获取结果，如import { h } from 'vue'时对h函数的调用；而运行时则是a-b-c，其中的a、c不变，增加了一层b的转换，如vue-loader

    对比

        h函数写出的代码可能性能更优，但是会增加用户的心智负担，难以维护，尤其当要描述的界面存在多层嵌套时，提供的树形数据势必又臭又长

        而编译时，则允许我们对用户提供的数据做提取分析，比如哪些节点是静态节点，可以在编译阶段打上特殊的tag，然后交给h函数做相应的优化处理

    结论

        则，为了框架的灵活性，运行时+编译时应该是最优选择

warning

    通常我们提供给用户的代码都是被打包过的，且用户不可能去修改包的源码，因此适当的给出warning提示辅助开发者排错是很有必要的

包产物大小

    由于浏览器会等待js下载并解析完成后才会继续解析html，因此越小的构建产物对页面的流畅性体验的影响就会越小，因此我们需要增加一些“代码守卫”，如前一部分提到的warning函数，应当仅在开发环境有效，因此可利用打包工具注入一些环境变量使其不在该模式下时成为dead code

    如上，我们已经让warn函数的执行在开发环境下成为dead code，则在打包工具的tree-shaking加持下，这部分代码将不会出现在构建产物中。此外，对于一些有引用，但是实际无执行意义的代码，我们还需要手动对其标记为“PURE”以明确告知打包工具：该部分代码虽然已被引用，但是如果无实际执行意义，可放心视为“dead code”

sourceMap

    当然，这是打包工具天生为我们提供的支持，但是需要注意的是打包工具一般只会以最后一次生成的sourceMap为准，因此如果存在在plugin或者loader阶段的源码修改，最好是借助一些三方库做二次生成，比如vue-loader

构建产物格式

    通常情况下，我们都期望尽可能多的覆盖应用场景，拿vue来说

    通过script标签引入

        为此，需要提供iife格式，即立即执行函数形式

    通过script标签的type=module引入

        为此，需要提供esm格式，并配置module字段

    在main.js中通过import xxx from ’pkgName‘引入

        为此，需要提供带bundler后缀的文件，当然这只是一种约定俗成，具体还是由main字段决定的，这主要是提供给打包工具使用的，它允许在构建过程中动态替换环境变量

    在node中使用

        vue提供了对ssr的支持，因此需要提供cjs格式的资源供require消费

特性开关

    一个健壮的应用程序应该都可以进行“尝鲜”，比如可以通过chrome://flags/#enable-experimental-web-platform-feature来开启浏览器的新的前端存储方案Storage Buckets

    又或者，由用户决定是否开启或关闭某个/部分功能，在vue3中，其默认兼容了vue2的options api的形式，但是如果我们的vue3应用明确不会用到2中的写法，则将这部分兼容代码输出到构建产物中无疑是在浪费资源

ts支持

    ts现在几乎是前端必备的了，虽然在业务开发中多显鸡肋，但是对于第三方包的增益却良多，因此做好类型支持并提供类型标注是很重要且有必要的

错误处理

    除了要在内部做好try...catch外，也需要对外抛出反馈，并允许将错误处理的控制权移交给用户

hmr

    说起vite，应该大部分人想到的不是它基于esbuild的更快打包，而是更快的hmr

    试想，用户使用你的包，每次改动代码都需要reload页面才能看到结果，那你说，它会不会喷你？

    因此，在开发环境提供hmr能力很有必要