hook似乎不应该返回一个组件

[ant-design]

hook似乎不应该返回一个组件

[yesmeck]

hooks 的一个重大作用就是能把逻辑从组件里剥离出来，现在又混在一起了第一感觉也是反模式。

我自己目前实践下来更倾向于这种写法：

import { Table, SearchForm, useList } from './List';

export default () => {
  const [searchForm, list] = useList();

  return (
    <>
      <SearchForm {...searchForm} />
      <Table {...list} />
    </>
  )
}

[twisger]

这个是有方法的，不会动态生成新的组件。

通过缓存之类的方法大概可以保证hook函数返回的组件类是同一个类，但我觉得类似的方式都比较hack，就像是在render函数里调用setState然后又在shouldComponentUpdate里做优化一样，有种自己给自己挖个坑又想办法填上的感觉，填的不好的话可能还会有其他的问题。
我主要想表达的其实是这种使用hook的方式属于对hook的"滥用"。
当然，这只是我个人观点。

[JIACHENG9]

新的方式是采用 #7 ，分为 @sunflower-antd 跟 @sunflower-hooks。@sunflower-hooks 就是不带 HOC 的 react hooks，也方便测试。@sunflower-antd 是让使用能方便使用的带有 HOC 的，基于 antd 组件的。

hooks 返回一个组件只是让了让开发者更方便。

“每次render的时候使用的都是不同的组件”

这个是有解的。还没有去为性能做优化。

$ yarn
$ yarn bootstrap
$ yarn dev

看看是否报错呢

[twisger]

报错是我这边环境的问题，已经解决了。
不过我觉得即使能通过一些手段优化性能，这种在render函数中动态生成新的组件的用法也是不正确的。hook在官方文档中的说明是重用状态逻辑的机制, 和HOC混在一起用并不合适。
@sunflower-hooks的话我没找到相关代码，但我估计单纯的hook用起来可能并不方便。

[JIACHENG9]

@sunflower-hooks 在 #7

单纯的hook用起来可能并不方便

嗯，之前的方式就是这样的，但是不是很方便。才会用这个方式。

这种在render函数中动态生成新的组件的用法也是不正确的

这个是有方法的，不会动态生成新的组件。

[blizzardzheng]

这里其实就是把业务受控组件概念和hook一起结合使用，API 对用户而言最友好，不需要再去感知一些 数据和ui的bind过程。至于动态生成新组件，可以通过条件记忆的方法尝试解决，让行为 make senese

[blizzardzheng]

@twisger react 的 hooks 本质也是在 function component 里做了记忆化，只是官方表达这个概念的时候用了 重用状态逻辑的机制，但是作为业务使用上希望沿用这个**做 useComponents 的实践的创新，毕竟这么写起来很舒服。当然这个点也可以在 facebook hooks 相关 issue 和社区讨论。react 目前也比较鼓励在 function component 里去做函数hook，只不过官方提供了这些 hook，我们应该结合自己的实践也可以有自己的hook机制，函数组件其实也可以理解成一种特殊的“状态渲染逻辑”

[JIACHENG9]

更新了代码，应该也没有很 hack。

[twisger]

@JIACHENG9
看了一下新的实现，返回的组件的确不再变化了。
但尝试模拟了一下 defaultPageSize发生变化的情况，返回的组件仍然未发生变化，这种情况应该是不正确的。
但如果将将相关参数加入useCallback的依赖列表里的话，useCallback似乎就白用了，因为相关参数在组件每次render时都会重新生成。

[JIACHENG9]

defaultPageSize发生变化的情况，返回的组件仍然未发生变化

这个就是这样设计的。defaultPageSize 只有在初始化有用，修改了没用。要是修改了有用，就应该为 pageSize。

[twisger]

defaultPageSize只是举例，考虑一下search函数发生发生变化的情况。比如search: (values) => request(values, 1)和search: (values) => request(values, 2)。现在的实现会导致组件使用的永远是第一次调用useSearchResult时传入的参数。

[JIACHENG9]

search 跟 defaultPageSize 都设计为初始传入的，你想外层动态去修改一个 search 方法？在这里 search 就是传入的使用方法，要做不同的处理是在search 里而不是外层传入不同的方法。

你可举例具体应用场景跟码说明问题。

[yesmeck]

确实会有问题，现在返回的组件相当于是一个非受控组件，defaultPageSize 这些相当于默认值，这样目前看来是没什么问题。但是，作为一个通用组件，肯定是要能受控的，后面如果要支持受控，就要增加 pageSize 这样可变的属性，这样属性一变，就必须返回一个新的组件了。

[JIACHENG9]

这里有两个维度，一个是设计，一个是怎么做受控。

设计层面，使用 useFormTable(config)，这里的 config 设计上为初始配置，比如之前说到的 search，不会去使用 config.search = value，之后修改 value 这里让修改，可理解为都是 defaultValue。在这里去做受控会让使用复杂。这个是设计层面。

另外个层面是怎么在 config 里传入受控的value，比如 pageSize。只需要加到 store 里即可，也没有复杂跟 hack，也不会重新返回新的组件。只是 useFormTable 没有在 config 里加上 pageSize。这里会想想设计上是否需要，要是需要加上即可。

[JIACHENG9]

这个在为什么有 sunflower 里有说明，useFormTable 会给出所有不需要用 HOC 的方法跟状态，用户可手动去做绑定，而只是更多的给出了帮用户绑定了的组件，是可选择不用的。

[twisger]

你可以把 useMemo 作为性能优化的手段，但不要把它当成语义上的保证。将来，React 可能会选择“遗忘”以前的一些 memoized 值，并在下次渲染时重新计算它们，比如为离屏组件释放内存。先编写在没有 useMemo 的情况下也可以执行的代码 —— 之后再在你的代码中添加 useMemo，以达到优化性能的目的。

引用自官方文档对useMemo的说明，看了一下store的实现,似乎也依赖于useCallback。
在某些情况下或许会出现store丢失(重新初始化)的情况。

[JIACHENG9]

这个讨论其实也分两个维度

1 要不要返回 HOC
2 要是返回技术怎么做

对于1，可持续讨论。
对于2，可提 pr，以及有问题的代码。

[JIACHENG9]

@twisger @yesmeck 修改为 props 方式，去掉了 HOC，欢迎 pr

[robert7git]

hooks 的一个重大作用就是能把逻辑从组件里剥离出来，现在又混在一起了第一感觉也是反模式。

我自己目前实践下来更倾向于这种写法：

import { Table, SearchForm, useList } from './List';

export default () => {
  const [searchForm, list] = useList();

  return (
    <>
      <SearchForm {...searchForm} />
      <Table {...list} />
    </>
  )
}

进一步， 为什么要 在 这里 use呢？ 把获取数据放到 SearchForm 内部如何？