- Implement synchronous / asynchronous requests in a web application
- Write custom event handlers in JavaScript and jQuery
- Change the DOM based on events
- Use jQuery to make an AJAX request
- Use AJAX actions to change views based on async data
We're going to build on the Deaf Sinatra challenge, this time using jQuery and AJAX to submit our form rather than the default browser behavior.
All your JavaScript should go into public/js/application.js
. It should look
something like this at first:
$(document).ready(function() {
// This is called after the document has loaded in its entirety
// This guarantees that any elements we bind to will exist on the page
// when we try to bind to them
// See: http://docs.jquery.com/Tutorials:Introducing_$(document).ready()
});
You're free to start from your earlier code. Otherwise, you can use the starter code provided in source
Use the following jQuery methods to implement an asynchronous version of Deaf Grandma:
Read up on how to bind to events with jQuery if you need to.
You'll need to do five things:
- Bind a callback to be triggered when your form is submitted
- Serialize the data in the form to be submitted
- Use jQuery's AJAX API to make a
POST
request to the server - When the server responds, update the page accordingly (this is the asynchronous part — you don't know when the server will respond)
- Prevent the form to be submitted from submitting in the default way
What is AJAX?
The "A" in AJAX stands for asynchronous. Under this model your browser sends an HTTP request to the server from inside the current page, via JavaScript. Because we don't know when the web server will respond to our request — it might take 100 milliseconds or it might take 2 seconds — our browser can't "freeze up" and stop everything while we wait. Instead, we write code in a style that permits the response to return at any time and with any data.
Think of it as the difference between a video call on Skype (synchronous) and email (asynchronous). Or the difference between a restaurant that forces you to wait to be seated versus a restaurant that takes your name and phone number and offers to call you when your table is ready. The former is easier for everyone to understand; there are fewer moving parts and it's easier to estimate when you'll be seated. But if the wait is long it becomes frustrating. You can't go to a nearby bar while you're waiting.
When your browser is operating synchronously it has to sit and wait for the server to respond before it can do anything else. This is how a browser normally works, by fetching or posting to a URL (via HTTP) and waiting for the response. When your browser is operating asynchronously, it can send off a request at any time and continue on its merry way, but has to deal with the fact that the response could come back at any moment.
In a synchronous environment it's easy to handle errors, for example. We submit a request, we wait to see whether it succeeds or fails, and display a message accordingly. The world is stopped as the request is being processed.
In an asynchronous environment it's much more difficult. We submit a request, but won't know when we'll know whether it succeeded or failed. There's a period of time where the request is "unknown," which often means an extra state we have to display in our user interface, e.g., not just "succeeded" or "failed" but "in progress", "succeeded", or "failed".