小编mat*_*zav的帖子

TypeScript 允许您编写递归类型，但无法深入了解代码在较低级别（即深度）中如何变化。例如，下面的代码在所有级别上都具有相同类型的签名，并且我们必须在每个级别上手动检查是否存在属性sub。

type Recurse = { foo: string; sub?: Recurse }

function recurse(depth: number): Recurse {
  if (depth === 0) return { foo: 'hey' }
  return {
    foo: 'hey',
    sub: recurse(depth - 1),
  }
}
const qux = recurse(5)

我正在寻找的是一个类型签名，它可以为我们提供函数在特定深度返回的内容的具体证据。

const qux0: { foo: string } = recurse(0)
const qux1: { foo: string, sub: { foo: string } } = recurse(1)
const qux2: { foo: string, sub: {  foo: string, sub: { foo: string }} } = recurse(2) …

我来自Elm-comunity和Elm,每个应用程序都有它的视图,模型和状态,并且基本上采用非常类似的方法,即IMO,以解决REDx的问题.

无论如何,我发现自己正在努力解决多个减速器的问题.在Elm中,我习惯为所有动作(消息)创建单独的文件,为"反应"(视图)创建单独的文件,为状态(模型)创建单独的文件,为所有减少器(更新)创建单独的文件.

更新文件中包含每个可能的操作,更新文件不能通过多个文件传播,将所有逻辑保存在一个位置.

另一方面,Redux鼓励为reducers制作多个单独的文件,然后将它们与combineReducers结合使用,我发现这非常令人困惑,或多或少是一个缺点而不是优势.

如果我把事情做对了,每个减速器只会获得它"负责"的部分并且能够对它做一些事情,并且不同的减速器不能访问其他减速器的其他状态属性/属性.

做这个IMO的缺点:

1. 减速器A的功能可能需要有关减速器B的信息,但由于此原因无法访问.
2. 更多文件会导致更多混乱和无意的错误.
3. 不必要的代码拆分....

拆分代码的优点是什么,或者我没有在这里看到什么？

我的站点由主页组成，然后由子文件夹分隔在文件夹内。如何在网页托管服务中添加子页面（Firebase托管）