夕水

一个记录react常见组件实现的代码段 https://eveningwater.github.io/code-segment-react/

> 感觉没有必要，直接在 useState 里判断就好了 > > ```tsx > useState((initialState === undefined || initialState === null) ? defaultState: initialState); > ``` 我认为还是有必要的，对于追求简单的人，只想定义好默认值，而不需要自己去写判断。

> 感觉没有必要，直接在 useState 里判断就好了 > > ```tsx > useState((initialState === undefined || initialState === null) ? defaultState: initialState); > ``` 我提供给开发者传默认值参数，他就不需要关心我内部的判断，直接使用就可以，也算是一个小技巧的提炼。

> 1、对于 `defaultState` 和 `initialState`，有一定的理解成本，看上去非常的类似... 不仔细看文档和 demo 的话，很难知道到底取哪个值 > > 2、如果初始状态就期望是 `null`，是不是得 `useDefault(null, null)` > > 3、通常情况下， `useState(value || defalutValue)` 就能满足要求，所以我觉得这个 hook 意义不大，先在自己的项目里使用吧 1.要用这个函数，那肯定也就要看文档描述。 2.这个并不适合默认状态为null的情况。 3. 这个相当于就是如果初始状态是null,就会采用传入的默认值作为默认状态，相当于有一个占位符。所以我才认为这个hook函数可以加入，也算是一个小技巧的提炼，如果期望默认值是null,那这个hook函数就失去了意义。当然我认为这里的默认状态值不应该允许传入null和undefined

就是我如果写邮件，可以写了邮件内容之后，在邮件内容后面插入我的签名，我的签名也是可以像修改富文本那样修改。如图所示: 

如果使用默认的菜单，title也是要修改的，避免不了产品经理的奇怪需求，比如你的默认全屏菜单，点击全屏，我可以将title换成"取消全屏"，英文状态下就是"Cancel Fullscreen",目前我的做法是定义两个类，然后注册两个自定义菜单去更换title，但是这样的代码显得很多余。 伪代码如下: `import { Boot, IButtonMenu } from '@wangeditor/editor' import { i18n } from 'react-i18n-next' // 定义菜单 class class MyButtonMenu implements IButtonMenu { // 菜单配置，参考“引用”菜单源码 title: i18n.language === "zh"...

如果默认菜单不能够提供自定义的功能，很多自定义场景下就需要自定义菜单，这显然用户体验不好。比如为了一个title我就自己去自定义实现全屏菜单的功能，而不使用默认提供的全屏菜单功能（这里是以全屏菜单为例，像其它诸如字体字号等等菜单也是同理），这显然是不合理的。我只是修改一些简单的UI，功能和默认菜单还是一致的，就因为无法自定义UI而选择自定义实现默认菜单覆盖掉原本的默认菜单，这显然不太合理。

还有就是，react版本的editor实例并没有提供setHtml方法的接口。

> > 1.工具栏菜单或者是自定义工具栏菜单自定义title的功能 > > 你自己扩展的菜单，肯定支持自定义 title 。但默认自带的菜单不支持自定义 title ，你有哪个菜单的 title 需要修改吗？可以列出来，我看看 （除了你说的“全屏”菜单之外） > > > 2.可以传递JSON数据结构的文本或者是提供将文本编译成slateNode的编译方法 > > 如果是纯文本，转换为 slate node 很简答，就 `{ text: 'xxx' }` 。如果不是纯文本，那应该就是 HTML 格式，直接...

> > 1.工具栏菜单或者是自定义工具栏菜单自定义title的功能 > > 你自己扩展的菜单，肯定支持自定义 title 。但默认自带的菜单不支持自定义 title ，你有哪个菜单的 title 需要修改吗？可以列出来，我看看 （除了你说的“全屏”菜单之外） > > > 2.可以传递JSON数据结构的文本或者是提供将文本编译成slateNode的编译方法 > > 如果是纯文本，转换为 slate node 很简答，就 `{ text: 'xxx' }` 。如果不是纯文本，那应该就是 HTML 格式，直接...