Skip to content

Instantly share code, notes, and snippets.

@mdang
Last active November 29, 2016 16:33
Show Gist options
  • Select an option

  • Save mdang/b40c0d52e87d123bbf73 to your computer and use it in GitHub Desktop.

Select an option

Save mdang/b40c0d52e87d123bbf73 to your computer and use it in GitHub Desktop.
Lesson: Single Page Applications

Single Page Applications

Lesson Objectives

  • Explain what it means to develop a single page application
  • Explain the pros and cons of developing a single page application
  • Describe the different ways to implement a Single Page Application
  • Compare and contrast the roles of JS and Rails in a fully functional AJAX application
  • Explain how Rails differentiates between request formats and serves the appropriate content format
  • Use respond_to to create RESTful actions that respond with JSON representations of objects
  • Use $.ajax to consume the contents of a JSON API
  • Develop a basic single page application

Review

  • Ajax, what is it and why is it important
  • success, error callbacks
  • CORS, JSONP

What is a Single Page Application?

A web application or web site that fits on a single web page with the goal of providing a more fluid user experience akin to desktop applications.

All the neccessary code - HTML, JavaScript, CSS - is retrieved with a single page load, or dynamically loaded and added to the page in response to user actions. The page doesn't reload or transfer control to another page.

Examples
  • Gmail/ Google Calendar
  • Trello
  • Asana

Pros

  • Avoid full page reloads
  • Faster and more fluid experience akin to desktop applications
  • Save processing power on the server by doing more work on the client

Cons

  • A lot of the heavy lifting is done up front, resulting in longer load times
  • Force users to download the entire site when you don't know if they'll even go beyond the homepage
  • Requires JavaScript for the site to function. Depends on browser and user settings
  • Maintaining history (back buttons) becomes a problem
  • Huge implications with SEO. When a crawler sees a link, it will only request the base URL from the server leaving the fragment identifier off the request. Since there aren't any "real" pages being requested, it's the same page with swapped out content. Makes tracking page views trickier
    • Google's hashbang solution (#!) is difficult to implement and hasn't been adopted by every search engine
    • Hijax - progressive ajax enhancement that allows crawlers to still go through content (e.g. mikedang.com)

Fetch as Google: https://support.google.com/webmasters/answer/6066467?hl=en&rd=1

SPA Implementation

  • All the content on a single page, hide/show content areas (e.g. jQuery mobile)
  • Request the dynamic content with ajax from the server for each page

SPA's use the hash symbol (#) as part of the URL, referred to as the fragment identifier. They use it to identify what content section to display or retrieve when a link is clicked.

NOTE Fragment identifiers are never sent to the server. It's only processed by JavaScript on the client side.

Previously, there was no way to detect a hash change so developers polled in set intervals to check if the hash had changed. Now though, something we have that is widely supported is the 'hashchange' event we can listen for

$(window).on('hashchange', function() {
  //.. work ..
});
  • Thin vs Thick clients
    • Most of what we see tends to be thin clients, keep as much business logic on the server side as possible
    • For CPU intensive operations like image optimization, consider doing on the client and then sending to the server

Explain the role of JavaScript and Ruby in an Ajax application

  • JavaScript on the client side, using Ajax to make requests to the Ruby backend
  • JSON strings for sharing data

JSON

  • Review format of JSON
  • Why we use JSON as an interchangable data format as opposed to XML

Differentiating request formats in Rails

In jQuery's $.ajax, set the data type. On the Rails side, use respond_to to determine the proper response.

Why not just respond to AJAX requests with HTML?

  • Might want to update multiple parts of the page
  • Not sure what actions need to be taken when response comes back successfully
  • Increased load on the server for processing

Use respond_to to create RESTful actions

respond_to is a Rails method that allows us to differentiate between request formats

def index
  @posts = Post.all

  respond_to do |format|
    format.html  # index.html.erb
    format.json  { render :json => @posts }
  end
end

What that says is, “if the client wants HTML in response to this action, just respond as we would have before, but if the client wants JSON, return them the list of people in a JSON format.” (Rails determines the desired response format from the HTTP Accept header submitted by the client.)

http://apidock.com/rails/ActionController/MimeResponds/respond_to

Use $.ajax to consume contents of a JSON API

Start a basic To Do application

I Do Create an endpoint to create To Do's

We Do Create an endpoint to view To Do's

You Do Create the missing endpoints

Exercises

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment