lhyt

Results 63 issues of lhyt

# 0. 前言 身为前端,打交道最多的就是浏览器和node了,也是我们必须熟悉的。接下来我们讲一下浏览器工作原理和工作过程。从url到页面的过程,......,我们直接来到收到服务器返回内容部分开始。 先上很多人都见过的一幅图: ![image](https://user-images.githubusercontent.com/33994612/40577767-469f7530-613d-11e8-81bd-d7c8e3fa367a.png) 还有一幅图: ![image](https://user-images.githubusercontent.com/33994612/40578871-a82d66c0-614e-11e8-945d-096a3358f927.png) 浏览器主要组成部分: - 浏览器引擎:在用户界面和呈现引擎之间传送指令。 - 渲染引擎:负责显示请求的内容。如果请求的内容是 HTML,它就负责解析 HTML 和 CSS 内容,并将解析后的内容显示在屏幕上。 - 网络:用于网络调用,比如 HTTP 请求。其接口与平台无关,并为所有平台提供底层实现。 - JavaScript 解释器:用于解析和执行 JavaScript 代码。 - 数据存储:浏览器需要在硬盘上保存各种数据,例如 Cookie、storage、indexdb。...

> 平时做的需求,都是前后端联调,可能有时候多一个客户端联调。但还有一些需求,需要前端与前端联调——iframe内嵌,一些很复杂的页面可能会选择直接内嵌、还有现在很火的微前端其中一种实现方式也是iframe,最后页面也基本少不了两个前端页面的通信了。前端和前端联调的时候,比起和后端联调的时候,需要做的更多。因为前端和前端联调不仅是数据层面上,还有页面状态的信息传递。下面我们来探讨一套前端联调通信的方案 # 技术选择 1. hashchange事件 页面监听hashchange事件,然后父页面改变哈希,子页面读取哈希来实现通信。但是这有一个问题,如果传递的信息过多,那就会导致url很长,而且维护起来也麻烦。更严重的问题是,如果页面本身有利用哈希的逻辑,将会无解 2. storage 虽然可以解决,但导致storage数据冗余,而且还需要及时清除多余数据。一般情况下不用,更适合多个tab通信 2. postmessage 这个应该是最稳定的方案,也不会带来额外的副作用,也不用担心数据量多少。加上一些鉴权校验逻辑,就比较完善了 # 设计思路 我们选择postmessage方案,那么需要考虑的设计思路有: 1. 需要鉴权,否则有安全性问题(host校验、data 传入一些flag来校验) 2. 使用的时候,像request http请求一样的无差别体验,只是底层换成前端通信 3. 支持promise的调用方式 4. 支持参数和数据的预处理、后处理 5. 容易扩展 # 实现细节...

> 如果觉得没有面试题,那么lodash每一个方法就可以当作一个题目,可以看着效果反过来实现,以不同的方法实现、多种方法实现,巩固基础。除了某些一瞬间就可以实现的函数,下面抽取部分函数作为试炼。时代在进步,下文所有的解法都采用es2015+ 本文实现方法都是看效果倒推实现方法,并进行一些拓展和思考,和源码无关。lodash这个库在这里更像一个题库,给我们刷题的 能收获什么: - 修炼代码基本功,了解常见的套路 - 了解到一些操作的英文命名和规范 - 积累经验,面对复杂逻辑问题可以迅速解决 - 也许可以查到自己的js基础知识的漏洞 注意: - 三星难度以上的会具体拓展和讲解 - 文中使用的基本都是数组原生api以及es6+函数式编程,代码简洁且过程清晰 - 如果说性能当然是命令式好,实现起来稍微麻烦一些而且比较枯燥无味 - 时代在进步,人生苦短,我选择语法糖和api。面临大数据的性能瓶颈,才是考虑命令式编程的时候 > 还是老生常谈的深浅拷贝,但是我们这次彻底探究一遍各种对象的拷贝以及补回一些js冷门知识 # clone & cloneDeep(不考虑不常用对象) lodash除了常用的数据类型拷贝外,还会对各种奇怪对象进行拷贝。在实现lodash的之前,我们先实现一个正常的满足大部分场景的拷贝: ## 浅拷贝...

> 面对过多的if-else,代码可能看起来比较冗余,搞不好又是一张被人到处转发的“我们项目几百几千行if”的图。但是经过各种设计模式和封装,if大大减少,但可读性可能稍微降低了,而且比较抽象。那我们应该如何取舍呢 抛开其他因素,如果if-else过多,可读性也许会好也可能会降低,可维护性也是或高或低;如果if-else少,代码高度抽象,可读性会低或者不变,可维护性可能会高也可能会低。这里大概可能会有几种情况 # if平铺条件单一 这种情况,if精简不精简,可读性是不会变的,但是精简程度和可维护性是正相关的。至于为什么,看一下代码就可以感受到了 ![](https://user-gold-cdn.xitu.io/2020/4/2/17136c70f73ccfd0?w=958&h=722&f=png&s=47250) ## 执行语句单一 ```js if (a === 1) { console.log('this is 1') } else if (a === 2) { console.log('this is 2') } else...

