MVI架构中的单次事件

Question

尝试新的架构范例，其中呈现器创建不可变状态（模型）流，视图只呈现它。

无法理解如何处理我们只需要制作一次事件的情况。有几个例子。

1) 笔记应用程序。我们有 editText 和 saveButton。用户点击 saveButton，会发生一些处理并且应该清除 editText。你们能不能描述一下我们的 ViewState 这里的内容和大概的逻辑流程？

我现在看到的问题和陷阱：

我们在主持人中订阅editText.textChanges()。如果我们在 ViewState 中有 text 并在每次渲染调用时渲染它，那么我们将陷入递归，因为它会发出新的 textChange 并更新状态并再次渲染。
我们是否需要 ViewState 中的 text 来恢复方向文本或进程 kill/restore，看起来它在这里开箱即用。但是想象一下 recyclerView 的滚动位置。我们肯定需要保存它才能恢复。我们无法在每次渲染调用时恢复它，因为它看起来很奇怪，不是吗？
如果我们将这样的逻辑视为副作用并调用 .doOnNext{ view.clearText() } 是有道理的，但是我们是否参考了规范 MVI 实现中的视图？正如我所见，莫斯比没有。
这是有道理的，但在 doOnNext 调用的那一刻，视图有可能死掉。 MVI 应该可以帮助我们解决这个问题，但前提是它是 ViewState 的一部分，对吗？

2) Github 应用程序。第一屏（组织）：orgEditText、okButton、progressBar。第二个屏幕（回购）：recyclerView。当用户将组织输入 orgEditText 并单击 okButton 时，应用程序应向 API 发出请求，并在成功时导航到 Repos 屏幕或在失败时显示 toast。您能否再次描述 ViewState 的组织屏幕以及应该是什么样的逻辑？

我现在看到的问题和陷阱：

我们应该在加载时显示 progressBar 并禁用 okButton。我们应该像 loading/content/error 密封的 class（我们称它为 ContentState）并将它的实例放在我们的 ViewState 中。 View 知道如何呈现 ContentState.loading 并显示 progressBar 并禁用 okButton。我说得对吗？
那么如何处理导航呢？与1.3和1.4相同的问题。
我看到有人认为导航应该被视为副作用，但又是 1.4。
Toast - 是否有状态或我们认为这是副作用？同样的问题。

Google 建议 SingleLiveEvent 解决方案，但它看起来很奇怪，然后应该有尽可能多的 LiveData<SingleLiveEvent> 流，因为我们有这样的东西，而不是真正的单一真相来源。其他人建议从 render func 生成更好的新意图，但有可能某些异步操作将再次更改状态，我们将在第一个显示时获得第二个 Toast，依此类推。

Answer 1

1) 笔记应用程序：在一个完美的世界中：是的，只要用户插入文本并呈现，您的 ViewState 就会发生 text 变化。关于递归：我可能是错的，但我认为某个地方的 RxBindings 提供了一个 Observable，它不仅包含更改的文本，而且如果此更改是由用户输入或以编程方式设置文本引起的，还包含一个布尔标志。无论如何，我认为你也可以解决递归问题，如果你检查 if (editText.text != viewState.text) 并且只设置文本以防它们不同（请记住，你可能必须使用在文本更改后触发的 TextWatcher 回调开始意图，而不是 "before is going to be changed").

话虽如此，在 Android 我们并不是生活在一个完美的世界中。正如您已经说过的，文本将由 android 自动恢复。因此，不让文本成为 ViewState 的一部分是有意义的。

听起来在那种情况下 ViewState 只是一个像这样的枚举：

enum ViewState {
   // The user can type typing text
   IDLING,

   // The app is saving the note
   PROCESSING,

   // After having saved (PROCESSING) the note, CLEARED means, show a new empty note  
   CLEARED
}

所以初始状态是IDLING。然后，一旦应该保存注释，下一个发出的 ViewState 就是 PROCESSING。成功后，您的业务逻辑会立即触发 CLEARED，然后立即触发 IDLING，因此最后用户会再次看到一个空笔记并可以开始输入新笔记。

不要使用 doOnNext() 来操纵视图。 ViewState 是视图的唯一真实来源。

关于 RecyclerView：如果没有，RecyclerView 会自动恢复其滚动位置（在恢复状态后，您将 LayoutManager 和/或适配器设置为延迟）。然而，如果你想在 ViewState 中模拟滚动位置，在完美的世界中这又是我猜想的最佳解决方案，你应该考虑不要在滚动的每个像素上更新 ViewState 中的滚动位置，而是在用户不再滚动/一扔已经完成。

2) Github 应用程序：

We should show progressBar and disable okButton while loading. We should have like loading/content/error sealed class(lets call it ContentState) and have its instance in our ViewState. View knows how to render ContentState.loading and shows progressBar and disables okButton. Am I right?

是

How to handle navigation then?

对我来说，将其作为副作用处理效果很好：我有一个 class Navigator 被注入演示者并在 doOnNext { navigator.goToX() } 中使用。 Navigator 然后将其分派给另一个可以临时附加/分离的组件。所以这个其他组件正在观察 "navigation events" 的导航器，我这样做的原因是这个组件不会泄漏 activity / 片段上下文。 "This component" 可以直接是 Activity 或 Fragment 或其他什么，但我倾向于有一个专用的 class，我们称它为 Router 观察 Navigator 进行导航事件并执行 FragmentTransactions 或您在应用中使用的任何内容。

Toast - is there something in state or we consider this as side effect? Same problems.

这可以像使用 Snackbar 那样处理（参见 here）。 Toast 没有 API 来隐藏 Toast。因此，您可以立即一个接一个地触发两个 ViewState 而不是计时器：第一个设置了错误标志（然后会导致 Toast 显示在屏幕上），第二个 "clear" 这个标志。像这样：

Observable.just( ViewState(error = true, ...), new ViewState( error = false, ... )

我希望这能澄清一些事情，但一如既往：不要把它们当作灵丹妙药。做最适合您的应用程序和用例的事情。不要过于虔诚，这始终是个案决定。

MVI架构中的单次事件

Single time events in MVI architecture

architecture

android

kotlin

mosby