审查屏幕 + 出口的最佳实践？

Question

跟进this question，我正在使用现在尝试实施审查屏幕，这将重新评估出口匝道。

代码是这样工作的：

1. 用户做出选择[强制代码触发问题] ...其中一个选项给出了值“not_supported”
2. 如果用户选择不支持的功能，将被发送到“不支持”屏幕 [事件] - 然后他们必须单击“返回”以继续采访并在第 1 项的屏幕上重新输入信息
3. 一旦用户做出支持的选择，他们最终会看到一个评论屏幕

现在发生的情况是，如果用户在审查屏幕上从上面第 1 项的屏幕中选择“不支持”功能，他们仍会返回到审查屏幕，但会将“不支持”选项作为变量（不是期望的行为）。

一个想法是根据this question，如果之前已经选择了该选项（即，如果用户之前被告知当前不支持该选项），则简单地停止显示该选项。不过，这只是部分解决方案，因为如果用户在某个时候没有选择不受支持的选项，该选项仍然可以从审查屏幕中选择。 我在这里遇到了一个小问题，虽然我在我的代码中设置了一个“标志”变量（见下文）以删除使用

'show if': not not_supported_shown_flag

的选项，这实际上效果很好，除了点击“评论” ”从审查屏幕取消设置 - 问题 1：有没有办法防止这种情况发生（即“审查证明”某些变量？）。

对于更大的问题，我认为可能有一个解决方案，包括带有

initial

说明符（或另一个 logic 控制说明符）的代码。例如：

mandatory: True
depends on: var
code: |
    if var == "not_supported":
        not_supported_shown_flag = True # the "offramp taken flag" variable, meant to remove the non-supported option from future visits to that screen by the user
        not_supported_event_screen # the "off ramp"

我现在遇到的问题是，按照this question的最佳答案是：

1. “后退”按钮将用户带回到审阅屏幕而不触发

   not_supported_event_screen

2. 然后各种混乱接踵而至，包括（a）用户仍然可以通过单击“恢复”进入审查屏幕，然后在随后的任何时候，如果他们返回，他们将被带到

   not_supported_event_screen

   ，和（ b) 当用户再次点击“重新访问”时，他们将被带到

   not_supported_event_screen

   ，“退出”和“退出并清除答案”按钮无法按预期工作。

问题 2：想知道是否有解决此类情况的最佳实践/公认方法？

Initial

和

reconsider

似乎不必要地处理繁重的过程，因为每次屏幕更改时它们都会调用代码块（如果我理解正确的话）（并不是我希望处理强度在这里产生明显的差异）。

mandatory: True

出现必要，或者代码块在第一次通过时不运行（仅在重新计算时）。