Posts

问题现象 ​ 本文以 Windows 系统为例进行说明。 ​ 在更换网络环境后，在个人电脑上使用 git push 命令推动代码至 Github 报错。 ssh: connect to host github.com port 22: Connection refused fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. 排查过程 ​ 报错提示的是连接 github.com 的 22 端口被拒绝了。遂使用浏览器访问 github.com，确实无法访问，开梯子后网页访问正常，但 git push 依旧失败。 使用 Github 的 443 端口 ​ 网上搜索后发现可能是 22 端口被防火墙屏蔽了，可以尝试连接 Github 的 443 端口。 ​ 命令 ssh -T git@github.com 可以检测和 Github 的网络通信是否正常，执行后报错 连接超时。...

问题描述： 前端仓库的 CI Runner 并行处理两个 job 有概率出现报错内容缺失或出包内容错误。 问题分析： ​ Gitlab 官方称：当只有一个 runner 在运行并且每个[[runner]] section 都有独立的 build 路径，concurrent 是生效的。若有多个 runner 使用同个 config.toml 文件或共享同个 build 路径，即使设置了 concurrent 为 1，也还是会有概率出现一个 runner 并发处理多个 job 的问题，官方认为这是用户的错误配置。config.toml 文件允许存在多个[[runner]] section，但这个 bug 会导致 concurrent 失效。 ​ 根据上次 ci runner 出现打包内容错误的问题推测是当时 config.toml 配置上的失误，即多个 runner 使用同个 config.toml 文件并且没有指定 build_dir（默认对应于宿主机的目录是在宿主机 的 docker volume )，因此有概率出现一个 runner 同时处理两个 job 的情况(curcurrent 设置为 1)，再加上一个 runner 映射一个 volume，从 gitlab 上拉下的源代码都存储在同个 volume，后拉的替换先拉的，最终导致必有一个 job 打出的包有问题含有其他分支的内容或直接报错编译失败。 ​ Branch_3.5.3 出的 sp4 包内容含其他分支的内容也就同样能解释通了，从下图中可以看出两次 job 先后执行并且持续了一段时间，但使用的是同一台 runner、同一个 volume，由于 Branch_3....

设计模式是针对软件设计中反复出现的问题所提出的通用解决方案。它们是在大量实际软件开发经验中总结出的优秀设计实践，描述了在特定场景下解决问题的方法和思路。设计模式旨在提高代码的可复用性、可扩展性和可维护性，使软件具有更好的灵活性和稳定性。因此学习设计模式对于个人代码水平提升十分重要。 以下为模式学习笔记汇总： Vanilla 篇 Command pattern 命令模式 命令模式是将方法（命令）从执行操作的对象中解耦，可以到特定时间或特定生命周期再执行命令。 Factory pattern 工厂模式 工厂模式是函数不通过使用 new 关键字来返回一个新对象。 Mediator/middleware pattern 中间件模式 中间件模式使得组件可以通过一个中心点（中介者）相互交互。中间件接收请求并将其转发，使我们能够轻松简化对象之间的多对多关系。 Observer pattern 观察者模式 通过观察者模式，可以将某些对象（observers观察者）订阅到另一个的对象（observable可观察对象)。每当事件发生时，可观察者都会通知其所有观察者。 Minin pattern 混合模式 Mixins 允许我们通过将功能注入到对象的原型中，轻松地向对象添加功能，而无需继承。（不推荐使用） Singleton pattern 单例模式 实现单例模式是实现只能实例化一次并可以全局访问的类。 Prototype pattern 原型模式 原型模式是通过原型链继承的方式使得相同类型的的对象之间共享属性。 Module Pattern 模块模式 通过 ES Module 来防止名称冲突和全局范围污染。导出用 export，导入用 import module from path 。 Provider Pattern 提供者模式 Provider 模式无需通过手动给每个组件层传递数据，使得将数据传递到许多组件。

箭头函数不绑定 arguments，可以使用 ...args 代替 箭头函数没有 prototype 属性，不能进行 new 实例化 箭头函数不能通过 call、apply 等绑定 this，因为箭头函数底层是使用bind永久绑定this了，bind绑定过的this不能修改 箭头函数的this指向创建时父级的this 箭头函数不能使用yield关键字，不能作为Generator函数 const fn1 = () => { // 箭头函数中没有arguments console.log("arguments", arguments); }; fn1(100, 300); const fn2 = () => { // 这里的this指向window，箭头函数的this指向创建时父级的this console.log("this", this); }; // 箭头函数不能修改this fn2.call({ x: 100 }); const obj = { name: "poetry", getName2() { // 这里的this指向obj return () => { // 这里的this指向obj return this.name; }; }, getName: () => { // 1、不适用箭头函数的场景1：对象方法 // 这里不能使用箭头函数，否则箭头函数指向window return this....

在某些情况下，我们希望为应用程序中的许多（如果不是全部）组件提供可用数据。尽管可以使用 props 将数据传递给组件，但如果应用程序中几乎所有组件都需要访问 props 的值，那么这可能很难做到。 我们经常会遇到一种称为“ prop drilling”的情况，将props传递到组件树的深处时，就会出现这种情况。重构依赖于 props 的代码几乎是不可能的，并且知道某些数据来自哪里也很困难。 假设有一个包含某些 data 的 App 组件。在组件树的最深处，有一个 ListItem 、 Header 和 Text 组件，它们都需要来自 App 的data。为了将这些数据传递给这些组件，必须将其传递给多层组件。 function App() { const data = { ... } return ( <div> <SideBar data={data} /> <Content data={data} /> </div> ) } const SideBar = ({ data }) => <List data={data} /> const List = ({ data }) => <ListItem data={data} /> const ListItem = ({ data }) => <span>{data....