5

I have a single page application - which means everything on the server gets redirected to a single index.html file which does the heavy lifting and routing using the HTML5 history api ().

Now, I want to add a new landing page to the side - let's call it landing.html and I want clients to first get to landing.html when they access / and index.html if they access any other route.

Now IE9 does not support the HTML5 history API, so using "hash urls" paths like /books/authors become /#!/books/authors in it. Since the hash section of the URL is not sent to the server as far as the server is concerned all paths are / which means I can't route to landing.html or index.html based on that logic.

I've thought of a hack - redirecting URLs with / to landing.html, detecting #! on the client, adding a cookie on the server (or client) called notReallyHomePage and redirecting to the correct page based on the cookie on the server. This is really hacky and not a good solution.

What would be the correct way to deal with routing in this case?

My backend is in ASP.NET MVC but I don't think that's relevant to the question

Community
  • 1
  • 1
Benjamin Gruenbaum
  • 270,886
  • 87
  • 504
  • 504
  • Why not use the routing features provided by ASP.NET MVC. – Antony Nov 30 '15 at 07:46
  • @Antony because that's not how single page applications work. Routing is done on the client side - so you don't actually need to hit the server when the user clicks on a link. The advantage is that most routes only need JSON from the server (and not markup) and others can skip hitting the server altogether. – Benjamin Gruenbaum Nov 30 '15 at 08:00
  • 2
    You probably want something like an index / container page that has your routing logic. That page loads in partials depending on the chosen route. Since your routes aren't being sent to the server, I don't think it's possible to immediately load the correct page. – Cerbrus Nov 30 '15 at 08:05
  • Have a look at http://projects.jga.me/routie/. Seems like thing for the job – Antony Nov 30 '15 at 08:11
  • @Cerbrus that would still mean another round trip on the client. – Benjamin Gruenbaum Nov 30 '15 at 08:25
  • Yes it would. I don't know of a different option though. – Cerbrus Nov 30 '15 at 08:35
  • I might be missing something but why not config it using uirouter with `$urlRouterProvider.otherwise("/landing");` where `.state('landing', { url: "/landing", templateUrl: "partials/landing.html" })` with another state for index which will use the index.html in its templateUrl ? – Royi Namir Nov 30 '15 at 09:43
  • @RoyiNamir that would, for one, require loading Angular itself. – Benjamin Gruenbaum Nov 30 '15 at 10:15

1 Answers1

0

Hmmmmm... What's the content of landing.html? From its name I'm guessing it's a pretty simple page.

Couldn't you have its contents be a part of index.html and hide/show it according to the "first time user" logic? Or if landing.html is some weird page created by your marketing or something, then place it in an iframe which hides/shows according to the same logic.

(obviously when you show landing.html then you hide index.html)

Tom Teman
  • 1,975
  • 3
  • 28
  • 43
  • No, half the point of having the landing page is not to load index.html in its entirety. – Benjamin Gruenbaum Nov 30 '15 at 07:42
  • Well, in that case, it seems like your cookie solution is the best way to go about it. Like you said, call it 'landingPageVisited' or something, and by default '/' would redirect to landing.html, unless the cookie has been set to true. Doesn't sound *that* hack-y :) – Tom Teman Nov 30 '15 at 07:55