二叉树中的 路径 被定义为一条节点序列，序列中每对相邻节点之间都存在一条边。同一个节点在一条路径序列中 至多出现一次 。该路径 至少包含一个 节点，且不一定经过根节点。

今天我们看一道 leetcode hard 难度题目：编辑距离。题目给你两个单词 word1 和 word2， 请返回将 word1 转换成 word2 所使用的最少操作数。你可以对一个单词进行如下三种操作：插入一个字符删除一个字符替换一个字符示例1： {代码...} 思考看到题目的第一感觉是按照人的直觉做题，比如示例中 horse 与 ros 其中都有 os...

最近数据可视化领域开源了一套 VisActor 方案，虽然刚开源没多久，但产品矩阵已经颇有特色，我们可以从中学习一下数据可视化领域是如何设计顶层架构的，以及对未来 3-5 年可视化领域的发展规划。

恶魔们抓住了公主并将她关在了地下城 dungeon 的 右下角 。地下城是由 m x n 个房间组成的二维网格。我们英勇的骑士最初被安置在 左上角 的房间里，他必须穿过地下城并通过对抗恶魔来拯救公主。

给你一个字符串 s 、一个字符串 t 。返回 s 中涵盖 t 所有字符的最小子串。如果 s 中不存在涵盖 t 所有字符的子串，则返回空字符串 "" 。

今天我们看一道 leetcode hard 难度题目：统计可以被 K 整除的下标对数目。题目给你一个下标从 0 开始、长度为 n 的整数数组 nums 和一个整数 k ，返回满足下述条件的下标对 (i, j) 的数目：0 <= i < j <= n - 1 且nums[i] * nums[j] 能被 k 整除。示例 1： {代码...} 思考首先想到的是动态规划，一个长度为 n ...

今天我们看一道 leetcode hard 难度题目：通配符匹配。题目给你一个输入字符串 (s) 和一个字符模式 (p) ，请你实现一个支持 '?' 和 '*' 匹配规则的通配符匹配：'?' 可以匹配任何单个字符。'*' 可以匹配任意字符序列（包括空字符序列）。判定匹配成功的充要条件是：字符模式必须能够 完全匹配 输入字符串（而不是部分匹配...

本篇精读来自笔者代码实践，没有原文出处请谅解。自由布局吸附线的效果如下图所示：那么如何实现吸附线呢？我们先归纳一下吸附线的特征：正在拖动的 box 与其他 box 在水平或垂直位置距离接近时，会显示对齐线。当吸附作用产生时，鼠标在一定范围内移动都不会改变组件位置，这样鼠标对齐就产生了一定的容错性，用户不需...

让磁贴布局与自由布局混合实现，从效果来看就是让画布同时存在磁贴与自由布局两种布局状态的组件，并且可以随时切换。接下来我们分析实现该方案的技术要点。

接下来用实战来说明该可视化搭建框架是否好用，以下几条原则需要始终贯穿在下面每个实战场景中：复杂的业务场景，背后使用的框架 API 是简单的。底层 API 并不为业务场景特殊编写，而是具有很强的抽象性，很容易挖掘出其他业务场景的用法。所有场景都是基于有限的几条基础规则实现，即背后实现的复杂度不随着业务场景复...

其实声明式一定程度上可以说是牺牲了性能换来了可维护性，所以在一个完全声明式的框架下做性能优化还是非常有挑战的。我们采取了两种策略来优化性能，分别是自动批处理与冻结。

组件通过 <Canvas /> 渲染在画布上，内容完全由组件树 componentTree 驱动，但也有一些情况我们需要把某个组件实例渲染到组件树之外，比如全屏、置顶等场景，甚至有些时候我们要渲染一个不在组件树中的临时组件，却要拥有一系列画布能力。

等等，那么为什么要提到 langChain 与 vector dataBase？因为 PDF 文章内容太长了，直接传给 GPT 很容易超出 Token 限制，就算他允许无限制的 Token 传输，可能一个问题可能需要花费 10~100 美元，这个 成本 也是不可接受的。

由于 React 的特点，组件改变所在父级后会产生 Remount，而在可视化搭建场景存在两个特点：自由、磁贴、流式布局都可以通过拖拽轻松改变组件父元素。大数据量下组件 Remount 的消耗不容忽视。结合上面两个特点，拖拽过程中或者松手时不可避免会产生卡顿，这就是我们这篇文章要解决的问题。利用 createPortal 解决 Remoun...

组件值校验，即在组件值变化时判断是否满足校验逻辑，若不满足校验逻辑，可以拿到校验错误信息进行错误提示或其他逻辑处理。声明 valueValidator 可开启值校验： {代码...} 如上面的例子，相当于对组件值做了 “不能为 undefined 且最大值为 10” 的限制。可以内置 JSONSchema validate 的全部校验规则作为内置规则。支持...

