一、Overview Taro 是用 React 的方式来写小程序，拥有与 React 一致的 api，因此可通过相同的实现来同时满足多端的需求。现在正在构建一个可跨端使用的 Hooks 包，关键的问题在于如何处理包的依赖。 当在小程序中使用时，实际上是依赖了  @tarojs/taro，而在 web 中使用时需要依赖 React： // cross-use（Hooks 包的包名） function useMyHook() { return useState(); } // 业务方使用时 import { useMyHook

本文主要介绍一种基于 React Hooks 的状态共享方案，介绍其实现，并总结一下使用感受，目的是在状态管理方面提供多一种选择方式。 实现基于 React Hooks 的状态共享 React 组件间的状态共享，是一个老生常谈的问题，也有很多解决方案，例如 Redux、MobX 等。这些方案很专业，也经历了时间的考验，但私以为他们不太适合一些不算复杂的项目，反而会引入一些额外的复杂度。 实际上很多时候，我不想定义 mutation 和 action、我不想套一层 context，更不想写 connect 和

一些基础变动参考官方文档：https://react-native-community.github.io/upgrade-helper/?from=0.60.5&to=0.64.2 1、native相关的修改 iOS 系统最低支持版本：9.0->10.0 在0.60的版本，一些基础库是通过手动一个个添加到podfile里引入的，现在官方提供了脚本，只需要调用这个脚本就行了 use_react_native!( :path

git 的 subtree 是一种复用源代码的方式，可以让多个仓库引用某个仓库的代码，也可以将仓库中的某个目录拆分成一个子仓库以供其他仓库使用。 相较于 git 的 submodule，目前社区中多更推崇 subtree，自己在使用了一段时间后总体也是认为 subtree 会更好用一些。 但同时，两者都有各自的一些问题，而 subtree 的问题目前有其他方式规避，整体用起来比较流畅，所以最终选择了 subtree。 实际上 subtree 命令需要在某个版本的 git 之后才被支持，但目前 git 的常用版本是完全足够的，所以也没去深究过。 为什么？

Brendan Eich在设计JavaScript的时候是没有加入类型系统的，所以JavaScript是一门动态语言，类型是进入执行上下文的时候可能才去确定，这就可能出现一个JavaScript变量在上一瞬间是String，下一瞬间就是Number了，在这个过程中，JavaScript变量进行了类型的转换。使用Javascript进行相等运算时，我们可能会用==，===和Object.is来进行比较两个值是否相等。 使用===时,恒等，严格比较运算符，不做类型转换，类型不同就是不等，NaN与NaN不相等。 使用Object.is()时，其行为与"==="基本一致，不过有两处不同: +0不等于-0。 NaN等于自身。 使用时，不同类型的值也可以被看作相等。这可能会让很多的JavaScript困开发者感到困惑。使用&

越来越臃肿的web应用 随着Web应用变得越来越复杂，特别是像一些toB的web应用(例如财务软件，ERP等企业级软件)，传统的前后端REST架构交互方案在极大的限制了软件的开发效率，提高维护的成本，不仅是前端，后端的开发和维护成本也是越来越高。 对于REST架构来说，主要的问题是以下几点： 过度获取数据，例如，有的时候前端为了满足在web和移动端的业务需求，可能会在同一接口是获取相同的数据，但是有的数据在两端上并不是必须的。 前端业务数据可能要通过多个接口请求去获得，而想chrome这样的浏览器允许的请求的最大的并发数是六个，在一定程度上会有体验方面的问题。 有一些REST接口并不十分规范，比如一些查询接口的数据字段过多就会被定义成POST接口。 前端需要知道每个接口服务的地址，才能去获得对应的资源数据。 如果后端API发生了更改，那么可能会导致另外一个或者多个API奔溃，前端数据可能会受到破坏，哪怕只是一个简单的数据结构调整，这对于前端来说很可能是致命的，大概率会跟着调整。 当有新的功能需要开发时，后台需要去聚合多个微服务的数据提供给前端使用。 由于REST架构让前后端产生了一定的耦合，除了以上的技术问题之外，

