docs(zh-cn): faq

documentation/zh-cn/faq.md

@@ -0,0 +1,66 @@
+# 常见问题
+
+### 1. 没有 VDOM 的 JSX？ 这是 [雾件](https://zh.wikipedia.org/wiki/%E9%9C%A7%E4%BB%B6)吗？ 我听过像其他框架的作者强调说这是不可能的。
+
+当你没有 React 的更新模型时，这是可能的。JSX 是一个模板 DSL，就像任何其他的模板一样。只是在某些方面更灵活的一种。插入任意 JavaScript 有时可能具有挑战性，但与支持扩展运算符没有什么不同。 所以不，这不是雾件，而是一种被证明是最高效的方法。
+
+真正的好处在于它的可扩展性。你有编译器为你工作，为您提供最佳的原生 DOM 更新，但您拥有像 React 这样的库的所有自由，可以使用诸如 Render Props 和高阶组件之类的技术以及响应式钩子来编写组件。不喜欢 Solid 的流程控制？ 写你自己的。
+
+### 2. Solid 的性能如何？
+
+我希望我只需要指出一件事，但它确实是最重要的许多选择决定的：
+
+1. 显式响应性，因此只跟踪应该反应性的事物。
+2. 编译时考虑到初始创建。 Solid 使用启发式算法来松散粒度以减少计算次数，同时保持关键更新的粒度和性能。
+3. 响应式表达式只是函数。这使得 "消失的组件" 能够通过惰性 props 求值移除不必要的包装器和同步开销。
+
+这些是目前独特的技术组合，使 Solid 在竞争中具有优势。
+
+### 3. 有 React 兼容包吗?
+
+不会。而且可能永远不会有。虽然 API 是相似的，并且组件通常可以通过小的编辑距离策略来移动，但更新模型根本不同。React 组件会一遍又一遍地渲染，因此 Hooks 之外的代码的运行方式非常不同。闭包和钩子规则不仅是不必要的，它们还可以以在 Solid 不起作用的方式使用。
+
+另一方面，Vue-compat 是可行的。 虽然目前没有实施的计划。
+
+### 4. 为什么解构不起作用？我觉得到我可以通过将整个组件包装在一个函数中来修复它。
+
+响应性发生在 Prop 和 Store 对象的属性访问上。在绑定或响应式计算之外引用它们将不会被跟踪。在这些情况下，解构正常工作。
+
+但是，将整个组件包装在一个函数中并不是你想不负责任地做的事情。Solid 没有 VDOM。因此，任何跟踪的更改都会再次运行整个函数，重新创建所有内容。不要这样做。
+
+### 5. 你能添加对 Class 组件的支持吗？ 我发现生命周期更容易推理。
+
+不打算支持类组件。Solid 的生命周期与调度反应系统相关，并且是人为的。我想你可以用它创建一个类，但实际上所有非事件处理器代码基本上都在构造函数中运行，包括渲染函数。这只是你不细化数据要求更多语法的借口。
+
+将数据及其行为组合在一起，而不是将生命周期组合在一起。这是一种已经奏效了数十年的响应式最佳实践。
+
+### 6. 我真的不喜欢 JSX，模板 DSL 有机会吗？ 哦，我看到你标记了标签模板字面量/HyperScript。也许我会用那些...
+
+别。我会马上阻止你。我们像 Svelte 使用他们的模板一样使用 JSX 来创建优化的 DOM 指令。标签模板字面量 和 HyperScript 解决方案确实令人印象深刻，但除非您有真正的理由，例如无构建要求，否则它们在各方面都较差。较大的包、较慢的性能以及需要手动解决方法包装值。
+
+有选择是件好事，但 Solid 的 JSX 确实是最好的解决方案。模板 DSL 也很棒，虽然限制更多，但 JSX 为我们免费提供了很多。现有解析器、语法高亮、TypeScript、Prettier、代码完成，以及最后但并非最不重要的 TypeScript。
+
+我知道其他库一直在增加对这些功能的支持，但这是一项巨大的努力，但仍然不完美，并且一直是维护问题。这也确实是一种务实的态度。
+
+### 7. 我什么时候使用 Signal 或者 Store? 它们有何不同?
+
+存储自动包装嵌套值，使其成为深层数据结构，是数据模型的理想选择。对于大多数其他情况，Signal 是轻量级的，并且可以出色地完成工作。
+
+尽管我很想将这些包装在一起作为一个单一的 API，但你不能代理基本数据类型。函数是最简单的接口，任何响应式式表达式（包括状态访问）都可以在传输时包装成一个，如果这提供了一个通用 API。您可以随意命名您的 signal 和状态，并且它保持最小。我想要做的最后一件事是在用户端强制键入 `.get()` `.set()` 或更糟的 `.value`。为了简洁起见，至少前者可以使用别名，而后者只是调用函数的最简单的方法。
+
+### 8.为什么我不能像在 Vue.js Svelte MobX 中那样为 Solid 的 Store 赋值？ 有双向绑定么？
+
+响应性是一种强大的工具，但也是一种危险的工具。 MobX 知道这一点并引入了严格模式和 Action 来限制更新发生的位置/时间。在 Solid 处理整个组件数据树时 ，我意识到我们可以从 React 中学到一些东西。只要您提供拥有相同约定的方法，您就不需要实际上是不可变的数据。
+
+能够传递更新状态的能力可以说比决定传递状态更重要。因此，能够将其分开很重要，而且只有在读取不可变的情况下才有可能。如果我们仍然可以粒度更新，我们也不需要付出不可变的成本。幸运的是，ImmutableJS 和 Immer 有大量的现有技术。具有讽刺意味的是，Solid 主要用作具有可变内部结构和不可变接口，和 Immer 刚好相反。
+
+### 9. 我可以单独使用 Solid 的响应性吗？
+
+
+当然。虽然我没有导出一个独立的包，但很容易在没有编译器的情况下安装 Solid，只需使用反应 primitive。粒度响应性的好处之一是它与库无关。就此而言，几乎每个反应式库都是这样工作的。这启发了 [Solid](https://github.com/solidjs/solid) ，Solid 内部使用 [DOM 表达式库](https://github.com/ryansolid/dom-expressions) 并根据纯粹的响应式系统来创建的渲染器。
+
+列出一些可尝试的库: [Solid](https://github.com/solidjs/solid), [MobX](https://github.com/mobxjs/mobx), [Knockout](https://github.com/knockout/knockout), [Svelte](https://github.com/sveltejs/svelte), [S.js](https://github.com/adamhaile/S), [CellX](https://github.com/Riim/cellx), [Derivable](https://github.com/ds300/derivablejs), [Sinuous](https://github.com/luwes/sinuous), 甚至最近的 [Vue](https://github.com/vuejs/vue). 制作响应式库比将其标记到渲染器上工作量要多得多，例如 [lit-html](https://github.com/Polymer/lit-html)，但这有助于帮你找到感觉。
+
+### 10. Solid 有我可以使用的 Next.js 或 Material Components 之类的库吗？
+
+据我所知没有。如果你有兴趣构建一个，我可以随时在我们的 [Discord](https://discord.com/invite/solidjs) 上帮助你构建它们。我们有基础，只需要在这些基础上再接再厉。