尝试新的架构范例，其中演示者创建不可变的状态(模型)流，而 View 只是呈现它。

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

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

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

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

2) Github 应用程序。第一屏(组织):orgEditText , okButton , progressBar .第二屏( repo ):recyclerView .当用户输入组织时 orgEditText并点击 okButton应用程序应向 API 发出请求，并在成功时导航到 Repos 屏幕或在失败时显示 toast。你能再描述一下ViewState吗？用于组织屏幕以及应该是什么样的逻辑？

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

1. 我们应该显示progressBar并禁用 okButton加载时。我们应该有加载/内容/错误密封类(我们称之为 ContentState )并在我们的 ViewState 中有它的实例. View 知道如何渲染 ContentState.loading并显示 progressBar并禁用 okButton .我说得对吗？
2. 然后如何处理导航？与 1.3 和 1.4 相同的问题。
3. 我看到有人认为导航应该被视为副作用，但 1.4 又是这样。
4. Toast - 状态是否有变化，或者我们认为这是副作用？同样的问题。

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

最佳答案

1) 笔记应用程序: 在一个完美的世界中:是的，只要用户插入文本并呈现，您的 ViewState 就会有 text 更改。关于递归:我可能是错的，但我认为某个地方的 RxBindings 提供了一个 Observable，它不仅包含更改的文本，而且如果此更改是由用户输入或以编程方式设置文本引起的，还包含一个 bool 标志。无论如何，我认为你也可以解决递归问题，如果你检查 if (editText.text != viewState.text) 并且只设置文本以防它们不同(请记住你可能有使用在文本更改后触发的 TextWatcher 回调来启动 Intent ，而不是“在将要更改之前”)。

话虽如此，在 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() 来操作 View 。 ViewState 是 View 的唯一真实来源。

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

2) Github 应用:

1. 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?

是

2. How to handle navigation then?

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

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

这可以像使用 Snackbar 那样处理(参见 here )。 Toast 没有用于隐藏 Toast 的 API。因此，您可以立即一个接一个地触发两个 ViewState 而不是计时器:第一个设置了错误标志(然后导致 Toast 确实显示在屏幕上)，第二个您“清除”此标志。像这样:

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

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

关于android - MVI架构中的单次事件，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/47777688/