在开始聊Webassembly(下文简称为wasm)之前，咱先了解一下为什么会出现wasm这个全新的web格式。这得从Javascript的诞生说起。 Javascript的诞生 在1994年的时候，网景公司成立，同年发布了Navigator浏览器0.9版本，这个浏览器只能用来浏览，不能和用户进行相关的交互。1995年，Brendan Eich进入网景公司，花了十天的时间研究出了Mocha，之后更名为LiveScript，最后因为网景公司想趁Java的热度才更名成Javascript。 Brendan Eich主要研究的方向是函数式编程，网景公司希望研究将Scheme语言作为网页脚本语言的可能性。Brendan Eich也认同这种想法。网景公司希望网页脚本语言要与Java足够相似，并且要比Java简单，要让非专业的开发者也能上手，然而，Brendan Eich对Java谈不上一点喜欢，所以他花了10天就设计出了JavaScript。 Javascript的弊端和改进之路 由于JavaScript最初只是为了简单的在浏览器上进行简单的交互，所以Brendan

原文地址：https://webfe.kujiale.com/electron-support-m1 酷家乐客户端：下载地址https://www.kujiale.com/activity/136 概述 目前存在两种架构芯片的 macbook，分别是 x86 和 arm 架构，对应了 Intel 芯片和 Apple M1 芯片。 旧版本酷家乐客户端，是通过 Rosetta 2 运行在 M1

之前做某个语音留言互动的需求时用到了浏览器录音相关功能，当时查了相关的资料，后续实际开发中也遇到了一些坑。 本次就web端实现语音录制的原理及一些踩坑记录做一个分享。 MediaRecorder MediaRecorder在原生app开发中，是一个应用广泛的api，用于在app内录制音频和视频。 随着web侧的应用越逐渐富媒体化，w3c也制定了相应的web标准，称为MediaRecorder API，它给我们的web页面赋予了录制音视频的能力，使得web可以脱离服务器、客户端的辅助，独立进行媒体流的录制。 该API由官方推出，对前端开发者友好，并且支持标准编码，直接返回媒体流数据，可以注入video/audio标签或者直接打包成文件。 基本API如下： MediaRecorder.start() 开始录制媒体 MediaRecorder.pause() 暂停媒体录制 MediaRecorder.resume() 继续录制之前被暂停的录制动作 MediaRecorder.

我们是干嘛的 酷家乐是目前全球最具创新体验的 VR 智能室内设计平台，国内最大的互联网家装公司之一，从 2011 年成立到现在，已经 D 轮融资，估值 6 亿美金，跟天猫、淘宝、小米等都有非常多的合作。 我们推崇硅谷氛围，在这里没有职位之分，每个人对自己负责，扁平化的氛围保证工程师的自由和创新。 小哥哥小姐姐们都在干点啥 酷家乐平台前端团队，负责酷家乐PC 门户、大家居 SaaS 平台以及桌面端等的开发，在这里你将与最优秀的小伙伴一起，与公司一同成长 业务：大家居 SaaS

学而时习之，不亦说乎？——孔丘《论语•学而》 单例模式的核心在于： 确保一个实例，并提供全局访问。 首先，单例模式要求只有一个实例，其次这个实例在全局都可以访问到。比如我在实习的时候写的这个页面： 点击邮件获取最新安装包的时候会弹出这个框框，很显然，这个框框只需要被创建一次即可，所以我们可以写下如下的代码： <button class="J-popup">btn</button> var popup = (function () { var div = document.

最近旁听了两场面试，有一些体会，简单地记录一下。 面试旁听其实是一件挺有趣的事，因为可以站在面试官和面试者之外的角度进行观察，进行自己的分析和判断。 对于像我这样既缺乏面试经验，又缺乏面试官经验的刚毕业没多久的“雏鹰”（哈哈，公司这么叫的）来说，这样面试旁听、观察学习，是一件非常有趣且有意义的事，以下是一些我旁听过程中的体会。 面试官篇 充分的准备 旁听前或者旁听过程中，面试官都会给我一份简历，我发现面试官在简历上都提前做了标记或是写下了问题。在旁听过程中，面试官一般会针对提前做好的标注进行提问。如果有不了解的内容，也会提前查阅一些资料。这让我意识到了作为面试官准备工作的重要性，因为只有你以专业的态度去面对面试者，才是对他最大的尊重。 这让我想起了我来到酷家乐时的面试官景天，我面试前准备其实并不充分，但是相反景天的准备是相当充分的，他把我简历上的 GitHub