Episode 24: JQUERY and AJAX

I’m going to keep this as short as possible to explain the analogy of what I believe jQuery is.

In the nitty gritty codes of a website, you have the following

• your logic code where you actually write how computers make functions that do things
• your views file, where you display all your logic code in a somewhat user friendly way so you can see how the interactivity would work
• your controller, where you tell what parts of your logic code to link to elements in your view file.

I, believe that JQUERY is the controller for JAVASCRIPT. Although, you can’t really say that entirely, think of it’s as an analogy.

JQUERY is a JAVASCRIPT library language that makes it easier to write and read, for a coder. There are two types of JQUERY libraries you can use. One, of which is production and the other development.

Production JQUERY is for live apps where if you were to launch an actual website or app live, this JQUERY library will have to be compressed as you don’t want it to use up so much data. Development JQUERY is normally use for testing or development of an app or website. This allows us to have more creative control of it, and use as much space as we need to. To my understanding, it’s similar to how we write out all the code and then refactor.

JQUERY:

What can we guess from the word “JQUERY” to what JQuery does. Well, okay we know it uses Javascript but we can also say, stupidly and literally that it also includes QUERIES. A query is how a URL communicates its routes and data, and yes, that plays a huge part of a controller does in an app or website.

In JQUERY, it works a bit differently than some other controllers. Imagine that JQUERY is an ear and its listening for callbacks. What are callbacks.

CALLBACKS can be for two different things. It can either CALLBACK events or it can CALLBACK functions. We all know that functions in Javascript could be analogies for methods in our code.

EVENTS in JQUERY are like actions. You could say when an action happens, an event occurs. Same thing. EVENTS could be features like click , response, ready, mouse up, mouse down, load, unload. All of these are actions that when occurs, becomes EVENTS.

To download the JQuery library, you can do it manually via this link:

Download jQuery | jQuery

Or you can simply link in your js file (which is your view file) in the head section as such…

Now, on the JQUERY website it is much easier but I believe there are certain version and certain requirements to link JQUERY to a file. This is the one that works for us so far (Dear future versions, please use the same methods to do so, I beg you).

The next line or so the last line in the Document, is the file that is going to be our controller for our website or for our app.

INTO the Javascript controller:

In our controller, we first need to mention how the page is going to load. There are features like “upload” or “onload” but if we want to be safe, where our page loads everything up including images, banners, ads to be ready to run, we can use the “ready” function as such…

This line initialises THE EAR and tells the EAR what to do when it has listened to everything. Let’s check out our first sound or call back.

This is in context of building a Thermostat.

