jump-and-jump

Results 72 issues of jump-and-jump

最近基于公司业务需求,可能会要开发一款浏览器插件,调查后发现插件UI开发本质上就是开发页面。于是我便开始寻找一个非常小又非常快的新玩具(工具)。毕竟前端 3 大框架无论哪一个去开发浏览器插件都无异于大炮打蚊子。至于开发效率极低的 Dom 操作我也不想去碰了。于是我就找到了这个已经在国外非常火热的魔法消失 UI 框架 —— [Svelte](https://svelte.dev/)。 ### Svelte是什么 [Svelte](https://svelte.dev/) 是一个编译型的前端组件框架。该框架没有使用虚拟 dom,而是通过编译在应用状态发生改变时提供异步响应。 ## 编译型框架 任何前端框架都是有运行时的,(以 Vue 为例) 该框架至少需要在浏览器携带虚拟dom 以及 diff 算法。如果在页面中直接引入 Vue 脚本,还需要追加 Vue 前端编译器代码。可以参考[Vue 对不同构建版本的解释](https://cn.vuejs.org/v2/guide/installation.html#对不同构建版本的解释)。 Svelte 则不同,它从开始就决定把其他框架在浏览器所完成的大部分工作转换到构建中的编译步骤,以便于减少应用代码量。它通过静态分析来做到按需提供功能(完全不需要引入),同时它也可以分析得出根据你当前的修改精准更新...

在 9102 年年初,一位室友问我一个问题,如何才能够提升写代码的能力? 可惜的是: 当时仅仅回复了一些自己的想法,如多看开源代码,多读书,多学习,多关注业界的动向与实践,同时也列了一些原则。但是这些并没有所总结,又或者说没有例子的语言始终是空泛的。所以在今年年底之际,对应着今年中遇到的形形色色的代码问题来一一讲解一下。 好代码的用处 ------ > 实际上本书建立在一个相当不可靠的前提之上:好的代码是有意义的。我见过太多丑陋的代码给他们的主人赚着大把钞票,所以在我看来,软件要取得商业成功或者广泛使用,“好的代码质量”既不必要也不充分。即使如此,我仍然相信,尽管代码质量不能保证美好的未来,他仍然有其意义:有了质量良好的代码以后,业务需求能够被充满信心的开发和交付,软件用户能够及时调整方向以便应对机遇和竞争,开发团队能够再挑战和挫折面前保持高昂的斗志。总而言之,比起质量低劣,错误重重的代码,好的代码更有可能帮助用户取得业务上的成功。 以上文字摘抄于《实现模式》的前言,距离本书翻译已经时隔 10 年了,但是这本书仍旧有着很大的价值。同时对于上述言论,我并不持否认意见。但是我认为,坏代码比好代码更加的费财(嗯,没打错,我确定)。对于相同的业务需求,坏代码需要投入的精力,时间更多,产出反而会更少。同时根据破窗理论( 此理论认为环境中的不良现象如果被放任存在,会诱使人们仿效,甚至变本加厉 ),坏代码会产生更坏的代码。这是一个恶性循环,如果不加以控制,完成需求的时间会慢慢失去控制。需要完成需求的人也会失落离开。 也就是说,好代码可以实现多赢,能够让用户爽,能够让老板爽,能够让开发者爽。总之,大家爽才是真的爽。 怎么写出好代码 ------- ### 少即使多 利用开源出来的设计与代码来减轻来自于业务线的时间压力。 > The best way to write secure and reliable applications....

9012 年末,作为一个前端,说不了解 Promise 对象用法的基本不存在,这里就不对功能用法进行介绍了。但本文将会讲述你可能不知道的 Promise 3 种奇妙用法。当然,每种用法都会有其适用的特殊场景。 ## Promise 对象是可以缓存 ### 需求 对于一个对象而言,能够被缓存并不是一件难以理解的事情。缓存使用的意义往往是为了解决性能问题。而对于一个特定请求的 Promise 对象而言,缓存的意义在于同时多个组件的使用该请求,会因为请求未返回而进行多次请求。一图胜千言,图示如下: ![别觉得丑](https://raw.githubusercontent.com/wsafight/personBlog/master/images/19-12-15/more-query.png) 因为在某些特定需求或者场景下(甚至因为团队的因素),某个组件在可以在页面单独使用,也可以结合其他组件共同使用。若此时多个组件都需要对某个通用数据进行请求,就会发生多次请求,对性能不利。但如果全部移植到父组件去请求,又是需要一顿操作,对开发不爽。 ### 解决方案 所以这时候我们基于 api 与 请求参数加缓存。先写一个生成 key 的函数(此函数仅仅只适用简单的请求参数,不适合对象等复杂数据结构,因为是通用型数据,不考虑太复杂的请求参数,如有需求可以自行改造)。 ```js // 生成key值错误 const generateKeyError...

自从 9102 年初 react 推出了 Hook 之后,我就开始在私人项目中先行了。不得不说的是,react Hook 的确足够“跨时代”。大量的文章研读以及伴随着项目中组件的改造,对Hook 的优点,缺点,以及本身的机制也有一定的了解。 如果你是 Hook 初学者,建议先阅读 [ https://usehooks.com/]( https://usehooks.com/ ) 以及 [Dan Abramov 的个人博客]( https://overreacted.io/ )。 伴随着 Hook 时代的带来,react 社区也是到来了无 Hook 不欢的时代。 如火如荼的封装。包括...

# 利用 WeakMap 对 Vue 新建数组中的对象赋予 :key ## 需求 在 Vue 中,对组件进行循环都需要加入key以便“就地复用”,可是在某些情况下,我们需要新建多个对象,而这些对象不是从后端获取到的,而是前端生成的,没有唯一值,且 Vue 目前版本只允许字符串,数字作为组件的 key。 ## 方案 ### 简单的组件 例如 ``` export default{ methods: { addSometing () { this.items.push({ //...

> Signals 在目前前端框架的选型中遥遥领先! 国庆节前最后一周在 Code Review 新同学的 React 代码,发现他想通过 memo 和 useCallback 只渲染被修改的子组件部分。事实上该功能在 React 中是难以做到的。因为 React 状态变化后,会重新执行 render 函数。也就是在组件中调用 setState 之后,整个函数将会重新执行一次。 React 本身做不到。但是基于 Signals 的框架却不会这样,它通过自动状态绑定和依赖跟踪使得当前状态变化后仅仅只会重新执行用到该状态代码块。 个人当时没有过多的解释这个问题,只是匆匆解释了一下 React 的渲染机制。在这里做一个 Signals 的梳理。...

缓存是提升 web 应用程序有效方法之一,尤其是用户受限于网速的情况下。提升系统的响应能力,降低网络的消耗。当然,内容越接近于用户,则缓存的速度就会越快,缓存的有效性则会越高。 之前个人写过 [前端 api 请求缓存方案](https://github.com/wsafight/personBlog/issues/2)。介绍的了内存中的缓存以及过期逻辑。后续也写过 [手写一个前端存储工具库](https://github.com/wsafight/personBlog/issues/55),该工具利用了适配器处理了不同的存储介质(内存,IndexedDB, localStorage 等)。 不过,在某些特定场景下缓存还需要优化,例如:用户需要在登录或者填写表单时需要通过某些接口获取必要数据,而这些接口是由第三方平台提供的。这些接口可能会出现错误或超时的情况。如果当前数据有很强实时性,开发者就必须重试或者联系第三方平台来处理对应的错误。如果数据的实时性不强,当前就可以使用本地缓存。 一般来说,当获取时效性缓存时候,我们会检查并删除当前数据。代码简写如下所示: ```javascript // 缓存对应的的模块以及功能 const EXTRA_INFO_CACHE_KEY = 'xxx.xxx.xxx'; // 缓存时长为 7 天 const CACHE_TIME = 7 * 24 *...