关于前端:第五期前端九条bug分享-ts相关知识较多

本期

最近换了新工作终于凑齐一些乏味的bug与问题了, 比方在ts方面做了深刻的钻研, 国际化开发方面有了一些思考等等, 总之新的工作刚刚开始就播种满满, 有对'字节跳动'国际化业务感兴趣的同学能够把简历砸过来, 未来一起挑战各种乏味的难题。(当然除了国际化其它岗位我也能够内推的! )

小声说: 最近切实是好多事要忙, 像3d地球那个系列只能过段时间更新了...

1: url的编码操作

当咱们通过url来传递一些信息的时候, 可能会呈现一些读取的问题,咱们罕用encodeURI与encodeURIComponent进行编码后再进行传递, 然而我发现我的项目中所有中央都用encodeURIComponent, 为什么会这样这两种有什么区别?

因为encodeURI并不会对;/?:@&=+$,#之类的字符进行转移, 这就会导致某些非凡状况下解析uri呈现问题(后端应用的语言不同导致解析形式不同), encodeURIComponent会本义URI各个局部的标点符号比方罕用的连接符&与?, 也就是说它本义的更彻底安全性更高, 所以倡议尽可能应用encodeURIComponent来解决。

2: 国际化我的项目左右翻转(前端 RTL 适配)

来到国际化前端团队才学习到, 从左往右写的为"LTR", 从右往左写的为"RTL", 比方'希伯来语'、'阿拉伯语'等,如果你的公司要开发一款app提供给多个国家应用, 那就要思考到有的国家书写文字是从右往左的, 并且很多图片也要从右往左展现, 比方把返回按钮放在右上方!

咱们要做的就是文字书写的翻转、输入框的翻转、图标的本身翻转以及地位的镜像、然而某些图标不必反转比方 "时钟" 亦或者 30%不必反转为%03, 当然这些头疼的问题也是有成熟的解决方案的。

第一种: `dir="rtl"`属性设置

为body元素加上属性dir="rtl", 浏览器就能够主动翻转了, 没试过的快试试很好玩的。

毛病也很显著, 就比方咱们的css属性margin: left; 依然是作用于右边。

第二种: `rtlcss`

rtlcss的官网, 他的实现思路就是配合rtl属性应用, 将页面上的left相干属性都转为right属性, 核心思想就是某些属性的全局替换。

3: 后端int64类型出错

公司外部有一个库能够把后端的rpc接口标准间接转成ts标准供前端应用, 然而忽然有一天呈现了类型谬误, 比方后端规定返回参数为code数字类型, msg为字符串类型, 那么就会生成如下文件:

export type XxxxApi = {   code: number;   msg: string;}

然而一天夜里后端返回的code对应的类型居然变成了string, 我和共事查看了后端同学的代码, 定义的也确实是int类型, 但不过不是int32而是int64, 原来是因为js的数字的极限是2的53次方:

所以才采纳string的形式来表白int64这个数据类型, 后端同学将类型改为int32就没问题了, 当然啦后端同学擅自改类型不告诉咱们要提出批评。

4: 开发时候款式好好的, 打包后就出问题了

* bug 场景
明明开发时候好好的, 但为什么打包之后就会呈现各种谬误, 比方款式失落, 这里说下起因之一:

很久之前的某天我把开发好的前端我的项目代码公布到了服务器上, 在我本地拜访时款式很完满, 然而当我通过测试环境url关上这个我的项目的时候, 居然表格款式有些崩坏宽高与我本地的不一样, 然而我没有想明确bug的起因, 就去与 '同学a' 交换为什么呈现这种景象。

'同学a' 说是因为用户的浏览器和我不一样导致的, 可是我就是用户, 开发就在我的浏览器上也是我用浏览器拜访的测试环境, 然而是同一个浏览器, 但'a同学'保持说不可能产生这种情况, 我就给他演示了一遍从开发到公布到测试环境的全流程, 看到bug的确再次出现的他说是我'人品'的问题.... (起初是通过改了一些css的写法解决的)

我对这个事件印象还是比拟粗浅的, 但在往年的某一天, 我在配置webpack的时候忽然发现了一个问题点, 比方postcss在配置的时候会有一个设置, 在development与production两种模式下别离兼容到支流浏览器什么版本, 那这里其实就很可能是问题所在, 因为针对开发与打包进行了不同的翻译, 这就会导致无奈预期的谬误产生, 尽管曾经不在那家公司了当年的代码曾经找不到了, 但想到这点还是会很强烈的感觉到之前毫无脉络的问题有了一个解决方向!

5: pc端唤起WhatsApp & Email 为何生效

URL Schema