Let’s go line by line. “$ (‘#PLUS’)” is kind of our tag or so id tag. We use this tag to be referred to into our HTML element. For instance, we know that this whole thing is going to done via ‘something that clicks.’ We can logically assume that could be highly likely to be a button. Hence, in our html when we create our button, we’ll be setting that ID of that button to the name “plus”.

I mentioned the word ‘click’ is an EVENT that will occur when the following method is being run (function().) Then, this calls two methods and this tells the ‘thing that is clicked’ that “HEY, if you are clicked, execute this following methods or things to do. In this case, since you don’t know the context, the thermostat increase the temperature and the methods update, updates the number from its initial state.

Note: What is interesting about the JAVASCRIPT controller is that unlike the RUBY controller I’ve learnt, JQUERY expects you to be very specific with your steps. Imagine it’s like telling the computer to execute a number of steps to reach and outcome, and it needs you to be as specific as possible.

It’s exactly like this scene.

I like to think of this as a little man who does your task. You will give him this instruction sheet of tasks, and then throughout the day where you won’t see him, he’ll being doing these tasks according to your instructions. You won’t know until he’s done what you want till he gets back to you. Similar to Chinese whispers, if you want the right whisper to come back, you need to give your instructions as specific as possible.

It’s a lot to take in, but this is an example setup of how you will have your controller file link to your HTML file.

In index html, on line 9, you can see I’ve linked the file there. That way, the HTML file knows which controller to listen to.

On line 21, you can see the button’s id is “plus”. The “plus” method we talked about is mentioned in our controller on line 6. Since you understand the basis of the concept I hope, you can get an overall picture of how the HTML file talks to the controller to tell each ELEMENT in the HTML file of what to do.

Note: Makers Academy defines in a really good way mentioned below:

user input -> event listener -> update model -> update view to reflect change in model(outcome)

Note note: The purpose of having a control file is to have all your connections listed down inside this file. If your connections have conditions on what directions to go in (Say and if and else statement, if yes go right if not go left kind of thing), you would also want to do it in your controller file. Remember, keep the purposes of your file seperate. In our case…

• index.html is where our code is being displayed with elements
• jq.js is where our routes are being managed to say “this code goes to this element”
• Thermostat.js would be where all the methods of our code lies.

If every file has a singular task to do, life would be easy for all our code to execute and it would be easier to spot an error.

AJAX:

Asynchronous JavaScript and XML. Yep, that’s what it is. It’s simply a crazy lingo term (I’m kidding). AJAX is part of JQUERY that aids data to be passed through the browser and sever using Xml-Http-Requests.

How it shortly works:

• AJAX request get triggered by your Javascript code.
• Your javascript code sends a request to a URL to get some data
• When the data is received, a callback function is used to handle the response

The request is occurring at the same time as your rest of your code, which makes it vital that a callback must be used to handle the response. This allows us to use methods like gets or posts. Although in RUBY, we use “get” or “post”, in JQUERY, it’s the same except with a different syntax:

• $get(‘’)

What’s special about AJAX is that it can run webpages simultaneously without having to reload the page! This means that every time there is a change to your website, the page won’t have to reload! You can see the interactivity all happen on the page that your on!

A curious wonder about APIS:

I’m touching on APIS as one of the challenges that we had to apply a weather api in our thermostat project. It’s quite cool because you are actually taking in data from the world’s weather and applying on your site. It basically is a hash that contains all sorts of stuff from the temperature, to the weather, the city name of course and even the icons (a designer’s dream).

However, what are API’S to begin with? First, it stands for Application Programming Interface. Second, it specifies the interaction between software components. Third, a good analogy that I briefly read about APIS was by David Berlin. API works like a electrical wall socket.

If we think about what an electrical socket does, it transfers electricity through wiring to our appliances. We know that sockets also have certain energy levels they can take and certain designs depending where you are. If we wanted electricity, we wouldn’t have to worry about the cabling structure or how it gets it, we just have to depend on the structure of the wall socket to provide us what we want (electricity )

It’s the same concept for APIS. We can depend on APIS to give us data in a format that is easily structured and that displays data in a way software can understand and translate that for us. The magic thing about APIS and code is that there’s no problem with originality because there are certain ways to write different structure of code.

For example, let’s say I wanted to include the weather data on my website. Instead of recreating and gathering all this data from scratch, someone’s probably thought of this idea and made an API for us. We can then just grab this API and display it in a way that’s different or use it in a different way! As the world is growing more fond of the digital world, APIS are becoming more popular to the point where there is an API economy for more data formats to be constructed. It’s a big thing and you can read more and briefly about APIS in the link below:

https://www.programmableweb.com/api-university/what-are-apis-and-how-do-they-work

So, now that we kinda know what APIS do, let’s take a look at how I’ve required an API, in this case a weather API…We’ll go line by line.

• Line no.1, we are calling a submit id and saying when something (in this case, button) is clicked on, it provies us the data. It begins with a method as we have “function()-
• Line no.2 we are assigning the data submissions coming from the user input to the variable city
• Line no.3, we have a get method (which gets the data for us) which is getting the data from the api.

This is where it gets interesting because the format here is where we see how our weather data is getting transferred to our api key. If we go back to thinking how our API works like electrical sockets, if we want our current of data to transfer to us, we ourselves would need an API KEY or so socket.

So, if we read the line, the link in blue is the online API where we are getting the weather data. Then we have the variable city, which is the user’s input of what city they want to see. Lastly, we have our api key listed which means the data will travel from one place to another.

By doing it this way, we are allowing users to input data to what country’s weather we would like to see! All right, we get that so far, now let’s look at the three lines but before I do that…let me briefly show how the data is stored.

If we type in the weather api link, choose a city and paste it in our URL, we get the following in our browser.

What’s incredible is that this is all the data we can access. So, in our code, we can actually choose what data to print out or grab from this api.

In which case, I have grabbed the temperature which is an array of a hash. I have grabbed the name of the city.

Further down in the code.

For fun, I’ve also grabbed the icon but I have had to interpolate it depending on what the user’s input of the city is.

HOW COOL IS THAT! You could then simply grab data from any API (that is free of course, some you have to pay) and place is in your website. API’s are half the work that’s already done for you!

Fun Fact of the Day:

Sometimes, if you have no idea how a system works, why not get a few of your friends and act it out? That way you can understand how data communicates from the BROWSER to the SERVER both ways! (Seriously, it helps)