虽然底层框架提供了通用的组件值与联动配置，可以建立对组件任意 props 的映射，但这只是一个能力，还不是协议。业务层是可以确定一个协议的，还要让这个协议具有拓展性。我们先从使用者角度设计 API，再看看如何根据已有的组件值与联动能力去实现。设计联动协议首先，不同的业务方会定义不同的联动协议，因此该联动协议...

组件联动是指几个组件相互关联。也就是当一个组件状态变化时，其他组件可以响应。组件联动是多对多关系的，且目的分为一次性与持续性：多对多关系：即一个组件可以同时被多个组件联动；多个组件可以同时联动一个组件。一次性与持续性：一次性事件可以被覆盖，持续性事件会同时生效，且要考虑叠加关系。一定程度上，持续...

可视化搭建会遇到如下三类容器组件：简单容器：以 children 容纳子组件的容器。卡片容器：以 props.header 加上 props.header 等多个插槽容纳子组件的容器。Tab 容器：以 props.tabPanel[x] 等动态数量插槽容纳子组件的容器。画布本身也是一个容器组件，所以可视化搭建离不开容器。另一方面，我们应该允许给组件 props ...

在设计好画布与组件数据流体系后，理论上主体功能已经完成，但缺乏方便易用的 API，所以还需要内置一些状态与方法。但是内置状态与方法必须寻求业务的最大公约数，极具抽象性，添加需慎重。接下来我们从必须有与建议有的角度，看看一个可视化搭建需要内置哪些 API。状态状态是可变的，引用方式有如下两种。第一种在任意 ...

接下来需要解决两个问题：可视化搭建的其他业务元素如何与画布交互。比如拓展属性配置面板、图层列表、拖拽添加组件、定位锚点、主题等等。runtimeProps 如何访问到当前组件实例的 props。这两个问题非常重要，而恰好又可以通过良好的数据流设计一次性解决，接下来让我们分别分析讨论一下。问题一：可视化搭建的其他业务...

接着可视化搭建的理论抽象，我们开始勾勒一个具体的 React 可视化搭建器。精读假如我们将可视化搭建整体定义为 <Designer>，那么 API 可能是这样的： {代码...} componentMetas: 定义组件元信息的数组。componentTree: 定义组件树结构。只要注册了组件元信息与组件树，可视化搭建的画布就可以渲染出来了，这很好理...

如果不抽象，当搭建项目做到后期可能会出现 API 杂乱，难以维护的问题；做到一半甚至会怀疑为什么需要一个搭建框架，怀疑把框架去掉会不会效率更高；在后期发现不能自然的水平拓展到仪表盘、大屏、表单搭建场景等。

试想，最朴素的判断组件碰撞方法是什么？一般会遍历画布所有的组件，根据当前组件位置与目标组件位置的相对位置判断是否产生碰撞，所以仅判断单个组件碰撞时，时间复杂度是 O(n)。

对布局抽象来说，它关心的就是 可拖拽的组件 与 容器 的 DOM，至于这些 DOM 是如何创建的都可以不用关心，在这个基础上，甚至可以再做一套搭建或者布局框架层，专门实现对 DOM 的管理，但这篇文章还是聚焦在布局的实现层。

因为需要做自由布局与磁贴布局混排，以及磁贴布局嵌套，所以要实现一套磁贴分析功能，所以本系列不是简单的介绍使用 react-grid-layout 这个库就行了，而是深入分析磁贴布局的特性，以及重头实现一遍。

现在许多国内互联网公司的项目都持续了五年左右，美国老牌公司如 IBM 的项目甚至持续维护了十五年，然而这些项目却有着截然不同的维护成本，有的公司项目运作几年后维护成本依然与初创期不大，可以保持较为高效的迭代速度，但有的项目甚至改几个文案都会导致线上事故，研发效率变得越来越慢。

原文很有有条理，先从 css-in-js 优点说起，再转而谈到缺点，说明了 css-in-js 这个新事物拥有明显的优点与缺点；然后从性能问题作为切入点，说明自己所在的公司为什么不得不抛弃 css-in-js；最后告诉读者目前自己的解决方案是 css-modules。

因为用 for ... of 循环数组非常方便，但如果仅数组才支持这个语法就太过于麻烦了，比如我们自然会希望 for ... of 可以遍历字符串的每个字符，希望 new Set([1, 2, 3]) 可以快速初始化一个新的 Set。

... 符号很形象的表示了把对象中所有属性拿出来平铺的含义。说到平铺，Spread 放在函数参数时，也表示将对象中每个 properties 拿出来作为平铺参数：

如上所示，如果 myLib 没有正确的开放 update 属性将会提示错误。但这种单测并不是我们要讲的类型。想一想，如果我们只开放 .update API 给用户，但框架内部可以使用全量的 .update、.add、.remove 方法，如何验证框架没有把不必要的属性也开放给了用户呢？