There are many approaches to it, depends on the need, use case and quality of it.
Here are some examples done in blueprints, recently done in forums as demo with interfaces and components.
These are the interactions .
In terms of your underlying questions.
1- Should UI be player side or interaction side ? Think about the interface and interaction as two different systems, they don’t have to tell something to each other. Interactions can be authored on player (interactor) side, that would be the appropriate approach. If a menu needs to be opened interaction system on player can tell this and hand over to the UI. UI shouldn’t be authored there, it should author itself. When a menu no longer is needed UI logic should do removal without the need of the interaction event. Also this approach would be valid in multiplayer too and more controllable. Actor UI couplings is not a good practice, it can be perceived as more work but in long run it would be less work.
EX: Interaction/Dialogue/Shop menu instigator != valid, in range, or instigator reference changed then maybe it can be a good time for the UI to auto close itself.
Subsystems are the correct home for these in modern unreal terms but depends on scope. For larger systems push, pop, pull layerings are common practice.
EX: interaction dialog(talk)->DialogueMenu(Barter, ask directions,etc)->BarterMenu
Interaction and dialogue are hidden collapsed and hold at stack in background when BarterMenu introduced.
Barter menu closing destroys it( less used / loaded)
Interaction dialog pops (since we are still in range as assumption).
2- Performance wise which one is better? A commonly used UI can be visibly collapsed rather than destroyed and reused like a pool. This can be a small widget like “press E to” or a bit bigger one. I don’t recommend bigger ones since it feels like a good idea but inventory menus, barter menus can contain many references and additional memory links so a working menu with complex logic can better be closed since if the logic changes it can throw errors or even crash things. A common practice in interfaces is not to hold state driven menus long time for no reason.
Another thing to add there is big difference between hidden vs collapsed in menus, collapsed doesn’t tick in slate, logically have no space allocated in render so use collaped not hidden as common practice where applicable.