block_id什么时候需要更新?

Dan*_*man 3 slack-api slack

我试图了解模态中唯一 block_ids 的要求。具体来说,输入块的现场文档中的此说明:

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

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

除了这似乎与“使用模态”更新文档中的注释直接矛盾(以及views.update文档视图参考中的相同注释):

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

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

(我想这里的一个子问题是,block_ids的唯一性范围到底是什么?我们已经有了action_ids和external_ids之间的区别,action_ids只需要在一个视图内唯一,而external_ids需要在“所有视图”中唯一在一个团队中”;block_id 是第三个类别吗?)

Wil*_*opp 8

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

\n
\n

这里的简短答案是 block_ids 在大多数情况下不需要是唯一的。我们的大多数 block_id 都不是唯一的。例如,我们有一个模式/视图,用户可以在其中设置定期民意调查。该块的 block_id 是set_up_recurring_poll。这个 block_id 不唯一是没有问题的。

\n

这就是我们的默认方法:为 block_ids 选择非唯一的、人类可读的名称。block_actions正如您所提到的,当 Slack 发送/有效负载时,这些也是最容易解析的view_submission

\n

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

\n

这有点抽象,所以我举两个例子:

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

plain_text_input更新具有块的表面

\n
    \n
  1. 想象一下您的应用程序打开了一个有块的视图plain_text_input
  2. \n
  3. 用户在此块中输入一些内容,例如“Hello World”
  4. \n
  5. 然后,用户单击视图中的按钮,您的应用程序决定更新视图,但在视图中views.update保留相同的块plain_text_input
  6. \n
\n

如果在此调用 中views.update,您的应用程序将 block_id 与您的应用程序在步骤 1 中使用的 block_id 保持相同则用户输入的“Hello World”仍将存在。

\n

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

\n

因此在这种情况下,如果您的目的是清除plain_text_input,则使用不同的 block_id 。如果您的目的是维护用户输入,则使用相同的 block_id。

\n

static_select更新具有菜单的表面

\n
    \n
  1. 想象一下您的应用程序发布了一条带有static_select菜单的消息
  2. \n
  3. static_select用户选择菜单中的选项之一
  4. \n
  5. 然后,您的应用程序会更新底层消息(使用chat.update)。之前的消息和更新后的消息之间的唯一变化是您的应用程序在static_select菜单中添加了另一个选项
  6. \n
\n

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

\n

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

\n

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

\n
\n

我推荐并且对我们有效的总体方法:

\n

默认使用非唯一的、人类可读的 block_ids。如果您碰巧遇到这样的情况,Slack 根据 id 缓存块内容,这会阻止您执行某些操作,那么向块 id 添加运行时生成的随机后缀,这将破坏 Slack缓存。

\n
\n

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

\n
\n

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

\n

因此,您不能在完全相同的消息、视图或 app_home 页面 \xe2\x80\x93 中使用相同的 block_id 两次,但使用相同的非唯一块 id 来驱动“升级”按钮是完全可以的在一条消息中。即使同一条消息被发布多次

\n
\n

最后一个想法:对于诸如此类和类似的问题,您可能还会发现向开发人员发送注释很有用@s​​lack.com\xe2\x80\x93,他们的客户成功团队中有几个人致力于回答技术问题,例如这个。他们过去帮助过我!

\n