My best days are the ones I learn something and today a college shared the following link with me: https://success.outsystems.com/documentation/how_to_guides/front_end/how_to_call_a_block_action_in_a_mobile_screen/, and this immediately remembered the use case where i need to force a refresh on something that lives inside a block, from the parent.

First things first. Let me share what I typically do…

To take it simple, I’ve created a block where I added 2 images. I also added 2 DataActions to retrieve both images (one for each placeholder).
When the block is rendered, 2 random images are displayed side by side in the page:

If I need to force a content refresh of the block I typically use a DateTime control variable as a block parameter, to take advantage of the OnParametersChanged event:

And from the parent, i just need a local variable (set as input parameter to the block) and change it’s value

And this works as expected. Each time i press “Refresh” button:

1. RefreshOnClick updates InnerBlock_RefreshTimestamp value;
2. InnerBlock OnParametersChanged is triggered and refreshes GetLeftImage and GetRightImage, which fetches new images;

This is the most intuitive way to achieve the required result, however …

What if we want to refresh Left and Right images individually?

I could create 2 input parameters to differentiate both images reload requests, but we would require 2 new internal control variables to detect which one of them changed and this starts to sound weird.

Let’s change our block to take advantage of what the article teach us…

First we start by exposing the actions we need in the inner block:

In the parent container (the page):

1. We have 2 buttons (one to reload each image individually);
2. We use Javascript to trigger the action inside the child block (Version2);

You can test both versions working on this link : https://tiagomlcdias.outsystemscloud.com/BlogArticles/RefreshChildBlockFromParent

---

Final Thoughts

This implementation can be seen as a workaround to call block’s internal client actions that’s restricted natively, however this must be carefully used because there’s a hidden contract between the producer and the consumer.
If we find references of an exposed client action, there’s no findings on the consumer:

and if someone creates a typo, this automatically breaks the contract/functionality without any warning from the platform

However, IMO this pattern “fits like a glove” for the discussed use case.
Breaking the contract/functionality can be avoided by placing some comments/hints…