A native way to run a block action from the consumer screen/block 
34
Views
5
Comments
New
Frontend (App Interfaces)

Many times, when developing an application, I have an action within a block that I need to trigger from the screen that uses it. 

I had many cases where this happens. For instance, let's say I have a button that will validate the the form within a block in the parent screen. I want to handle the validation just inside the block, and will need to perform the validations within it. 
Or when you want two blocks to react with eachother, but don't want to join them on a single block. Or even when I just want a button to perform an action that is inside the block.

Currently, there are indeed some workarounds for it: 

But things get complicated when you have many blocks inside the screen, and this end with many "dummy" screen variables, too many screen actions just to perform an action that is already inside the block, or refactoring the screen/block to join them against your own will, and increasing development time.

In blocks, the communication between the block and the consumer screen block are triggered by Events. It would be nice if we had the possibility to consume a screen action from the block, like setting it to "public" so you can run it from the parent. And would be way easier to manage this actions from blocks inside a list, so you would only need the row number to trigger the action.

This issue brings many questions on the forum as well, like:

It would make the development cleaner, easier to follow good-practices and follow the low-code philosophy.

Hi, Daniël, thanks for answering.
Yes, these Forge components help some of the instances of the Idea. However, It's not actually what I was thinking of. Trying to be more specific:

My suggestion is not accessing the Web Block data from the parent itself, since it's easy to do it with events, but run an screen action inside the Block from outside, in a native way. Basically the issue highlighted on the community posts I've shared.  

Actually, there really do exist two forge components that kind of do what I've described:
https://www.outsystems.com/forge/component-overview/597/event-system-o11 for traditional web 

https://www.outsystems.com/forge/component-overview/10760/event-system-reactive-web-o11 for reactive

https://www.outsystems.com/forge/component-overview/20565/custom-events-odc for ODC


But these components could create confusion when handling, since 

  • There is no way to know which actions are "public" from the parent screen until you search for the EventHandler component inside the block    
  • If someone (let's say a junior) who doesn't know about the EventHandler block change the action name, he may forget to refactorate in the component and get unexpected bugs.
  • It's not that intuitive, and needs a more complex handling, even more when working with multiple input parameters
  • Finally, this is probably a personal issue but I will need first to convince my tech lead and wait him to add the forge component to the environment instead of having it built-in xD

There are indeed many possible workarounds for this issue, but they demand a bigger knowledge and implementing it increases development time for a simple task. 

Being able to quickly call a screen action from a block like "WebBlock.SampleAction" would be a nice development life improvement to be on Outsystems radar.

Hi Guilherme,

I think the reason why they haven't enabled us to do this, it is that this isn't how OutSystems intended blocks to be used.

Blocks are intended as layout templates, and aren't supposed to have business logic.

Kind Regards,

Nathan Hobbs

Hi Nathan, thanks for sharing your point of view

I get your point, I know the web blocks are mainly used for closed components and front-end libraies, but I really didn't know about web blocks having some business logics is against the best practices. There had many times I would use them to have better encapsulation of the system I`m developing, and keep them in a Core Widgets module with some business logic - at least it was I'm used to do. 

Even so, my idea shouldn't limit to business logic, though. It could have just front-end logics, and even this way there are many times I would want to simply be able trigger a screen action that does something inside the block front-end logic, but couldn't without working on some makeshift solution like updating a dummy input parameters to run the "OnParametersChanged" event, and since there are forge components and community posts that I shared on my coments that try to replicate the idea I'm proposing, I was thinking that it was a common issue between developers.

Let me know that I'm still wrong about the Web Block functionalities even with this explanation


Thanks, Guilherme

Hi Guilherme,

Yeah I've put business logic in them before in trad web development, but the OutSystems architecture course say it's a no-no.  I do wonder how much of it is revenue based, to encourage you to use more screens!

(I had a reporting screen with 60 web blocks in it, each for different report, wrapping each webblock in an IF(Report="Sales Report") type thing to avoid duplicating the filtering functionality!)


I can't see them adding something that would go against their own best practices, so you'll probably have to stick to a dummy parameter.


Kind Regards,

Nathan Hobbs