要想学习唤起app就要先晓得Schema是什么, 我艰深点讲一下, 就是你下载到零碎里的每个app其实都能够注册一个属于它的url地址, 这个地址你能够了解为就是Schema。

而咱们唤起某个app就能够利用这个"Schema 地址"。

调起WhatsApp

假如联系人的电话号码为 18200000000, 并且为中国的号码区号为(86)

- window.open("https://wa.me/8618200000000")  会闪屏- 或- window.open("https://api.whatsapp.com/send/?phone=8618200000000")

不倡议用window.location.href的形式跳转, 他会导致闪屏。

pc端为何无奈通过给定的WhatsApp号码唤起WhatsApp?

因为WhatsApp属于国内软件它要兼容辨别各个国家, 所以要加上国家的区号。
当然这个网址有时候不稳固也会导致加载不进去。

什么是 mailto

mailto是一种相似http的url协定, 但它属于本地协定(本地协定比拟典型的还有file), 也就是不须要连贯网络就能够解析的协定, mailto的性能是唤起默认邮箱。

唤起Email

假如联系人的邮箱号码为 xxx@qqqqq.com

指定收件人- window.location.href="mailto: xxx@qqqqq.com"如果为多集体发邮件则 ',' 宰割- window.location.href="mailto: xxx1@qqqqq.com, xxx2@qqqqq.com"如果要增加主题, 减少subject参数- window.location.href=`mailto: xxx@qqqqq.com?subject=${encodeURIComponent("我是主题xxx")}`如果要增加主题, 减少body参数- window.location.href=`mailto: xxx@qqqqq.com?subject=${encodeURIComponent("我是主题xxx")}&body=${encodeURIComponent('我是内容xxx')}`

6: React.FC

