Where is the best location/best practices for interaction related widgets such as a shop menu or a dialogue selection menu?

My pleasure, I am glad that it helps and I totally understand that it can be confusing sometimes.

Well in editor there is a memory inspector you can check, however more accurately Insights and GC logs will help but the main rule is quite simple: if there are no references to a widget, with some delay the garbage collector will completely remove it.

So lets imagine that you have a UIManager, some class, maybe a subsystem, but for now lets assume it’s the player controller.

This UIManager has a function like AddContentToViewPort(Class). This function when called creates the instance (CreateWidget), adds it to the viewport, additionally gets the instance reference and adds it to an array named CurrentCreatedWidgets.Lets make another function RemoveLastCreatedContent(). This simply gets the last entry in the array → RemoveFromParent() → then RemoveFromArray.

Player does something in the menu and eventually closes it.

If closing is done from inside the widget with RemoveFromParent, since the player controller still holds it in an array as a reference, the widget will actually never be destroyed. It will stay in memory.

If closing is done from a function in the controller, lets say RemoveLastCreatedContent(), this would clear the references connected to the widget and eventually when garbage collection runs it will be gone.

Even sometimes RemoveLastCreatedContent() can have an additional ForceGarbageCollection() to immediately do the removal. This is not a good practice in gameplay menus, HUDs etc. However it can sometimes make sense on state-driven menu panels, menus that cover the screen and where the player can only interact with this (like pause / options menus) since the load on the game thread is more stable, leaving some room for a forced garbage collection.

Garbage collection is something unique. I don’t know super deep how it works on engine level but I know it tracks certain timings and game state to trigger a collection, so it decides a bit by itself. It is good practice to leave it alone most of the time (not always). It is expensive and can stall the game thread. I also don’t want to misdirect you about garbage collection but you can see some useful information in the Insights window.

Also as spice from my side: Don’t know how you are into it or your skillset focus but if you are going to deal with this thought it can be a good idea to share some tutorials.

If you are new into interface systems, technical ux, interface architecture and you are into it (not knowing your background) there is a lot of documentation around topics in many different development environments. Still I should warn that not every advice is meaningfull and helpfull in the long term, majority of tutorials are shortcuts, so I strongly suggest making mistakes, learning from mistakes is the best experience ever can be. However wisdom is always something to seek and find.

With that said accessing the right information and evaluating the architecture and approach becomes very important, its not very easy nowadays to navigate correct information in the sea of information. UI systems can get quite sophisticated and mistakes there can severely affect UX and even gameplay. Unfortunately this is quite common in UI development even in experienced teams.

Here are a few tutorials that can help you kickstart things.

This one is brief but a nice starting point.

Blueprint approach that is still scalable and proper. Seems leans on more default engine components and features more as a series of tutorials

C++ example, you can just skim it for the general approach.