Pluggable Widgets - Better Actions

17

Currently we have a few ways of getting data into a Pluggable Widget, namely through Dynamic Values etc. However, we don't have a way of getting data through actions.

Here's a scenario:

• Widget receives some content through a Dynamic Value
• User does something in the widget that triggers an action and has to wait for a value that comes out this action

In a current implementation, I will need to set a few properties:

• A Dynamic Value, for example an attribute
• An Action
• Most likely a second Dynamic Value that is set after I have executed the action.
• Most likely another attribute that indicates the action is still running.

This setup is already getting more and more complicated, especially when we might want to use more user actions.

 

So, we need a better solution for this… Brace for some technical widget advice:

 

Make the action.execute a Promise that resolves when the action is completed.

This may or may not work in its current implementation.

Currently an action has a few properties: canExecute and isExecuting. When you execute the action, these properties might change, which re-renders the widget. One way of circumventing (if my thought process is correct) would be to always execute and return a status in the return. More on that in the next point.

 

The action .execute should always return a Promise,

 

and the returnType of the promise should depend on the XML configuration:

<property key="action" type="action" expectReturn="true"> <caption>Data source</caption> <description /> <returnType type="String" /> </property>

This would either result in .execute returning

• Promise<void> in case expectReturn = false
  • This is the case if an action does not return something, for example ‘Open page’
• Promise<T> when expectReturn = true and a returnType is given

 

Going back to my first point, the Promise could be rejected on the basis of the action

• not executable (this is now ActionValue.canExecute)
• being executed currently (this is now ActionValue.isExecuting)

It is up to the user to catch the error with action.execute().catch(e ⇒ { … })

 

When Studio Pro encounters an action that expects a return, it will reject any of the actions that do not return anything, for example Open Page. Furthermore, it will enforce the action (Nanoflow/Microflow) to always return a value.

 

List of ReturnTypes

These would be your ‘standard’ returnTypes

• Boolean
• DateTime
• Decimal
• Integer
• String

 

If you want to get even fancier (see this as version 2.0 of my proposal above), we could even introduce two more returnTypes

• Object
  • This will result in Promise<ObjectItem>
• List
  • This will result in Promise<Array<ObjectItem>>

Both of these could be useful later on, because we can read data coming from the ObjectItem or ObjectItem[].

 

This is just the beginning of improving Actions.

 

In the current implementation we cannot have any input in our Action, besides an ObjectItem. In your Nanoflow (I am using mostly Nanoflows) your input would only be the Mendix object (listValue) and maybe contexts (dataViews surrounding your widget)

 

Why not adding inputs here as well?

 

My above proposal would look like this:

<property key="action" type="action" expectReturn="true"> <caption>Data source</caption> <description /> <inputType type="String" /> <returnType type="String" /> </property>

 

This would change the action from:

ActionValue.execute<T> : () ⇒ Promise<T>

to

ActionValue.execute<T,U> : (input: T) ⇒ Promise<U>

• In Studio Pro it would see this Action as some type of ‘Data Action’ and thus reject any actions that cannot have custom inputs, like Open Page
• In the case of a Nanoflow/Microflow this would result in it having an extra parameter with the name ‘Input’. By limiting the inputType to a certain type, like the above 5 ‘standard’ returnTypes, it would be easy to enforce this in Studio Pro

 

asked 2023-10-03

1 answers