Attack on Life ⚔️

新年伊始,我也开始了麻烦的美签办理流程,从1月6号开始着手准备资料到1月15日拿到护照，过程还是很顺利的，这里记录下注意事项及坑，兴许能够帮到些人。

我这里是因公出差，所以算是商签，但最后拿到的签证是B1/B2的。

整体需要准备

必须要有

前端代码里对于逻辑判断是常量在前还是变量在前，个人一直没有定论。没有定论的结果就是没有标准，没有标准的结果就是程序代码中两种风格并存，个人觉得很不爽。于是就在网上搜索资料，偶然发现有个说法叫尤达表达式，似乎答案就在这块，于是就有了下文。

尤达表达式？

尤达表达式是计算机编程中的一种风格，其中表达式的两个部分与条件语句中的典型顺序相反。这种风格的命名，来源于星球大战的一个角色，绝地大师尤达（Yoda）。剧中，该角色喜欢以颠倒的语序说英语。比如“当九百岁你活到，看起来很好你将不”。  

例子

1
2
3
4
5
6
7

if ( $value == 42 ) { /* ... */ }
// Reads like: "If the value is equal to 42..."

// 尤达表达式
if ( 42 == $value ) { /* ... */ }
// Reads like: "If 42 equals the value..."

Package.json中有依赖和开发依赖，但这些依赖都统称为直接依赖，而我们依赖的包本身也可能再依赖一些包，那这些依赖的包版本是如何管理的呢，并且当我们项目直接依赖了A 1.x，而间接包依赖了A 2.x,最终我们是安装的1.x还是2.x呢？

答案

实际上，两个版本会并存,package.json中记录的是棵依赖树，对应node_modules下的存储也如此。

举个例子，项目中依赖了@types/react,而依赖的@types/react-router-dom间接依赖了`@types/react``

关于Unknown的详细具体介绍，文末推荐的文章已是最好，这里不再啰嗦。文章只说下两个类型的根本区别。

any是顶级类型，但弊端就是滥用这个类型，实际上就丧失了类型安全，unknown是为了弥补这个问题。

so。any类型安全为无，而unknown在具体使用时会很严格。

严格来说，这篇文章晚了一天，对19年的自己说声抱歉。

物理年龄改变不了，但奋斗的心依然炙热，毕竟这是自己所热衷的职业。

上半年

2月-6月，一直停留在做一个交付-企业级项目A，整个的技术栈是【React,Spring Boot，MongoDB等】。项目中我扮演的是个基本的开发，主力去做前端开发，但部分后端任务也会去做。

这个项目的挑战是：与N个系统的集成，协作。

Team在制定API时，有时很纠结要不要区分Put与Patch。既然纠结，那就搞明白。

图片源自这里

Put VS Patch

Put

当前项目中部分通用异常比如500，400希望全局统一处理，而部分的请求异常比如400，又希望具体的功能块个性化处理。这样就存在冲突，于是开始了解决之路

部分技术栈

背景

全局使用了Axios拦截器来实现，具体的请求代码，我们一般是在saga中进行的处理，所以个性化异常也会在这里。

项目代码中，大家人云亦云的使用takeEvery辅助函数,实际上大错特错，应该按需使用。Saga的官方文档确实写的很差，于是翻源码，做测试，对此理解的透彻了些，这里Mark一番。

辅助函数

takeEvery

官方介绍如下

最近升级前端某个包时，报以下错误。经过分析，最终fixed，这里Mark下

原因

查看具体报错意思是存在两个版本的React类型定义。

在React组件开发时，Props是不可以修改的。但Why?如何尽可能确保在实际开发中被修改呢？继续喵

React中关于Props解释

Whether you declare a component as a function or a class, it must never modify its own props.
React is pretty flexible but it has a single strict rule:
All React components must act like pure functions with respect to their props.

结论