jump-and-jump
jump-and-jump
> 在大多数情况下，我们推荐使用 [受控组件](https://zh-hans.reactjs.org/docs/forms.html#controlled-components) 来处理表单数据。在一个受控组件中，表单数据是由 React 组件来管理的。另一种替代方案是使用非受控组件，这时表单数据将交由 DOM 节点来处理。 以上是 React 官网对受控组件与非受控组件的一次解释，大学刚刚毕业时候，看到这一段， 实在有些难以接受，在我看来，既然已经选择使用了 React ,就应该完全彻底的使用受控组件，为什么开发者会有直接使用 DOM 节点开发的的非受控组件。当时在 vue 中，并没有这种设定。同时我当时在开发 Sass 网站，因为在开发 pc 端网站总是需要即时验证(即时给予用户交互，不让用户在填写完整的数据后再提示错误以致于过分沮丧)。 不过现在来看，非受控组件的确是 React 非常好的设计。 ## 非受控与受控组件的区别与选择 **非受控的输入**就像传统的HTML表单输入一样： ```jsx class...
今年下半年打算正式撸一撸小游戏，正好这些天整理一下有关游戏的一些知识，当然了，目前还是打算使用浏览器网页进行游戏开发。 ## 网页游戏开发的优势与未来 如果使用其他语言开发游戏，无论游戏本身大小与否，我们都需要游戏引擎来帮助我们构建开发，而对于浏览器来说，我们在开发小游戏时候，利用浏览器本身提供的组件和 api 就可以直接进行业务处理，我们也可以更加高效的学习与实践游戏逻辑。同时网页游戏的构建与发布也非常简单。 例如像 [**Js13kGames** ](http://js13kgames.com/) (Js13kGames是一个针对 HTML5游戏开发者的 JavaScript 编码竞赛,该竞赛的有趣之处在于将文件大小限制设置为13 kb ) 这样的限制代码量的游戏开发竞赛。对于非网页游戏开发来说，这基本上是不可能完成的，因为它们不具备有像浏览器这种量级的通用型的工具。 随着时间的发展，浏览器的功能，性能也在不断提升。通过 WebGL, WebAssembly 各种层出不穷的技术。让很多之前想都不敢想的功能在浏览器上实现。同时,伴随着 5G 到来，网速的提升，在浏览器上开发游戏充满了无限的可能。 当然了，事实上，不同的游戏需要不同的组件，其中包括数学库，随机算法，碰撞及物理引擎，音频，资源管理，AI机制等等等等，不过在浏览器环境下，这些组件都可以做到按需引用。 ## 游戏循环架构与风格 游戏本身是基于动画的。不知道大家在小学的时候有没有买果或者玩过翻纸动画？如果你没有了解过，也可以看一看bilibili 中的视频 [高中生自制的翻纸动画短片]( https://www.bilibili.com/video/av24463374/?p=2)。视频中通过快速翻动纸张来实现两个火彩人打架的精彩动画。事实上，我们的电脑，手机设备能够展示动画都是基于此原理。 所谓动画，就是不间断，基于时间和逻辑不断更新数据以及重绘界面。其核心一定会有至少一个循环。这里我介绍几种常见架构。...
无论是 pc 端还是移动端，无可避免都会涉及到列表查询有关的操作，但对于这两种不同的设备，其列表查询的最佳处理方式也是完全不同。 对于 pc 端列表查询来说，前端通常是给与服务端当前需要获取的数据量(如 pageCount，limit 等参数)以及所需要获取数据的位置(如 pageSize，offset 等参数)作为查询条件。然后服务端然后返回数据总数，以及当前数据，前端再结合这些数据显示页面总数等信息。这里我称为相对位置取数。 对于移动端而言，没有pc 端那么大的空间展示以及操作，所以基本上都会采用下拉取数这种方案。 那么我们在处理移动端列表查询时候使用这种相对位置取数会有什么问题呢？ ## 相对位置取数存在的问题 ### 性能劣势 通过相对位置取数会具有性能问题，因为一旦使用 offset 信息来获取数据，随着页数的增加，响应速度也会变的越来越慢。因为在数据库层面，我们每次所获取的数据都是“从头开始第几条”，每次我们都需要从第一条开始计算，计算后舍弃前面的数据，只取最后多条数据返回前端。 当然了，对于相对位置取数来说，数据库优化是必然的，这里我就不多做赘述了。对于前端开发来说，优秀的的查询条件设计可以在一定方面解决此问题。 ### 数据显示重复 事实上，对于一个实际运行的项目而言，数据更新才是常态，如果数据更新的频率很高或者你在当前页停留的时间过久的话，会导致当前获取的数据出现一定的偏差。 例如：当你在获取最开始的 20 条数据后，正准备获取紧接着的后 20 条数据时，在这段时间内 ，发生了数据增加，此时移动端列表就可能会出现重复数据。虽然这个问题在...
去年 11 月份中旬，随着有赞 Vant Weapp 库 1.0 版本的正式发布，我们的小程序也是立即跟随官方的脚步，着手把依赖库升级了一下。但是却发现 Vant Weapp 对于苹果的底边适配却在微信开发者工具中消失了。在不了解 css env 实际作用和开发工具适配的的情况下，就鲁莽的发了一个 [issue](https://github.com/youzan/vant-weapp/issues/2264)，在此也记录一下，以便于今后查阅与学习。 ## safe-area 事实上，因为个人之前工作的重心在了 js 与 pc 上，对 css 以及移动端有所忽略，才会对这个安全区域没有更多的学习以及理解。  面对新式手机的刘海以及胡子，在开发移动端的小伙伴们不得不对手机型号做适配，如果当前使用的界面是整个屏幕，就会发生当前的显示被遮挡的问题。当然，其实对于小程序来说，绝大情况下完全不用考虑上面的刘海，一方面是因为当前的小程序的 navigationBar 做到了适配的功能，不需要考虑头部的问题。从另一方面来说，小程序没有特别的需求下也不需要横屏展示。但是对于底部的胡子，我们需要留给其 34px 的高度。在...
自从上周在阮一峰的 [每周分享第 60 期](http://www.ruanyifeng.com/blog/2019/06/weekly-issue-60.html) 看到了可以将 GitHub 的 issue 当作评论系统，插入第三方网页的 JS 库——[utterances](https://utteranc.es/)。我就对此“魂牵梦绕”。个人博客使用的是[VuePress](https://vuepress.vuejs.org/zh/)。 ## TLDR (不多废话，先看效果) 之前是使用了 Valine 作为博客的评论系统。  下图是改为 utterances 风格。  ## utterances 介绍及使用 utterances 是基于github issue，拥有多种主题的开源免费小组件。 1.首先我们所需要的 github...
当谈到前端构建工具，就不得不提的功能强大的 [Webpack](https://www.webpackjs.com/), 尤其是在最新版本中提出了 [Module Federation](https://indepth.dev/webpack-5-module-federation-a-game-changer-in-javascript-architecture/#its-important-to-note-these-are-special-entry-points-they-are-only-a-few-kb-in-size-containing-a-special-webpack-runtime-that-can-interface-with-the-host-it-is-not-a-standard-entry-point--7/) 功能，该功能进一步增强了 Webpack 的实际作用。我相信凭借 Webpack 这几年的积累，恐怕未来几年内没有哪一个打包工具能够与之媲美，但是这并不妨碍我们探讨一下新的工具 [Snowpack](https://www.snowpack.dev/)。 ## 现代打包工具的问题 使用 Snowpack，当您构建现代的 Web 应用程序（使用React，Vue等），无需使用类似于 Webpack，Parcel 和 Rollup 等打包工具。每次您点击保存时，都无需等待打包程序重新构建。相反，所有的文件更改都会立即反映在浏览器中。 请关注立即这个词语, bundleless ? 这个究竟有什么意义？为什么我会这么重点关注这一个工具。 对于一些项目与开发者而言，可能对此没有太大的感触，但是对于我来说，开发中打包曾经是一个噩梦。几年前，我从头开发一个前端 Sass 项目，该项目开始时候就使用 Vue 以...
最近在补一些 HTML 的书籍，偶尔读到这本书，虽然这本书已经是10年以前的书籍了，不过其中有些有趣的知识点与观点被我提取了出来。 ## 标准创建与技术实现冲突 作者在开始就提出了 Mozilla 开发人员关于标准与实现之间的冲突的一个观点: > 一份技术规范和他的具体实现必须要做到步调一致。实现先于规范完成不是什么好事情，因为人们会开始依赖这些已实现的细节，这样会对规范造成制约。然而，你也不希望在规范已经完成时还没有任何相关的具体实现与实践经验，因为这样规范就得不到任何反馈。这里面如果存在着无法避免的冲突，而我们也需要硬着头皮去克服了。 事实上，对于前端开发而言，具体实现早于技术规范的制定已经是一种常态了。但与其他领域不同的是:前端的新标准非必要条件下是不可以破坏之前的实现。 在这里，我可以举几个兼容性的例子: 大家可能都使用过 String.prototype.includes 来判断一个字符串是否包含在另一个字符串中。但是实际上，在 Firefox 18 - 39中，这个方法的名称叫 `contains()`。由于在Firefox 17上，一些使用 [MooTools](http://mootools.net/) 1.2的网站会崩溃掉。当年由于各个框架为了能够更简单的使用函数，在各自的代码库中修改内置对象的 prototype，同时框架也考虑到了未来标准可能会实现，为了兼容以后的标准，他们对 prototype 进行判断，然后如果对象当前 prototype 上没有函数实现，就使用当前自己定制的函数，如果有函数实现的话，就使用浏览器所提供的函数。虽然他们考虑到了兼容标准，但是他们却没能考虑到标准是会发生改变的。可能在若干年后，标准实现后，函数已经与当前大相径庭。所使用的代码就会发生错误。所以，无奈之下，该函数被重命名为 `includes()` 。事实上我们可以看出，contains...
就目前来看，微前端已经不是一个新话题了。随着越来越多的公司的深入研究，当前也提出了很多的解决方案。不过本文不是想要来介绍微前端，更想介绍项目如何一步步到达微前端架构的实际需求。 当然，也不排除有些项目在初期就需要微前端这样的架构，不过我一直相信，任何架构模式都是根据实际需求来构建的。为什么很多大公司投入那么多的精力去做这样一件事，更多的也是因为他们真正需要这样一种架构，甚至达到了不用会影响业务开发的可能。不过对于大部分企业，不太需要关注这一点。 事实上，无论是什么架构形式,都是为了项目能够更快的进行开发。 所以不难得出，ETC 原则 (Easier To Change ，易于修改) 贯穿始终。 对于 ToC 端应用而言，可能生存期只有 2，3 年就会结束或者重写。但是对于 ToB 端应用基本上是公司不关门之前都会持续开发和使用下去。当然很多 ToC 端应用提供的更多是服务而不是业务，他们更多的关注重点放在服务上而并非业务范畴。 ## 单项目应用 对于后端开发而言，都是由单体应用开始的，但是对于前端开发，所谓单体应用的说法并不合适，所以我在这里把它叫做单项目应用。 对于一个刚刚开始的创业公司，是没有足够的人力储备以及代码实践。此时我们要做的就是利用脚手架开启项目进行开发。我们需要做的是做好代码规范，把代码写好。更多的考虑前端组件化与服务分离。 ### 依赖注入 如果不考虑项目中基于业务的各种依赖库以及其中的设计模式，那么依赖注入必然是打造一个易于修改与扩展的项目不可或缺的设计模式。控制反转和依赖注入可以参考 [控制反转和依赖注入的理解(通俗易懂)](https://blog.csdn.net/sinat_21843047/article/details/80297951)。 但很可惜，在众多的前端框架中仅仅只有 Angular 内置该功能，且仅有...
在开发微信小程序之前，个人从来没有接触过开发中涉及到第三方服务器交互的流程。在开发的过程本身倒是没有什么太大的意外，只是在维护服务器登陆状态这一点很讨厌。因为涉及到自身服务器的登录状态以及微信官方服务器登陆状态三方的关系。 下图是微信登陆机制:  在这种场景下，个人非常关注的点在于: 如何能够无感知的进行登陆(并且无多余请求)。微信的登陆状态倒是还好解决，可以利用 wx.checkSession 来进行判定，但是在与后台服务器交互时候，如果后台交互中返回 HTTP 状态码 401 (未授权)或者其他未登陆指示时候。则需要对其进行额外处理。 当时记得为了优雅的解决这个问题，想了很多方案，也与一些伙伴讨论过这个问题。虽然当时的确实现了无感知的登陆，但是要么需要多请求服务器，要么就是代码上实现逻辑过于复杂，代码维护。虽然不满意，但是在当时也没想到什么非常好的解决方法。 ## weRequest 自带状态管理的请求组件 后面经过老大的介绍，看到这个组件时，我顿时眼前一亮，这正是我所需要的解决方案,该方案的图示如下:  只需要配置一些初始化项目，便可以直接拿去使用了。 ``` // 导入 import weRequest from 'we-request'; weRequest.init({ // [可选]...
去年年末，微信小程序的分包大小已经到达了 12M 大小,一方面说明小程序的确逐步为开发者放开更大的权限，另一方面也说明了对于某些小程序 8M 的大小已经不够用了。我个人今年也是在开发一个 to B 小程序应用。这里列举一些跨页面交互的场景。 对于 B 端应用的业务需求来说，小程序开发的复杂度相对比网页开发要复杂一些。一个是双线程的处理机制问题，另一个是页面栈之间交互问题。 注: 笔者目前只需要开发微信小程序，为了在小程序页面中可以使用 properties behaviors observers 等新功能，已经使用 Component 构造器来构造页面。具体可以参考[微信小程序 Component 构造器](https://developers.weixin.qq.com/miniprogram/dev/framework/custom-component/component.html)。如果你也没有多端开发的需求，建议尝试使用，可以得到不错的体验。 ## 性能优化类 对于小程序在页面中点击触发 wx.navigateTo 跳转其他页面，中间会有一段时间的空白加载期(对于分包出去的页面，空白期则会更长)，但是这是小程序内部机制，没有办法进行优化。我们只能眼睁睁的等待这段没有意思的空白期过去。 当考虑到跳转页面后的第一件事情便是取数逻辑，那么我们是否能够进行优化呢？答案是肯定的。我们没有办法直接在当前页面取得数据之后再进行跳转操作(这样操作更不好)，但是我们却可以利用缓存当前的请求，详情可以参考我之前的博客文章 ——[Promise对象 3 种妙用](https://github.com/wsafight/personBlog/issues/13)。...