经常出现React.Fc这个函数, 比方我不应用React.Fc来解决组件的函数, 则在组件外面应用props.children会报错, 咱们一起进入源码剖析一下。

    type FC<P = {}> = FunctionComponent<P>;    interface FunctionComponent<P = {}> {        // 第一句        (props: PropsWithChildren<P>, context?: any): ReactElement<any, any> | null;        propTypes?: WeakValidationMap<P> | undefined;        contextTypes?: ValidationMap<any> | undefined;        defaultProps?: Partial<P> | undefined;        displayName?: string | undefined;    }

FC这个type接管一个参数P, 默认值为空对象, 而这个P。
FunctionComponent就是个适度的名称而已, 能够认为FC就是FunctionComponent。
第一句意义为第一个参数为PropsWithChildren<P>类型, 第二个参数可有可无, 有则为任意类型, 返回React的dom或者返回null。
前面四个参数不是必填, 咱们次要钻研第一句。

咱们追究一下PropsWithChildren

    type PropsWithChildren<P> = P & { children?: ReactNode | undefined };

只是将传入的P的类型与{ children?: ReactNode | undefined }合并而已, 看到这里咱们就明确了, 其实用React.FC包裹一下是能够帮忙ts推导出props身上可能有children属性。

7: RematchRootState

rematch官网;

rematch是对Redux的二次封装, 而RematchRootState是rematch导出的一个ts推导函数, RematchRootState到底做了什么令程序员脱发的操作...

我的项目里应用了这个RematchRootState之后, 发现某些类型推导进去never类型如图所示:

一起摸索源码里的奥义

export type RematchRootState<M> = ExtractRematchStateFromModels<M>export type ExtractRematchStateFromModels<M> = {    [modelKey in keyof M]: M[modelKey] extends ModelConfig ? M[modelKey]['state'] : never}

在应用RematchRootState时咱们应用typeof的模式导出了一个ts类型, typeof在ts外面应用就不是js外面的意义了:
```
Xxx<typeof {name:'金毛', age:9}>// 此处就相当于:Xxx<typeof {name:string, age:number}>
```
[modelKey in keyof M]循环M对象外面所有的key值, 每次循环时命名为modelKey。
M[modelKey]就是取出对应的值, 这里特指ts外面的类型值。
M[modelKey] extends ModelConfig ? M[modelKey]['state'] : never, 也就是每次取出'值', 并且此'值'合乎ModelConfig类型的话则返回M[modelKey]['state']的类型, 否则返回never, 这里的extends你能够了解为is用来判断某个值是不是符合规范的, 当前文章还会波及extends的其余用法。

至此咱们曾经明确了, 问题肯定出在M[modelKey]的类型未合乎 ModelConfig的类型标准导致的返回的never, 那ModelConfig又是什么标准那?

export interface ModelConfig<S = any, SS = S, K extends string = string> {    name?: string    state: S    baseReducer?: (state: SS, action: Action) => SS    reducers?: ModelReducers<S>    effects?:        | ModelEffects<any>        | (<M extends Models<K> | void = void>(dispatch: RematchDispatch<M>) => ModelEffects<any>)}

因为调用ModelConfig时什么参数都没传, 则应用默认值。
当name属性咱们赋予了number类型时会导致谬误。
state 对应的S类型, 也就是默认的any任何类型都能够。
baseReducer的参数不符合规范, 或是返回值不符合规范时。

`effects` 要独自拿出来讲

第一个: effects = ModelEffects<any>

type ModelEffects<S> = {    [key: string]: ( this: { [key: string]: (payload?: any, meta?: any) => Action<any, any> },payload: any,rootState: S) => void}export type Action<P = any, M = any> = {    type: string,    payload?: P,    meta?: M,}

[key: string]这种写法意思就是取出外面所有的项进行循环。
ModelEffects每一项都为函数, 并且没有返回值。
ModelEffects对象的每个函数的第一个参数为一个对象, 这个对象外面值都为函数, 并且返回值为Action<any, any>。
ModelEffects对象的每个函数的第二个参数为任意类型。
ModelEffects对象的每个函数的第三个参数为rootState: S S类型, S则是咱们上一步传入进来的, 也就是any。

第二个:

effects = (<M extends Models<K> | void = void>(dispatch: RematchDispatch<M>) => ModelEffects<any>)

M是新定义的一个泛型, 它合乎Models<K>的标准, 如果不合乎的话就为void类型。
这个K就是下面默认的string (写到这里我都感觉好麻烦)。

这里是Models的类型:

export type Models<K extends string = string> = {    [key in K]: ModelConfig}

每项都是ModelConfig, 而ModelConfig咱们下面曾经讲过啦。

这个函数接管的第一个参数dispatch要合乎类型RematchDispatch<M>, 这里就不再扩大了, 往下还有特地深:

export type RematchDispatch<M = void> =  ExtractRematchDispatchersFromModels<M> &    (RematchDispatcher | RematchDispatcherAsync) &    (Redux.Dispatch<any>)

能够看进去, 这个参数的类型咱们用Redux.Dispatch<any>来定义就没问题的。

返回值必须为: ModelEffects<any>这个咱们方才也讲过了。

正确的用法能够是如下的样子:

  effects: (dispatch: Redux.Dispatch) => ({    async FnXxx(_: any, state: RootState) {      console.log(state.xxx.xxxList)    },  }),

总结一句话就是"读这代码善意累"!

8: ts 批改函数参数

实现: 减少函数一个参数

假如以后我有这样一个type:

  type Obj = {    getX: (a: string, c: boolean) => void;    getN: (a: number) => void;  };

而我心愿将这个type解决成上面这个样子:

  type Obj = {    getX: (s: string[], a: string, c: boolean) => void;    getN: (s: string[], a: number) => void;  };

这里的关键点就是取到函数返回值的类型, 以及函数参数的类型汇合, 实现代码如下:

  type Obj2<T> = {    [Key in keyof T]: T[Key] extends (...arg: any) => any      ?(s: string[], ...arg: Parameters<T[Key]>) => ReturnType<T[Key]>      : T[Key];  };

循环泛型T外面所有的值。
如果T[Key]不满足(...arg: any) => any则不解决, 因为T[Key]可能不是函数类型。
反之T[Key]为函数类型, 则第一个参数为s: string[]。
...arg为后续参数类型, Parameters<>为自带办法, 能够推导出函数的所有参数组成的数组的类型。
ReturnType<>为自带办法, 能够推导出函数的返回值的类型。

应用办法就是:

type NewObj = Obj2<Obj1>

实现: 去掉函数第一个参数

假如以后我有这样一个type:

  type Obj = {    getX: (a: string, c: boolean) => void;    getN: (a: number) => void;  };

而我心愿将这个type解决成上面这个样子:

  type Obj = {    getX: (c: boolean) => void;    getN: () => void;  };

这里的关键点就是, 在ts里如何剔除数组的第一个元素, 并应用剩下的元素组成数组返回进去:

  type Obj2<T> = {    [Key in keyof T]: T[Key] extends (s: any, ...arg: infer Arg) => any      ? (...arg: Arg) => ReturnType<T[Key]>      : T[Key];  };

这里整体的逻辑是不变的, 与下面一个原理。
(s: any, ...arg: infer Arg) => any, 这里是外围, 将函数解决第一个参数以外的参数独自拿进去命名为Arg, 而后应用Arg来定义函数的参数。
infer是ts内置的关键字, 有点相似js中的var, 他能够定义一个变量。