We have conditional visibility based on attribute and expression, but wouldn’t it be great if it was possible to activate classes based on a microflow or nanoflow?
This way the UI could be created more dynamically based on attribute values that are not available over one association and create the possibility to manage more complicated decisions for visibility.
I agree that there might be a possibility for slower performance, but that is the task of the developer to monitor and develop in such a way that performance is ensured. The use of Nanoflows would push the developer to use client side information, reducing the chance of performance loss.
The most common usecase for this feature would be the ability to go one or 2 associations deeper into the model, which (in most cases with ui) are already available client side when retrieved over association, but just not available on the screen.
If this is to be created, it would need some best practices, but these would ultimately boil down to the same best practices as we all should already be familiar with.
This idea sounds very good, but in “normal” visibility/editability conditions (can) slow down the performance. Using a microflow/nanoflow in this case decreases performance even more.
In addition, this is only useful for the developer. At most, the user may suffer from it.