为什么这么讲呢？
【 在 libgcc 的大作中提到: 】
: 本青最近研究了一下vue3，感觉不不如angular设计的好
--
FROM 183.245.77.*

composition api 摆明了抄的 react hooks 啊。react 里 function component 是每次重绘都再把函数跑一遍，vue 的 setup 函数只在创建控件时跑一遍，那自然需要不同的机制来实现 reactive。

reactive 只能接受 object 类型参数，那 primitive 类型就得想办法转成 object。因为这样的语法是没办法 reactive 的：
let foo = 1;
const onBar = () => { foo = 2 };
return  { foo, onBar }; // foo 的值永远是 1

通过 ref 就可以解决这个问题，得到一个 object，然后用 refObj.value 代表原值。同理，虽然 props 本身是 reactive，但 destruct 之后就变成一个普通值了，所以如果想单独使用某个 prop 的话，要么直接用 props.foo，要么 toRef/toRefs 之后再用。

vue 本来就是抄特性起家的（非贬义，本来开源界也都抄来抄去的，完全原创几乎是不可能的），抄 angular、react、svelte 都不是什么稀奇事。至于为什么选择抄了 hooks 就只有 yyx 自己知道了，不过个人理解，大概有一条是有利于有 hooks 基础的人转 vue，毕竟目前 react 是绝对的老大。

另外，vue 团队目前的精力主要集中在 vite 上面，vue-cli 以后默认转用 vite，或者是直接说不用 vue-cli 改用 vite 也有可能。vite 的影响力也越来越大，比如 storybook 最近除了支持 webpack5，也支持 vite。svelte 用来替代 sapper 的 sveltekit 一开始说要用 snowpack，没过俩月换了 vite，也是超级大的免费广告。所以目前来看，在竞争用来替代 webpack 的下一代工具上面，vite 是取得了极大的优势的。如果哪天 react 说我们也不考虑支持 ie 的话，突然 CRA 把 webpack 换成 vite 我一点都不会意外。

我今年给公司主产品（老旧的 rails）加入了 vue3 的支持，开发环境就使用了 vite，生产环境还是用 webpack 来生成代码。上上个礼拜刚刚加入了一个非常重要的页面，主体还是老旧的 rails + jquery，但其中一部分用来管理页面内几组 tabs 的控件是用 vue 实现的，新代码用 typescript，需要和老代码库交互的地方通过 composition api 的 js 实现。具体来说就是直接

// a.ts
export const foo = reactive({...});

export const bar = { onFooChange: () => {} };

watch(foo, (...args) => { foo.onFooChange(...args); });

// b.js
import { foo, bar } from './a';

bar.onFooChange = () => {
  ...
  window.legacyLib.blahblah // 直接调用老代码库的代码
  $.get(...)
    .done((data) => {
      ...
      foo.baz = 'abc';
    })
}

在其它 vue 控件里直接用 foo 就完了。用起来非常香，回头再慢慢用 ts 重写 js，因为还需要在 jquery 的基础上增加一堆声明，还有我们自己的一堆封装的声明才能用。另外我们的 jquery 是 1.12.4，而 @types/jquery 最高只有 1.10.36，估计凑合用问题不大吧。

【 在 libgcc (乞讨积分,求施舍,长期有效) 的大作中提到: 】
: https://mp.weixin.qq.com/s?__biz=Mzg4MTYwMzY1Mw==&mid=2247496480&idx=1&sn=ee
: c778b7d6a6709dfc86bd525ea89a52&source=41#wechat_redirect
: 反正把ref和reactive搞清楚都挺磨叽的,我现在还没完全弄明白
: ...................
--
修改:eGust FROM 115.188.133.*
FROM 115.188.133.*

现在vue3 sfc文件模式+typescrip+webpack，你能用code调试ts么

我搜了下，这个issue2018年挂出来，现在官方也没解决，sourcemap有问题。野路子的倒是有

神器公司的也不行
【 在 eGust 的大作中提到: 】
: composition api 摆明了抄的 react hooks 啊。react 里 function component 是每次重绘都再把函数跑一遍，vue 的 setup 函数只在创建控件时跑一遍，那自然需要不同的机制来实现 reactive。
: reactive 只能接受 object 类型参数，那 primitive 类型就得想办法转成 object。因为这样的语法是没办法 reactive 的：
: let foo = 1;
: ...................
--
FROM 119.103.161.*

感觉这个微信链接里的是瞎掰，第一个例子就有问题。
继续看
【 在 libgcc (乞讨积分,求施舍,长期有效) 的大作中提到: 】
: https://mp.weixin.qq.com/s?__biz=Mzg4MTYwMzY1Mw==&mid=2247496480&idx=1&sn=ee
: c778b7d6a6709dfc86bd525ea89a52&source=41#wechat_redirect
: 反正把ref和reactive搞清楚都挺磨叽的,我现在还没完全弄明白
: ...................
--
FROM 111.166.5.*

跟babel什么的没关系，只有sfc文件有这个问题
单编ts文件没问题，sfc+js也没问题

所以压根就是vue的生态工具不行
【 在 eGust 的大作中提到: 】
: sourcemap 的锅不容易找人背，尤其在 webpack 里面，涉及的方面太多了
: 如果浏览器能调试的话，我是从来不用 vscode 的。首先就是不管 react 还是 vue，浏览器都有专门的 devtools 插件。很多简单的 bug 进去一看控件本身的 state/data 不对，或者 redux/vuex 的状态不对，就直接知道怎么回事了，不需要跟代码。其次，能不能下断点也是取决于 sourcemap 的，不是任何一行都能下断点的，在浏览器里不能下断点的行是灰色的。
: webpack 根据你的设置，可能会调用 babel，而 babel 可能会把代码搞的面目全非。反正我的 ts 是 target esnext 的，vite 调用 esbuild 应该只是很简单的把类型信息都去掉，这样的 js 代码与 ts 源代码几乎是一一对应的，非常容易调试。被 babel 搞成 es5 的代码，要是调试能不跑飞了反倒奇怪了。
: ...................
--
FROM 119.103.161.*