Dynamic Environments ¶ SwiftUI Rules #284

ericchuhong · 2019-12-22T17:03:16Z

这篇文章对应的 Issue 链接是：
#263
本文的大致阅读时长：[ 15 ] 分钟。

PR Checklist:

我已经仔细阅读翻译说明文档
我的文章符合格式要求
我的文章头部符合头部格式
我已经完成自查环节，从读者角度阅读，我确定文章足够通顺易懂

请校对同学帮忙校对。

appcoda/20190831_dynamic-environments-swiftui-rules.md

Nemocdz · 2019-12-27T11:50:30Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+
+> [EnvironmentValues](https://developer.apple.com/documentation/swiftui/environmentvalues) 这个结构体代表了视图当前使用中的值。开发者不能直接访问到它底层的数据。想要访问的当前状态，下标值需要用 **type** 作为 key 。
+
+所以我们应该如何使用它呢？还是跟之前展示过的一样！有的 View 通过使用 [@Environment](https://developer.apple.com/documentation/swiftui/environment) 属性封装器访问了我们新开发的优秀 key —— `fancyColor`：


有的 -> 让某个

Nemocdz · 2019-12-27T11:54:00Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+}
+```
+
+并且由一个 View 提供了它：


另一个 View 来提供它的值

Nemocdz · 2019-12-27T11:54:52Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+}
+```
+
+顺着视图层次结构传递值显得简单并相当高效。


显得简单并相当高效 -> 多么简单和高效

Nemocdz · 2019-12-27T11:56:26Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+
+顺着视图层次结构传递值显得简单并相当高效。
+
+> 那如果是 [EnvironmentObject](https://developer.apple.com/documentation/swiftui/environmentobject) 呢？它们和常规的 environment 值很相似，但他们也规定了相应的值需要是一个遵循了 ObservableObject 协议的类。要做的这些事情对一些简单的行限制或者颜色限制规则来说，显得有点太多了。


但他们也规定了相应的值需要是一个遵循了 ObservableObject 协议的类 -> 但规定了对应值的类型需要遵循 ObservableObject 协议

Nemocdz · 2019-12-27T11:58:49Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+
+# SwiftUI 规则
+
+这已经是个相当棒而且强大的概念了！但目前为止 environment key 仍需要有静态值的支持。它们需要显式地推入到当前那个用 `.environment` 视图封装器（如果为空则是 `defaultValue` ）的 enviroment 中。


这已经是个相当棒而且强大的概念了 -> 这个概念已经……

Nemocdz · 2019-12-27T12:00:31Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+
+# SwiftUI 规则
+
+这已经是个相当棒而且强大的概念了！但目前为止 environment key 仍需要有静态值的支持。它们需要显式地推入到当前那个用 `.environment` 视图封装器（如果为空则是 `defaultValue` ）的 enviroment 中。


第二句话不通顺，它们需要通过xxx来赋值到当前的xxx

Nemocdz · 2019-12-27T12:01:23Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+
+这已经是个相当棒而且强大的概念了！但目前为止 environment key 仍需要有静态值的支持。它们需要显式地推入到当前那个用 `.environment` 视图封装器（如果为空则是 `defaultValue` ）的 enviroment 中。
+
+如果我们能够避免 `.environment(\.fancyColor, .red)` 这样的声明，然后基于其他 environment key 的值，定义我们自己的 `fancyColor`。甚至可以 **制定** 如何从其他 key 值衍生的规则。**欢迎来到 [SwiftUI 规则](https://github.com/DirectToSwift/SwiftUIRules)**：


如果……呢？这甚至……

Nemocdz · 2019-12-27T12:03:00Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+
+### Environment Key
+
+**environment key** 适用于我们例子中的 `fancyColor`。那意味着如果一个 View 想要 `fancyColor` 环境值，规则引擎将会查找每一个规则，看哪一个可以应用到那个 key。


查找每一个规则，看哪一个可以应用到那个 key -> 找到规则中xxxx

Nemocdz · 2019-12-27T12:06:03Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+
+大概意思就是：给导航栏使用这个标题。这个标题是待办的标题。除非待办的是 "IMPORTANT"，我们才用 "Can wait." 重写它。
+
+详细讲讲过程中发生了的事情：


Nemocdz

一次校对

Nemocdz · 2019-12-28T03:35:50Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+详细讲讲过程中发生了的事情：
+
+1. `PageView` 中的 `@Environment` 想获取 `navigationBarTitle`，
+2. 规则系统查看了模型，并给标题查找到了这个规则：`\.navigationBarTitle <= \.title`，


并给标题查找到了这个规则 -> 并找到了标题的这个规则

Nemocdz · 2019-12-28T03:40:55Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+
+1. `PageView` 中的 `@Environment` 想获取 `navigationBarTitle`，
+2. 规则系统查看了模型，并给标题查找到了这个规则：`\.navigationBarTitle <= \.title`，
+3. 规则系统向自己请求 `title` 的值，


向自己 -> 从自身

appcoda/20190831_dynamic-environments-swiftui-rules.md

Nemocdz · 2019-12-28T03:44:51Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+6. 它去查找了在 environment 中的 `todo` 对象，然后将它标题和常量 “IMPORTANT” 对比。假若情况是谓词匹配到了，规则就会被使用，`title` 的值将会是 `“Can wait.”`。
+7. 规则系统现在决策出 `title` 的值 - `"Can wait."`，然后返回给 `navigationBarTitle`，并把值推入给 `PageView`。
+
+要留意的关键点是一个规则可以通过其他规则中声明。


从……中/通过……来

Nemocdz · 2019-12-28T03:46:04Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+
+# 使用 SwiftUI 规则
+
+这个 [仓库](https://github.com/DirectToSwift/SwiftUIRules) 主要是以在 


主要是以……为主要组成不通顺！

Nemocdz · 2019-12-28T03:46:41Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+
+这个 [仓库](https://github.com/DirectToSwift/SwiftUIRules) 主要是以在 
+[`Samples`](https://github.com/DirectToSwift/SwiftUIRules/tree/develop/Samples/)
+子目录下一个很小型的 [示例应用](https://github.com/DirectToSwift/SwiftUIRules/tree/develop/Samples/RulesTestApp) 为主要组成，去看看吧。它是一个没有条理可言的示例，但是展示了如何设置和运行整个架构。


虽然是个没什么条理的

Nemocdz · 2019-12-28T03:50:43Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+]
+```
+
+你可以在 SwiftUI 视图层次架构中的任何地方拦截注入到规则系统，但我们再一次推荐在每个最上层的视图中做。例如，在 Xcode 中新生成一个应用，你可以给生成的 `ContentView` 做如下的修改：


拦截注入到规则系统 -> 拦截注入规则系统

Nemocdz · 2019-12-28T03:51:21Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+]
+```
+
+你可以在 SwiftUI 视图层次架构中的任何地方拦截注入到规则系统，但我们再一次推荐在每个最上层的视图中做。例如，在 Xcode 中新生成一个应用，你可以给生成的 `ContentView` 做如下的修改：


再一次 -> 依旧

Nemocdz · 2019-12-28T03:53:37Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+```swift
+\.todos.count > 10 => \.person.status <= "VIP"
+```
+也就是赋值给一个多组合关键路径（`\.person.status`）。那 **运行不了** 的。


这样是无法运行的

Nemocdz · 2019-12-28T03:54:55Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+
+## 联系方式
+
+嘿！我们希望你喜欢这篇文章，并且我们喜欢反馈！Twitter，或他们任一一位：


这下面任意一个的 Twitter

Nemocdz

还有一些小问题

Nemocdz · 2020-01-04T03:51:24Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+}
+```
+
+请注意 environment 可以在任意一视图层次中 _变换_：


变换这里不需要空格

Nemocdz · 2020-01-04T03:51:53Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+```
+这样就可以了。我们可以开始使用我们的新 key 了。
+
+> [EnvironmentValues](https://developer.apple.com/documentation/swiftui/environmentvalues) 这个结构体代表了视图当前使用中的值。开发者不能直接访问到它底层的数据。想要访问的当前状态，下标值需要用 **type** 作为 key 。


key 后面多了一个空格

Nemocdz · 2020-01-04T04:07:30Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+]
+```
+
+首先这里假设当前 environment 带有一个 `todo` 的 environment key，而且这个 environment key 持有一个 todo 对象。然后我们定义了值 `fancyColor` 将带有 todo 的 priority 值。通过用 **规则**，我们 **声明** 了它。 


中文之间不需要空格

Nemocdz · 2020-01-04T04:13:56Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+
+# 使用 SwiftUI 规则
+
+这个 [仓库](https://github.com/DirectToSwift/SwiftUIRules) 的主要组成是在 


第一句话翻译不对，不通顺，这个仓库在 Sample 子文件夹中提供了一个小型的示例应用

Nemocdz · 2020-01-04T04:18:32Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+
+## 用例
+
+哈！没完没了的 🤓 它和 “Think In Rules”™（又称声明式）相当不同，但是他们允许你使用一种高度解耦的方式组合你的应用，实际上就是“声明式”方式。


第一句不太通顺

Nemocdz · 2020-01-04T04:20:00Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+  \.lineLimit <= 2
+]
+```
+**还不能用**。这是当下依赖系统使用的键来显式创建才有的 [`DynamicEnvironmentKey`](https://github.com/DirectToSwift/SwiftUIRules/blob/develop/Sources/SwiftUIRules/DynamicEnvironment/DynamicEnvironmentKey.swift#L17) 类型。所以你没办法立刻就用上。


还不能用 -> 这没有效果

ericchuhong · 2020-01-21T15:51:24Z

@Nemocdz 已修改，请校对。不好意思，拖了这么久。

numbbbbb · 2020-04-10T02:33:12Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+
+## 声明自己的 Environment 键
+
+SwiftUI environments 对内置键的数量是不限制的，你可以添加自己的键。除了 `foregroundColor` 之外，我们如果说想要添加一个自己的 environment 键，叫做 `fancyColor`。


我们如果说想要添加一个自己的 => 假设我们想添加一个

numbbbbb · 2020-04-10T02:33:43Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+  }
+}
+```
+这样就可以了。我们可以开始使用我们的新 key 了。


我们可以开始使用我们的 => 可以开始使用

numbbbbb · 2020-04-10T02:34:15Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+
+这个概念已经是相当棒而且强大了！但目前为止 environment key 仍需要有静态值的支持。它们需要通过 `.environment` 视图封装器（如果为空则是 `defaultValue` ）来赋值到当前的 enviroment。
+
+如果我们能够避免 `.environment(\.fancyColor, .red)` 这样的声明，然后基于其他 environment key 的值定义我们自己的 `fancyColor` 呢？这甚至可以**制定**如何从其他 key 值衍生的规则。**欢迎来到 [SwiftUI 规则](https://github.com/DirectToSwift/SwiftUIRules)**：


去掉第一个”我们”

numbbbbb · 2020-04-10T02:35:28Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+]
+```
+
+但它也可以被用得很高级，例如在一个工作流系统：


但它也可以被用得很高级 => 但它也有一些高级用法

numbbbbb · 2020-04-10T02:35:42Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+]
+
+struct TaskView: View {
+  @Environment(\.view) var body // body derived from rules


翻译注释

numbbbbb · 2020-04-10T02:36:39Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+}
+```
+
+因为 SwiftUI Views 也只是一个轻量的结构体，你可以构建动态的属性携带它们！


这段漏掉了很多内容，对照原文重新翻译。

numbbbbb · 2020-04-10T02:37:11Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+
+# 总结
+
+我们希望你喜欢它！


漏掉一段

这一段还是他们后面更新的 😂

numbbbbb · 2020-04-12T16:53:44Z

appcoda/20190831_dynamic-environments-swiftui-rules.md

+
+我们希望你喜欢它！
+
+更新：也同时检出我们的新版 [Direct to SwiftUI](http://www.alwaysrightinstitute.com/directtoswiftui/)，它不管在什么时候都用 SwiftUI 构建了精美的数据库前端。


检出？机翻？

读不通修改

【feature】新增翻译

c520b47

ericchuhong changed the title ~~【feature】新增翻译~~ Dynamic Environments ¶ SwiftUI Rules Dec 23, 2019

Nemocdz reviewed Dec 28, 2019

View reviewed changes

Nemocdz requested changes Dec 28, 2019

View reviewed changes

【feature】校对修改

da6fffa

Nemocdz requested changes Jan 4, 2020

View reviewed changes

【feature】二次校对

515e87a

Nemocdz approved these changes Apr 7, 2020

View reviewed changes

numbbbbb requested changes Apr 10, 2020

View reviewed changes

根据帮主校对修改

d9011d1

numbbbbb requested changes Apr 12, 2020

View reviewed changes

调整翻译意思不通畅的句子

8e3532d


		> [EnvironmentValues](https://developer.apple.com/documentation/swiftui/environmentvalues) 这个结构体代表了视图当前使用中的值。开发者不能直接访问到它底层的数据。想要访问的当前状态，下标值需要用 type 作为 key 。

		所以我们应该如何使用它呢？还是跟之前展示过的一样！有的 View 通过使用 [@Environment](https://developer.apple.com/documentation/swiftui/environment) 属性封装器访问了我们新开发的优秀 key —— `fancyColor`：


		顺着视图层次结构传递值显得简单并相当高效。

		> 那如果是 [EnvironmentObject](https://developer.apple.com/documentation/swiftui/environmentobject) 呢？它们和常规的 environment 值很相似，但他们也规定了相应的值需要是一个遵循了 ObservableObject 协议的类。要做的这些事情对一些简单的行限制或者颜色限制规则来说，显得有点太多了。


		# SwiftUI 规则

		这已经是个相当棒而且强大的概念了！但目前为止 environment key 仍需要有静态值的支持。它们需要显式地推入到当前那个用 `.environment` 视图封装器（如果为空则是 `defaultValue` ）的 enviroment 中。


		这已经是个相当棒而且强大的概念了！但目前为止 environment key 仍需要有静态值的支持。它们需要显式地推入到当前那个用 `.environment` 视图封装器（如果为空则是 `defaultValue` ）的 enviroment 中。

		如果我们能够避免 `.environment(\.fancyColor, .red)` 这样的声明，然后基于其他 environment key 的值，定义我们自己的 `fancyColor`。甚至可以制定如何从其他 key 值衍生的规则。欢迎来到 [SwiftUI 规则](https://github.com/DirectToSwift/SwiftUIRules)：


		### Environment Key

		environment key 适用于我们例子中的 `fancyColor`。那意味着如果一个 View 想要 `fancyColor` 环境值，规则引擎将会查找每一个规则，看哪一个可以应用到那个 key。


		大概意思就是：给导航栏使用这个标题。这个标题是待办的标题。除非待办的是 "IMPORTANT"，我们才用 "Can wait." 重写它。

		详细讲讲过程中发生了的事情：


		# 使用 SwiftUI 规则

		这个 [仓库](https://github.com/DirectToSwift/SwiftUIRules) 主要是以在


		## 联系方式

		嘿！我们希望你喜欢这篇文章，并且我们喜欢反馈！Twitter，或他们任一一位：


		## 用例

		哈！没完没了的 🤓 它和 “Think In Rules”™（又称声明式）相当不同，但是他们允许你使用一种高度解耦的方式组合你的应用，实际上就是“声明式”方式。


		## 声明自己的 Environment 键

		SwiftUI environments 对内置键的数量是不限制的，你可以添加自己的键。除了 `foregroundColor` 之外，我们如果说想要添加一个自己的 environment 键，叫做 `fancyColor`。


		# 总结

		我们希望你喜欢它！


		这个概念已经是相当棒而且强大了！但目前为止 environment key 仍需要有静态值的支持。它们需要通过 `.environment` 视图封装器（如果为空则是 `defaultValue` ）来赋值到当前的 enviroment。

		如果我们能够避免 `.environment(\.fancyColor, .red)` 这样的声明，然后基于其他 environment key 的值定义我们自己的 `fancyColor` 呢？这甚至可以制定如何从其他 key 值衍生的规则。欢迎来到 [SwiftUI 规则](https://github.com/DirectToSwift/SwiftUIRules)：


		我们希望你喜欢它！

		更新：也同时检出我们的新版 [Direct to SwiftUI](http://www.alwaysrightinstitute.com/directtoswiftui/)，它不管在什么时候都用 SwiftUI 构建了精美的数据库前端。

Dynamic Environments ¶ SwiftUI Rules #284

Are you sure you want to change the base?

Dynamic Environments ¶ SwiftUI Rules #284

Conversation

ericchuhong commented Dec 22, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Nemocdz Dec 27, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Nemocdz left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Nemocdz left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ericchuhong commented Jan 21, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ericchuhong commented Dec 22, 2019 •

edited

Loading

Nemocdz Dec 27, 2019 •

edited

Loading