Hi since WeWeb can now make SPAs, how can I make loader animation when changing pages? Thank you
1 Like
Hi @khairul,
At the moment it’s not possible, you can suggest this feature in our roadmap
You can try to add a loader and show it if your content is fetching. And do the opposite for your content, show it if it’s not fetching
1 Like
I think there’s need because my page takes too long to load, even though the next page just contains one section. Is there a reason for that?
I think you have a lot of data if your page is too long to load
If you want, you can create a workflow on your page with a variable dataReady. On page load (before fetching), you set up the variable to false. And on page load to true
And you can bind this variable to your section and a loader
1 Like
Hey there,
Thought I would let you know this is now possible.
You can add a loader during page transitions here:
Currently it’s fairly subtle and you can only customize its color but we are working on improve it in the future:
That’s indeed @Joyce very nice! Question what are you guys thinking of when considering improving the loader? Thanks! 
Hi @ben 
I don’t have the detail of what the product team is exploring. If you have ideas / needs you’d like them to explore on that front, we’d love to know!
We’re collecting and reviewing all product feedback here.
Hi @Joyce
Is it possible to show a custom spinning loader between pages?
If not, does it mean the only solution would be to create an SPA with only one page and show/hide elements accordingly?
Not at the moment though.
If the spinning loader element was crucial to your app, conditional rendering could be a solution yes, but I would warn against using conditional CSS display too much. You can learn about the difference here: Conditional rendering | WeWeb documentation
Also, I would like to stress that every WeWeb app is a standard Vue.js Single-Page Application. You can learn more about that here: Multi-page sections | WeWeb documentation
1 Like
A spinning loader (or another element) is very important to me, cause otherwise there’s only the tiny loading bar at the top of an entirely blank page. Not a big fan of that UX.
I’m using conditional rendering, not conditional “display”. From what I understand that’s a viable, scalable solution?
I’ve read the page you provided. How does that impact using conditionally rendered sections?
Hello unlustucru 
I don’t know whether that’s exactly what you are looking for but this video might help you
Btw I think this guy makes really good video and tutorials.
@MrUnfreeze Skeleton loaders are very nice, but they would appear only once the user has arrived on the destination page—unless i’m mistaken.
My problem is the blank screen that the users find themselves on inbetween the current page and the destination page.
I’m not sure I follow your comment, “appear only once the user has arrived on the destination page.” Why wouldn’t the user arrive on the destination page immediately, after which the data begins to load?
I’ve managed to implement skeleton loading with some success. When a user navigates to a page, I display the skeleton loader while the data collection .isFetching.
It’s worth noting that depending on the order of operations, the fetching may be delayed and thus the user might see a prior state for a very brief moment, in which case @Mael’s recommendation to create a dataReady variable to control the loading state as opposed to the out of the box .isFetching attribute will probably produce a more elegant outcome.
Here’s a quick GIF showing the transition from skeleton to content:
1 Like
Yes
If you are leveraging multi-page sections, you don’t need conditional rendering.
Let’s look at a use case with a topbar, a footer, and 4 content items, you could have:
- 1 page with 6 sections and use conditional rendering to display only 3 sections at a time (the topbar, relevant content section, and footer)
- 4 pages with 2 linked section (the topbar and footer) and 1 content section. The UX would still be great on the published app because the topbar and footer sections would not be reloaded when the user changes page (the experience in the editor will not reflect that though)
You can do it either way. For a complex project, I would go with option 2 because it will be much easier to maintain than having everything in one page.
Does that make sense?
1 Like
Create a linked section with a full page overlay, with your decided loading spinner, text or whatever. You can create a div with absolute placement and 100% width and height. Set this background to your decided color.
When leaving the page, trigger a variable that loads this full page overlay. Since this is a linked section, it will hide the page change completely.
When user arrives on the new page (loads and displays behind the full page overlay) you can turn off the loader after all relevant data has been fetched.
I’ve done this after login, and I do a bit of fetching menus, loading collections and rendering behind the loader, and this makes user experience really good. I’ve made a complete “loading” system with various different types of loaders that I use around the page depending on what wait time I’m expecting.
1 Like
@Mael That’s weird, cause I’ve created a new page containing nothing but a piece of text just to test that, and still, I get a blank loading page in between.
@archenia_jsanchez Because seemingly Weweb doesn’t go from one page to another immediately; at least that’s what I’m experiencing. Idk why that is in technical terms, but there’s a delay between the current page and the destination page, that translates into a blank page, here with the built-in progress loader being displayed:
I’m really impressed by the GIF you shared, because it looks like your blue sidebar doesn’t get affected. Are you actually navigating to another page? If so, what kind of element is that sidebar? I’m using multi-page instances.
@thomlov That’s how my loader is set up (completely covering the page), but since every element (loader included) has to be on a page, it doesn’t stay there when navigating to another page. Here it is once I arrive on the destination page:
Even using multi-page instances, I don’t manage to get the result described on this WW’s article:
NB: I’m still on a free plan and therefore my app isn’t live, if that makes a difference.
It only becomes a SPA after publishing your app, so this will not work for you in the editor.
Published app also goes a lot faster, so you might not need a loader.
Also, make sure that your loader is in a multi-page instance that is present both on the page you are leaving and going to, then the loader will be present all the time.
It’s worth noting that I might have clipped the GIF a bit tight to obtain the desired file size—my Editor does go blank when switching pages, but can confirm it performs as a single page application when published to Staging, like @thomlov said.
To answer your question about which element, I’m using the native WeWeb Sidemenu element:
Another tip I think is worth sharing is to observe the log to “walk through” your app. You can see when workflows start and end, when variables change, etc. It’s helped me understand the order of operations so I can better control them.
