MVI架构中的单次事件

Single time events in MVI architecture

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

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

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

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

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

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

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

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

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

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 应用程序:

  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?

  1. How to handle navigation then?

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

  1. 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, ... )

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