Page with named views loading partially at first?


#1

CodePen: http://codepen.io/anon/pen/vObWBw

There are two named views in this CodePen, appContent for the main content area, and menuList for the sidemenu. It uses Firebase to support google login, which is only relevant here because it illustrates the problem:

  1. Make sure you’re not logged in, in the app. Click ‘Log out’ on the page if it displays.

  2. Click ‘Log in’. Log in is an OAuth Firebase re-direct.

Upon #2, when the page loads again the nav-bar and content area show for a period, before the nav-bar title transition and content actually appear. I’m not entirely sure why this happens, or how I can prevent it from happening? It looks quite bad.


#2

Can’t make it work in codepen iframe, it probably would need a Content Security Policy

Refused to display 'https://accounts.google.com/o/oauth2/auth?response_type=code&redirect_uri=h…d=951603183312-s6oevdvtfgq4vm8his8k6fa056990240.apps.googleusercontent.com' 
in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'.

About your problem, have you tried using ng-cloak?


#3

Odd - It works for me without a CSP on CodePen. I tried adding one, but it seems to be ignoring it because it considers it outside the head tag.

I haven’t tried ng-cloak for this, no. Should I be cloaking the app as a whole? I.e. the top-level ion-side-menus inside body ? That doesn’t seem to work, at least.


#4

Not the whole app, only parts that are bound to something that could take some delay.


#5

I’ve tried ng-cloak on the ion-nav-view’s, and as an alternative on the home ion-view itself; neither seems to have an effect. The visual result/problem is essentially the same as from this thread - I’ve tried cloaking various parts of the app without any change.

I’ve tried to create a new CodePen which I hope solves the CSP issue: http://codepen.io/anon/pen/vObWBw - Try that in an incognito Chrome tab or similar. Not sure how to make it work otherwise, unfortunately :frowning:


#6

So I’ve found out what the underlying issue is: The app is rendering while waiting for the route to resolve.

CodePen that illustrates, with a 5 second delay on a resolve: http://codepen.io/anon/pen/NqoXRM

This makes sense as there is no reason to hold up rendering the rest of the application for a particular controller to resolve, I suppose. So this is solved.