How to hide elements vs. disabled them on page load for better performance

How to hide elements vs. disabled them on page load on Weweb.

Big difference that impact your performance depending on the use case.

Let’s connect on Twitter: @victornocode

6 Likes

I always wondered what that conditional display was for, thought it was an old function. But thank you for noting the difference!

1 Like

Hehe it’s actually a new one :slight_smile:

You may have seen it come through as “Conditional rendering” in the changelog.

It will be renamed soon in the product because “Conditional display” makes it easy to confuse with the CSS display property and, technically, it is related to rendering.

You can learn more about it here.

1 Like

Out of curiosity, from a technical standpoint, after page load, how long does it take to display an element that is triggered ‘on click’ using conditional rendering vs. the standard css display property?

Conditional rendering seems underappreciated but I love the concept. I’m just trying to determine what elements it should be applied to and not get overzealous about improving page load time and potentially sacrificing a more fluid UX with user interactions.

I’m using the editor at the moment so can’t compare on the published site, but there is an obvious difference between the two interaction types.

Example - using the standard css display property there is a very smooth transition for a side element to open when a user clicks an a record. The side element has a large number of nested elements. Should I be applying conditional rendering to the whole element or just individual elements inside? If a user is navigating between multiple records it seems to be slower ux (conditional rendering) because each time the user clicks a new record it renders again.

Interested to have some more guidance about the do’s and don’ts when using conditional rendering!

I think you can think about this not as visual element but data.
For example, in your case, when your page loads your drawer (Edit workspace member) element shouldn’t have any data, so is just an UI with empty data because you haven’t selected any records yet. So using CSS display should be enough.

But when you have for example a table that displays a lot of information by default, you should think if you really need this table to display on page load or if depends on an action that the user performs after the page load.

So I would say:
When the element has loaded data by default (The different buttons in your tab): Conditional rendering
When the element it’s empty by default and only works to show/hide data from a selected variable (Popups, modals, etc): use CSS display

1 Like

Conditional rendering: the element is not “compute”, so when toggling the condition to true, everything is computed (can take more or less time depending on the complexity). Also some things only happen when an element is actually compute (creating internal variable for exemple)
Conditional display: the element is compute, so when toggling the condition to true, everything is smooth as this is just a css line which changed. But because everything is compute, it can slow the page.

Its a discussion also happening on the “dev” world, it’s the famous v-if (conditional rendering) vs v-show (conditional display).
The doc of vue is talking a bit about it, and you can search more info on the subject using these terms, general advices for web developement also apply here (we try to stick as much as possible to web dev convention)

Quoting the link above
Generally speaking, [Conditional display] has higher toggle costs while [conditional display] has higher initial render costs. So prefer [Conditional display] if you need to toggle something very often, and prefer [conditional rendering] if the condition is unlikely to change at runtime

Using conditional rendering can be a choice if you have a heavy componenent (complex chart, map) in a tab for example as well.

6 Likes