Error message appears before user has time to process prompt

[neil.gebbie]

Hey, we’ve built a plugin that if a certain attribute of a field has been modified we show a prompt and then based on that prompt’s decision we send a message into slack. Everything is fine except we get a little toast in the bottom right hand saying that it’s taking too long. While this is fine for engineers - our editors will likely get spooked by this, and it’s kind of untrue - as the editor is processing the prompt.

The specific hook is onBeforeItemUpsert and here is an example of my code (some nested code removed for brevity and sensitive info).

connect({
  renderConfigScreen(ctx) {
    return render(<ConfigScreen ctx={ctx} />)
  },
  // creation and update of records
  onBeforeItemUpsert(item, ctx) {
    return masterMessager(item, ctx, 'created or saved')
  },
  // delete of records
  onBeforeItemsDestroy(items, ctx) {
    return masterMessageLooper(items, ctx, 'Deleted')
  },
  // Publishing records
  onBeforeItemsPublish(items, ctx) {
    return masterMessageLooper(items, ctx, 'Published')
  },
  // Unpublish Publishing records
  onBeforeItemsUnpublish(items, ctx) {
    return masterMessageLooper(items, ctx, 'Unpublished')
  },
})

export async function masterMessager(
  item: ItemUpdateSchema | ItemCreateSchema,
  ctx: OnBootPropertiesAndMethods,
  actionTaken: string,
) {

// some code removed
  const confirmation = await ctx.openConfirm({
    title: `some title`,
    content: `some message`,
    cancel: { label: 'Cancel', value: false },
    choices: [{ label: 'Yes, Save', value: true }],
  })

  if (!confirmation) {
    return false
  }


// some other code removed...

return true
}

If any more info is required please let me know. Thanks!

[roger]

Hi @neil.gebbie, welcome to the forum and thank you for the detailed report!

As far as I can tell, you’re doing everything right. This might be a bug on our end. Let me check with the devs and get back to you as soon as I hear back.

Sorry about that!

[roger]

@neil.gebbie, I just wanted to let you know that we’ve started our investigation into this issue, but we don’t have an immediate resolution for it yet. It’s an unintentional side effect (meant to detect slow plugins that do background tasks, which isn’t applicable to your use case), but the fix isn’t trivial.

Is this blocking work for you? While the devs look into what we can do, can we (as in support staff) maybe help you think of some workarounds, perhaps…? If you can please tell us a bit about your intended use case (what is the prompt supposed to do?), perhaps we can find some other less intrusive/scary way for your users to accomplish the same thing?

[neil.gebbie]

Hey, it’s probably ok for a few weeks. I can make some changes on my end (Such as putting a little banner above the field or some other alternative). I’ll do my best to explain the use case, and the reason why I couldn’t use the solution provided by Dato - as you do provide the functionality about 95%.

We have a radio group “page_type” (of type string) which is nested inside a “static_page” model. Depending on the choice of the page_type in the example below(in my second reply) you would say “Anytime we save/update/publish anything that is “important” we want to send a slack message via a webhook”

Now - Dato provides VERY similar functionality but it’s missing the granularity of targetting blocks nested inside models. See below:

For me to “avoid” having to do the manual plugin work we need an extra filter something like “Add a Condition → Trigger only on specific blocks → Trigger only on specific block choice” or something very granular like that.

I’ve seen this feature request here: Trigger webhook on field change? which I believe will cover our use case, but with all things SWE it’s easier said then done…

We can live with it for now and/or find work arounds if anyone complains. If you need anymore more info let me know. Thanks.

[neil.gebbie]

Your forum only let me post one image, this is the image I was talking about “an example”:

[roger]

Thank you for the detailed example, @neil.gebbie!

Does this mean that your plugin would pop up a modal asking “Do you want to send a Slack notification?” on every record update? Because you can’t tell whether the specific block caused the record update?

A potential workaround (negating the need for a plugin) could be to do what matjack suggested in the other forum thread, to just diff the webhook’s payload entity vs its previous_entity to determine if the field/block !== the previous one. Docs for that here: Webhooks — DatoCMS

We’ll still look into the timeout warning (because 5 seconds really isn’t a lot of time to answer any sort of modal), but maybe that can help you in the meantime?

Or if I misunderstood where the modal comes in, sorry about that! Please feel free to correct me.

[neil.gebbie]

Hey, thanks for your quick replies. This would require us to set up {something in the middle} to transform the webhook payload before it got “passed on” to Slack.

What we have works for the moment, I’m likely not going to change it. The prompt is a “nice to have” - it wasn’t part of the requirements from our editors, but it’s a nice touch to what we’re trying to do. I can likely just replace it with toast, a banner, or a conditionally shown banner based on the selection, all good.