Bonjour à tous, je suis cette vague peut riposter.
Ce soir, mes amis du groupe et moi avons regardé une émission spéciale en direct sur les Nuggets.
Que puis-je dire, j'ai apprécié l'ambiance. Regarder la même chose avec un groupe d'amis partageant les mêmes idées, puis exprimer leurs propres opinions et opinions est très différent de regarder des émissions en direct et de publier des écrans à puces.
Lorsque je suis entré dans la salle de diffusion en direct, la diffusion en direct avait déjà commencé depuis plus de dix minutes. En particulier, il se plaint fréquemment des lacunes des crochets React : charge mentale, pièges de fermeture, dépendances de useEffect, etc.
Cependant, j'ai une opinion différente sur ces plaintes. L'origine du piège de fermeture est que tout le monde n'a pas une compréhension approfondie des fermetures, donc lors de l'utilisation de certains crochets, ils ne peuvent pas percevoir la génération de certaines fermetures. En fait, si la logique du piège de fermeture est établie, elle n'existe pas seulement dans les crochets React, mais dans tous les scénarios possibles en JavaScript. Surtout dans les scénarios de faible perception comme les fonctions anonymes.
À mon avis, le problème de dépendance de useEffect n'est pas seulement l'inconvénient des crochets, mais l'avantage des crochets. Je dédie cet article au chapitre le plus important de mon nouveau livre, React Fate, "The Philosophy of React". Les dépendances de useEffect peuvent nous aider à surveiller une seule donnée pour piloter plusieurs données, nous pouvons donc utiliser cette fonctionnalité pour compléter le changement en pensant à des données uniques pilotant plusieurs données et à plusieurs données pilotant l'interface utilisateur. Cela peut grandement simplifier notre développement et améliorer l'efficacité du développement.
La pensée de commutation est mon propre concept de développement original, qui fait référence au concept de conception selon lequel un état de données pilote plusieurs états de données, puis plusieurs états de données pilotent l'interface utilisateur.
useEffect(() => {
if (refreshing) {
http.get(api).then(res => {
setList(res.data)
setRefreshing(false)
})
}
}, [refreshing])
// refreshing 发生变化时，useEffect 回调函数必定执行
// 开关回调就变得异常简单
function onRefresh() {
setRefreshing(true)
}
复制代码// 使用时，可用使用非常简洁的代码实现复杂的交互逻辑
function App() {
const {refreshing, incresing, list, setRefreshing, setIncresing} = usePagination(api)
return (
<PaginationList
list={list}
refreshing={refreshing}
incresing={incresing}
onRefresh={() => setRefreshing(true)}
onIncrese={() => setIncresing(true)}
/>
)
}
复制代码You Da a également présenté les avantages de l'API Options et de l'API Composition.
La combinaison de Vue3 et ts
La deuxième question traite de la combinaison imparfaite de vue3 et ts. Le principal problème est la façon dont les accessoires sont définis et les composants génériques.
On peut seulement dire que l'ami qui a posé la question est en effet assez pointu, et il appartient au modèle dont le pot ne doit pas être ouvert et mentionné. La question à laquelle You Da a répondu sur le côté a également reconnu les problèmes existants. Il y a en fait une très bonne discussion sur ce sujet sur Zhihu. Vous pouvez en savoir plus ici.
Traversée Vue 3
许多朋友在期待 Vue3 能够提供一些官方支持的稳定维护的跨端方案。这里就要让大家失望了，尤大明确的表达了 Vue 团队没有精力去做这些事情，只有公司级别的体量才有能力去做，因为跨端的支持确实很复杂。
不过这个时候尤大一句带过踩了一下 uniapp，所以技术选型准备使用的可能要稍微小心一些，群里也有小伙伴在吐槽 uniapp 的坑点，比如 css 只支持类选择器等等。
除此之外，尤大介绍了 Vue 一个非常强大的特性：vue3 直接暴露了一套自定义渲染器的接口，理论上可以接入任何渲染目标，比如有个团队的小伙伴正在接入一套很炫酷的命令行 UI。
如何加入开源项目
几位大佬对于开源的讨论挺多的。月影认为开源项目的复杂并不低运营一个公司低。郭辉认为搞开源需要有热情，初衷单纯一些，因为可能没有回报，甚至还要义务去解决很多 issue。加上许多使用者态度并不是那么友好。
对于尤大而言，他更在意的是你能够持续的为某一个项目提供优质代码，就能够很大机会加入该开源团队。
尤大潜台词：都来给 vue 干活吧，哈哈。
Vue -> canvas
这个问题其实非常有意思，理论上是可以实现的。但是这种方向其实有点类似于跨端方向的一种，尤大认为浏览器实现这些能力其实花费了很多精力，言外之意就是说，可能 Vue 并不会考虑这个事情。
我们其实也可以思考一下这个实现的复杂度，例如，我们需要有 vue 组件结构，需要有样式标准，那么就额外需要实现一个组件解析器和样式解析器，需要将两者的解析结果合并计算成为类似 render tree 的东西并渲染到 canvas 上。这个过程确实比较复杂，也是浏览器底层原理实现的一套解析和渲染的机制。
状态管理 vuex5
很可惜尤大并没有介绍 vuex5 的特性，只是介绍了相关的背景。我不是 vue 的深度用户，所以没听出来什么特别有用的信息。
vue3 的缺点，vue4 新的变化
对于这个问题，尤大明确的表达了 ts 方面还需要再完善，包括泛型与 slots。
除此之外，vue3 过于在意大型项目的可维护新问题，导致了在特别轻量的嵌入式场景反而显得有些笨重。因此后续会出一个非常小的只有 6KB 左右的 petite-vue 来解决这种场景的应用。
最值得期待的是，尤大明确的表示了 vue 会借鉴 solid 的编译模式。了解 solid 的朋友应该知道，那将是一次巨大的性能飞跃。
solid 是一个摈弃了虚拟 DOM，走编译型路线的框架，别的不说，他的性能是能吊打目前的 Vue 与 React。因此如果 Vue 真能做到借鉴这种模式的话，性能上的表现是非常值得期待的。
月影：前端技术新趋势
在聊前端技术新趋势的时候，月影大佬扯了很多历史，大概针对 web1.0 和 web2.0 都做了一些描述和感受。比如 web 1.0 的只读特性，web2.0 的强交互，我觉得都谈的非常到位。我心想，花了那么多时间聊前世今生，那肯定是要聊 web 3.0 的一些展望了预判吧，然而，我等了个寂寞。
结果他只是针对网速越来越快，前端的项目会越来越重这个点出发聊了一些内容。并表达了技术虽然变化莫测，但是万变不离其宗的核心哲学。
说得很有道理，不过多多少少还是有些失望。
郭辉：低代码，无代码
说实话很多小伙伴都在关注低代码，甚至有的焦虑型选手在担心低代码的推进会不会影响前端程序员的饭碗。郭老师用简单明了的表达打消了我们的顾虑。
他说确实有很多团队都在尝试低代码，甚至有一些财务公司「我怀疑他说的可能是金蝶」在低代码做得非常成熟，但是呢，大多数团队都做得不是很好。主要的原因在于许多场景业务逻辑比较复杂，不通用，无法抽象。也就导致了低代码的实现成为了一种愿景。
许多团队在攻克组件渲染这一层的东西，但是实际上这些都是比较简单的，不是项目的核心痛点。也就是说，郭老师觉得他们的方向走错了。
低代码仅仅只适合逻辑抽象比较简单，比较通用的场景。例如发票。业务逻辑抽象比较容易。toB 的业务逻辑是无法解决的。
无代码，低代码，早在很多年前，在其他语言有其他类似的概念场景和应用。郭老师也提了一个非常有用的概念：我们应该适当跳出前端的圈子。甚至不要局限于技术圈子。
我深表认同。
尤大：前端新技术的看法
国外国内对于低代码的看法不一样。国内搞低代码的大多数都是一些大厂，为了绩效什么什么的「哈哈哈，含糊的踢了一句，懂的都懂」
国外呢，更多的是小厂在搞这些。
不过尤大提了一个我很赞同的观点：不同的阶段，关注的东西应该是不一样的。比如初入前端，关注低代码没太大的必要。更应该关注自身能力的提升。
其实尤大在新技术这一块，给我们提供了一个非常好的展望。那就是前端工程化的变迁。当项目变得更加复杂，更快的开发性能成为了我们的追求。他列举了一些例子。
使用 rust 重写 postcss，用于快速处理 css AST 的转换。这种场景使用原生语言去写，收益回报比比较确定。
当然除此之外，还有我们熟悉的 esbuild，使用 go 语言编写。工程化的变迁已经慢慢的渗透到了我们的项目开发者。
这其实是对于高级前端工程的一次大的挑战和机遇。
出了工程化之外，尤大也提供了一些原生化场景的决策思考，对于业务逻辑，迭代速度，灵活性，稳定性，性能等多方面去聊了对应的场景「图像处理、前端框架」是否适合原生化。
例如在框架层面原生化是否合适：一部分计算快了，但是与DOM的通信成本更高。实现成本也更高了。所以用原生语言写一个模块，获得明确的性能提升。抛弃 JavaScript，all in WebAssembly 是不现实的。
程序员未来的出路
对于这个问题，尤大并没有提供什么有参考价值的建议。
他也直接表达了个人经验参考价值比较有限。比如找到机会做一个用户量比较大的开源项目是一次偶然性事件。能力虽然是前提条件，但是运气占很大一部分。
他觉得自己是比较幸运的。做 vue 的时候，前端刚好处于一个刀耕火种的年代。
并且给了一些建议，如果要做一个产品卖给某些团队的话，应该更多的关注海外市场。
Dans l'ensemble, il y a encore quelques gains, mais le plus gros gain est que plusieurs groupes de personnes se plaignent de la joie de ces gros bonnets dans le groupe en même temps. Ha ha.
Je suis celui qui peut riposter, suivez-moi pour débloquer plus de compétences frontales !