I would like to understand better how “visibility” works in the UI Builder, and how components are mounted & un-mounted…if this is a silly question or one which has been answered already, I apologize
I believe toggle of ‘visibility’ on a component simply changes its style to display: none;. I think this means the component itself is not unmounted — correct?
I also read in another support topic (here) that children (components inside) of a component which gets its visibility set to false are un-mounted when the parent component gets visibility set to false.
This implies that children are mounted when a parent component has its visibility change from false to true.
I would love for someone to confirm my assumptions above (or dispel them with more info).
Another (kind of related) set of questions I have revolve around “On Before Mount” vs “On Mount”… and also “on Before Page Enter” vs. “On Page Enter” — what is the difference exactly? When would I want to put logic into one but not the other?
No, the component is fully removed, not just hidden. On front-end language: we remove a node from DOM.
The component not unmounted(component state still alive) but it’s hidden(removed from markup)
Yes.
You can see descriptions of these handlers in UI Builder
On Before Page Enter - This event is triggered immediately before the page is loaded or reloaded. On Page Enter - This event is fired when the page is loaded or reloaded.
As for the difference, On Page Enter is called at the first page render(some elements already on the scene), and On Before Page Enter is called before we try to render something.
Unfortunately, I couldn’t think of some fit example, and for me, there are not pretty many cases when choosing the right handler will be critical, but…
Before Enter - we could load data that need for us in any case, for example - the version of our app, to choose which API we must use. Or check if the user could get access to this page and make redirect.
On Enter - we could start to load data that needed to render UI.
Also, since there are some technical things that I may not have been entirely correct in, I can request that the person who designed it take a look at your questions and correct the inaccuracies in my answers. Do you want it?
Thank you so much for these answers, really helps me to wrap my head around things! I don’t think I want more info (unless what you said isn’t quite correct )
Thanks @Alex_Klein for these great questions. @Dima : remains to be clarified what mount/unmount really means. Is it creating/destroying objects in an object oriented sense?
Having read through Mark’s reference, it leaves open for me what the difference is between unmount and display=false.
Both seem to remove elements from the DOM. display=false keeps a state. Does unmount in addition destroys the React component instance?
when changing display=false (visibility=false) for a ComponentA it still stays mounted and you have access to the component to be able to set display=true
However, it stops rendering its children (UI elements and other inner components), for instance, if your ComponentA is a Text component you won’t see any text on the Page. And the component is still in the memory (mounted) and you can use logic to modify it.
In case your ComponentA is a container (for instance Block) and it contains other component Text/Buttom/Input/etc and setting display=false and it stops rendering its children all the inner components will be unmounted
ComponentA (Block) `display=false`: // it's mounted but doesn't render any UI
- Text: // it's unmounted and you do not have access to the component in logic
The main idea of the approach is to be able to:
when hiding a component keeps a reference to the component and its state
when hiding a component unmount unnecessary children components to release memory and improve performance
in case you need to just hide a component but keep children states you can use the CSS property display:none
Thanks for clarifying @vladimir-upirov — we are building logic such that children inside of a block get data from the database in the event of “On Mounted”, and we want this logic to be executed each time the parent component is made visible. So the way things are structured in Backendless works for us
)