block_id 什么时候需要更新？ 更新具有 plain_text_input 块的表面更新具有 static_select 菜单的表面

如何解决block_id 什么时候需要更新？ 更新具有 plain_text_input 块的表面更新具有 static_select 菜单的表面

我正在尝试了解模式中对唯一 block_id 的要求。具体来说，输入块的字段文档中的 this instruction：

block_id 对于每条消息和消息的每次迭代都应该是唯一的。如果消息更新，请使用新的 block_id。

好的，这似乎意味着如果我发送 views.update 调用来更新模态以响应某些交互，我需要使用新的唯一值更新所有 block_id。这很烦人，尤其是那些相同的 block_ids 是错误响应的关键，但无论如何。

除了这似乎与“使用模态”更新文档中的 this note 直接矛盾（以及 views.update docs 和 views reference 中的相同注释）：

在更新视图时可以保留在输入块中输入或选择的数据。您与 views.update 一起使用的新视图对象应包含具有相同 block_id 和 action_id 值的相同输入块和元素。

所以我不需要在更新视图时改变block_id？那么第一个注释是什么意思 - 我什么时候需要一个新的 block_id？或者在那里“消息”有什么特定的意义——而不是“视图”或“表面”——我没有得到？

（我猜这里有一个子问题，block_ids的唯一性范围到底是什么？我们已经区分了action_ids，它只需要在一个视图中是唯一的，而external_ids，它需要在整个视图中是唯一的“一个团队的所有观点”；block_id 是第三类吗？）

解决方法

注意：此答案基于我构建和运行 Simple Poll Slack 应用程序的经验。我不完全确定 Slack 认可的“最正确”的方法是什么，但我对实践中的有效方法有很好的了解。

---

这里的简短回答是，在大多数情况下，block_ids 不需要是唯一的。我们的大部分 block_id 都不是唯一的。例如，我们有一个模态/视图，用户可以在其中设置循环投票。此区块的区块 ID 为 set_up_recurring_poll。这个 block_id 不是唯一的没有问题。

所以这是我们的默认方法：为 block_id 选择非唯一的、人类可读的名称。正如您所提到的，当 Slack 通过 block_actions/view_submission 负载发送时，这些也是最容易解析的。

在实践中，Slack 使用 block_id 作为维护交互/输入块内状态的一种方式。具体来说，block_id 唯一性用于决定是否用新块更新/替换您之前指定的块，或者是否保留现有块。本质上是一种缓存形式。

这有点抽象，所以我将举两个例子：

• 更新具有 plain_text_input 块的表面
• 更新具有 static_select 菜单的表面

更新具有 plain_text_input 块的表面

1. 假设您的应用打开了一个包含 plain_text_input 块的视图。
2. 用户在此块中输入了一些内容，例如“Hello World”
3. 然后用户点击视图中的按钮，您的应用决定使用 views.update 更新视图，但在视图中保留相同的 plain_text_input 块

如果在此对 views.update 的调用中，您的应用将 block_id 保持为与您的应用在第 1 步中使用的 block_id 相同，则用户输入的“Hello World”仍将是

如果在对 views.update 的调用中，您的应用程序使用了与您在第 1 步中使用的应用程序不同的 block_id，则用户输入的“Hello World”消失了，并且用户将看到一个空的输入字段。

所以在这种情况下，如果您打算清除 plain_text_input，请使用不同的 block_id。如果您的目的是维护用户输入，请使用相同的 block_id。

更新具有 static_select 菜单的表面

1. 想象一下，您的应用发布了一条带有 static_select 菜单的消息
2. 用户选择 static_select 菜单中的选项之一
3. 然后，您的应用会更新基础消息（使用 chat.update）。上一条消息和更新消息之间的唯一变化是您的应用在 static_select 菜单中添加了另一个选项

在这种情况下，如果包含 static_select 菜单的块在更新的消息中具有 相同 block_id，则新选项将不会显示 static_select 菜单。 Slack看到block_id和之前一样，决定不更新block的实际内容。

因此，在这种情况下，如果您希望在 static_select 菜单中添加另一个选项，那么您需要使用新的块 ID。

当我们遇到这样的情况时，我们倾向于将一个随机生成的后缀附加到我们现有的、人类可读的块 ID 上。因此，我们将使用 my-static-select-menu 作为我们的 block_id，而不是 my-static-select-menu&5jRMA。然后当我们解析 block_id 时，我们只查看 &

之前的值

---

我推荐的并且对我们有用的整体方法：

默认使用非唯一的、人类可读的 block_id。如果您碰巧遇到 Slack 根据 id 缓存块内容而阻止您做某事的情况，则在块 id 中添加一个运行时生成的随机后缀，这将破坏 Slack 的缓存。

block_ids 的唯一性范围到底是什么？

在我的心智模型中，block_id 只需要在任何给定的 block_id 存在于其中的直接相邻块（即 blocks: [] 的数组）的上下文中是唯一的。或者换句话说，对于它们所属的表面实例（消息、视图、应用程序主页）来说，它们需要是唯一的

因此，您不能在完全相同的消息、视图或 app_home 页面中具有两次相同的 block_id – 但是使用相同的、非唯一的块 ID 来例如电源是完全可以的消息中的“升级”按钮。即使同一条消息被多次发布

---

最后一个想法：对于此类和类似的问题，您可能还会发现向 [e-mail] 发送便条很有用 - 他们的客户成功团队中有几个人致力于回答这样的技术问题.他们过去曾帮助过我！