There are few relative minor differences between the Html generated for a reactive screen block vs an OutSystems reactive widget that inhibit the overall functionality of user based reactive screen blocks.
1a. When creating a screen block, ServiceStudio should automatically include an optional, but non deletable, input attribute called ExtendedClass.
1b. The screen block's ExtendedClass should automatically be included as a CSS Class on the top most HTML element that OutSystems generates for any user reactive screen block.
2a. The OutSystems generated Html for a user screen block should not induce an additional wrapper element around the user reactive screen block.
2b. If a wrapper dom element is required by OutSystems to generate a user reactive screen block, there needs to be Developer documentation on what gets generated, how to identify the overall screen block, the distinction between the OutSystems wrapper element and the start of the developer user Screen block, in addition any needed design patterns around customization and inheritance of attributes and events between the two dom elements.
Note that user reactive screen blocks that are contained within a flexbox based parent container are not displayed the same way their native OutSystems widget are.
To correct this, the dom must be inspected such that a one can create a hard coded CSS rule against undocumented wrapper dom element that fixes your user reactive screen block display issues and hopefully does not break anyone else's user reactive screen block. The situation gets more complicated with a set of nested reactive screen blocks where a CSS rule expects a certain hierarchy.