![](https://user-gold-cdn.xitu.io/2020/1/31/16ff94ff5dda508a?w=2144&h=964&f=png&s=150260) > 对于webpack,一切皆模块。因此,无论什么文件,都需要转换成js可识别模块。你可以理解为,无论什么后缀的文件,都当作js来使用(即使是img、ppt、txt文件等等)。但是直接当作js使用肯定是不行的,需转换为一种能被js理解的方式才能当作js模块来使用——这个转换的过程由webpack的loader来处理。一个webpack loader 是一个导出为函数的 js 模块。webpack内部的`loader runner`会调用这个函数,然后把上一个 loader 产生的结果或者资源文件传入进去,然后返回处理后的结果 下面会从基本使用开始出发,探究一个loader怎么写,并实现`raw-loader`、`json-loader`、`url-loader`、`bundle-loader` **准备工作: 先安装`webpack`、`webpack-cli`、`webpack-dev-server`,后面的实践用到什么再装什么** # loader使用 1. 常规方法:webpack.config里面配置rules ```js module.exports = { module: { rules: [ { test: /\.js$/, // 匹配规则...

# 前言 我们如果使用过ppt、keynote,元素的小控件一定少不了,可以实现修改修改宽高和位移,大概是这样 ![](https://user-gold-cdn.xitu.io/2020/1/8/16f80f0cc0dbba0c?w=636&h=426&f=png&s=264227) ![](https://user-gold-cdn.xitu.io/2020/1/8/16f81180d81460ec?w=1604&h=496&f=png&s=32223) 最终效果预览: ![](https://user-gold-cdn.xitu.io/2020/1/9/16f85ed17c87a16d?w=640&h=400&f=gif&s=211958) 下面,我们从0开始,使用原生js实现这个效果,并封装成插件 # 过程分析 - 一个元素正常展示。点击的时候,会多出边框,边框的角落会有拖拽修改宽高的控件,控件位置、大小和元素一模一样 - 点击某个角落的拖拽控件,以该控件的的中心对称点为中心点,变更宽高。新的width = 旧的width + 控件x坐标变化量(可正可负),height也是 ![](https://user-gold-cdn.xitu.io/2020/1/8/16f81256e2d4b5bc?w=1274&h=490&f=png&s=81389) - 点击非某个角落的拖拽控件的拖拽控件,拖拽整个元素,此时`cursor`为`all-scroll` - 点击其他地方,控件消失,元素变成原本样子 ![](https://user-gold-cdn.xitu.io/2020/1/8/16f8129e8bfed46a?w=1298&h=444&f=png&s=156367) - 代码复用:多处涉及到拖拽,拖拽需要抽取出来做公共方法 # 实现一个拖拽 > ❌...

# 前言 AOP(面向切面编程)针对业务中的一些关键点/关键时刻所做的事情(即切面)进行抽离,抽离的是代码执行的过程中的某个关键步骤。简单来说,AOP关注的是什么时间点下的什么行为/定义。 # 快速了解AOP和OOP区别 OOP(面向对象编程)对于前端er应该都很熟悉了,我们下面举个例子来对比一下AOP和OOP ## OOP 假设我们有一个“车🚗”的类: ```js class Car { constructor({ name, door, material, accelaration }) { Object.assign(this, { name, door, material, accelaration }) } // 起步...

> 平时前端都是和后台联调,或者在内嵌webview的客户端上和客户端联调,前端和前端联调是什么鬼?其实也是存在的,比如另一个前端写了一个庞大的模块(如游戏、在线ide、可视化编辑页面等需要沙盒环境的情况),此时引进来需要使用iframe来使用。在一个大需求里面,按照模块化分工的话,显然iframe里面的功能由一个人负责,主页面由另一个人负责。不同的人负责的东西同时展示在页面上交互,那么两个前端开发的过程中必然有联调的过程 # 传统方式——iframe的postmessage通信 背景:父页面里面有一个iframe,src为子页面 ```js // 父页面的js document.querySelector("iframe").onload = () => { window.frames[0].postMessage("data from parent", "*"); }; // 子页面的js window.addEventListener( "message", e => { console.log(e); // e是事件对象,e.data即是父页面发送的message }, false...

# 前言 > **今天(12月13日)是国家公祭日🕯️🙏** 今天打开b站,看见一片灰色。 ![](https://user-gold-cdn.xitu.io/2019/12/13/16effabfab3e6ad5?w=2016&h=1254&f=png&s=1566217) 首先,职业下意识就打开了控制台。为什么呢?是想看看怎么实现的,是css自定义属性吗?是引入一份css吗?是预处理器修改全局变量吗?结果,打开控制台,浏览了一下,最后定位发现在于一行css代码,关掉就变成彩色了 ```css filter: grayscale(100%); ``` 于是乎,我们马上来看看filter这个滤镜效果具体还有什么值可选 # 效果预览 赶紧的,写个脚本遍历所有的属性,并都看看效果: ```js const url = "https://www.baidu.com/img/[email protected]"; let html = ""; [ { name: "灰度100%", style: "grayscale(100%)"...

> [【两数相加】——leetcode原题链接](https://leetcode-cn.com/problems/add-two-numbers/) # 前言 题目描述: 给出两个 非空 的链表用来表示两个非负的整数。其中,它们各自的位数是按照`逆序`的方式存储的,并且它们的每个节点只能存储`一位`数字。 如果,我们将这两个数相加起来,则会返回一个新的链表来表示它们的和。 您可以假设除了数字 0 之外,这两个数都不会以 0 开头。 示例: > 输入:(2 -> 4 -> 3) + (5 -> 6 -> 4) 输出:7 -> 0...