ok, so microflows are run serverside in java and nanoflows are run clientside in javascript, so therefore technically you cannot call a nanoflow in a microflow, but this idea is about reusing the logic of a nanoflow in a microflow (and vice versa).
Consider the following scenario:
We have clientside validation, checking if a certain inputfield is valid cf. certain rules and logic. For a better performance and user experience, this logic is in a nanoflow, which is set as an on change on the input field.
Now, on save, we want do this same validation. But the save action is a microflow, so I either have to duplicate my logic, or I have to convert my on change nanoflow to a microflow. Both options are not ideal.
So basically, I think when creating logic in a sub flow, it shoudn't really matter whether it is a nanoflow or microflow, it is generic logic which I should be able to call from either a microflow or nanoflow.
Rules might be a good solution for this very specific validation use case. The main issue from my pov is that rules can be used only in decisions.
In my use case I need to define the editability of fields based on a complex logic. I want to put that logic into a nanoflow that writes the results into a non-persisted object.
The nanoflow has to be called
The ideal solution would be to define the logic in a naoflow that can be called both from another nanoflow and from a microflow.
Since a microflow contains all functionalities of a nanoflow and the Toolbox blocks are the same (from Mendix Studio Pro perspective, I don’t see a problem to interpret a sub-nanoflow as sub-microflow as soon as it is calle in a microflow.
This could be achieved by adding a Rules processor to the client side runtime, that way you can use Rules as a way to set up the validation and then use that in your nanoflow and your microflow.