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 (pushstate).
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
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)
Related
I'm building a react web application that has around 7 different routes. The landing page is a sign in route that has a background image it retrieves from cloud storage (according to the url params, as several different client stores will use the domain). I'm trying to choose between client-side rendering or server-side, SEO is not important for me. I would like the initial page load to be fast but also the subsequent page views, and from my reading CSR is better for subsequent pages and SSR is better for initial page loads
But I was unsure if route changes are considered subsequent page loads? Because doesn't the window tab itself not actually go through a full page reload(?) ( for example in comparison to when I enter a url in the browser and click enter) So if this is truly the case, is SSR just as good as CSR for these route changes in my app?
Also, I know initial page load is faster with SSR but I was wondering if maybe the CSR initial load page time is also good enough usually? Meaning the user experience isn't hurt
I have to display a third party site, say site X, upon successful authentication from my existing APIs, as it is, on my web site. But due to certain reasons, I cannot afford to use an iframe, which is the most obvious solution in this case, as that will expose the site X's URL when inspected in browser. So, I landed up on another idea to create a web app whose front end is written in AngularJS and use existing back end APIs written in C#. The application will basically have two pages, login and main page. Upon successful authentication from API on login page, user is navigated to main page. Now main page, I have to show another site. So, instead of using iframe on main page having source as site X, I will display an iframe with source Url as one of my API endpoint, say baseURL/data. So, this API will basically fetch the site X data and do something like server side rendering and return me an exact replica of site X which I will load in my webapp. When user will navigate on site X and route to any path, that route will be sent to same API and now the response will be replica of baseURL/data/route. Even though my API endpoint is now exposed instead of site X url in browser console, I am okay with this because that API is protected somehow and cannot be accessed as it is without proper authentication which I am doing in my case on login page.
I want to get more thoughts on this entire scenario and possible alternatives. Also, if anyone can suggest if/how it is possible to write such an API. I can think about changing AngularJS or C# as technologies in my project but definitely that's not the most go-to-solution for me. Any suggestions and thoughts are welcome!
Edit: I have created a site using a static site generator. I want my users to be able to access that site only if they are 'my users' i.e. authenticated by my APIs. But, that generator is not allowing me to integrate my API and neither I can get the static assets like .html, .css and .js files that I can host on my own server and integrate my authentication API. Hence, I had to think about a workaround like this.
I am trying to implement a javascript router with window.history API. I've been using ui-router for a long time but I want to create my own router for my smaller apps. Everything looks fine until meeting a problem like this: I am serving my page at localhost:8080/index.html. I am routing in the page with history API related properties. When I click to a route, I lose the index.html part. For example url becomes localhost:8080/home. When I directly try to go to that state, as you expect I get 404 error naturally. How can force to route over index.html to that state?
HTML5 history (pushState, etc) works by rewriting the URL on the client side. Hence it needs the server to also be able to rewrite the URL, and load the same index.html file whatever the URL.
Without this server rewrite, the two possible options are :
Use a hashbang JavaScript router based on URL like /idex.html#!/current/path
Do not use JavaScript for routing, and just rely on server directory structure to serve different file for each endpoint
For rapid prototyping of my concepts, I'm using Express with Mongo and so far have set up a mongostore cookie storage system.
My question: Is it possible, after logging in/authenticating/etc, to have everything occur on the same page, aka '/game'? I still want multiple views and routes to be rendered, but using different areas of the screen, or overwriting elements on the screen, with the base game.jade still visible.
I essentially want to have the user on the same URL the entire time, but still use multiple routes and views. I looked into stuff like '/game/:stuff' but that still changes the URL I think.
FYI this is called a single-page web application.
One common way to do this is to route to different views using the hash token. For example, all of the following URLs would be part of the same page:
/game#introScreen
/game#level1
/game#level2
Your client code can respond to changes in the hash portion of the URL and change the display accordingly. The page does not reload and all your JavaScript code (and variable state) remains in place.
If you're using a framework like angularjs it can help do the routing for you.
I am trying to create an MVC web app, without any MVC framework. What I've done is to make an index.html with a section were all the views are loaded, when a user wants them. This though creates the problem that when a user types a direct url like: www.foo.com/bar - it doesn't point him to the view bar. I know how to point the user to a webpage with a router file, but I don't know how to do it, when the view is only a part of a page and it is opened in another page. Can I do this with the router, or how can this be done?
For clarity I am running php on the server side and I use AJAX calls to get the views.
Since all the detail pages do not have a real page server side you need a server side component that rewrites the URLS to a frontcontroller page that loads the index.html and that bootstraps that page with the correct view.
I suggest to take a look at the mini PHP frontcontroller component Silex
If you do not want to use such a component you can always do this using something like apache rewrite rules and your own PHP landing page. This is rather simple for smaller MVC websites. If you're going to build a bigger one I suggest to pick a few smaller frameworks that each do one thing well. I have done this using Silex and Twig on the server side and jQuery and Knockout on the client side.