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.
Related
Note: I am kind of new to web development so please help me through any misconceptions I might have.
I am trying to learn the MERN stack. As an example, I am trying to make a two page site with a homepage and an about page. I made a ./public folder and added an index.html and an about.html to that folder. Then I started by learning some basic express where I have this line which will let the server serve static files from the ./public folder:
// set static folder
app.use(express.static(path.join(__dirname, 'public', )));
After I felt good about this, I wanted to add React to my existing project. This is where I ran into some confusion. It seems like React doesn't allow multiple pages in my website; I saw this SO post. So, React is good for building single page applications. I also saw this YouTube video where the first three minutes explain the difference between traditional multiple-page applications and React SPAs. He stated that all the pages will be sent at one time and the react-router will intercept any page requests and re-render the browser with the pages it already received on the first page load.
So, finally we get to my question. Going back to my example, suppose my about page is VERY large, with a lot of text and images. Isn't that potentially wasteful if I load the homepage, but the server has to send the entire website including the large about page, even though I might never even click on the about page? Once it is all loaded, I understand that the client has a smooth experience going from one page to the next without having to contact the server. But doesn't it mean that the client experiences long initial wait times. And, isn't this wasting server resources by sending pages the user might never click on. And the problem only seems to get worse the more unique pages the website has.
"He stated that all the pages will be sent at one time and the react-router will intercept any page requests and re-render the browser with the pages it already received on the first page load."
This is an oversimplification that is at the root of your misunderstanding.
Your react app is going to be a small amount of HTML that acts as the document root, and then a fair amount of CSS and JS. This JS React app will execute to generate your pages based on how you have configured your views and wired them to any data model. Generally with a SPA like this, you will load one view at a time, and it will, if applicable, make a request to the server for any data it needs to render, which will generally be returned as JSON. Once the JSON is received, it will get parsed in the browser into the data model and the UI will update to reflect the new state of the data model. Critically, each view (if wired correctly) will only fetch data from the server when the view loads; furthermore, any images or other assets in the UI will only be loaded when the UI renders them, so there will be no prefetching that wastes resources.
Because the react components can basically act as templates, you can actually save bandwidth in this way. Say you had 100 product pages on your site that were identical except for the product information. If you were to serve a new HTML document for each page there would be duplicated bandwidth in the markup sent each time. However, in React you can define a single <ProductPage /> component that will fetch only the product information and load it into the markup template each time, removing the issue of sending duplicate HTML.
There are also additional ways to split up your react app using tricks like lazy loading, to only fetch the salient JS when it is about to be used.
So, no, using a React app does not mean that it fetches all the HTML pages and assets for the site all at once. While one could write a React app in a wasteful manner, most properly structured React apps should be smaller than the rendered totality of the site.
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)
I have graph with data in welcome page like widget(/welcome). when the user clicks the graph the page change to /home/default and the same graph should be displayed along with some extra data which is populated by Ajax call. What I want is to persist the graph data from /welcome into /home/default page. I don't want the data to go controller and back to the /home/default page. Kindly suggest.
In a nutshell, you need to set some state for the user and then when the /home/default page is rendered, you need to check that state and make corresponding changes to the presentation of the page.
This can be done either server-side (in the rendering of the page) or client-side (via Javascript adding things to the page).
If you do this client-side, then the state can be stored in a cookie, in LocalStorage or in a query parameter in the URL when you redirect. Then, you place Javascript code into /home/default that checks that state and adds content to the page dynamically based on the state.
If you do this server-side, then the state can be stored in a cookie or in some server-side data store and then when the /hoome/default page is rendered, your server side page rendering process can check the state for this particular user and modify the rendering of the page to include the desired content.
You have a plethora of options. The best solution depends on how your application is currently implemented -- whether in a framework or not, with sessions or not, etc. The principle whatever method you choose is almost identical: store a value and then retrieve it later.
Single Page Application (SPA)
If you aren't already using a framework, I would urge you to consider migrating to one as tasks like these are made infinitely more elegant in their implementation.
Service / Data Store
If you are building an SPA then you may not have to consider any of the options below... so long as it doesn't matter if the data is lost if the user performs a 'real' navigation that cannot be intercepted by the framework (for example, refreshing the page).
In Angular you can maintain a temporary data store in the form of a service. Simply store the data and then pick it up later from another controller. Similar functionality can be achieved in all other popular SPA frameworks:
Angular
Ember
React
Local Storage
Local Storage is available in IE8 and above and has a really simple API.
Angular: angular-local-storage
React: react-local-storage
Ember: ember-local-storage-adapter
jQuery: jStorage
IndexedDB
If you're into the cutting edge and aren't tied down by browser support, consider using IndexedDB. I don't recommend using this unless you are wanting to persist large amounts of data remotely on the client's machine. (It really does have bad support at the moment.)
Angular: angular-indexed-db
React: ???
Ember: ember-indexeddb-adapter
jQuery: jquery-indexeddb
Cookies
If your application is inflexible then cookies will be the easiest and least time-consuming. However Local Storage may be a contender.
Angular: $cookie service
React: react-cookie
Ember: ???
jQuery: jquery-cookie
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.
I have a client side router with which I can navigate through my web application with hash based urls, like http://example.com/#home. With the history.pushState(..) method I make the url more cleaner, like http://example.com/home. Now my problem is when someone reload the page, the url is unknown, because there is no hash in it. Is there a elegant way to fix this?
What it's meant for
history.pushState(..) is needed for single-page-applications to create an artificial browser history. That artificial history allows users to navigate via back and forward buttons and also to bookmark a "page" (there is only one, but it feels like multiple pages).
What you're doing
Now you're rewriting URLs to locations, which don't exist. On reload the browser navigates to that location and finds nothing, it doesn't know the relationship between your single-page-application and that new URL.
Solutions
You could try to fix this by creating redirections on server-side. Then you'll be able to read the current state. There are multiple options for redirects:
mod_rewrite - all to index except static folder
Redirect from an HTML page? (discouraged)
...
Keep the hashed URLs and use the saved time to work on real features.
I'd take the second option.