The Branding Store | Logo Design, Web Design and E-commerce specialists.| Pembroke Pines, Florida. | APIs Archives - The Branding Store | Logo Design, Web Design and E-commerce specialists.| Pembroke Pines, Florida.

Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884

03 Jun

Consuming REST APIs In React With Fetch And Axios

by TBSCategories: News

Consuming REST APIs In React With Fetch And Axios

Shedrack Akintayo

2020-06-03T10:30:00+00:00 2020-06-03T17:35:34+00:00

Consuming REST APIs in a React Application can be done in various ways, but in this tutorial, we will be discussing how we can consume REST APIs using two of the most popular methods known as Axios (a promise-based HTTP client) and Fetch API (a browser in-built web API). I will discuss and implement each of these methods in detail and shed light on some of the cool features each of them have to offer.

APIs are what we can use to supercharge our React applications with data. There are certain operations that can’t be done on the client-side, so these operations are implemented on the server-side. We can then use the APIs to consume the data on the client-side.

APIs consist of a set of data, that is often in JSON format with specified endpoints. When we access data from an API, we want to access specific endpoints within that API framework. We can also say that an API is a contractual agreement between two services over the shape of request and response. The code is just a byproduct. It also contains the terms of this data exchange.

In React, there are various ways we can consume REST APIs in our applications, these ways include using the JavaScript inbuilt fetch() method and Axios which is a promise-based HTTP client for the browser and Node.js.

Note: A good knowledge of ReactJS, React Hooks, JavaScript and CSS will come in handy as you work your way throughout this tutorial.

Let’s get started with learning more about the REST API.

What Is A REST API

A REST API is an API that follows what is structured in accordance with the REST Structure for APIs. REST stands for “Representational State Transfer”. It consists of various rules that developers follow when creating APIs.

The Benefits Of REST APIs

Very easy to learn and understand;
It provides developers with the ability to organize complicated applications into simple resources;
It easy for external clients to build on your REST API without any complications;
It is very easy to scale;
A REST API is not language or platform-specific, but can be consumed with any language or run on any platform.

An Example Of A REST API Response

The way a REST API is structured depends on the product it’s been made for — but the rules of REST must be followed.

The sample response below is from the Github Open API. We’ll be using this API to build a React app later on in this tutorial.

{ "login": "hacktivist123", "id": 26572907, "node_id": "MDQ6VXNlcjI2NTcyOTA3", "avatar_url": "https://avatars3.githubusercontent.com/u/26572907?v=4", "gravatar_id": "", "url": "https://api.github.com/users/hacktivist123", "html_url": "https://github.com/hacktivist123", "followers_url": "https://api.github.com/users/hacktivist123/followers", "following_url": "https://api.github.com/users/hacktivist123/following{/other_user}", "gists_url": "https://api.github.com/users/hacktivist123/gists{/gist_id}", "starred_url": "https://api.github.com/users/hacktivist123/starred{/owner}{/repo}", "subscriptions_url": "https://api.github.com/users/hacktivist123/subscriptions", "organizations_url": "https://api.github.com/users/hacktivist123/orgs", "repos_url": "https://api.github.com/users/hacktivist123/repos", "events_url": "https://api.github.com/users/hacktivist123/events{/privacy}", "received_events_url": "https://api.github.com/users/hacktivist123/received_events", "type": "User", "site_admin": false, "name": "Shedrack akintayo", "company": null, "blog": "https://sheddy.xyz", "location": "Lagos, Nigeria ", "email": null, "hireable": true, "bio": "☕ Software Engineer | | Developer Advocate🥑|| ❤ Everything JavaScript", "public_repos": 68, "public_gists": 1, "followers": 130, "following": 246, "created_at": "2017-03-21T12:55:48Z", "updated_at": "2020-05-11T13:02:57Z" }

The response above is from the Github REST API when I make a GET request to the following endpoint https://api.github.com/users/hacktivist123. It returns all the stored data about a user called hacktivist123. With this response, we can decide to render it whichever way we like in our React app.

Consuming APIs Using The Fetch API

The fetch() API is an inbuilt JavaScript method for getting resources from a server or an API endpoint. It’s similar to XMLHttpRequest, but the fetch API provides a more powerful and flexible feature set.

It defines concepts such as CORS and the HTTP Origin header semantics, supplanting their separate definitions elsewhere.

The fetch() API method always takes in a compulsory argument, which is the path or URL to the resource you want to fetch. It returns a promise that points to the response from the request, whether the request is successful or not. You can also optionally pass in an init options object as the second argument.

Once a response has been fetched, there are several inbuilt methods available to define what the body content is and how it should be handled.

The Difference Between The Fetch API And jQuery Ajax

The Fetch API is different from jQuery Ajax in three main ways, which are:

The promise returned from a fetch() request will not reject when there’s an HTTP error, no matter the nature of the response status. Instead, it will resolve the request normally, if the response status code is a 400 or 500 type code, it’ll set the ok status. A request will only be rejected either because of network failure or if something is preventing the request from completing
fetch() will not allow the use of cross-site cookies i.e you cannot carry out a cross-site session using fetch()
fetch() will also not send cookies by default unless you set the credentials in the init option.

Parameters For The Fetch API

resource
This is the path to the resource you want to fetch, this can either be a direct link to the resource path or a request object
init
This is an object containing any custom setting or credentials you’ll like to provide for your fetch() request. The following are a few of the possible options that can be contained in the init object:
- method
  This is for specifying the HTTP request method e.g GET, POST, etc.
- headers
  This is for specifying any headers you would like to add to your request, usually contained in an object or an object literal.
- body
  This is for specifying a body that you want to add to your request: this can be a Blob, BufferSource, FormData, URLSearchParams, USVString, or ReadableStream object
- mode
  This is for specifying the mode you want to use for the request, e.g., cors, no-cors, or same-origin.
- credentials
  This for specifying the request credentials you want to use for the request, this option must be provided if you consider sending cookies automatically for the current domain.

Basic Syntax for Using the Fetch() API

A basic fetch request is really simple to write, take a look at the following code:

fetch('https://api.github.com/users/hacktivist123/repos')   .then(response => response.json())   .then(data => console.log(data));

In the code above, we are fetching data from a URL that returns data as JSON and then printing it to the console. The simplest form of using fetch() often takes just one argument which is the path to the resource you want to fetch and then return a promise containing the response from the fetch request. This response is an object.

The response is just a regular HTTP response and not the actual JSON. In other to get the JSON body content from the response, we’d have to change the response to actual JSON using the json() method on the response.

Using Fetch API In React Apps

Using the Fetch API in React Apps is the normal way we’d use the Fetch API in javascript, there is no change in syntax, the only issue is deciding where to make the fetch request in our React Apps. Most fetch requests or any HTTP request of any sort is usually done in a React Component.

This request can either be made inside a Lifecycle Method if your component is a Class Component or inside a useEffect() React Hook if your component is a Functional Component.

For example, In the code below, we will make a fetch request inside a class component, which means we’ll have to do it inside a lifecycle method. In this particular case, our fetch request will be made inside a componentDidMount lifecycle method because we want to make the request just after our React Component has mounted.

import React from 'react';  class myComponent extends React.Component {   componentDidMount() {     const apiUrl = 'https://api.github.com/users/hacktivist123/repos';     fetch(apiUrl)       .then((response) => response.json())       .then((data) => console.log('This is your data', data));   }   render() {     return <h1>my Component has Mounted, Check the browser 'console' </h1>;   } } o export default myComponent;

In the code above, we are creating a very simple class component that makes a fetch request that logs the final data from the fetch request we have made to the API URL into the browser console after the React component has finished mounting.

The fetch() method takes in the path to the resource we want to fetch, which is assigned to a variable called apiUrl. After the fetch request has been completed it returns a promise that contains a response object. Then, we are extracting the JSON body content from the response using the json() method, finally we log the final data from the promise into the console.

Let’s Consume A REST API With Fetch Method

In this section, we will be building a simple react application that consumes an external API, we will be using the Fetch method to consume the API.

The simple application will display all the repositories and their description that belongs to a particular user. For this tutorial, I’ll be using my GitHub username, you can also use yours if you wish.

The first thing we need to do is to generate our React app by using create-react-app:

npx create-react-app myRepos

The command above will bootstrap a new React app for us. As soon as our new app has been created, all that’s left to do is to run the following command and begin coding:

npm start

If our React is created properly we should see this in our browser window when we navigate to localhost:3000 after running the above command.

In your src folder, create a new folder called component. This folder will hold all of our React components. In the new folder, create two files titled List.js and withListLoading.js. These two files will hold the components that will be needed in our app.

The List.js file will handle the display of our Repositories in the form of a list, and the withListLoading.js file will hold a higher-order component that will be displayed when the Fetch request we will be making is still ongoing.

In the List.js file we created inside the components folder, let’s paste in the following code:

import React from 'react'; const List = (props) => {   const { repos } = props;   if (!repos) return null;   if (repos.length === 0) return <p>No repos, sorry</p>;   return (     <ul>       <h2 className='list-head'>Available Public Repositories</h2>       {repos.map((repo) => {         return (           <li key={repo.id} className='list'>             <span className='repo-text'>{repo.name} </span>             <span className='repo-description'>{repo.description}</span>           </li>         );       })}     </ul>   ); }; export default List;

The code above is a basic React list component that would display the data, in this case, the repositories name and their descriptions in a list.

Now, Let me explain the code bit by bit.

const { repos } = props;

We are initializing a prop for the component called repos.

if (!repos) return null;   if (repos.length === 0) return No repos, sorry
;

Here, all we are doing is making a conditional statement that will render a message when the length of the repos we get from the request we make is equal to zero.

return (     <ul>       <h2 className='list-head'>Available Public Repositories</h2>       {repos.map((repo) => {         return (           <li key={repo.id} className='list'>             <span className='repo-text'>{repo.name} </span>             <span className='repo-description'>{repo.description}</span>           </li>         );       })}     </ul>   );

Here, we are mapping through each of the repositories that will be provided by the API request we make and extracting each of the repositories names and their descriptions then we are displaying each of them in a list.

export default List;

Here we are exporting our List component so that we can use it somewhere else.

In the withListLoading.js file we created inside the components folder, let’s paste in the following code:

import React from 'react';  function WithListLoading(Component) {   return function WihLoadingComponent({ isLoading, ...props }) {     if (!isLoading) return <Component {...props} />;     return (       <p style={{ textAlign: 'center', fontSize: '30px' }}>         Hold on, fetching data may take some time :)       </p>     );   }; } export default WithListLoading;

The code above is a higher-order React component that takes in another component and then returns some logic. In our case, our higher component will wait to check if the current isLoading state of the component it takes is true or false. If the current isLoading state is true, it will display a message Hold on, fetching data may take some time 🙂. Immediately the isLoading state changes to false it’ll render the component it took in. In our case, it’ll render the List component.

In your *App.js file inside the src folder, let’s paste in the following code:

import React, { useEffect, useState } from 'react'; import './App.css'; import List from './components/List'; import withListLoading from './components/withListLoading'; function App() {   const ListLoading = withListLoading(List);   const [AppState, SetAppState] = useState({     loading: false,     repos: null,   });    useEffect(() => {     SetAppState({ loading: true });     const user = `https://api.github.com/users/hacktivist123/repos`;     fetch(user)       .then((res) => res.json())       .then((repos) => {         SetAppState({ loading: false, repos: repos });       });   }, [SetAppState]);   return (     <div className='App'>       <div className='container'>         <h1>My Repositories</h1>       </div>       <div className='repo-container'>         <ListLoading isLoading={AppState.loading} repos={AppState.repos} />       </div>       <footer>         <div className='footer'>           Built{' '}           <span role='img' aria-label='emoji'>             💚           </span>{' '}           with by Shedrack Akintayo         </div>       </footer>     </div>   ); } export default App;

Our App.js is a functional component that makes use of React Hooks for handling state and also side effects. If you’re not familiar with React Hooks, read my Getting Started with React Hooks Guide.

Let me explain the code above bit by bit.

import React, { useEffect, useState } from 'react'; import './App.css'; import List from './components/List'; import withListLoading from './components/withListLoading';

Here, we are importing all the external files we need and also the components we created in our components folder. We are also importing the React Hooks we need from React.

const ListLoading = withListLoading(List);   const [AppState, SetAppState] = useState({     loading: false,     repos: null,   });

Here, we are creating a new component called ListLoading and assigning our withListLoading higher-order component wrapped around our list component. We are then creating our state values loading and repos using the useState() React Hook.

useEffect(() => {     SetAppState({ loading: true });     const user = `https://api.github.com/users/hacktivist123/repos`;     fetch(user)       .then((res) => res.json())       .then((repos) => {         SetAppState({ loading: false, repos: repos });       });   }, [SetAppState]);

Here, we are initializing a useEffect() React Hook. In the useEffect() hook, we are setting our initial loading state to true, while this is true, our higher-order component will display a message. We are then creating a constant variable called user and assigning the API URL we’ll be getting the repositories data from.

We are then making a basic fetch() request like we discussed above and then after the request is done we are setting the app loading state to false and populating the repos state with the data we got from the request.

return (     <div className='App'>       <div className='container'>         <h1>My Repositories</h1>       </div>       <div className='repo-container'>         <ListLoading isLoading={AppState.loading} repos={AppState.repos} />       </div>     </div>   ); } export default App;

Here we are basically just rendering the Component we assigned our higher-order component to and also filling the isLoading prop and repos prop with their state value.

Now, we should see this in our browser, when the fetch request is still being made, courtesy of our withListLoading higher-order component:

Now, when the fetch request has completed successfully, we should see the repositories displayed in a list format as below:

Now, let’s style our project a little bit, in your App.css file, copy and paste this code.

@import url('https://fonts.googleapis.com/css2?family=Amiri&display=swap'); :root {   --basic-color: #23cc71; } .App {   box-sizing: border-box;   display: flex;   justify-content: center;   align-items: center;   flex-direction: column;   font-family: 'Amiri', serif;   overflow: hidden; } .container {   display: flex;   flex-direction: row; } .container h1 {   font-size: 60px;   text-align: center;   color: var(--basic-color); } .repo-container {   width: 50%;   height: 700px;   margin: 50px;   box-shadow: 0 2px 10px rgba(0, 0, 0, 0.3);   overflow: scroll; } @media screen and (max-width: 600px) {   .repo-container {     width: 100%;     margin: 0;     box-shadow: none;   } } .repo-text {   font-weight: 600; } .repo-description {   font-weight: 600;   font-style: bold;   color: var(--basic-color); } .list-head {   text-align: center;   font-weight: 800;   text-transform: uppercase; } .footer {   font-size: 15px;   font-weight: 600; } .list {   list-style: circle; }

So in the code above, we are styling our app to look more pleasing to the eyes, we have assigned various class names to each element in our App.js file and thus we are using these class names to style our app.

Once we’ve applied our styling, our app should look like this:

Now our app looks much better. 😊

So that’s how we can use the Fetch API to consume a REST API. In the next section, we’ll be discussing Axios and how we can use it to consume the same API in the same App.

Consuming APIs With Axios

Axios is an easy to use promise-based HTTP client for the browser and node.js. Since Axios is promise-based, we can take advantage of async and await for more readable and asynchronous code. With Axios, we get the ability to intercept and cancel request, it also has a built-in feature that provides client-side protection against cross-site request forgery.

Features Of Axios

Request and response interception
Streamlined error handling
Protection against XSRF
Support for upload progress
Response timeout
The ability to cancel requests
Support for older browsers
Automatic JSON data transformation

Making Requests With Axios

Making HTTP Requests with Axios is quite easy. The code below is basically how to make an HTTP request.

// Make a GET request axios({   method: 'get',   url: 'https://api.github.com/users/hacktivist123', });  // Make a Post Request axios({   method: 'post',   url: '/login',   data: {     firstName: 'shedrack',     lastName: 'akintayo'   } });

The code above shows the basic ways we can make a GET and POST HTTP request with Axios.

Axios also provides a set of shorthand method for performing different HTTP requests. The Methods are as follows:

axios.request(config)
axios.get(url[, config])
axios.delete(url[, config])
axios.head(url[, config])
axios.options(url[, config])
axios.post(url[, data[, config]])
axios.put(url[, data[, config]])
axios.patch(url[, data[, config]])

For example, if we want to make a similar request like the example code above but with the shorthand methods we can do it like so:

// Make a GET request with a shorthand method axios.get(   url: 'https://api.github.com/users/hacktivist123', );  // Make a Post Request with a shorthand method axios.post('/signup', {     firstName: 'shedrack',     lastName: 'akintayo' });

In the code above, we are making the same request as what we did above but this time with the shorthand method. Axios provides flexibility and makes your HTTP requests even more readable.

Making Multiple Requests With Axios

Axios provides developers the ability to make and handle simultaneous HTTP requests using the axios.all() method. This method takes in an array of arguments and it returns a single promise object that resolves only when all arguments passed in the array have resolved.

For example, we can make multiple requests to the GitHub api using the axios.all() method like so:

axios.all([   axios.get('https://api.github.com/users/hacktivist123'),   axios.get('https://api.github.com/users/adenekan41') ]) .then(response => {   console.log('Date created: ', response[0].data.created_at);   console.log('Date created: ', response[1].data.created_at); });

The code above makes simultaneous requests to an array of arguments in parallel and returns the response data, in our case, it will log to the console the created_at object from each of the API responses.

Let’s Consume A REST API With Axios Client

In this section, all we’ll be doing is replacing fetch() method with Axios in our existing React Application. All we need to do is to install Axios and then use it in our App.js file for making the HTTP request to the GitHub API.

Now let’s install Axios in our React app by running either of the following:

With NPM:

npm install axios

With Yarn:

yarn add axios

After installation is complete, we have to import axios into our App.js. In our App.js we’ll add the following line to the top of our App.js file:

import axios from 'axios'

After adding the line of code our App.js all we have to do inside our useEffect() is to write the following code:

useEffect(() => {     SetAppState({ loading: true });     const user = 'https://api.github.com/users/hacktivist123/repos';     axios.get(user).then((repos) => {       const allRepos = repos.data;       SetAppState({ loading: false, repos: allRepos });     });   }, [SetAppState]);

If you’ve noticed, we have replaced the fetch API there with the Axios shorthand method axios.get to make a get request to the API.

axios.get(user).then((repos) => {       const allRepos = repos.data;       SetAppState({ loading: false, repos: allRepos });     });

In this block of code, we are making a GET request then we are returning a promise that contains the repos data and assigning the data to a constant variable called allRepos. We are then setting the current loading state to false and also passing the data from the request to the repos state variable.

If we did everything correctly, we should see our app still render the same way without any change.

So this is how we can use Axios client to consume a REST API.

Fetch vs Axios

In this section, I will be listing our certain features and then I’ll talk about how well Fetch and Axios support these features.

Basic Syntax
Both Fetch and Axios have very simple syntaxes for making requests. But Axios has an upper hand because Axios automatically converts a response to JSON, so when using Axios we skip the step of converting the response to JSON, unlike Fetch() where we’d still have to convert the response to JSON. Lastly, Axios shorthand methods allow us to make specific HTTP Requests easier.
Browser Compatibility
One of the many reasons why developers would prefer Axios over Fetch is because Axios is supported across major browsers and versions unlike Fetch that is only supported in Chrome 42+, Firefox 39+, Edge 14+, and Safari 10.1+.
Handling Response Timeout
Setting a timeout for responses is very easy to do in Axios by making use of the timeout option inside the request object. But in Fetch, it is not that easy to do this. Fetch provides a similar feature by using the AbortController() interface but it takes more time to implement and can get confusing.
Intercepting HTTP Requests
Axios allows developers to intercept HTTP requests. HTTP interceptors are needed when we need to change HTTP requests from our application to the server. Interceptors give us the ability to do that without having to write extra code.
Making Multiple Requests Simultaneously
Axios allows us to make multiple HTTP requests with the use of the axios.all() method ( I talked about this above). fetch() provides the same feature with the use of the promise.all() method, we can make multiple fetch() requests inside it.

Conclusion

Axios and fetch() are all great ways of consuming APIs but I advise you to use fetch() when building relatively small applications and make use of Axios when building large applications for scalability reasons. I hope you enjoyed working through this tutorial, you could always read more on Consuming REST APIs with either Fetch or Axios from the references below. If you have any questions, you can leave it in the comments section below and I’ll be happy to answer every single one.

“REST API Structure,”
“Understanding And Using REST APIs,” Zell Liew
“CORS,”
“HTTP Headers,”
“Fetch API,” Mozilla Developer Network
“Using Axios And React,” Paul Halliday
“How To Make HTTP Requests Like A Pro With Axios,” Faraz Kelhini

(ks, ra, il)

Articles on Smashing Magazine — For Web Designers And Developers

Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884

20 Feb

Get Started With Node: An Introduction To APIs, HTTP And ES6+ JavaScript

by TBSCategories: News

Get Started With Node: An Introduction To APIs, HTTP And ES6+ JavaScript

Jamie Corkhill

2019-02-20T14:00:53+01:00 2019-02-20T15:04:24+00:00

You’ve probably heard of Node.js as being an “asynchronous JavaScript runtime built on Chrome’s V8 JavaScript engine”, and that it “uses an event-driven, non-blocking I/O model that makes it lightweight and efficient”. But for some, that is not the greatest of explanations.

What is Node in the first place? What exactly does it mean for Node to be “asynchronous”, and how does that differ from “synchronous”? What is the meaning “event-driven” and “non-blocking” anyway, and how does Node fit into the bigger picture of applications, Internet networks, and servers?

We’ll attempt to answer all of these questions and more throughout this series as we take an in-depth look at the inner workings of Node, learn about the HyperText Transfer Protocol, APIs, and JSON, and build our very own Bookshelf API utilizing MongoDB, Express, Lodash, Mocha, and Handlebars.

What Is Node.js

Node is only an environment, or runtime, within which to run normal JavaScript (with minor differences) outside of the browser. We can use it to build desktop applications (with frameworks like Electron), write web or app servers, and more.

Blocking/Non-Blocking And Synchronous/Asynchronous

Suppose we are making a database call to retrieve properties about a user. That call is going to take time, and if the request is “blocking”, then that means it will block the execution of our program until the call is complete. In this case, we made a “synchronous” request since it ended up blocking the thread.

So, a synchronous operation blocks a process or thread until that operation is complete, leaving the thread in a “wait state”. An asynchronous operation, on the other hand, is non-blocking. It permits execution of the thread to proceed regardless of the time it takes for the operation to complete or the result it completes with, and no part of the thread falls into a wait state at any point.

Let’s look at another example of a synchronous call that blocks a thread. Suppose we are building an application that compares the results of two Weather APIs to find their percent difference in temperature. In a blocking manner, we make a call to Weather API One and wait for the result. Once we get a result, we call Weather API Two and wait for its result. Don’t worry at this point if you are not familiar with APIs. We’ll be covering them in an upcoming section. For now, just think of an API as the medium through which two computers may communicate with one another.

A graphic depicting the fact Synchronous Operations take a long time complete — Time progression of synchronous blocking operations (Large preview)

Allow me to note, it’s important to recognize that not all synchronous calls are necessarily blocking. If a synchronous operation can manage to complete without blocking the thread or causing a wait state, it was non-blocking. Most of the time, synchronous calls will be blocking, and the time they take to complete will depend on a variety of factors, such as the speed of the API’s servers, the end user’s internet connection download speed, etc.

In the case of the image above, we had to wait quite a while to retrieve the first results from API One. Thereafter, we had to wait equally as long to get a response from API Two. While waiting for both responses, the user would notice our application hang — the UI would literally lock up — and that would be bad for User Experience.

In the case of a non-blocking call, we’d have something like this:

A graphic depicting the fact that Asynchronous Non-Blocking Operations are almost 50 percent faster — Time progression of asynchronous non-blocking operations (Large preview)

You can clearly see how much faster we concluded execution. Rather than wait on API One and then wait on API Two, we could wait for both of them to complete at the same time and achieve our results almost 50% faster. Notice, once we called API One and started waiting for its response, we also called API Two and began waiting for its response at the same time as One.

At this point, before moving into more concrete and tangible examples, it is important to mention that, for ease, the term “Synchronous” is generally shortened to “Sync”, and the term “Asynchronous” is generally shortened to “Async”. You will see this notation used in method/function names.

Callback Functions

You might be wondering, “if we can handle a call asynchronously, how do we know when that call is finished and we have a response?” Generally, we pass in as an argument to our async method a callback function, and that method will “call back” that function at a later time with a response. I’m using ES5 functions here, but we’ll update to ES6 standards later.

function asyncAddFunction(a, b, callback) {   callback(a + b); //This callback is the one passed in to the function call below. }  asyncAddFunction(2, 4, function(sum) {   //Here we have the sum, 2 + 4 = 6. });

Such a function is called a “Higher-Order Function” since it takes a function (our callback) as an argument. Alternatively, a callback function might take in an error object and a response object as arguments, and present them when the async function is complete. We’ll see this later with Express. When we called asyncAddFunction(...), you’ll notice we supplied a callback function for the callback parameter from the method definition. This function is an anonymous function (it does not have a name) and is written using the Expression Syntax. The method definition, on the other hand, is a function statement. It’s not anonymous because it actually has a name (that being “asyncAddFunction”).

Some may note confusion since, in the method definition, we do supply a name, that being “callback”. However, the anonymous function passed in as the third parameter to asyncAddFunction(...) does not know about the name, and so it remains anonymous. We also can’t execute that function at a later point by name, we’d have to go through the async calling function again to fire it.

As an example of a synchronous call, we can use the Node.js readFileSync(...) method. Again, we’ll be moving to ES6+ later.

var fs = require('fs'); var data = fs.readFileSync('/example.txt'); // The thread will be blocked here until complete.

If we were doing this asynchronously, we’d pass in a callback function which would fire when the async operation was complete.

var fs = require('fs'); var data = fs.readFile('/example.txt', function(err, data) { //Move on, this will fire when ready.   if(err) return console.log('Error: ', err);   console.log('Data: ', data); // Assume var data is defined above. }); // Keep executing below, don’t wait on the data.

If you have never seen return used in that manner before, we are just saying to stop function execution so we don’t print the data object if the error object is defined. We could also have just wrapped the log statement in an else clause.

Like our asyncAddFunction(...), the code behind the fs.readFile(...) function would be something along the lines of:

function readFile(path, callback) {  // Behind the scenes code to read a file stream.  // The data variable is defined up here.  callback(undefined, data); //Or, callback(err, undefined); }

Allow us to look at one last implementation of an async function call. This will help to solidify the idea of callback functions being fired at a later point in time, and it will help us to understand the execution of a typical Node.js program.

setTimeout(function {   // ... }, 1000);

The setTimeout(...) method takes a callback function for the first parameter which will be fired after the number of milliseconds specified as the second argument has occurred.

Let’s look at a more complex example:

console.log('Initiated program.');  setTimeout(function {   console.log('3000 ms (3 sec) have passed.'); }, 3000);  setTimeout(function {   console.log('0 ms (0 sec) have passed.'); }, 0);  setTimeout(function {   console.log('1000 ms (1 sec) has passed.'); }, 1000);  console.log('Terminated program');

The output we receive is:

Initiated program. Terminated program. 0 ms (0 sec) have passed. 1000 ms (1 sec) has passed. 3000 ms (3 sec) have passed.

You can see that the first log statement runs as expected. Instantaneously, the last log statement prints to the screen, for that happens before 0 seconds have surpassed after the second setTimeout(...). Immediately thereafter, the second, third, and first setTimeout(...) methods execute.

If Node.js was not non-blocking, we’d see the first log statement, wait 3 seconds to see the next, instantaneously see the third (the 0-second setTimeout(...), and then have to wait one more second to see the last two log statements. The non-blocking nature of Node makes all timers start counting down from the moment the program is executed, rather than the order in which they are typed. You may want to look into Node APIs, the Callstack, and the Event Loop for more information about how Node works under the hood.

It is important to note that just because you see a callback function does not necessarily mean there is an asynchronous call in the code. We called the asyncAddFunction(…) method above “async” because we are assuming the operation takes time to complete — such as making a call to a server. In reality, the process of adding two numbers is not async, and so that would actually be an example of using a callback function in a fashion that does not actually block the thread.

Promises Over Callbacks

Callbacks can quickly become messy in JavaScript, especially multiple nested callbacks. We are familiar with passing a callback as an argument to a function, but Promises allow us to tack, or attach, a callback to an object returned from a function. This would allow us to handle multiple async calls in a more elegant manner.

As an example, suppose we are making an API call, and our function, not so uniquely named ‘makeAPICall(...)’, takes a URL and a callback.

Our function, makeAPICall(...), would be defined as

function makeAPICall(path, callback) {   // Attempt to make API call to path argument.   // ...   callback(undefined, res); // Or, callback(err, undefined); depending upon the API’s response. }

and we would call it with:

makeAPICall('/example', function(err1, res1) {   if(err1) return console.log('Error: ', err1);   // ... });

If we wanted to make another API call using the response from the first, we would have to nest both callbacks. Suppose I need to inject the userName property from the res1 object into the path of the second API call. We would have:

makeAPICall('/example', function(err1, res1) {   if(err1) return console.log('Error: ', err1);   makeAPICall('/newExample/' + res1.userName, function(err2, res2) {     if(err2) return console.log('Error: ', err2);     console.log(res2);   }); });

Note: The ES6+ method to inject the res1.userName property rather than string concatenation would be to use “Template Strings”. That way, rather than encapsulate our string in quotes (‘, or “), we would use backticks (), located beneath the Escape key on your keyboard. Then, we would use the notation $ {} to embed any JS expression inside the brackets. In the end, our earlier path would be: /newExample/$ {res.UserName}, wrapped in backticks.

It is clear to see that this method of nesting callbacks can quickly become quite inelegant, so-called the “JavaScript Pyramid of Doom”. Jumping in, if we were using promises rather than callbacks, we could refactor our code from the first example as such:

makeAPICall('/example').then(function(res) { // Success callback.   // ... }, function(err) { // Failure callback.   console.log('Error:', err); });

The first argument to the then() function is our success callback, and the second argument is our failure callback. Alternatively, we could lose the second argument to .then(), and call .catch() instead. Arguments to .then() are optional, and calling .catch() would be equivalent to .then(successCallback, null).

Using .catch(), we have:

makeAPICall('/example').then(function(res) { // Success callback.   // ... }).catch(function(err) {  // Failure Callback   console.log('Error: ', err); });

We can also restructure this for readability:

makeAPICall('/example')   .then(function(res) {     // ...   })   .catch(function(err) {     console.log('Error: ', err);   });

It is important to note that we can’t just tack a .then() call on to any function and expect it to work. The function we are calling has to actually return a promise, a promise that will fire the .then() when that async operation is complete. In this case, makeAPICall(...) will do it’s thing, firing either the then() block or the catch() block when completed.

To make makeAPICall(...) return a Promise, we assign a function to a variable, where that function is the Promise constructor. Promises can be either fulfilled or rejected, where fulfilled means that the action relating to the promise completed successfully, and rejected meaning the opposite. Once the promise is either fulfilled or rejected, we say it has settled, and while waiting for it to settle, perhaps during an async call, we say that the promise is pending.

The Promise constructor takes in one callback function as an argument, which receives two parameters — resolve and reject, which we will call at a later point in time to fire either the success callback in .then(), or the .then() failure callback, or .catch(), if provided.

Here is an example of what this looks like:

var examplePromise = new Promise(function(resolve, reject) {   // Do whatever we are going to do and then make the appropiate call below:   resolve('Happy!'); // — Everything worked.   reject('Sad!'); // — We noticed that something went wrong. }):

Then, we can use:

examplePromise.then(/* Both callback functions in here */); // Or, the success callback in .then() and the failure callback in .catch().

Notice, however, that examplePromise can’t take any arguments. That kind of defeats the purpose, so we can return a promise instead.

function makeAPICall(path) {   return new Promise(function(resolve, reject) {     // Make our async API call here.     if (/* All is good */) return resolve(res); //res is the response, would be defined above.     else return reject(err); //err is error, would be defined above.   }); }

Promises really shine to improve the structure, and subsequently, elegance, of our code with the concept of “Promise Chaining”. This would allow us to return a new Promise inside a .then() clause, so we could attach a second .then() thereafter, which would fire the appropriate callback from the second promise.

Refactoring our multi API URL call above with Promises, we get:

makeAPICall('/example').then(function(res) { // First response callback. Fires on success to '/example' call.   return makeAPICall(`/newExample/$ {res.UserName}`); // Returning new call allows for Promise Chaining. }, function(err) { // First failure callback. Fires if there is a failure calling with '/example'.   console.log('Error:', err); }).then(function(res) { // Second response callback. Fires on success to returned '/newExample/...' call.   console.log(res); }, function(err) { // Second failure callback. Fire if there is a failure calling with '/newExample/...'   console.log('Error:', err); });

Notice that we first call makeAPICall('/example'). That returns a promise, and so we attach a .then(). Inside that then(), we return a new call to makeAPICall(...), which, in and of itself, as seen earlier, returns a promise, permitting us chain on a new .then() after the first.

Like above, we can restructure this for readability, and remove the failure callbacks for a generic catch() all clause. Then, we can follow the DRY Principle (Don’t Repeat Yourself), and only have to implement error handling once.

makeAPICall('/example')   .then(function(res) { // Like earlier, fires with success and response from '/example'.     return makeAPICall(`/newExample/$ {res.UserName}`); // Returning here lets us chain on a new .then().    })   .then(function(res) { // Like earlier, fires with success and response from '/newExample'.     console.log(res);    })   .catch(function(err) { // Generic catch all method. Fires if there is an err with either earlier call.     console.log('Error: ', err);    });

Note that the success and failure callbacks in .then() only fire for the status of the individual Promise that .then() corresponds to. The catch block, however, will catch any errors that fire in any of the .then()s.

ES6 Const vs. Let

Throughout all of our examples, we have been employing ES5 functions and the old var keyword. While millions of lines of code still run today employing those ES5 methods, it is useful to update to current ES6+ standards, and we’ll refactor some of our code above. Let’s start with const and let.

You might be used to declaring a variable with the var keyword:

var pi = 3.14;

With ES6+ standards, we could make that either

let pi = 3.14;

const pi = 3.14;

where const means “constant” — a value that cannot be reassigned to later. (Except for object properties — we’ll cover that soon. Also, variables declared const are not immutable, only the reference to the variable is.)

In old JavaScript, block scopes, such as those in if, while, {}. for, etc. did not affect var in any way, and this is quite different to more statically typed languages like Java or C++. That is, the scope of var is the entire enclosing function — and that could be global (if placed outside a function), or local (if placed within a function). To demonstrate this, see the following example:

function myFunction() {   var num = 5;   console.log(num); // 5   console.log('--');   for(var i = 0; i < 10; i++)   {     var num = i;     console.log(num); //num becomes 0 — 9   }   console.log('--');   console.log(num); // 9   console.log(i); // 10 }  myFunction();

Output:

5 --- 0 1 2 3 ... 7 8 9 --- 9 10

The important thing to notice here is that defining a new var num inside the for scope directly affected the var num outside and above the for. This is because var’s scope is always that of the enclosing function, and not a block.

Again, by default, var i inside for() defaults to myFunction’s scope, and so we can access i outside the loop and get 10.

In terms of assigning values to variables, let is equivalent to var, it’s just that let has block scoping, and so the anomalies that occurred with var above will not happen.

function myFunction() {   let num = 5;   console.log(num); // 5   for(let i = 0; i < 10; i++)   {     let num = i;     console.log('--');     console.log(num); // num becomes 0 — 9   }   console.log('--');   console.log(num); // 5   console.log(i); // undefined, ReferenceError }

Looking at the const keyword, you can see that we attain an error if we try to reassign to it:

const c = 299792458; // Fact: The constant "c" is the speed of light in a vacuum in meters per second. c = 10; // TypeError: Assignment to constant variable.

Things become interesting when we assign a const variable to an object:

const myObject = {   name: 'Jane Doe' };  // This is illegal: TypeError: Assignment to constant variable. myObject = {   name: 'John Doe' };  // This is legal. console.log(myObject.name) -> John Doe myObject.name = 'John Doe';

As you can see, only the reference in memory to the object assigned to a const object is immutable, not the value its self.

ES6 Arrow Functions

You might be used to creating a function like this:

function printHelloWorld() {   console.log('Hello, World!'); }

With arrow functions, that would become:

const printHelloWorld = () => {   console.log('Hello, World!'); };

Suppose we have a simple function that returns the square of a number:

const squareNumber = (x) => {   return x * x; }  squareNumber(5); // We can call an arrow function like an ES5 functions. Returns 25.

You can see that, just like with ES5 functions, we can take in arguments with parentheses, we can use normal return statements, and we can call the function just like any other.

It’s important to note that, while parentheses are required if our function takes no arguments (like with printHelloWorld() above), we can drop the parentheses if it only takes one, so our earlier squareNumber() method definition can be rewritten as:

const squareNumber = x => { // Notice we have dropped the parentheses for we only take in one argument.   return x * x; }

Whether you choose to encapsulate a single argument in parentheses or not is a matter of personal taste, and you will likely see developers use both methods.

Finally, if we only want to implicitly return one expression, as with squareNumber(...) above, we can put the return statement in line with the method signature:

const squareNumber = x => x * x;

That is,

const test = (a, b, c) => expression

is the same as

const test = (a, b, c) => { return expression }

Note, when using the above shorthand to implicitly return an object, things become obscure. What stops JavaScript from believing the brackets within which we are required to encapsulate our object is not our function body? To get around this, we wrap the object’s brackets in parentheses. This explicitly lets JavaScript know that we are indeed returning an object, and we are not just defining a body.

const test = () => ({ pi: 3.14 }); // Spaces between brackets are a formality to make the code look cleaner.

To help solidify the concept of ES6 functions, we’ll refactor some of our earlier code allowing us to compare the differences between both notations.

asyncAddFunction(...), from above, could be refactored from:

function asyncAddFunction(a, b, callback){   callback(a + b); }

to:

const aysncAddFunction = (a, b, callback) => {   callback(a + b); };

or even to:

const aysncAddFunction = (a, b, callback) => callback(a + b); // This will return callback(a + b).

When calling the function, we could pass an arrow function in for the callback:

asyncAddFunction(10, 12, sum => { // No parentheses because we only take one argument.   console.log(sum); }

It is clear to see how this method improves code readability. To show you just one case, we can take our old ES5 Promise based example above, and refactor it to use arrow functions.

makeAPICall('/example')   .then(res => makeAPICall(`/newExample/$ {res.UserName}`))   .then(res => console.log(res))   .catch(err => console.log('Error: ', err));

Now, there are some caveats with arrow functions. For one, they do not bind a this keyword. Suppose I have the following object:

const Person = {   name: 'John Doe',   greeting: () => {     console.log(`Hi. My name is $ {this.name}.`);   } }

You might expect a call to Person.greeting() will return “Hi. My name is John Doe.” Instead, we get: “Hi. My name is undefined.” That is because arrow functions do not have a this, and so attempting to use this inside an arrow function defaults to the this of the enclosing scope, and the enclosing scope of the Person object is window, in the browser, or module.exports in Node.

To prove this, if we use the same object again, but set the name property of the global this to something like ‘Jane Doe’, then this.name in the arrow function returns ‘Jane Doe’, because the global this is within the enclosing scope, or is the parent of the Person object.

this.name = 'Jane Doe';  const Person = {   name: 'John Doe',   greeting: () => {     console.log(`Hi. My name is $ {this.name}.`);   } }  Person.greeting(); // Hi. My name is Jane Doe

This is known as ‘Lexical Scoping’, and we can get around it by using the so-called ‘Short Syntax’, which is where we lose the colon and the arrow as to refactor our object as such:

const Person = {   name: 'John Doe',   greeting() {     console.log(`Hi. My name is $ {this.name}.`);   } }  Person.greeting() //Hi. My name is John Doe.

ES6 Classes

While JavaScript never supported classes, you could always emulate them with objects like the above. EcmaScript 6 provides support for classes using the class and new keywords:

class Person {    constructor(name) {       this.name = name;    }    greeting() {       console.log(`Hi. My name is $ {this.name}.`);    } }  const person = new Person(‘John’); person.greeting(); // Hi. My name is John.

The constructor function gets called automatically when using the new keyword, into which we can pass arguments to initially set up the object. This should be familiar to any reader who has experience with more statically typed object-oriented programming languages like Java, C++, and C#.

Without going into too much detail about OOP concepts, another such paradigm is “inheritance”, which is to allow one class to inherit from another. A class called Car, for example, will be very general — containing such methods as “stop”, “start”, etc., as all cars need. A sub-set of the class called SportsCar, then, might inherit fundamental operations from Car and override anything it needs custom. We could denote such a class as follows:

class Car {    constructor(licensePlateNumber) {       this.licensePlateNumber = licensePlateNumber;    }    start() {}    stop() {}    getLicensePlate() {       return this.licensePlateNumber;    }    // … }   class SportsCar extends Car {    constructor(engineRevCount, licensePlateNumber) {       super(licensePlateNumber); // Pass licensePlateNumber up to the parent class.       this.engineRevCount = engineRevCount;    }    start() {       super.start();    }    stop() {       super.stop();    }    getLicensePlate() {       return super.getLicensePlate();    }    getEngineRevCount() {       return this.engineRevCount;    } }

You can clearly see that the super keyword allows us to access properties and methods from the parent, or super, class.

JavaScript Events

An Event is an action that occurs to which you have the ability to respond. Suppose you are building a login form for your application. When the user presses the “submit” button, you can react to that event via an “event handler” in your code — typically a function. When this function is defined as the event handler, we say we are “registering an event handler”. The event handler for the submit button click will likely check the formatting of the input provided by the user, sanitize it to prevent such attacks as SQL Injections or Cross Site Scripting (please be aware that no code on the client-side can ever be considered safe. Always sanitize data on the server — never trust anything from the browser), and then check to see if that username and password combination exits within a database to authenticate a user and serve them a token.

Since this is an article about Node, we’ll focus on the Node Event Model.

We can use the events module from Node to emit and react to specific events. Any object that emits an event is an instance of the EventEmitter class.

We can emit an event by calling the emit() method and we listen for that event via the on() method, both of which are exposed through the EventEmitter class.

const EventEmitter = require('events');  const myEmitter = new EventEmitter();

With myEmitter now an instance of the EventEmitter class, we can access emit() and on():

const EventEmitter = require('events');  const myEmitter = new EventEmitter();  myEmitter.on('someEvent', () => {   console.log('The "someEvent" event was fired (emitted)'); });  myEmitter.emit('someEvent'); // This will call the callback function above.

The second parameter to myEmitter.on() is the callback function that will fire when the event is emitted — this is the event handler. The first parameter is the name of the event, which can be anything we like, although the camelCase naming convention is recommended.

Additionally, the event handler can take any number of arguments, which are passed down when the event is emitted:

const EventEmitter = require('events');  const myEmitter = new EventEmitter();  myEmitter.on('someEvent', (data) => {   console.log(`The "someEvent" event was fired (emitted) with data: $ {data}`); });  myEmitter.emit('someEvent', 'This is the data payload');

By using inheritance, we can expose the emit() and on() methods from ‘EventEmitter’ to any class. This is done by creating a Node.js class, and using the extends reserved keyword to inherit the properties available on EventEmitter:

const EventEmitter = require('events');  class MyEmitter extends EventEmitter {   // This is my class. I can emit events from a MyEmitter object. }

Suppose we are building a vehicle collision notification program that receives data from gyroscopes, accelerometers, and pressure gauges on the car’s hull. When a vehicle collides with an object, those external sensors will detect the crash, executing the collide(...) function and passing to it the aggregated sensor data as a nice JavaScript Object. This function will emit a collision event, notifying the vendor of the crash.

const EventEmitter = require('events');  class Vehicle extends EventEmitter {   collide(collisionStatistics) {     this.emit('collision', collisionStatistics)   } }  const myVehicle = new Vehicle(); myVehicle.on('collision', collisionStatistics => {   console.log('WARNING! Vehicle Impact Detected: ', collisionStatistics);   notifyVendor(collisionStatistics); });  myVehicle.collide({ ... });

This is a convoluted example for we could just put the code within the event handler inside the collide function of the class, but it demonstrates how the Node Event Model functions nonetheless. Note that some tutorials will show the util.inherits() method of permitting an object to emit events. That has been deprecated in favor of ES6 Classes and extends.

The Node Package Manager

When programming with Node and JavaScript, it’ll be quite common to hear about npm. Npm is a package manager which does just that — permits the downloading of third-party packages that solve common problems in JavaScript. Other solutions, such as Yarn, Npx, Grunt, and Bower exist as well, but in this section, we’ll focus only on npm and how you can install dependencies for your application through a simple Command Line Interface (CLI) using it.

Let’s start simple, with just npm. Visit the NpmJS homepage to view all of the packages available from NPM. When you start a new project that will depend on NPM Packages, you’ll have to run npm init through the terminal in your project’s root directory. You will be asked a series of questions which will be used to create a package.json file. This file stores all of your dependencies — modules that your application depends on to function, scripts — pre-defined terminal commands to run tests, build the project, start the development server, etc., and more.

To install a package, simply run npm install [package-name] --save. The save flag will ensure the package and its version is logged in the package.json file. Since npm version 5, dependencies are saved by default, so --save may be omitted. You will also notice a new node_modules folder, containing the code for that package you just installed. This can also be shortened to just npm i [package-name]. As a helpful note, the node_modules folder should never be included in a GitHub repository due to its size. Whenever you clone a repo from GitHub (or any other version management system), be sure to run the command npm install to go out and fetch all the packages defined in the package.json file, creating the node_modules directory automatically. You can also install a package at a specific version: npm i [package-name]@1.10.1 --save, for example.

Removing a package is similar to installing one: npm remove [package-name].

You can also install a package globally. This package will be available across all projects, not just the one your working on. You do this with the -g flag after npm i [package-name]. This is commonly used for CLIs, such as Google Firebase and Heroku. Despite the ease this method presents, it is generally considered bad practice to install packages globally, for they are not saved in the package.json file, and if another developer attempts to use your project, they won’t attain all the required dependencies from npm install.

APIs & JSON

APIs are a very common paradigm in programming, and even if you are just starting out in your career as a developer, APIs and their usage, especially in web and mobile development, will likely come up more often than not.

An API is an Application Programming Interface, and it is basically a method by which two decoupled systems may communicate with each other. In more technical terms, an API permits a system or computer program (usually a server) to receive requests and send appropriate responses (to a client, also known as a host).

Suppose you are building a weather application. You need a way to geocode a user’s address into a latitude and longitude, and then a way to attain the current or forecasted weather at that particular location.

As a developer, you want to focus on building your app and monetizing it, not putting the infrastructure in place to geocode addresses or placing weather stations in every city.

Luckily for you, companies like Google and OpenWeatherMap have already put that infrastructure in place, you just need a way to talk to it — that is where the API comes in. While, as of now, we have developed a very abstract and ambiguous definition of the API, bear with me. We’ll be getting to tangible examples soon.

Now, it costs money for companies to develop, maintain, and secure that aforementioned infrastructure, and so it is common for corporations to sell you access to their API. This is done with that is known as an API key, a unique alphanumeric identifier associating you, the developer, with the API. Every time you ask the API to send you data, you pass along your API key. The server can then authenticate you and keep track of how many API calls you are making, and you will be charged appropriately. The API key also permits Rate-Limiting or API Call Throttling (a method of throttling the number of API calls in a certain timeframe as to not overwhelm the server, preventing DOS attacks — Denial of Service). Most companies, however, will provide a free quota, giving you, as an example, 25,000 free API calls a day before charging you.

Up to this point, we have established that an API is a method by which two computer programs can communicate with each other. If a server is storing data, such as a website, and your browser makes a request to download the code for that site, that was the API in action.

Let us look at a more tangible example, and then we’ll look at a more real-world, technical one. Suppose you are eating out at a restaurant for dinner. You are equivalent to the client, sitting at the table, and the chef in the back is equivalent to the server.

Since you will never directly talk to the chef, there is no way for him/her to receive your request (for what order you would like to make) or for him/her to provide you with your meal once you order it. We need someone in the middle. In this case, it’s the waiter, analogous to the API. The API provides a medium with which you (the client) may talk to the server (the chef), as well as a set of rules for how that communication should be made (the menu — one meal is allowed two sides, etc.)

Now, how do you actually talk to the API (the waiter)? You might speak English, but the chef might speak Spanish. Is the waiter expected to know both languages to translate? What if a third person comes in who only speaks Mandarin? What then? Well, all clients and servers have to agree to speak a common language, and in computer programming, that language is JSON, pronounced JAY-sun, and it stands for JavaScript Object Notation.

At this point, we don’t quite know what JSON looks like. It’s not a computer programming language, it’s just, well, a language, like English or Spanish, that everyone (everyone being computers) understands on a guaranteed basis. It’s guaranteed because it’s a standard, notably RFC 8259, the JavaScript Object Notation (JSON) Data Interchange Format by the Internet Engineering Task Force (IETF).

Even without formal knowledge of what JSON actually is and what it looks like (we’ll see in an upcoming article in this series), we can go ahead introduce a technical example operating on the Internet today that employs APIs and JSON. APIs and JSON are not just something you can choose to use, it’s not equivalent to one out of a thousand JavaScript frameworks you can pick to do the same thing. It is THE standard for data exchange on the web.

Suppose you are building a travel website that compares prices for aircraft, rental car, and hotel ticket prices. Let us walk through, step-by-step, on a high level, how we would build such an application. Of course, we need our User Interface, the front-end, but that is out of scope for this article.

We want to provide our users with the lowest price booking method. Well, that means we need to somehow attain all possible booking prices, and then compare all of the elements in that set (perhaps we store them in an array) to find the smallest element (known as the infimum in mathematics.)

How will we get this data? Well, suppose all of the booking sites have a database full of prices. Those sites will provide an API, which exposes the data in those databases for use by you. You will call each API for each site to attain all possible booking prices, store them in your own array, find the lowest or minimum element of that array, and then provide the price and booking link to your user. We’ll ask the API to query its database for the price in JSON, and it will respond with said price in JSON to us. We can then use, or parse, that accordingly. We have to parse it because APIs will return JSON as a string, not the actual JavaScript data type of JSON. This might not make sense now, and that’s okay. We’ll be covering it more in a future article.

Also, note that just because something is called an API does not necessarily mean it operates on the web and sends and receives JSON. The Java API, for example, is just the list of classes, packages, and interfaces that are part of the Java Development Kit (JDK), providing programming functionality to the programmer.

Okay. We know we can talk to a program running on a server by way of an Application Programming Interface, and we know that the common language with which we do this is known as JSON. But in the web development and networking world, everything has a protocol. What do we actually do to make an API call, and what does that look like code-wise? That’s where HTTP Requests enter the picture, the HyperText Transfer Protocol, defining how messages are formatted and transmitted across the Internet. Once we have an understanding of HTTP (and HTTP verbs, you’ll see that in the next section), we can look into actual JavaScript frameworks and methods (like fetch()) offered by the JavaScript API (similar to the Java API), that actually allow us to make API calls.

HTTP And HTTP Requests

HTTP is the HyperText Transfer Protocol. It is the underlying protocol that determines how messages are formatted as they are transmitted and received across the web. Let’s think about what happens when, for example, you attempt to load the home page of Smashing Magazine in your web browser.

You type the website URL (Uniform Resource Locator) in the URL bar, where the DNS server (Domain Name Server, out of scope for this article) resolves the URL into the appropriate IP Address. The browser makes a request, called a GET Request, to the Web Server to, well, GET the underlying HTML behind the site. The Web Server will respond with a message such as “OK”, and then will go ahead and send the HTML down to the browser where it will be parsed and rendered accordingly.

There are a few things to note here. First, the GET Request, and then the “OK” response. Suppose you have a specific database, and you want to write an API to expose that database to your users. Suppose the database contains books the user wants to read (as it will in a future article in this series). Then there are four fundamental operations your user may want to perform on this database, that is, Create a record, Read a record, Update a record, or Delete a record, known collectively as CRUD operations.

Let’s look at the Read operation for a moment. Without incorrectly assimilating or conflating the notion of a web server and a database, that Read operation is very similar to your web browser attempting to get the site from the server, just as to read a record is to get the record from the database.

This is known as an HTTP Request. You are making a request to some server somewhere to get some data, and, as such, the request is appropriately named “GET”, capitalization being a standard way to denote such requests.

What about the Create portion of CRUD? Well, when talking about HTTP Requests, that is known as a POST request. Just as you might post a message on a social media platform, you might also post a new record to a database.

CRUD’s Update allows us to use either a PUT or PATCH Request in order to update a resource. HTTP’s PUT will either create a new record or will update/replace the old one.

Let’s look at this a bit more in detail, and then we’ll get to PATCH.

An API generally works by making HTTP requests to specific routes in a URL. Suppose we are making an API to talk to a DB containing a user’s booklist. Then we might be able to view those books at the URL .../books. A POST requests to .../books will create a new book with whatever properties you define (think id, title, ISBN, author, publishing data, etc.) at the .../books route. It doesn’t matter what the underlying data structure is that stores all the books at .../books right now. We just care that the API exposes that endpoint (accessed through the route) to manipulate data. The prior sentence was key: A POST request creates a new book at the ...books/ route. The difference between PUT and POST, then, is that PUT will create a new book (as with POST) if no such book exists, or, it will replace an existing book if the book already exists within that aforementioned data structure.

Suppose each book has the following properties: id, title, ISBN, author, hasRead (boolean).

Then to add a new book, as seen earlier, we would make a POST request to .../books. If we wanted to completely update or replace a book, we would make a PUT request to .../books/id where id is the ID of the book we want to replace.

While PUT completely replaces an existing book, PATCH updates something having to do with a specific book, perhaps modifying the hasRead boolean property we defined above — so we’d make a PATCH request to …/books/id sending along the new data.

It can be difficult to see the meaning of this right now, for thus far, we’ve established everything in theory but haven’t seen any tangible code that actually makes an HTTP request. We shall, however, get to that soon, covering GET in this article, ad the rest in a future article.

There is one last fundamental CRUD operation and it’s called Delete. As you would expect, the name of such an HTTP Request is “DELETE”, and it works much the same as PATCH, requiring the book’s ID be provided in a route.

We have learned thus far, then, that routes are specific URLs to which you make an HTTP Request, and that endpoints are functions the API provides, doing something to the data it exposes. That is, the endpoint is a programming language function located on the other end of the route, and it performs whatever HTTP Request you specified. We also learned that there exist such terms as POST, GET, PUT, PATCH, DELETE, and more (known as HTTP verbs) that actually specify what requests you are making to the API. Like JSON, these HTTP Request Methods are Internet standards as defined by the Internet Engineering Task Force (IETF), most notably, RFC 7231, Section Four: Request Methods, and RFC 5789, Section Two: Patch Method, where RFC is an acronym for Request for Comments.

So, we might make a GET request to the URL .../books/id where the ID passed in is known as a parameter. We could make a POST, PUT, or PATCH request to .../books to create a resource or to .../books/id to modify/replace/update a resource. And we can also make a DELETE request to .../books/id to delete a specific book.

A full list of HTTP Request Methods can be found here.

It is also important to note that after making an HTTP Request, we’ll receive a response. The specific response is determined by how we build the API, but you should always receive a status code. Earlier, we said that when your web browser requests the HTML from the web server, it’ll respond with “OK”. That is known as an HTTP Status Code, more specifically, HTTP 200 OK. The status code just specifies how the operation or action specified in the endpoint (remember, that’s our function that does all the work) completed. HTTP Status Codes are sent back by the server, and there are probably many you are familiar with, such as 404 Not Found (the resource or file could not be found, this would be like making a GET request to .../books/id where no such ID exists.)

A complete list of HTTP Status Codes can be found here.

MongoDB

MongoDB is a non-relational, NoSQL database similar to the Firebase Real-time Database. You will talk to the database via a Node package such as the MongoDB Native Driver or Mongoose.

In MongoDB, data is stored in JSON, which is quite different from relational databases such as MySQL, PostgreSQL, or SQLite. Both are called databases, with SQL Tables called Collections, SQL Table Rows called Documents, and SQL Table Columns called Fields.

We will use the MongoDB Database in an upcoming article in this series when we create our very first Bookshelf API. The fundamental CRUD Operations listed above can be performed on a MongoDB Database.

It’s recommended that you read through the MongoDB Docs to learn how to create a live database on an Atlas Cluster and make CRUD Operations to it with the MongoDB Native Driver. In the next article of this series, we will learn how to set up a local database and a cloud production database.

Building A Command Line Node Application

When building out an application, you will see many authors dump their entire code base at the beginning of the article, and then attempt to explain each line thereafter. In this text, I’ll take a different approach. I’ll explain my code line-by-line, building the app as we go. I won’t worry about modularity or performance, I won’t split the codebase into separate files, and I won’t follow the DRY Principle or attempt to make the code reusable. When just learning, it is useful to make things as simple as possible, and so that is the approach I will take here.

Let us be clear about what we are building. We won’t be concerned with user input, and so we won’t make use of packages like Yargs. We also won’t be building our own API. That will come in a later article in this series when we make use of the Express Web Application Framework. I take this approach as to not conflate Node.js with the power of Express and APIs since most tutorials do. Rather, I’ll provide one method (of many) by which to call and receive data from an external API which utilizes a third-party JavaScript library. The API we’ll be calling is a Weather API, which we’ll access from Node and dump its output to the terminal, perhaps with some formatting, known as “pretty-printing”. I’ll cover the entire process, including how to set up the API and attain API Key, the steps of which provide the correct results as of January 2019.

We’ll be using the OpenWeatherMap API for this project, so to get started, navigate to the OpenWeatherMap sign-up page and create an account with the form. Once logged in, find the API Keys menu item on the dashboard page (located over here). If you just created an account, you’ll have to pick a name for your API Key and hit “Generate”. It could take at least 2 hours for your new API Key to be functional and associated with your account.

Before we start building out the application, we’ll visit the API Documentation to learn how to format our API Key. In this project, we’ll be specifying a zip code and a country code to attain the weather information at that location.

From the docs, we can see that the method by which we do this is to provide the following URL:

api.openweathermap.org/data/2.5/weather?zip={zip code},{country code}

Into which we could input data:

api.openweathermap.org/data/2.5/weather?zip=94040,us

Now, before we can actually attain relevant data from this API, we’ll need to provide our new API Key as a query parameter:

api.openweathermap.org/data/2.5/weather?zip=94040,us&appid={YOUR_API_KEY}

For now, copy that URL into a new tab in your web browser, replacing the {YOUR_API_KEY} placeholder with the API Key you obtained earlier when you registered for an account.

The text you can see is actually JSON — the agreed upon language of the web as discussed earlier.

To inspect this further, hit Ctrl + Shift + I in Google Chrome to open the Chrome Developer tools, and then navigate to the Network tab. At present, there should be no data here.

Empty Chrome Dev Tools Network Tab — The empty Google Chrome Developer Tools(Large preview)

To actually monitor network data, reload the page, and watch the tab be populated with useful information. Click the first link as depicted in the image below.

Populated Chrome Dev Tools Network Tab — The populated Google Chrome Developer Tools (Large preview)

Once you click on that link, we can actually view HTTP specific information, such as the headers. Headers are sent in the response from the API (you can also, in some cases, send your own headers to the API, or you can even create your own custom headers (often prefixed with x-) to send back when building your own API), and just contain extra information that either the client or server may need.

In this case, you can see that we made an HTTP GET Request to the API, and it responded with an HTTP Status 200 OK. You can also see that the data sent back was in JSON, as listed under the “Response Headers” section.

Google Dev Tools depicting the Headers from the API response — Headers in the response from the API (Large preview)

If you hit the preview tab, you can actually view the JSON as a JavaScript Object. The text version you can see in your browser is a string, for JSON is always transmitted and received across the web as a string. That’s why we have to parse the JSON in our code, to get it into a more readable format — in this case (and in pretty much every case) — a JavaScript Object.

You can also use the Google Chrome Extension “JSON View” to do this automatically.

To start building out our application, I’ll open a terminal and make a new root directory and then cd into it. Once inside, I’ll create a new app.js file, run npm init to generate a package.json file with the default settings, and then open Visual Studio Code.

mkdir command-line-weather-app && cd command-line-weather-app touch app.js npm init code .

Thereafter, I’ll download Axios, verify it has been added to my package.json file, and note that the node_modules folder has been created successfully.

In the browser, you can see that we made a GET Request by hand by manually typing the proper URL into the URL Bar. Axios is what will allow me to do that inside of Node.

Starting now, all of the following code will be located inside of the app.js file, each snippet placed one after the other.

The first thing I’ll do is require the Axios package we installed earlier with

const axios = require('axios');

We now have access to Axios, and can make relevant HTTP Requests, via the axios constant.

Generally, our API calls will be dynamic — in this case, we might want to inject different zip codes and country codes into our URL. So, I’ll be creating constant variables for each part of the URL, and then put them together with ES6 Template Strings. First, we have the part of our URL that will never change as well as our API Key:

const API_URL = 'https://api.openweathermap.org/data/2.5/weather?zip='; const API_KEY = 'Your API Key Here';

I’ll also assign our zip code and country code. Since we are not expecting user input and are rather hard coding the data, I’ll make these constant as well, although, in many cases, it will be more useful to use let.

const LOCATION_ZIP_CODE = '90001'; const COUNTRY_CODE = 'us';

We now need to put these variables together into one URL to which we can use Axios to make GET Requests to:

const ENTIRE_API_URL = `$ {API_URL}$ {LOCATION_ZIP_CODE},$ {COUNTRY_CODE}&appid=$ {API_KEY}`;

Here is the contents of our app.js file up to this point:

const axios = require('axios');  // API specific settings. const API_URL = 'https://api.openweathermap.org/data/2.5/weather?zip='; const API_KEY = 'Your API Key Here';  const LOCATION_ZIP_CODE = '90001'; const COUNTRY_CODE = 'us';  const ENTIRE_API_URL = `$ {API_URL}$ {LOCATION_ZIP_CODE},$ {COUNTRY_CODE}&appid=$ {API_KEY}`;

All that is left to do is to actually use axios to make a GET Request to that URL. For that, we’ll use the get(url) method provided by axios.

axios.get(ENTIRE_API_URL)

axios.get(...) actually returns a Promise, and the success callback function will take in a response argument which will allow us to access the response from the API — the same thing you saw in the browser. I’ll also add a .catch() clause to catch any errors.

axios.get(ENTIRE_API_URL)     .then(response => console.log(response))     .catch(error => console.log('Error', error));

If we now run this code with node app.js in the terminal, you will be able to see the full response we get back. However, suppose you just want to see the temperature for that zip code — then most of that data in the response is not useful to you. Axios actually returns the response from the API in the data object, which is a property of the response. That means the response from the server is actually located at response.data, so let’s print that instead in the callback function: console.log(response.data).

Now, we said that web servers always deal with JSON as a string, and that is true. You might notice, however, that response.data is already an object (evident by running console.log(typeof response.data)) — we didn’t have to parse it with JSON.parse(). That is because Axios already takes care of this for us behind the scenes.

The output in the terminal from running console.log(response.data) can be formatted — “pretty-printed” — by running console.log(JSON.stringify(response.data, undefined, 2)). JSON.stringify() converts a JSON object into a string, and take in the object, a filter, and the number of characters by which to indent by when printing. You can see the response this provides:

{   "coord": {     "lon": -118.24,     "lat": 33.97   },   "weather": [     {       "id": 800,       "main": "Clear",       "description": "clear sky",       "icon": "01d"     }   ],   "base": "stations",   "main": {     "temp": 288.21,     "pressure": 1022,     "humidity": 15,     "temp_min": 286.15,     "temp_max": 289.75   },   "visibility": 16093,   "wind": {     "speed": 2.1,     "deg": 110   },   "clouds": {     "all": 1   },   "dt": 1546459080,   "sys": {     "type": 1,     "id": 4361,     "message": 0.0072,     "country": "US",     "sunrise": 1546441120,     "sunset": 1546476978   },   "id": 420003677,   "name": "Lynwood",   "cod": 200 }

Now, it is clear to see that the temperature we are looking for is located on the main property of the response.data object, so we can access it by calling response.data.main.temp. Let’s look at out application’s code up to now:

const axios = require('axios');  // API specific settings. const API_URL = 'https://api.openweathermap.org/data/2.5/weather?zip='; const API_KEY = 'Your API Key Here';  const LOCATION_ZIP_CODE = '90001'; const COUNTRY_CODE = 'us';  const ENTIRE_API_URL = `$ {API_URL}$ {LOCATION_ZIP_CODE},$ {COUNTRY_CODE}&appid=$ {API_KEY}`;  axios.get(ENTIRE_API_URL)     .then(response => console.log(response.data.main.temp))     .catch(error => console.log('Error', error));

The temperature we get back is actually in Kelvin, which is a temperature scale generally used in Physics, Chemistry, and Thermodynamics due to the fact that it provides an “absolute zero” point, which is the temperature at which all thermal motion of all inner particles cease. We just need to convert this to Fahrenheit or Celcius with the formulas below:

F = K * 9/5 — 459.67 C = K — 273.15

Let’s update our success callback to print the new data with this conversion. We’ll also add in a proper sentence for the purposes of User Experience:

axios.get(ENTIRE_API_URL)     .then(response => {         // Getting the current temperature and the city from the response object.         const kelvinTemperature = response.data.main.temp;         const cityName = response.data.name;         const countryName = response.data.sys.country;          // Making K to F and K to C conversions.         const fahrenheitTemperature = (kelvinTemperature * 9/5) — 459.67;         const celciusTemperature = kelvinTemperature — 273.15;          // Building the final message.         const message = (             `Right now, in              $ {cityName}, $ {countryName} the current temperature is              $ {fahrenheitTemperature.toFixed(2)} deg F or              $ {celciusTemperature.toFixed(2)} deg C.`.replace(/s+/g, ' ')         );          console.log(message);     })     .catch(error => console.log('Error', error));

The parentheses around the message variable are not required, they just look nice — similar to when working with JSX in React. The backslashes stop the template string from formatting a new line, and the replace() String prototype method gets rid of white space using Regular Expressions (RegEx). The toFixed() Number prototype methods rounds a float to a specific number of decimal places — in this case, two.

With that, our final app.js looks as follows:

const axios = require('axios');  // API specific settings. const API_URL = 'https://api.openweathermap.org/data/2.5/weather?zip='; const API_KEY = 'Your API Key Here';  const LOCATION_ZIP_CODE = '90001'; const COUNTRY_CODE = 'us';  const ENTIRE_API_URL = `$ {API_URL}$ {LOCATION_ZIP_CODE},$ {COUNTRY_CODE}&appid=$ {API_KEY}`;  axios.get(ENTIRE_API_URL)     .then(response => {         // Getting the current temperature and the city from the response object.         const kelvinTemperature = response.data.main.temp;         const cityName = response.data.name;         const countryName = response.data.sys.country;          // Making K to F and K to C conversions.         const fahrenheitTemperature = (kelvinTemperature * 9/5) — 459.67;         const celciusTemperature = kelvinTemperature — 273.15;          // Building the final message.         const message = (             `Right now, in              $ {cityName}, $ {countryName} the current temperature is              $ {fahrenheitTemperature.toFixed(2)} deg F or              $ {celciusTemperature.toFixed(2)} deg C.`.replace(/s+/g, ' ')         );          console.log(message);     })     .catch(error => console.log('Error', error));

Conclusion

We have learned a lot about how Node works in this article, from the differences between synchronous and asynchronous requests, to callback functions, to new ES6 features, events, package managers, APIs, JSON, and the HyperText Transfer Protocol, Non-Relational Databases, and we even built our own command line application utilizing most of that new found knowledge.

In future articles in this series, we’ll take an in-depth look at the Call Stack, the Event Loop, and Node APIs, we’ll talk about Cross-Origin Resource Sharing (CORS), and we’ll build a Full Stack Bookshelf API utilizing databases, endpoints, user authentication, tokens, server-side template rendering, and more.

From here, start building your own Node applications, read the Node documentation, go out and find interesting APIs or Node Modules and implement them yourself. The world is your oyster and you have at your fingertips access to the largest network of knowledge on the planet — the Internet. Use it to your advantage.

Using Vue.js To Create An Interactive Weather Dashboard With APIs

by TBSCategories: News

Using Vue.js To Create An Interactive Weather Dashboard With APIs

Souvik Sarkar

2019-02-01T13:00:18+01:00 2019-02-01T17:32:19+00:00

(This is a sponsored article.) In this tutorial, you will build a simple weather dashboard from scratch. It will be a client-end application that is neither a “Hello World” example, nor too intimidating in its size and complexity.

The entire project will be developed using tools from the Node.js + npm ecosystem. In particular, we will be heavily relying on the Dark Sky API for the data, Vue.js for all the heavy lifting, and FusionCharts for data visualization.

Prerequisites

We expect that you are familiar with the following:

HTML5 and CSS3 (we will also be using the basic features provided by Bootstrap;
JavaScript (especially ES6 way of using the language);
Node.js and npm (the basics of the environment and package management is just fine).

Apart from the ones mentioned above, it would be great if you have familiarity with Vue.js, or any other similar JavaScript framework. We don’t expect you to know about FusionCharts — it’s so easy to use that you will learn it on the fly!

Expected Learnings

Your key learnings from this project will be:

How to plan about implementing a good dashboard
How to develop applications with Vue.js
How to create data-driven applications
How to visualize data using FusionCharts

In particular, each of the sections take you a step closer to the learning goals:

An Introduction To The Weather Dashboard
This chapter gives you an overview of different aspects of the undertaking.
Create The Project
In this section, you learn about creating a project from scratch using the Vue command-line tool.
Customize The Default Project Structure
The default project scaffolding that you get in the previous section is not enough; here you learn the additional stuff needed for the project from a structural point of view.
Data Acquisition And Processing
This section is the meat of the project; all the critical code for acquiring and processing data from the API is showcased here. Expect to spend maximum time on this section.
Data Visualization With FusionCharts
Once we have all the data and other moving parts of the project stabilized, this section is dedicated towards visualizing the data using FusionCharts and a bit of CSS.

1. The Dashboard Workflow

Before we dive into the implementation, it is important to be clear about our plan. We break our plan into four distinct aspects:

Requirements

What are our requirements for this project? In other words, what are the things that we want to showcase through our Weather Dashboard? Keeping in mind that our intended audience are probably mere mortals with simple tastes, we would like to show them the following:

Details of the location for which they want to see the weather, along with some primary information about the weather. Since there are no stringent requirements, we will figure out the boring details later. However, at this stage, it is important to note that we will have to provide the audience a search box, so that they can provide input for the location of their interest.
Graphical information about the weather of their location of interest, such as:
- Temperature variation for the day of query
- Highlights of today’s weather:
  - Wind Speed and Direction
  - Visibility
  - UV Index

Note: The data obtained from the API provides information regarding many other aspects of the weather. We choose not to use all of them for the sake of keeping the code to a minimum.

Structure

Based on the requirements, we can structure our dashboard as shown below:

Data

Our dashboard is as good as the data we get, because there will be no pretty visualizations without proper data. There are plenty of public APIs that provide weather data — some of them are free, and some are not. For our project, we will collect data from the Dark Sky API. However, we will not be able to poll the API endpoint from the client end directly. Don’t worry, we have a workaround that will be revealed just at the right time! Once we get the data for the searched location, we will do some data processing and formatting — you know, the type of technicalities that helps us pay the bills.

Visualization

Once we get clean and formatted data, we plug it in to FusionCharts. There are very few JavaScript libraries in the world as capable as FusionCharts. Out of the vast number of offerings from FusionCharts, we will use only a few — all written in JavaScript, but works seamlessly when integrated with the Vue wrapper for FusionCharts.

Armed with the bigger picture, let’s get our hands dirty — it’s time to make things concrete! In the next section, you will create the basic Vue project, on top of which we will build further.

2. Creating The Project

To create the project, execute the following steps:

Install Node.js + npm
(If you have Node.js installed on your computer, skip this step.)
Node.js comes with npm bundled with it, so you don’t need to install npm separately. Depending on the operating system, download and install Node.js according to the instructions given here.
Once installed, it’s probably a good idea to verify if the software is working correctly, and what are their versions. To test that, open the command-line/terminal and execute the following commands:
```
node --version npm --version 
```
Install packages with npm
Once you have npm up and running, execute the following command to install the basic packages necessary for our project.
```
npm install -g vue@2 vue-cli@2 
```
Initialize project scaffolding with vue-cli
Assuming that the previous step has gone all well, the next step is to use the vue-cli — a command-line tool from Vue.js, to initialize the project. To do that, execute the following:

Initialize the scaffolding with webpack-simple template.
```
vue init webpack-simple vue_weather_dashboard         
```
You will be asked a bunch of questions — accepting the defaults for all but the last question will be good enough for this project; answer N for the last one.

(Large preview)

Keep in mind that although webpack-simple is excellent for quick prototyping and light application like ours, it is not particularly suited for serious applications or production deployment. If you want to use any other template (although we would advise against it if you are a newbie), or would like to name your project something else, the syntax is:
```
vue init [template-name] [project-name]         
```
Navigate to the directory created by vue-cli for the project.
```
cd vue_weather_dashboard         
```
Install all the packages mentioned in the package.json, which has been created by the vue-cli tool for the webpack-simple template.
```
npm install         
```
Start the development server and see your default Vue project working in the browser!
```
npm run dev         
```

If you are new to Vue.js, take a moment to savor your latest achievement — you have created a small Vue application and its running at localhost:8080!

A screenshot of the Vue.js website — (Large preview)

Brief Explanation Of The Default Project Structure

It’s time to take a look at the structure inside the directory vue_weather_dashboard, so that you have an understanding of the basics before we start modifying it.

The structure looks something like this:

vue_weather_dashboard |--- README.md |--- node_modules/ |     |--- ... |     |--- ... |     |--- [many npm packages we installed] |     |--- ... |     |--- ... |--- package.json |--- package-lock.json |--- webpack.config.js |--- index.html |--- src |     |--- App.vue |     |--- assets |     |     |--- logo.png |     |--- main.js

Although it might be tempting to skip getting familiar with the default files and directories, if you are new to Vue, we strongly recommend at least taking a look at the contents of the files. It can be a good educational session and trigger questions that you should pursue on your own, especially the following files:

package.json, and just a glance at its cousin package-lock.json
webpack.config.js
index.html
src/main.js
src/App.vue

A brief explanation of each of the files and directories shown in the tree diagram are given below:

README.md
No prize for guessing — it is primarily for humans to read and understand the steps necessary for creating the project scaffolding.
node_modules/
This is the directory where npm downloads the packages necessary for kickstarting the project. The information about the packages necessary are available in the package.json file.
package.json
This file is created by the vue-cli tool based on the requirements of the webpack-simple template, and contains information about the npm packages (including with their versions and other details) that must be installed. Take a hard look at the content of this file — this is where you should visit and perhaps edit to add/delete packages necessary for the project, and then run npm install. Read more about package.json here.
package-lock.json
This file is created by npm itself, and is primarily meant for keeping a log of things that npm downloaded and installed.
webpack.config.js
This a JavaScript file that contains the configuration of webpack — a tool that bundles different aspects of our project together (code, static assets, configuration, environments, mode of use, etc.), and minifies before serving it to the user. The benefit is that all things are tied together automatically, and the user experience enhances greatly because of the improvement in the application’s performance (pages are served quickly and loads faster on the browser). As you might encounter later, this is the file that needs to be inspected when something in the build system does not works the way it is intended to be. Also, when you want to deploy the application, this is one of the key files that needs to be edited (read more here).
index.html
This HTML file serves as the matrix (or you can say, template) where data and code is to be embedded dynamically (that’s what Vue primarily does), and then served to the user.
src/main.js
This JavaScript file contains code that primarily manages top/project level dependencies, and defines the topmost level Vue component. In short, it orchestrates the JavaScript for the entire project, and serves as the entry point of the application. Edit this file when you need to declare project-wide dependencies on certain node modules, or you want something to be changed about the topmost Vue component in the project.
src/App.vue
In the previous point, when we were talking about the “topmost Vue component”, we were essentially talking about this file. Each .vue file in the project is a component, and components are hierarchically related. At the start, we have only one .vue file, i.e. App.vue, as our only component. But shortly we will add more components to our project (primarily following the structure of the dashboard), and link them in accordance to our desired hierarchy, with App.vue being the ancestor of all. These .vue files will contain code in a format that Vue wants us to write. Don’t worry, they are JavaScript code written maintaining a structure that can keep us sane and organized. You have been warned — by the end of this project, if you are new to Vue, you may get addicted to the template — script — style way of organizing code!

Now that we have created the foundation, it’s time to:

Modify the templates and tweak the configuration files a bit, so that the project behaves just the way we want.
Create new .vue files, and implement the dashboard structure with Vue code.

We will learn them in the next section, which is going to be a bit long and demands some attention. If you need caffeine or water, or want to discharge — now is the time! 

3. Customizing The Default Project Structure

It’s time to tinker with the foundation that the scaffolded project has given us. Before you start, ensure that the development server provided by webpack is running. The advantage of running this server continuously is that any changes you make in the source code — one you save it and refresh the web page — it gets immediately reflected on the browser.

If you want to start the development server, just execute the following command from the terminal (assuming your current directory is the project directory):

npm run dev

In the following sections, we will modify some of the existing files, and add some new files. It will be followed by brief explanations of the content of those files, so that you have an idea of what those changes are meant to do.

Modify Existing Files

index.html

Our application is literally a single page application, because there is just one webpage that gets displayed on the browser. We will talk about this later, but first let’s just make our first change — altering the text within the <title> tag.

With this small revision, the HTML file looks like the following:

<!DOCTYPE html> <html lang="en">   <head>     <meta charset="utf-8">     <!-- Modify the text of the title tag below -->     <title>Vue Weather Dashboard</title>   </head>   <body>     <div id="app"></div>     <script src="/dist/build.js"></script>   </body> </html>

Take a moment to refresh the webpage at localhost:8080, and see the change reflected on the title bar of the tab on the browser — it should say “Vue Weather Dashboard”. However, this was just to demonstrate you the process of making changes and verifying if it’s working. We have more things to do!

This simple HTML page lacks many things that we want in our project, especially the following:

Some meta information
CDN links to Bootstrap (CSS framework)
link to custom stylesheet (yet to be added in the project)
Pointers to the Google Maps Geolocation API from <script> tag

After adding those things, the final index.html has the following content:

<!DOCTYPE html> <html lang="en">  <head>    <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />    <meta http-equiv="X-UA-Compatible" content="IE=edge">    <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">    <link rel="stylesheet" href="//maxcdn.bootstrapcdn.com/bootstrap/4.0.0/css/bootstrap.min.css">    <link rel="stylesheet" type="text/css" href="src/css/style.css">    <title>Weather Dashboard</title>    <script src="https://maps.googleapis.com/maps/api/js?key=AIzaSyC-lCjpg1xbw-nsCc11Si8Ldg2LKYizqI4&libraries=places"></script>  </head>  <body>    <div id="app"></div>    <script src="/dist/build.js"></script>  </body> </html>

Save the file, and refresh the webpage. You might have noticed a slight bump while the page was getting loaded — it is primarily due to the fact that the page style is now being controlled by Bootstrap, and the style elements like fonts, spacing, etc. are different from the default we had earlier (if you are not sure, roll back to the default and see the difference).

A screenshot when you refresh the webpage with localhost:8080 — (Large preview)

Note: One important thing before we move on — the URL for the Google Maps API contains a key which is a property of FusionCharts. For now, you can use this key to build the project, as we don’t want you to get bogged down by these type of minute details (which can be distractions while you are new). However, we strongly urge you to generate and use your own Google Maps API key once you have made some progress and feel comfortable to pay attention to these tiny details.

package.json

At the time of writing this, we used certain versions of the npm packages for our project, and we know for sure that those things work together. However, by the time you are executing the project, it is very much possible that the latest stable versions of the packages that npm downloads for you are not the same as we used, and this might break the code (or do things that are beyond our control). Thus, it is very important to have the exact same package.json file that was used to build this project, so that our code/explanations and the results you get are consistent.

The content of the package.json file should be:

{  "name": "vue_weather_dashboard",  "description": "A Vue.js project",  "version": "1.0.0",  "author": "FusionCharts",  "license": "MIT",  "private": true,  "scripts": {    "dev": "cross-env NODE_ENV=development webpack-dev-server --open --hot",    "build": "cross-env NODE_ENV=production webpack --progress --hide-modules"  },  "dependencies": {    "axios": "^0.18.0",    "babel": "^6.23.0",    "babel-cli": "^6.26.0",    "babel-polyfill": "^6.26.0",    "fusioncharts": "^3.13.3",    "moment": "^2.22.2",    "moment-timezone": "^0.5.21",    "vue": "^2.5.11",    "vue-fusioncharts": "^2.0.4"  },  "browserslist": [    "> 1%",    "last 2 versions",    "not ie <= 8"  ],  "devDependencies": {    "babel-core": "^6.26.0",    "babel-loader": "^7.1.2",    "babel-preset-env": "^1.6.0",    "babel-preset-stage-3": "^6.24.1",    "cross-env": "^5.0.5",    "css-loader": "^0.28.7",    "file-loader": "^1.1.4",    "vue-loader": "^13.0.5",    "vue-template-compiler": "^2.4.4",    "webpack": "^3.6.0",    "webpack-dev-server": "^2.9.1"  } }

We encourage you to go through the new package.json, and figure out what are functions of different objects in the json. You may prefer changing the value of the “author” key to your name. Also, the packages mentioned in the dependencies will reveal themselves at the right time in the code. For the time being, it’s sufficient to know that:

babel-related packages are for properly handling the ES6 style code by the browser;
axios deals with Promise-based HTTP requests;
moment and moment-timezone are for date/time manipulation;
fusioncharts and vue-fusioncharts are responsible for rendering charts:
vue, for obvious reasons.

webpack.config.js

As with package.json, we suggest you to maintain a webpack.config.js file that is consistent with the one we used for building the project. However, before making any changes, we recommend you to carefully compare the default code in the webpack.config.js, and the code we have provided below. You will notice quite a few differences — google them and have a basic idea of what they mean. Since explaining webpack configurations in depth is out of the scope of this article, you are on your own in this regard.

The customized webpack.config.js file is as follows:

var path = require('path') var webpack = require('webpack')  module.exports = {  entry: ['babel-polyfill', './src/main.js'],  output: {    path: path.resolve(__dirname, './dist'),    publicPath: '/dist/',    filename: 'build.js'  },  module: {    rules: [      {        test: /.css$ /,        use: [          'vue-style-loader',          'css-loader'        ],      },      {        test: /.vue$ /,        loader: 'vue-loader',        options: {          loaders: {          }          // other vue-loader options go here        }      },      {        test: /.js$ /,        loader: 'babel-loader',        exclude: /node_modules/      },      {        test: /.(png|jpg|gif|svg)$ /,        loader: 'file-loader',        options: {          name: '[name].[ext]?[hash]'        }      }    ]  },  resolve: {    alias: {      'vue$ ': 'vue/dist/vue.esm.js'    },    extensions: ['*', '.js', '.vue', '.json']  },  devServer: {    historyApiFallback: true,    noInfo: true,    overlay: true,    host: '0.0.0.0',    port: 8080  },  performance: {    hints: false  },  devtool: '#eval-source-map' }  if (process.env.NODE_ENV === 'production') {  module.exports.devtool = '#source-map'  // http://vue-loader.vuejs.org/en/workflow/production.html  module.exports.plugins = (module.exports.plugins || []).concat([    new webpack.DefinePlugin({      'process.env': {        NODE_ENV: '"production"'      }    }),    new webpack.optimize.UglifyJsPlugin({      sourceMap: true,      compress: {        warnings: false      }    }),    new webpack.LoaderOptionsPlugin({      minimize: true    })  ]) }

With changes made to the project’s webpack.config.js, it’s imperative that you stop the development server which is running (Ctrl + C), and restart it with the following command executed from the project’s directory after installing all the packages mentioned in the package.json file:

npm install  npm run dev

With this, the ordeal of tweaking the configurations and ensuring that the right packages are in place ends. However, this also marks the journey of modifying and writing code, which is a bit long but also very rewarding!

src/main.js

This file is the key to top-level orchestration of the project — it is here that we define:

What the top level dependencies are (where to get the most important npm packages necessary);
How to resolve the dependencies, along with instructions to Vue on using plugins/wrappers, if any;
A Vue instance that manages the topmost component in the project: src/App.vue (the nodal .vue file).

In line with our goals for the src/main.js file, the code should be:

// Import the dependencies and necessary modules import Vue from 'vue'; import App from './App.vue'; import FusionCharts from 'fusioncharts'; import Charts from 'fusioncharts/fusioncharts.charts'; import Widgets from 'fusioncharts/fusioncharts.widgets'; import PowerCharts from 'fusioncharts/fusioncharts.powercharts'; import FusionTheme from 'fusioncharts/themes/fusioncharts.theme.fusion'; import VueFusionCharts from 'vue-fusioncharts';  // Resolve the dependencies Charts(FusionCharts); PowerCharts(FusionCharts); Widgets(FusionCharts); FusionTheme(FusionCharts);  // Globally register the components for project-wide use Vue.use(VueFusionCharts, FusionCharts);  // Instantiate the Vue instance that controls the application new Vue({  el: '#app',  render: h => h(App) })

src/App.vue

This is one of the most important files in the entire project, and represents the topmost component in the hierarchy — the entire application itself, as a whole. For our project, this component will do all the heavy lifting, which we will explore later. For now, we want to get rid of the default boilerplate, and put something of our own.

If you are new to Vue’s way of organizing code, it would be better to get an idea of the general structure within the .vue files. The .vue files comprises of three sections:

Template
This is where the HTML template for the page is defined. Apart from the static HTML, this section also contains Vue’s way of embedding dynamic content, using the double curly braces {{ }}.
Script
JavaScript rules this section, and is responsible for generating dynamic content that goes and sits within the HTML template at appropriate places. This section is primarily an object that is exported, and consists of:
- Data
  This is a function itself, and usually it returns some desired data encapsulated within a nice data structure.
- Methods
  An object that consists of one or more functions/methods, each of which usually manipulates data in some way or the other, and also controls the dynamic content of the HTML template.
- Computed
  Much like the method object discussed above with one important distinction — while all the functions within the method object are executed whenever any one of them is called, the functions within the computed object behaves much more sensibly, and executes if and only if it has been called.
Style
This section is for CSS styling that applies to the HTML of the page (written within template) — put the good old CSS here to make your pages beautiful!

Keeping the above paradigm in mind, let’s minimally customize the code in App.vue:

<template>   <div id="app">     <p>This component’s code is in {{ filename }}</p>   </div> </template>  <script> export default {   data() {     return {       filename: 'App.vue'     }   },   methods: {    },   computed: {    }, } </script>  <style>  </style>

Remember that the above code snippet is simply for testing out that App.vue is working with our own code in it. It will later go on through a lot of changes, but first save the file and refresh the page on the browser.

A screenshot of the browser with the message “This component’s code is in App.vue” — (Large preview)

At this point, it’s probably a good idea to get some help in tooling. Check out the Vue devtools for Chrome, and if you don’t have much problems in using Google Chrome as your default browser for development, install the tool and play around with it a bit. It will come in extremely handy for further development and debugging, when things becomes more complicated.

Additional Directories And Files

The next step would be to add additional files, so that the structure of our project becomes complete. We would add the following directories and files:

src/css/ — style.css
src/assets/ — calendar.svg — vlocation.svg — search.svg — winddirection.svg — windspeed.svg
src/components/ — Content.vue — Highlights.vue — TempVarChart.vue — UVIndex.vue — Visibility.vue — WindStatus.vue

Note: Save the hyperlinked .svg files in your project.

Create the directories and files mentioned above. The final project structure should like look (remember to delete folders and files from the default structure that are now unnecessary):

vue_weather_dashboard/ |--- README.md |--- node_modules/ |     |--- ... |     |--- ... |     |--- [many npm packages we installed] |     |--- ... |     |--- ... |--- package.json |--- package-lock.json |--- webpack.config.js |--- index.html |--- src/ |     |--- App.vue |     |--- css/ |     |     |--- style.css  |     |--- assets/ |     |     |--- calendar.svg |     |     |--- location.svg |     |     |--- location.svg |     |     |--- winddirection.svg |     |     |--- windspeed.svg |     |--- main.js |     |--- components/ |     |     |--- Content.vue |     |     |--- Highlights.vue |     |     |--- TempVarChart.vue |     |     |--- UVIndex.vue |     |     |--- Visibility.vue |     |     |--- WindStatus.vue

There might be some other files, like .babelrc, .gitignore, .editorconfig, etc. in the project’s root folder. You may ignore them safely for now.

In the following section, we will add minimal content to the newly added files, and test whether they are properly working.

src/css/style.css

Although it will not be of much use immediately, copy the following code to the file:

@import url("https://fonts.googleapis.com/css?family=Roboto:300,400,500");  :root {    font-size: 62.5%; }  body {    font-family: Roboto;    font-weight: 400;    width: 100%;    margin: 0;    font-size: 1.6rem; }  #sidebar {    position: relative;    display: flex;    flex-direction: column;    background-image: linear-gradient(-180deg, #80b6db 0%, #7da7e2 100%); }  #search {    text-align: center;    height: 20vh;    position: relative; }  #location-input {    height: 42px;    width: 100%;    opacity: 1;    border: 0;    border-radius: 2px;    background-color: rgba(255, 255, 255, 0.2);    margin-top: 16px;    padding-left: 16px;    color: #ffffff;    font-size: 1.8rem;    line-height: 21px; }  #location-input:focus {    outline: none; }  ::placeholder {    color: #FFFFFF;    opacity: 0.6; }  #current-weather {    color: #ffffff;    font-size: 8rem;    line-height: 106px;    position: relative; }  #current-weather>span {    color: #ffffff;    font-size: 3.6rem;    line-height: 42px;    vertical-align: super;    opacity: 0.8;    top: 15px;    position: absolute; }  #weather-desc {    font-size: 2.0rem;    color: #ffffff;    font-weight: 500;    line-height: 24px; }  #possibility {    color: #ffffff;    font-size: 16px;    font-weight: 500;    line-height: 19px; }  #max-detail, #min-detail {    color: #ffffff;    font-size: 2.0rem;    font-weight: 500;    line-height: 24px; }  #max-detail>i, #min-detail>i {    font-style: normal;    height: 13.27px;    width: 16.5px;    opacity: 0.4; }  #max-detail>span, #min-detail>span {    color: #ffffff;    font-family: Roboto;    font-size: 1.2rem;    line-height: 10px;    vertical-align: super; }  #max-summary, #min-summary {    opacity: 0.9;    color: #ffffff;    font-size: 1.4rem;    line-height: 16px;    margin-top: 2px;    opacity: 0.7; }  #search-btn {    position: absolute;    right: 0;    top: 16px;    padding: 2px;    z-index: 999;    height: 42px;    width: 45px;    background-color: rgba(255, 255, 255, 0.2);    border: none; }  #dashboard-content {    text-align: center;    height: 100vh; }  #date-desc, #location-desc {    color: #ffffff;    font-size: 1.6rem;    font-weight: 500;    line-height: 19px;    margin-bottom: 15px; }  #date-desc>img {    top: -3px;    position: relative;    margin-right: 10px; }  #location-desc>img {    top: -3px;    position: relative;    margin-left: 5px;    margin-right: 15px; }  #location-detail {    opacity: 0.7;    color: #ffffff;    font-size: 1.4rem;    line-height: 20px;    margin-left: 35px; }  .centered {    position: fixed;    top: 45%;    left: 50%;    transform: translate(-50%, -50%); }  .max-desc {    width: 80px;    float: left;    margin-right: 28px; }  .temp-max-min {    margin-top: 40px }  #dashboard-content {    background-color: #F7F7F7; }  .custom-card {    background-color: #FFFFFF !important;    border: 0 !important;    margin-top: 16px !important;    margin-bottom: 20px !important; }  .custom-content-card {    background-color: #FFFFFF !important;    border: 0 !important;    margin-top: 16px !important;    margin-bottom: 0px !important; }  .header-card {    height: 50vh; }  .content-card {    height: 43vh; }  .card-divider {    margin-top: 0; }  .content-header {    color: #8786A4;    font-size: 1.4rem;    line-height: 16px;    font-weight: 500;    padding: 15px 10px 5px 15px; }  .highlights-item {    min-height: 37vh;    max-height: 38vh;    background-color: #FFFFFF; }   .card-heading {    color: rgb(33, 34, 68);    font-size: 1.8rem;    font-weight: 500;    line-height: 21px;    text-align: center; }  .card-sub-heading {    color: #73748C;    font-size: 1.6rem;    line-height: 19px; }  .card-value {    color: #000000;    font-size: 1.8rem;    line-height: 21px; }  span text {    font-weight: 500 !important; }  hr {    padding-top: 1.5px;    padding-bottom: 1px;    margin-bottom: 0;    margin-top: 0;    line-height: 0.5px; }  @media only screen and (min-width: 768px) {    #sidebar {        height: 100vh;    }     #info {        position: fixed;        bottom: 50px;        width: 100%;        padding-left: 15px;    }     .wrapper-right {        margin-top: 80px;    } }  @media only screen and (min-width:1440px) {    #sidebar {        width: 350px;        max-width: 350px;        flex: auto;    }     #dashboard-content {        width: calc(100% — 350px);        max-width: calc(100% — 350px);        flex: auto;    } }

src/assets/

In this directory, download and save the .svg files mentioned below:

src/components/Content.vue

This is what we call a dumb component — a placeholder, that is there just to maintain the hierarchy, and essentially passes on data to its child components.

Remember that there is no technical bar for writing all our code in the App.vue file, but we take the approach of splitting up the code by nesting the components for two reasons:

To write clean code, which aids readability and maintainability;
To replicate the same structure that we will see on screen, i.e., the hierarchy.

Before we nest the component defined in Content.vue within the root component App.vue, let’s write some toy (but educational) code for Content.vue:

<template>   <div>     <p>This child components of Content.vue are:</p>     <ul>       <li v-for="child in childComponents">{{ child }}</li>     </ul>   </div> </template>  <script> export default {   data () {     return {       childComponents: ['TempVarChart.vue', 'Highlights.vue']     }   },   methods: {    },   computed: {    }, } </script>  <style>  </style>

In the code, carefully observe and understand the following:

Within the <script> tag (where we obviously write some JavaScript code), we define an object that is exported (made available to other files) by default. This object contains a function data(), that returns an array object called childComponents, with its elements being names of the component files that should be nested further.
Within the <template> tag (where we write some HTML template), the thing of interest is the <ul>.
- Within the unordered list, each list item should be names of the intended child components, as defined in the array object childComponents. Moreover, the list should automatically extend till the last element of the array. Seems like we should write a for-loop, isn’t it? We do that by using the v-for directive provided by Vue.js. The v-for directive:
  - Acts as an attribute of the <li> tag, iterates through the array, renders the names of the child components where the iterator is mentioned within the {{ }} brackets (where we write the text for the list items).

The code and the explanation above forms the basis of your subsequent understanding of how the script and the template are interrelated, and how we can use the directives provided by Vue.js.

We have learnt quite a lot, but even after all these, we have one thing left to learn about seamlessly connecting components in hierarchy — passing data down from the parent component to its children. For now, we need to learn how to pass some data from src/App.vue to src/components/Content.vue, so that we can use the same techniques for the rest of the component nesting in this project.

Data trickling down from the parent to the child components might sound simple, but the devil is in the details! As briefly explained below, there are multiple steps involved in making it work:

Defining and the data
For now, we want some static data to play with — an object containing hard-coded values about different aspects of weather will just be fine! We create an object called weather_data and return it from the data() function of App.vue. The weather_data object is given in the snippet below:

weather_data: {         location: "California",         temperature: {           current: "35 C",         },         highlights: {           uvindex: "3",           windstatus: {             speed: "20 km/h",             direction: "N-E",           },           visibility: "12 km",         },       },

Passing the data from the parent
To pass the data, we need a destination where we want to send the data! In this case, the destination is the Content.vue component, and the way to implement it is to:
- Assign the weather_data object to a custom attribute of the <Content> tag
- Bind the attribute with the data using the v-bind: directive provided by Vue.js, which makes the attribute value dynamic (responsive to changes made in the original data).
```
<Content v-bind:weather_data=“weather_data”></Content> 
```

Defining and passing the data is handled at the source side of the handshake, which in our case is the App.vue file.

The code for the App.vue file, at its current status, is given below:

<template>   <div id="app">     <p>This component’s code is in {{ filename }}</p>     <Content v-bind:weather_data="weather_data"></Content>   </div> </template>  <script> import Content from './components/Content.vue'  export default {   name: 'app',   components: {     'Content': Content   },   data () {     return {       filename: 'App.vue',       weather_data: {         location: "California",         temperature: {           current: "35 C",         },         highlights: {           uvindex: "3",           windstatus: {             speed: "20 km/h",             direction: "N-E",           },           visibility: "12 km",         },       },     }   },   methods: {    },   computed: {    }, } </script>  <style>  </style>

A screenshot of the browser with the message “This component’s code is in App.vue. This child components of Content.vue are: TempVarChart.vue, Highlights.vue” — (Large preview)

With the data defined and passed from the source (parent component), it is now the child’s responsibility to receive the data and render it appropriately, as explained in the next two steps.

Receiving the data by the child
The child component, in this case Content.vue, must receive the weather_data object send to it by the parent component App.vue. Vue.js provides a mechanism to do so — all you need is an array object called props, defined in the default object exported by Content.vue. Each element of the array props is a name of the data objects it wants to receive from its parent. For now, the only data object that it is supposed to receive is weather_data from App.vue. Thus, the props array looks like:

<template>   // HTML template code here </template>  <script> export default {   props: ["weather_data"],   data () {     return {       // data here     }   }, } </script>  <style>   // component specific CSS here </style>

Rendering the data in the page
Now that we have ensured receiving the data, the last task we need to complete is to render the data. For this example, we will directly dump the received data on the web page, just to illustrate the technique. However, in real applications (like the one we are about to build), data normally goes through lots of processing, and only the relevant parts of it are displayed in ways that suits the purpose. For example, in this project we will eventually get raw data from the weather API, clean and format it, feed the data to the data structures necessary for the charts, and then visualize it. Anyway, to display the raw data dump, we will just use the {{ }} brackets that Vue understands, as shown in the snippet below:

<template>   <div id="pagecontent">     // other template code here     {{ weather_data }}   </div> </template>

It’s now time to assimilate all the bits and pieces. The code for Content.vue — at its current status — is given below:

<template>   <div id="pagecontent">     <p>This child components of Content.vue are:</p>     <ul>       <li v-for="child in childComponents">{{ child }}</li>     </ul>     {{ weather_data }}   </div> </template>  <script> export default {   props: ["weather_data"],   data () {     return {       childComponents: ['TempVarChart.vue', 'Highlights.vue']     }   },   methods: {    },   computed: {        }, } </script>  <style> #pagecontent {   border: 1px solid black;   padding: 2px; } </style>

A screenshot of the browser with the result of the code provided — (Large preview)

After making the changes discussed above, refresh the webpage on the browser and see how it looks. Take a moment to appreciate the complexity that Vue handles — if you modify the weather_data object in App.vue, it gets silently conveyed to Content.vue, and eventually to the browser displaying the webpage! Try by changing the value for the key location.

Although we have learned about props and data binding using static data, we will be using dynamic data collected using web APIs in the application, and will change the code accordingly.

Summary

Before we move on to the rest of the .vue files, let’s summarize what we have learnt while we wrote the code for App.vue and components/Content.vue:

The App.vue file is what we call the root component — the one that sits at the top of the component hierarchy. The rest of the .vue files represents components that are its direct child, grandchild, and so on.
The Content.vue file is a dummy component — its responsibility is to pass on the data to levels below and maintain the structural hierarchy, so that our code remains consistent with the philosophy “*what we see is what we implement*”.
The parent-child relationship of component does not happen out of thin air — you must register a component (either globally or locally, depending on the intended usage of the component), and then nest it using custom HTML tags (whose spellings are the exact same as that of the names with which the components has been registered).
Once registered and nested, data is passed on from parent to child components, and the flow is never reverse (bad things will happen if the project architecture allows backflow). The parent component is the relative source of the data, and it passes down relevant data to its children using the v-bind directive for the attributes of the custom HTML elements. The child receives the data intended for it using props, and then decides on its own what to do with the data.

For the rest of the components, we will not indulge in detailed explanation — we will just write the code based on the learnings from the above summary. The code will be self-evident, and if you get confused about the hierarchy, refer to the diagram below:

A diagram explaining the hierarchy of the code — (Large preview)

The diagram says that TempVarChart.vue and Highlights.vue are the direct child of Content.vue. Thus, it might be a good idea to prepare Content.vue for sending data to those components, which we do using the code below:

<template>   <div id="pagecontent">     <p>This child components of Content.vue are:</p>     <ul>       <li v-for="child in childComponents">{{ child }}</li>     </ul>     {{ weather_data }}     <temp-var-chart :tempVar="tempVar"></temp-var-chart>     <today-highlights :highlights="highlights"></today-highlights>   </div> </template>  <script> import TempVarChart from './TempVarChart.vue' import Highlights from './Highlights.vue'  export default {   props: ["weather_data"],   components: {     'temp-var-chart': TempVarChart,     'today-highlights': Highlights   },   data () {     return {       childComponents: ['TempVarChart.vue', 'Highlights.vue'],       tempVar: this.weather_data.temperature,       highlights: this.weather_data.highlights,     }   },   methods: {    },   computed: {    }, } </script>  <style>  </style>

Once you save this code, you will get errors — don’t worry, it is expected. It will be fixed once you have the rest of the component files ready. If it bothers you not to be able to see the output, comment out the lines containing the custom element tags <temp-var-chart> and <today-highlights>.

For this section, this is the final code of Content.vue. For the rest of this section, we will reference to this code, and not the previous ones that we wrote for learning.

src/components/TempVarChart.vue

With its parent component Content.vue passing on the data, TempVarChart.vue must be set up to receive and render the data, as shown in the code below:

<template>   <div id="tempvarchart">     <p>Temperature Information:</p>     {{ tempVar }}   </div> </template>  <script>  export default {   props: ["tempVar"],   data () {     return {      }   },   methods: {    },   computed: {    }, } </script>  <style>  </style>

src/components/Highlights.vue

This component will also receive data from App.vue — its parent component. After that, it should be linked with its child components, and relevant data should be passed on to them.

Let’s first see the code for receiving data from the parent:

<template>   <div id="highlights">     <p>Weather Highlights:</p>     {{ highlights }}   </div> </template>  <script>  export default {   props: ["highlights"],   data () {     return {            }   },   methods: {    },   computed: {    }, } </script>  <style>  </style>

At this point, the web page looks like the image below:

Result of the code displayed in the browser — (Large preview)

Now we need to modify the code of Highlights.vue to register and nest its child components, followed by passing the data to children. The code for it is as follows:

<template>   <div id="highlights">     <p>Weather Highlights:</p>     {{ highlights }}     <uv-index :highlights="highlights"></uv-index>     <visibility :highlights="highlights"></visibility>     <wind-status :highlights="highlights"></wind-status>     </div> </template>  <script> import UVIndex from './UVIndex.vue'; import Visibility from './Visibility.vue'; import WindStatus from './WindStatus.vue';  export default {   props: ["highlights"],   components: {     'uv-index': UVIndex,     'visibility': Visibility,     'wind-status': WindStatus,   },     data () {     return {            }   },   methods: {    },   computed: {    }, } </script>  <style>  </style>

Once you save the code and see the web page, you are expected to see errors in the Developer Console tool provided by the browser; they appear because although Highlights.vue is sending data, nobody is receiving them. We are yet to write the code for the children of Highlights.vue.

Observe that we have not done much of the data processing, i.e, we have not extracted the individual factors of weather data that goes under the Highlights section of the dashboard. We could have done that in the data() function, but we preferred to keep Highlights.vue a dumb component that just passes on the entire data dump it receives to each of the children, who then own their own extracts what is necessary for them. However, we encourage you to try out extracting data in the Highlights.vue, and send relevant data down to each child component — it’s a good practice exercise nonetheless!

src/components/UVIndex.vue

The code for this component receives the data dump of highlights from Highlights.vue, extracts the data for UV Index, and renders it on the page.

<template>   <div id="uvindex">     <p>UV Index: {{ uvindex }}</p>   </div> </template>  <script>  export default {   props: ["highlights"],   data () {     return {       uvindex: this.highlights.uvindex     }   },   methods: {    },   computed: {    }, } </script>  <style>  </style>

src/components/Visibility.vue

The code for this component receives the data dump of highlights from Highlights.vue, extracts the data for Visibility, and renders it on the page.

<template>   <div id="visibility">     <p>Visibility: {{ visibility }}</p>   </div> </template>  <script>  export default {   props: ["highlights"],   data () {     return {       visibility: this.highlights.visibility,     }   },   methods: {    },   computed: {    }, } </script>  <style>  </style>

src/components/WindStatus.vue

The code for this component receives the data dump of highlights from Highlights.vue, extracts the data for Wind Status (speed and direction), and renders it on the page.

<template>   <div id="windstatus">     <p>Wind Status:</p>     <p>Speed — {{ speed }}; Direction — {{ direction }}</p>   </div> </template>  <script>  export default {   props: ["highlights"],   data () {     return {       speed: this.highlights.windstatus.speed,       direction: this.highlights.windstatus.direction     }   },   methods: {    },   computed: {    }, } </script>  <style>  </style>

After adding the code for all the components, take a look at the web page on the browser.

Not to dishearten, but all these toiling was just to link the components in hierarchy, and test out whether data flow is happening between them or not! In the next section, we will throw away most of the code we have written so far, and add a lot more pertaining to the actual project. However, we will certainly retain the structure and nesting of the components; the learnings from this section will allow us to build a decent dashboard with Vue.js.

4. Data Acquisition And Processing

Remember the weather_data object in App.vue? It had some hard-coded data that we used to test whether all the components are working correctly, and also to help you learn some basic aspects of Vue application without getting bogged down in the details of real-world data. However, it’s now time that we shed our shell, and step out into the real world, where data from the API will dominate most of our code.

Preparing Child Components To Receive And Process Real Data

In this section, you will get code dump for all the components except App.vue. The code will handle receiving real data from App.vue (unlike the code we wrote in the previous section to receive and render dummy data).

We strongly encourage to read the code of each component carefully, so that you form an idea of what data each of those components are expecting, and will eventually use in visualization.

Some of the code, and the overall structure, will be similar to the ones you have seen in the previous structure — so you will not face something drastically different. However, the devil is in the details! So examine the code carefully, and when you have understood them reasonably well, copy the code to the respective component files in your project.

Note: All the components in this section are in the src/components/ directory. So each time, the path will not be mentioned — only the .vue file name will be mentioned to identify the component.

Content.vue

<template>  <div style="position: relative;">      <temp-var-chart :tempVar="tempVar"></temp-var-chart>      <today-highlights :highlights="highlights"></today-highlights>  </div> </template>  <script> import TempVarChart from './TempVarChart.vue'; import Highlights from './Highlights.vue';  export default {  props: ['highlights', 'tempVar'],  components: {    'temp-var-chart': TempVarChart,    'today-highlights': Highlights  }, } </script>

The following changes have been made from the previous code:

In the <template>, text and data within {{ }} has been removed, since we are now just receiving data and passing down to the children, with no rendering specific this component.
In the export default {}:
- The props have been changed to match the data objects that will be send by the parent: App.vue. The reason for changing the props is that App.vue itself will display some of the data it acquires from the weather API and other online resources, based on the search query of the user, and pass on the rest of the data. In the dummy code we wrote earlier, App.vue was passing on the entire dummy data dump, without any discrimination, and the props of Content.vue was set up accordingly.
- The data() function now returns nothing, as we are not doing any data manipulation in this component.

TempVarChart.vue

This component is supposed to receive detailed temperature projections for the rest of the current day, and eventually display them using FusionCharts. But for the time being, we will display them only as text on the webpage.

<template>   <div>     {{ tempVar.tempToday }}       </div> </template>  <script> export default {   props: ["tempVar"],   components: {},   data() {     return {      };   },   methods: {        },    }; </script>  <style>  </style>

Highlights.vue

<template>   <div>     <uv-index :highlights="highlights"></uv-index>     <visibility :highlights="highlights"></visibility>     <wind-status :highlights="highlights"></wind-status>   </div> </template>  <script> import UVIndex from './UVIndex.vue'; import Visibility from './Visibility.vue'; import WindStatus from './WindStatus.vue';  export default {   props: ["highlights"],   components: {     'uv-index': UVIndex,     'visibility': Visibility,     'wind-status': WindStatus,   },   data () {     return {      }   },   methods: {    },   computed: {    }, } </script>  <style>  </style>

The changes made from the previous code are:

In the <template>, the text and the data within {{ }} has been removed, because this is a dumb component, just like Content.vue, whose only job is to pass on the data to children while maintaining the structural hierarchy. Remember that dumb components like Highlights.vue and Content.vue exists to maintain the parity between the visual structure of the dashboard, and the code we write.

UVIndex.vue

The changes made to the previous code are as follows:

In the <template> and <style>, the div id has been changed to uvIndex, which is more readable.
In the export default {}, the data() function now returns a string object uvIndex, whose value is extracted from the highlights object received by the component using props. This uvIndex is now temporarily used to display the value as text within the <template>. Later on, we will plug in this value to the data structure suitable for rendering a chart.

Visibility.vue

<template>   <div>     <p>Visibility: {{ visibility }}</p>   </div> </template>  <script>  export default {   props: ["highlights"],   data () {     return {       visibility: this.highlights.visibility.toString()     }   },   methods: {    },   computed: {    }, } </script>  <style>  </style>

The only change made in this file (with respect to its previous code) is that the definition of the visibility object returned by the data() function now contains toString() at its end, since the value received from the parent will be a floating point number, which needs to be converted into string.

WindStatus.vue

<template>   <div>     <p>Wind Speed — {{ windSpeed }}</p>     <p>Wind Direction — {{ derivedWindDirection }}, or {{ windDirection }} degree clockwise with respect to true N as 0 degree.</p>   </div> </template>  <script>  export default {   props: ["highlights"],   data () {     return {       windSpeed: this.highlights.windStatus.windSpeed,       derivedWindDirection: this.highlights.windStatus.derivedWindDirection,       windDirection: this.highlights.windStatus.windDirection     }   },   methods: {    },   computed: {    }, } </script>  <style>  </style>

The changes made to the previous code are as follows:

Throughout the file, windstatus has been renamed as windStatus, to promote readability and also to be in sync with the the highlights object that App.vue provides with actual data.
Similar naming changes have been made for the speed and direction — the new ones are windSpeed and windDirection.
A new object derivedWindDirection has come into play (also provided by App.vue in the highlights bundle).

For now, the received data is rendered as text; later, it will be plugged in to the data structure necessary for visualization.

Testing With Dummy Data

Resorting to dummy data repeatedly might be a bit frustrating for you, but there are some good reasons behind it:

We have made a lot of changes to the code of each component, and it’s a good idea to test whether those changes are breaking the code. In other words, we should check that whether the data flow is intact, now that we are about to move to more complex parts of the project.
The real data from the online weather API will need lot of massaging, and it might be overwhelming for you to juggle between the code for data acquisition and processing, and the code for smooth data flow down the components. The idea is to keep the quantum of complexity under control, so that we have a better understanding of the errors we might face.

In this section, what we do is essentially hardcode some json data in the App.vue, which will obviously be replaced with live data in the near future. There are a lot of similarity between the dummy json structure, and the json structure we will use for the actual data. So it also provides you a rough idea of what to expect from the real data, once we encounter it.

However, we admit that this is far from the ideal approach one might adopt while building such a project from scratch. In the real world, you will often start with the real data source, play around with it a bit to understand what can and should be done to tame it, and then think about the appropriate json data structure to capture the relevant information. We intentionally shielded you from all those dirty work, since it takes you farther from the objective — learning how to use Vue.js and FusionCharts to build a dashboard.

Let’s now jump into the new code for App.vue:

<template>   <div id="app">     <dashboard-content :highlights="highlights" :tempVar="tempVar"></dashboard-content>   </div> </template>  <script> import Content from './components/Content.vue'  export default {   name: 'app',   components: {     'dashboard-content': Content   },   data () {     return {       tempVar: {         tempToday: [           {hour: '11.00 AM', temp: '35'},           {hour: '12.00 PM', temp: '36'},           {hour: '1.00 PM', temp: '37'},           {hour: '2.00 PM', temp: '38'},           {hour: '3.00 PM', temp: '36'},           {hour: '4.00 PM', temp: '35'},         ],       },       highlights: {         uvIndex: 4,         visibility: 10,         windStatus: {           windSpeed: '30 km/h',           windDirection: '30',           derivedWindDirection: 'NNE',         },       },     }   },   methods: {    },   computed: {    }, } </script>  <style>  </style>

The changes made to the code with respect to its previous version are as follows:

The name of the child component has been changed to dashboard-content, and accordingly the custom HTML element in the <template> has been revised. Note that now we have two attributes — highlights and tempVar — instead of a single attribute that we used earlier with the custom element. Accordingly, the data associated with those attributes have also changed. What’s interesting here is that we can use the v-bind: directive, or its shorthand : (as we have done here), with multiple attributes of a custom HTML element!
The data() function now returns the filename object (that existed earlier), along with two new objects (instead of the old weather_data): tempVar and highlights. The structure of the json is appropriate for the code we have written in the child components, so that they can extract the data pieces they need from the dumps. The structures are quite self-explanatory, and you can expect them to be quite similar when we deal with live data. However, the significant change that you will encounter is the absence of hardcoding (obvious, isn’t it) — we will leave the values blank as the default state, and write code to dynamically update them based on the values we will receive from the weather API.

You have written a lot of code in this section, without seeing the actual output. Before you proceed further, take a look at the browser (restart the server with npm run dev, if necessary), and bask in the glory of your achievement. The web page that you should see at this point looks like the image below:

Code For Data Acquisition And Processing

This section is going to be the meat of the project, with all the code to be written in App.vue for the following:

Location input from the user — an input box and a call-to-action button is sufficient;
Utility functions for various tasks; these functions will be called later in various parts of the component code;
Getting detailed geolocation data from Google Maps API for JavaScript;
Getting detailed weather data from the Dark Sky API;
Formatting and processing the geolocation and weather data, which will be passed on to the child components.

The subsections that follows illustrates how we can implement the tasks laid out for us in the above points. With some exceptions, most of them will follow the sequence.

Input From The User

It’s quite obvious that the action starts when the user provides the name of the place for which the weather data needs to be displayed. For this to happen, we need to implement the following:

An input box for entering the location;
A submit button that tells our application that the user has entered the location and it’s time to do the rest. We will also implement the behavior when processing starts upon hitting Enter.

The code we show below will be restricted to the HTML template part of App.vue. We will just mention the name of the method associated with the click events, and define them later in the methods object of the <script> in App.vue.

<div id="search">            <input              id="location-input"              type="text"              ref="input"              placeholder="Location?"              @keyup.enter="organizeAllDetails"            >            <button id="search-btn" @click="organizeAllDetails">              <img src="./assets/Search.svg" width="24" height="24">            </button> </div>

Placing the above snippet in the right place is trivial — we leave it to you. However, the interesting parts of the snippet are:

@keyup.enter="organizeAllDetails"
@click="organizeAllDetails"

As you know from the earlier sections, @ is Vue’s shorthand for the directive v-on:, which is associated with some event. The new thing is “organizeAllDetails” — it’s nothing but the method that will fire once the events (pressing Enter or clicking the button) happens. We are yet to define method, and the puzzle will be complete by the end of this section.

Text Information Display Controlled By App.vue

Once the user input triggers the action and lots of data is acquired from the APIs, we encounter the inevitable question — “What to do with all these data?”. Obviously some data massaging is required, but that does not answer our question fully! We need to decide what’s the end use of the data, or more directly, which are the entities that receives different chunks of the acquired and processed data?

The child components of App.vue, based on their hierarchy and purpose, are the frontline contenders for the bulk of the data. However, we will also have some data that does not belong to any of those child components, yet are quite informative and makes the dashboard complete. We can make good use of them if we display them as text information directly controlled by App.vue, while the rest of the data are passed on to the child for getting displayed as pretty charts ultimately.

With this context in mind, let’s focus on the code for setting the stage of using text data. It’s simple HTML template at this point, on which the data will eventually come and sit.

<div id="info">   <div class="wrapper-left">     <div id="current-weather">       {{ currentWeather.temp }}       <span>°C</span>     </div>     <div id="weather-desc">{{ currentWeather.summary }}</div>     <div class="temp-max-min">       <div class="max-desc">         <div id="max-detail">           <i>▲</i>           {{ currentWeather.todayHighLow.todayTempHigh }}           <span>°C</span>         </div>         <div id="max-summary">at {{ currentWeather.todayHighLow.todayTempHighTime }}</div>       </div>       <div class="min-desc">         <div id="min-detail">           <i>▼</i>           {{ currentWeather.todayHighLow.todayTempLow }}           <span>°C</span>         </div>         <div id="min-summary">at {{ currentWeather.todayHighLow.todayTempLowTime }}</div>       </div>     </div>   </div>   <div class="wrapper-right">     <div class="date-time-info">       <div id="date-desc">         <img src="./assets/calendar.svg" width="20" height="20">         {{ currentWeather.time }}       </div>     </div>     <div class="location-info">       <div id="location-desc">         <img           src="./assets/location.svg"           width="10.83"           height="15.83"           style="opacity: 0.9;"         >         {{ currentWeather.full_location }}         <div id="location-detail" class="mt-1">           Lat: {{ currentWeather.formatted_lat }}           <br>           Long: {{ currentWeather.formatted_long }}         </div>       </div>     </div>   </div> </div>

In the above snippet, you should understand the following:

The stuff inside {{ }} — they are Vue’s way of inserting dynamic data in the HTML template, before it renders in the browser. You have encountered them before, and there is nothing new or surprising. Just keep in mind that these data objects stems from the data() method in the export default() object of App.vue. They have default values that we will set according to our requirements, and then write certain methods to populate the objects with real API data.

Don’t worry for not seeing the changes on the browser — the data is not defined yet, and it’s natural for Vue to not render things that it does not know. However, once the data is set (and for now, you can even check by hard-coding the data), the text data will be controlled by App.vue.

The `data()` Method

The data() method is a special construct in the .vue files — it contains and returns data objects that are so crucial for the application. Recollect the generic structure of the <script> part in any .vue file — it roughly contains the following:

<script> // import statements here  export default {     // name, components, props, etc.      data() {         return {             // the data that is so crucial for the application is defined here.             // the data objects will have certain default values chosen by us.             // The methods that we define below will manipulate the data.             // Since the data is bounded to various attributes and directives, they             // will update as and when the values of the data objects change.         }     },      methods: {         // methods (objects whose values are functions) here.         // bulk of dynamic stuff (the black magic part) is controlled from here.     },      computed: {         // computed properties here     },      // other objects, as necessary  } </script>

So far, you have encountered the names of some of the data objects, but are a lot more. Most of them are relevant for the child components, each of which handles a different aspect of the weather information dump. Given below is the entire data() method that we will need for this project — you will have a fair idea about what data we are expecting from the APIs, and how we are disseminating the data, based on the nomenclature of the objects.

data() {    return {      weatherDetails: false,      location: '', // raw location from input      lat: '', // raw latitude from google maps api response      long: '', // raw longitude from google maps api response      completeWeatherApi: '', // weather api string with lat and long      rawWeatherData: '', // raw response from weather api      currentWeather: {        full_location: '', // for full address        formatted_lat: '', // for N/S        formatted_long: '', // for E/W        time: '',        temp: '',        todayHighLow: {          todayTempHigh: '',          todayTempHighTime: '',          todayTempLow: '',          todayTempLowTime: ''        },        summary: '',        possibility: ''      },      tempVar: {        tempToday: [          // gets added dynamically by this.getSetHourlyTempInfoToday()        ],      },      highlights: {        uvIndex: '',        visibility: '',        windStatus: {          windSpeed: '',          windDirection: '',          derivedWindDirection: ''        },      }    };  },

As you can see, in most cases the default value is empty, because that will suffice at this point. Methods will be written for manipulating the data and filling it up with appropriate values, before it is rendered or passed on to the child components.

Methods in App.vue

For .vue files, the methods are generally written as values of keys nested in the methods { } object. Their primary role is to manipulate the data objects of the component. We will write the methods in App.vue keeping the same philosophy in mind. However, based on their purpose, we can categorize the methods of App.vue into the following:

Utility methods
Action/Event oriented methods
Data acquisition methods
Data processing methods
High level glue methods

It’s important that you understand this — we are presenting the methods to you on a platter because we have already figured out how the APIs work, what data they give, and how we should use the data in our project. It’s not that we pulled the methods out of thin air, and wrote some arcane code to deal with the data. For the purpose of learning, it’s a good exercise to diligently read and understand the code for the methods and data. However, when faced with a new project that you have to build from scratch, you must do all the dirty work yourself, and that means experimenting a lot with the APIs — their programmatic access and their data structure, before glueing them seamlessly with the data structure that your project demands. You will not have any hand holding, and there will be frustrating moments, but that’s all part of maturing as a developer.

In the following subsections, we will explain each of the method types, and also show the implementation of the methods belonging to that category. The method names are quite self-explanatory about their purpose, and so is their implementation, which we believe you will find to be easy enough to follow. However, before that, recollect the general scheme of writing methods in .vue files:

<script> // import statements here  export default {     // name, components, props, etc.      data() {         return {             // the data that is so crucial for the application is defined here.         }     },      methods: {         // methods (objects whose values are functions) here.         // bulk of dynamic stuff (the black magic part) is controlled from here.         method_1: function(arg_1) {                  },         method_2: function(arg_1, arg_2) {                  },         method_3: function(arg_1) {                  },         …….     },      computed: {         // computed properties here     },      // other objects, as necessary  } </script>

Utility Methods

The utility methods, as the name suggests, are methods written primarily for the purpose of modularizing repetitive code used for fringe tasks. They are called by other methods when necessary. Given below are the utility methods for App.vue:

convertToTitleCase: function(str) {      str = str.toLowerCase().split(' ');      for (var i = 0; i < str.length; i++) {        str[i] = str[i].charAt(0).toUpperCase() + str[i].slice(1);      }      return str.join(' ');    },

// To format the “possibility” (of weather) string obtained from the weather API formatPossibility: function(str) {      str = str.toLowerCase().split('-');      for (var i = 0; i < str.length; i++) {        str[i] = str[i].charAt(0).toUpperCase() + str[i].slice(1);      }      return str.join(' ');    },

// To convert Unix timestamps according to our convenience unixToHuman: function(timezone, timestamp) {      /* READ THIS BEFORE JUDGING & DEBUGGING      For any location beyond the arctic circle and the      antarctic circle, the goddamn weather api does not return certain      keys/values in each of this.rawWeatherData.daily.data[some_array_index].      Due to this, console throws up an error.      The code is correct, the problem is with the API.      May be later on I will add some padding to tackle missing values.      */      var moment = require('moment-timezone'); // for handling date & time      var decipher = new Date(timestamp * 1000);      var human = moment(decipher)        .tz(timezone)        .format('llll');      var timeArray = human.split(' ');      var timeNumeral = timeArray[4];      var timeSuffix = timeArray[5];      var justTime = timeNumeral + ' ' + timeSuffix;      var monthDateArray = human.split(',');      var monthDate = monthDateArray[1].trim();      return {        fullTime: human,        onlyTime: justTime,        onlyMonthDate: monthDate      };    },

// To convert temperature from fahrenheit to celcius fahToCel: function(tempInFahrenheit) {      var tempInCelcius = Math.round((5 / 9) * (tempInFahrenheit — 32));      return tempInCelcius;    },

// To convert the air pressure reading from millibar to kilopascal milibarToKiloPascal: function(pressureInMilibar) {      var pressureInKPA = pressureInMilibar * 0.1;      return Math.round(pressureInKPA);    },

// To convert distance readings from miles to kilometers mileToKilometer: function(miles) {      var kilometer = miles * 1.60934;      return Math.round(kilometer);    },

// To format the wind direction based on the angle deriveWindDir: function(windDir) {      var wind_directions_array = [        { minVal: 0, maxVal: 30, direction: 'N' },        { minVal: 31, maxVal: 45, direction: 'NNE' },        { minVal: 46, maxVal: 75, direction: 'NE' },        { minVal: 76, maxVal: 90, direction: 'ENE' },        { minVal: 91, maxVal: 120, direction: 'E' },        { minVal: 121, maxVal: 135, direction: 'ESE' },        { minVal: 136, maxVal: 165, direction: 'SE' },        { minVal: 166, maxVal: 180, direction: 'SSE' },        { minVal: 181, maxVal: 210, direction: 'S' },        { minVal: 211, maxVal: 225, direction: 'SSW' },        { minVal: 226, maxVal: 255, direction: 'SW' },        { minVal: 256, maxVal: 270, direction: 'WSW' },        { minVal: 271, maxVal: 300, direction: 'W' },        { minVal: 301, maxVal: 315, direction: 'WNW' },        { minVal: 316, maxVal: 345, direction: 'NW' },        { minVal: 346, maxVal: 360, direction: 'NNW' }      ];      var wind_direction = '';      for (var i = 0; i < wind_directions_array.length; i++) {        if (          windDir >= wind_directions_array[i].minVal &&          windDir <= wind_directions_array[i].maxVal        ) {          wind_direction = wind_directions_array[i].direction;        }      }      return wind_direction;    },

Although we haven’t implemented it, you can take out the utility methods from the .vue file, and put it in a separate JavaScript file. All you need to do is import the .js file at the start of the script part in the .vue file, and you should be good to go. Such approach works really well and keeps the code clean, especially in big applications where you might use lots of methods that are better grouped together based on their purpose. You can apply this approach to all of the method groups listed in this article, and see the effect itself. However, we suggest you do that exercise once you have followed the course presented here, so that you have the big picture understanding of all the parts working in complete sync, and also have a working piece of software which you can refer to, once something breaks while experimenting.

Action/Event Oriented Methods

These methods are generally executed when we need to take an action corresponding to an event. Depending on the case, the event might be triggered from an user interaction, or programmatically. In the App.vue file, these methods sit below the utility methods.

makeInputEmpty: function() {      this.$ refs.input.value = '';    },

makeTempVarTodayEmpty: function() {      this.tempVar.tempToday = [];    },

detectEnterKeyPress: function() {      var input = this.$ refs.input;      input.addEventListener('keyup', function(event) {        event.preventDefault();        var enterKeyCode = 13;        if (event.keyCode === enterKeyCode) {          this.setHitEnterKeyTrue();        }      });    },

locationEntered: function() {      var input = this.$ refs.input;      if (input.value === '') {        this.location = "New York";      } else {        this.location = this.convertToTitleCase(input.value);      }      this.makeInputEmpty();      this.makeTempVarTodayEmpty();    },

One interesting thing in some of the above code snippets is the use of $ ref. In simple terms, it’s Vue’s way of associating the code statement containing it, to the HTML construct it is supposed to affect (for more information, read the official guide). For example, the methods makeInputEmpty() and detectEnterKeyPress() affects the input box, because in the HTML of the input box we have mentioned the value of the attribute ref as input.

Data Acquisition Methods

We are using the following two APIs in our project:

Google Maps Geocoder API
This API is for getting the coordinates of the location that the user searches. You will need an API key for yourself, which you can get by following the documentation in the given link. For now, you can use the API key used by FusionCharts, but we request you not to abuse it and get a key of your own. We refer to the JavaScript API from the index.html of this project, and we shall use the constructors provided by it for our code in the App.vue file.
The Dark Sky Weather API
This API is for getting the weather data corresponding to the coordinates. However, we won’t be using it directly; we will wrap it within an URL that redirects through one of the FusionCharts’s server. The reason is that if you send a GET request to the API from an entirely client-end application such as ours, it results in the frustrating CORS error (more information here and here).

Important Note: Since we have used Google Maps and Dark Sky APIs, Both these APIs have their own API keys which we have shared with you in this article. This will help you focus on client-side developments rather than the headache of backend implementation. However, we recommend you to create your own keys, because our APIs keys will come with limits and if these limits exceed you won't be able to try the application by yourself.

For Google Maps, go to this article to get your API key. For Dark Sky API, visit https://darksky.net/dev to create your API key and respective endpoints.

With the context in mind, let’s see the implementation of the data acquisition methods for our project.

getCoordinates: function() {      this.locationEntered();      var loc = this.location;      var coords;      var geocoder = new google.maps.Geocoder();      return new Promise(function(resolve, reject) {        geocoder.geocode({ address: loc }, function(results, status) {          if (status == google.maps.GeocoderStatus.OK) {            this.lat = results[0].geometry.location.lat();            this.long = results[0].geometry.location.lng();            this.full_location = results[0].formatted_address;            coords = {              lat: this.lat,              long: this.long,              full_location: this.full_location            };            resolve(coords);          } else {            alert("Oops! Couldn't get data for the location");          }        });      });    },

/* The coordinates that Google Maps Geocoder API returns are way too accurate for our requirements. We need to bring it into shape before passing the coordinates on  to the weather API. Although this is a data processing method in its own right, we can’t  help mentioning it right now, because the data acquisition method for the weather API has dependency on the output of this method.  */ setFormatCoordinates: async function() {      var coordinates = await this.getCoordinates();      this.lat = coordinates.lat;      this.long = coordinates.long;      this.currentWeather.full_location = coordinates.full_location;      // Remember to beautify lat for N/S      if (coordinates.lat > 0) {        this.currentWeather.formatted_lat =          (Math.round(coordinates.lat * 10000) / 10000).toString() + '°N';      } else if (coordinates.lat < 0) {        this.currentWeather.formatted_lat =          (-1 * (Math.round(coordinates.lat * 10000) / 10000)).toString() +          '°S';      } else {        this.currentWeather.formatted_lat = (          Math.round(coordinates.lat * 10000) / 10000        ).toString();      }      // Remember to beautify long for N/S      if (coordinates.long > 0) {        this.currentWeather.formatted_long =          (Math.round(coordinates.long * 10000) / 10000).toString() + '°E';      } else if (coordinates.long < 0) {        this.currentWeather.formatted_long =          (-1 * (Math.round(coordinates.long * 10000) / 10000)).toString() +          '°W';      } else {        this.currentWeather.formatted_long = (          Math.round(coordinates.long * 10000) / 10000        ).toString();      }    },

/* This method dynamically creates the the correct weather API query URL, based on the  formatted latitude and longitude. The complete URL is then fed to the method querying for  weather data. Notice that the base URL used in this method (without the coordinates) points towards a  FusionCharts server — we must redirect our GET request to the weather API through a server to avoid the CORS error. */ fixWeatherApi: async function() {      await this.setFormatCoordinates();      var weatherApi =        'https://csm.fusioncharts.com/files/assets/wb/wb-data.php?src=darksky&lat=' +        this.lat +        '&long=' +        this.long;      this.completeWeatherApi = weatherApi;    },

fetchWeatherData: async function() {      await this.fixWeatherApi();      var axios = require('axios'); // for handling weather api promise      var weatherApiResponse = await axios.get(this.completeWeatherApi);      if (weatherApiResponse.status === 200) {        this.rawWeatherData = weatherApiResponse.data;      } else {        alert('Hmm... Seems like our weather experts are busy!');      }    },

Through these methods, we have introduced the concept of async-await in our code. If you have been a JavaScript developer for some time now, you must be familiar with the callback hell, which is a direct consequence of the asynchronous way JavaScript is written. ES6 allows us to bypass the cumbersome nested callbacks, and our code becomes much cleaner if we write JavaScript in a synchronous way, using the async-await technique. However, there is a downside. It takes away the speed that asynchronous code gives us, especially for the portions of the code that deals with data being exchanged over the internet. Since this is not a mission-critical application with low latency requirements, and our primary aim is to learn stuff, the clean code is much more preferable over the slightly fast code.

Data Processing Methods

Now that we have the methods that will bring the data to us, we need to prepare the ground for properly receiving and processing the data. Safety nets must be cast, and there should be no spills — data is the new gold (OK, that might be an exaggeration in our context)! Enough with the fuss, let’s get to the point.

Technically, the methods we implement in this section are aimed at getting the data out of the acquisition methods and the data objects in App.vue, and sometimes setting the data objects to certain values that suits the purpose.

getTimezone: function() {      return this.rawWeatherData.timezone;    },

getSetCurrentTime: function() {      var currentTime = this.rawWeatherData.currently.time;      var timezone = this.getTimezone();      this.currentWeather.time = this.unixToHuman(        timezone,        currentTime      ).fullTime;    },

getSetSummary: function() {      var currentSummary = this.convertToTitleCase(        this.rawWeatherData.currently.summary      );      if (currentSummary.includes(' And')) {        currentSummary = currentSummary.replace(' And', ',');      }      this.currentWeather.summary = currentSummary;    },

getSetPossibility: function() {      var possible = this.formatPossibility(this.rawWeatherData.daily.icon);      if (possible.includes(' And')) {        possible = possible.replace(' And', ',');      }      this.currentWeather.possibility = possible;    },

getSetCurrentTemp: function() {      var currentTemp = this.rawWeatherData.currently.temperature;      this.currentWeather.temp = this.fahToCel(currentTemp);    },

getTodayDetails: function() {      return this.rawWeatherData.daily.data[0];    },

getSetTodayTempHighLowWithTime: function() {      var timezone = this.getTimezone();      var todayDetails = this.getTodayDetails();      this.currentWeather.todayHighLow.todayTempHigh = this.fahToCel(        todayDetails.temperatureMax      );      this.currentWeather.todayHighLow.todayTempHighTime = this.unixToHuman(        timezone,        todayDetails.temperatureMaxTime      ).onlyTime;      this.currentWeather.todayHighLow.todayTempLow = this.fahToCel(        todayDetails.temperatureMin      );      this.currentWeather.todayHighLow.todayTempLowTime = this.unixToHuman(        timezone,        todayDetails.temperatureMinTime      ).onlyTime;    },

getHourlyInfoToday: function() {      return this.rawWeatherData.hourly.data;    },

getSetHourlyTempInfoToday: function() {      var unixTime = this.rawWeatherData.currently.time;      var timezone = this.getTimezone();      var todayMonthDate = this.unixToHuman(timezone, unixTime).onlyMonthDate;      var hourlyData = this.getHourlyInfoToday();      for (var i = 0; i < hourlyData.length; i++) {        var hourlyTimeAllTypes = this.unixToHuman(timezone, hourlyData[i].time);        var hourlyOnlyTime = hourlyTimeAllTypes.onlyTime;        var hourlyMonthDate = hourlyTimeAllTypes.onlyMonthDate;        if (todayMonthDate === hourlyMonthDate) {          var hourlyObject = { hour: '', temp: '' };          hourlyObject.hour = hourlyOnlyTime;          hourlyObject.temp = this.fahToCel(hourlyData[i].temperature).toString();          this.tempVar.tempToday.push(hourlyObject);          /*          Since we are using array.push(), we are just adding elements          at the end of the array. Thus, the array is not getting emptied          first when a new location is entered.          to solve this problem, a method this.makeTempVarTodayEmpty()          has been created, and called from this.locationEntered().          */        }      }      /*      To cover the edge case where the local time is between 10 — 12 PM,      and therefore there are only two elements in the array      this.tempVar.tempToday. We need to add the points for minimum temperature      and maximum temperature so that the chart gets generated with atleast four points.      */      if (this.tempVar.tempToday.length <= 2) {        var minTempObject = {          hour: this.currentWeather.todayHighLow.todayTempHighTime,          temp: this.currentWeather.todayHighLow.todayTempHigh        };        var maxTempObject = {          hour: this.currentWeather.todayHighLow.todayTempLowTime,          temp: this.currentWeather.todayHighLow.todayTempLow        };        /*        Typically, lowest temp are at dawn,        highest temp is around mid day.        Thus we can safely arrange like min, max, temp after 10 PM.        */        // array.unshift() adds stuff at the beginning of the array.        // the order will be: min, max, 10 PM, 11 PM.        this.tempVar.tempToday.unshift(maxTempObject, minTempObject);      }    },

getSetUVIndex: function() {      var uvIndex = this.rawWeatherData.currently.uvIndex;      this.highlights.uvIndex = uvIndex;    },

getSetVisibility: function() {      var visibilityInMiles = this.rawWeatherData.currently.visibility;      this.highlights.visibility = this.mileToKilometer(visibilityInMiles);    },

getSetWindStatus: function() {      var windSpeedInMiles = this.rawWeatherData.currently.windSpeed;      this.highlights.windStatus.windSpeed = this.mileToKilometer(        windSpeedInMiles      );      var absoluteWindDir = this.rawWeatherData.currently.windBearing;      this.highlights.windStatus.windDirection = absoluteWindDir;      this.highlights.windStatus.derivedWindDirection = this.deriveWindDir(        absoluteWindDir      );    },

High Level Glue Methods

With the utility, acquisition, and processing methods out of our way, we are now left with the task of orchestrating the entire thing. We do that by creating high level glue methods, that essentially calls the methods written above in a particular sequence, so that the entire operation is executed seamlessly.

// Top level for info section // Data in this.currentWeather organizeCurrentWeatherInfo: function() {      // data in this.currentWeather      /*      Coordinates and location is covered (get & set) in:      — this.getCoordinates()      — this.setFormatCoordinates()      There are lots of async-await involved there.      So it's better to keep them there.      */      this.getSetCurrentTime();      this.getSetCurrentTemp();      this.getSetTodayTempHighLowWithTime();      this.getSetSummary();      this.getSetPossibility();    },

// Top level for highlights organizeTodayHighlights: function() {      // top level for highlights      this.getSetUVIndex();      this.getSetVisibility();      this.getSetWindStatus();    },

// Top level organization and rendering organizeAllDetails: async function() {      // top level organization      await this.fetchWeatherData();      this.organizeCurrentWeatherInfo();      this.organizeTodayHighlights();      this.getSetHourlyTempInfoToday();    },

mounted

Vue provides instance lifecycle hooks — properties that are essentially methods, and gets triggered when the instance lifecycle reaches that stage. For example, created, mounted, beforeUpdate, etc., are all very useful lifecycle hooks that allows the programmer to control the instance at a much more granular level than that would have been possible otherwise.

In the code of a Vue component, these lifecycle hooks are implemented just like you would for any other prop. For example:

<template> </template>  <script> // import statements export default {   data() {     return {     // data objects here     }   },   methods: {   // methods here   },   mounted: function(){   // function body here   }, } </script>  <style> </style>

Armed with this new understanding, take a look at the code below for the mounted prop of App.vue:

mounted: async function() {    this.location = "New York";    await this.organizeAllDetails();      }

Complete Code For App.vue

We have covered a lot of ground in this section, and the last few sections have given you things in bits and pieces. However, it’s important that you have the complete, assembled code for App.vue (subject to further modifications in subsequent sections). Here it goes:

<template>  <div id="ancestor">    <div class="container-fluid" id="app">      <div class="row">        <div id="sidebar" class="col-md-3 col-sm-4 col-xs-12 sidebar">          <div id="search">            <input              id="location-input"              type="text"              ref="input"              placeholder="Location?"              @keyup.enter="organizeAllDetails"            >            <button id="search-btn" @click="organizeAllDetails">              <img src="./assets/Search.svg" width="24" height="24">            </button>          </div>          <div id="info">            <div class="wrapper-left">              <div id="current-weather">                {{ currentWeather.temp }}                <span>°C</span>              </div>              <div id="weather-desc">{{ currentWeather.summary }}</div>              <div class="temp-max-min">                <div class="max-desc">                  <div id="max-detail">                    <i>▲</i>                    {{ currentWeather.todayHighLow.todayTempHigh }}                    <span>°C</span>                  </div>                  <div id="max-summary">at {{ currentWeather.todayHighLow.todayTempHighTime }}</div>                </div>                <div class="min-desc">                  <div id="min-detail">                    <i>▼</i>                    {{ currentWeather.todayHighLow.todayTempLow }}                    <span>°C</span>                  </div>                  <div id="min-summary">at {{ currentWeather.todayHighLow.todayTempLowTime }}</div>                </div>              </div>            </div>            <div class="wrapper-right">              <div class="date-time-info">                <div id="date-desc">                  <img src="./assets/calendar.svg" width="20" height="20">                  {{ currentWeather.time }}                </div>              </div>              <div class="location-info">                <div id="location-desc">                  <img                    src="./assets/location.svg"                    width="10.83"                    height="15.83"                    style="opacity: 0.9;"                  >                  {{ currentWeather.full_location }}                  <div id="location-detail" class="mt-1">                    Lat: {{ currentWeather.formatted_lat }}                    <br>                    Long: {{ currentWeather.formatted_long }}                  </div>                </div>              </div>            </div>          </div>        </div>        <dashboard-content          class="col-md-9 col-sm-8 col-xs-12 content"          id="dashboard-content"          :highlights="highlights"          :tempVar="tempVar"        ></dashboard-content>      </div>    </div>  </div> </template>  <script> import Content from './components/Content.vue';  export default {  name: 'app',  props: [],  components: {    'dashboard-content': Content  },  data() {    return {      weatherDetails: false,      location: '', // raw location from input      lat: '', // raw latitude from google maps api response      long: '', // raw longitude from google maps api response      completeWeatherApi: '', // weather api string with lat and long      rawWeatherData: '', // raw response from weather api      currentWeather: {        full_location: '', // for full address        formatted_lat: '', // for N/S        formatted_long: '', // for E/W        time: '',        temp: '',        todayHighLow: {          todayTempHigh: '',          todayTempHighTime: '',          todayTempLow: '',          todayTempLowTime: ''        },        summary: '',        possibility: ''      },      tempVar: {        tempToday: [          // gets added dynamically by this.getSetHourlyTempInfoToday()        ],      },      highlights: {        uvIndex: '',        visibility: '',        windStatus: {          windSpeed: '',          windDirection: '',          derivedWindDirection: ''        },      }    };  },  methods: {    // Some utility functions    convertToTitleCase: function(str) {      str = str.toLowerCase().split(' ');      for (var i = 0; i < str.length; i++) {        str[i] = str[i].charAt(0).toUpperCase() + str[i].slice(1);      }      return str.join(' ');    },    formatPossibility: function(str) {      str = str.toLowerCase().split('-');      for (var i = 0; i < str.length; i++) {        str[i] = str[i].charAt(0).toUpperCase() + str[i].slice(1);      }      return str.join(' ');    },    unixToHuman: function(timezone, timestamp) {      /* READ THIS BEFORE JUDGING & DEBUGGING      For any location beyond the arctic circle and the      antarctic circle, the goddamn weather api does not return certain      keys/values in each of this.rawWeatherData.daily.data[some_array_index].      Due to this, console throws up an error.      The code is correct, the problem is with the API.      May be later on I will add some padding to tackle missing values.      */      var moment = require('moment-timezone'); // for handling date & time      var decipher = new Date(timestamp * 1000);      var human = moment(decipher)        .tz(timezone)        .format('llll');      var timeArray = human.split(' ');      var timeNumeral = timeArray[4];      var timeSuffix = timeArray[5];      var justTime = timeNumeral + ' ' + timeSuffix;      var monthDateArray = human.split(',');      var monthDate = monthDateArray[1].trim();      return {        fullTime: human,        onlyTime: justTime,        onlyMonthDate: monthDate      };    },    fahToCel: function(tempInFahrenheit) {      var tempInCelcius = Math.round((5 / 9) * (tempInFahrenheit — 32));      return tempInCelcius;    },    milibarToKiloPascal: function(pressureInMilibar) {      var pressureInKPA = pressureInMilibar * 0.1;      return Math.round(pressureInKPA);    },    mileToKilometer: function(miles) {      var kilometer = miles * 1.60934;      return Math.round(kilometer);    },    deriveWindDir: function(windDir) {      var wind_directions_array = [        { minVal: 0, maxVal: 30, direction: 'N' },        { minVal: 31, maxVal: 45, direction: 'NNE' },        { minVal: 46, maxVal: 75, direction: 'NE' },        { minVal: 76, maxVal: 90, direction: 'ENE' },        { minVal: 91, maxVal: 120, direction: 'E' },        { minVal: 121, maxVal: 135, direction: 'ESE' },        { minVal: 136, maxVal: 165, direction: 'SE' },        { minVal: 166, maxVal: 180, direction: 'SSE' },        { minVal: 181, maxVal: 210, direction: 'S' },        { minVal: 211, maxVal: 225, direction: 'SSW' },        { minVal: 226, maxVal: 255, direction: 'SW' },        { minVal: 256, maxVal: 270, direction: 'WSW' },        { minVal: 271, maxVal: 300, direction: 'W' },        { minVal: 301, maxVal: 315, direction: 'WNW' },        { minVal: 316, maxVal: 345, direction: 'NW' },        { minVal: 346, maxVal: 360, direction: 'NNW' }      ];      var wind_direction = '';      for (var i = 0; i < wind_directions_array.length; i++) {        if (          windDir >= wind_directions_array[i].minVal &&          windDir <= wind_directions_array[i].maxVal        ) {          wind_direction = wind_directions_array[i].direction;        }      }      return wind_direction;    },     // Some basic action oriented functions    makeInputEmpty: function() {      this.$ refs.input.value = '';    },    makeTempVarTodayEmpty: function() {      this.tempVar.tempToday = [];    },    detectEnterKeyPress: function() {      var input = this.$ refs.input;      input.addEventListener('keyup', function(event) {        event.preventDefault();        var enterKeyCode = 13;        if (event.keyCode === enterKeyCode) {          this.setHitEnterKeyTrue();        }      });    },    locationEntered: function() {      var input = this.$ refs.input;      if (input.value === '') {        this.location = "New York";      } else {        this.location = this.convertToTitleCase(input.value);      }      this.makeInputEmpty();      this.makeTempVarTodayEmpty();    },       getCoordinates: function() {      this.locationEntered();      var loc = this.location;      var coords;      var geocoder = new google.maps.Geocoder();      return new Promise(function(resolve, reject) {        geocoder.geocode({ address: loc }, function(results, status) {          if (status == google.maps.GeocoderStatus.OK) {            this.lat = results[0].geometry.location.lat();            this.long = results[0].geometry.location.lng();            this.full_location = results[0].formatted_address;            coords = {              lat: this.lat,              long: this.long,              full_location: this.full_location            };            resolve(coords);          } else {            alert("Oops! Couldn't get data for the location");          }        });      });    },     // Some basic asynchronous functions    setFormatCoordinates: async function() {      var coordinates = await this.getCoordinates();      this.lat = coordinates.lat;      this.long = coordinates.long;      this.currentWeather.full_location = coordinates.full_location;      // Remember to beautify lat for N/S      if (coordinates.lat > 0) {        this.currentWeather.formatted_lat =          (Math.round(coordinates.lat * 10000) / 10000).toString() + '°N';      } else if (coordinates.lat < 0) {        this.currentWeather.formatted_lat =          (-1 * (Math.round(coordinates.lat * 10000) / 10000)).toString() +          '°S';      } else {        this.currentWeather.formatted_lat = (          Math.round(coordinates.lat * 10000) / 10000        ).toString();      }      // Remember to beautify long for N/S      if (coordinates.long > 0) {        this.currentWeather.formatted_long =          (Math.round(coordinates.long * 10000) / 10000).toString() + '°E';      } else if (coordinates.long < 0) {        this.currentWeather.formatted_long =          (-1 * (Math.round(coordinates.long * 10000) / 10000)).toString() +          '°W';      } else {        this.currentWeather.formatted_long = (          Math.round(coordinates.long * 10000) / 10000        ).toString();      }    },    fixWeatherApi: async function() {      await this.setFormatCoordinates();      var weatherApi =        'https://csm.fusioncharts.com/files/assets/wb/wb-data.php?src=darksky&lat=' +        this.lat +        '&long=' +        this.long;      this.completeWeatherApi = weatherApi;    },    fetchWeatherData: async function() {      await this.fixWeatherApi();      var axios = require('axios'); // for handling weather api promise      var weatherApiResponse = await axios.get(this.completeWeatherApi);      if (weatherApiResponse.status === 200) {        this.rawWeatherData = weatherApiResponse.data;      } else {        alert('Hmm... Seems like our weather experts are busy!');      }    },     // Get and set functions; often combined, because they are short     // For basic info — left panel/sidebar    getTimezone: function() {      return this.rawWeatherData.timezone;    },    getSetCurrentTime: function() {      var currentTime = this.rawWeatherData.currently.time;      var timezone = this.getTimezone();      this.currentWeather.time = this.unixToHuman(        timezone,        currentTime      ).fullTime;    },    getSetSummary: function() {      var currentSummary = this.convertToTitleCase(        this.rawWeatherData.currently.summary      );      if (currentSummary.includes(' And')) {        currentSummary = currentSummary.replace(' And', ',');      }      this.currentWeather.summary = currentSummary;    },    getSetPossibility: function() {      var possible = this.formatPossibility(this.rawWeatherData.daily.icon);      if (possible.includes(' And')) {        possible = possible.replace(' And', ',');      }      this.currentWeather.possibility = possible;    },    getSetCurrentTemp: function() {      var currentTemp = this.rawWeatherData.currently.temperature;      this.currentWeather.temp = this.fahToCel(currentTemp);    },    getTodayDetails: function() {      return this.rawWeatherData.daily.data[0];    },    getSetTodayTempHighLowWithTime: function() {      var timezone = this.getTimezone();      var todayDetails = this.getTodayDetails();      this.currentWeather.todayHighLow.todayTempHigh = this.fahToCel(        todayDetails.temperatureMax      );      this.currentWeather.todayHighLow.todayTempHighTime = this.unixToHuman(        timezone,        todayDetails.temperatureMaxTime      ).onlyTime;      this.currentWeather.todayHighLow.todayTempLow = this.fahToCel(        todayDetails.temperatureMin      );      this.currentWeather.todayHighLow.todayTempLowTime = this.unixToHuman(        timezone,        todayDetails.temperatureMinTime      ).onlyTime;    },    getHourlyInfoToday: function() {      return this.rawWeatherData.hourly.data;    },    getSetHourlyTempInfoToday: function() {      var unixTime = this.rawWeatherData.currently.time;      var timezone = this.getTimezone();      var todayMonthDate = this.unixToHuman(timezone, unixTime).onlyMonthDate;      var hourlyData = this.getHourlyInfoToday();      for (var i = 0; i < hourlyData.length; i++) {        var hourlyTimeAllTypes = this.unixToHuman(timezone, hourlyData[i].time);        var hourlyOnlyTime = hourlyTimeAllTypes.onlyTime;        var hourlyMonthDate = hourlyTimeAllTypes.onlyMonthDate;        if (todayMonthDate === hourlyMonthDate) {          var hourlyObject = { hour: '', temp: '' };          hourlyObject.hour = hourlyOnlyTime;          hourlyObject.temp = this.fahToCel(hourlyData[i].temperature).toString();          this.tempVar.tempToday.push(hourlyObject);          /*          Since we are using array.push(), we are just adding elements          at the end of the array. Thus, the array is not getting emptied          first when a new location is entered.          to solve this problem, a method this.makeTempVarTodayEmpty()          has been created, and called from this.locationEntered().          */        }      }      /*      To cover the edge case where the local time is between 10 — 12 PM,      and therefore there are only two elements in the array      this.tempVar.tempToday. We need to add the points for minimum temperature      and maximum temperature so that the chart gets generated with atleast four points.      */      if (this.tempVar.tempToday.length <= 2) {        var minTempObject = {          hour: this.currentWeather.todayHighLow.todayTempHighTime,          temp: this.currentWeather.todayHighLow.todayTempHigh        };        var maxTempObject = {          hour: this.currentWeather.todayHighLow.todayTempLowTime,          temp: this.currentWeather.todayHighLow.todayTempLow        };        /*        Typically, lowest temp are at dawn,        highest temp is around mid day.        Thus we can safely arrange like min, max, temp after 10 PM.        */        // array.unshift() adds stuff at the beginning of the array.        // the order will be: min, max, 10 PM, 11 PM.        this.tempVar.tempToday.unshift(maxTempObject, minTempObject);      }    },     // For Today Highlights    getSetUVIndex: function() {      var uvIndex = this.rawWeatherData.currently.uvIndex;      this.highlights.uvIndex = uvIndex;    },    getSetVisibility: function() {      var visibilityInMiles = this.rawWeatherData.currently.visibility;      this.highlights.visibility = this.mileToKilometer(visibilityInMiles);    },    getSetWindStatus: function() {      var windSpeedInMiles = this.rawWeatherData.currently.windSpeed;      this.highlights.windStatus.windSpeed = this.mileToKilometer(        windSpeedInMiles      );      var absoluteWindDir = this.rawWeatherData.currently.windBearing;      this.highlights.windStatus.windDirection = absoluteWindDir;      this.highlights.windStatus.derivedWindDirection = this.deriveWindDir(        absoluteWindDir      );    },     // top level for info section    organizeCurrentWeatherInfo: function() {      // data in this.currentWeather      /*      Coordinates and location is covered (get & set) in:      — this.getCoordinates()      — this.setFormatCoordinates()      There are lots of async-await involved there.      So it's better to keep them there.      */      this.getSetCurrentTime();      this.getSetCurrentTemp();      this.getSetTodayTempHighLowWithTime();      this.getSetSummary();      this.getSetPossibility();    },    organizeTodayHighlights: function() {      // top level for highlights      this.getSetUVIndex();      this.getSetVisibility();      this.getSetWindStatus();    },     // topmost level orchestration    organizeAllDetails: async function() {      // top level organization      await this.fetchWeatherData();      this.organizeCurrentWeatherInfo();      this.organizeTodayHighlights();      this.getSetHourlyTempInfoToday();    },  },  mounted: async function() {    this.location = "New York";    await this.organizeAllDetails();      } }; </script>

And finally, after so much of patience and hard work, you can see the data flow with its raw power! Visit the application on the browser, refresh the page, search for a location in the application’s search box, and hit Enter!

The application as shown in the browser — (Large preview)

Now that we are done with all the heavy lifting, take a break. The subsequent sections focus on using the data to create charts that are beautiful and informative, followed by giving our ugly looking application a much deserved grooming session using CSS.

5. Data Visualization With FusionCharts

Fundamental Considerations For Charts

For the end user, the essence of a dashboard is essentially this: a collection of the filtered and carefully curated information on a particular topic, conveyed through visual/graphic instruments for quick ingestion. They don’t care about the subtleties of your data pipeline engineering, or how aesthetic your code is — all they want is a high-level view in 3 seconds. Therefore, our crude application displaying text data means nothing to them, and it’s high time we implement mechanisms to wrap the data with charts.

However, before we dive deep into the implementation of charts, let’s consider some pertinent questions and the possible answers from our perspective:

What type of charts are appropriate for the type of data we are dealing with?
Well, the answer has two aspects — the context, and the purpose. By context, we mean the type of data, and it’s overall fit in the scheme of bigger things, bounded by the scope and audience of the project. And by purpose, we essentially mean “what we want to emphasize on?”. For example, we can represent today’s temperature at different times of the day by using a Column chart (vertical columns of equal width, with height proportional to the value the column represents). However, we are rarely interested in the individual values, but rather the overall variation and trend throughout the data. To suit the purpose, it is in our best interest to use a Line chart, and we will do that shortly.
What should be kept in mind before selecting a charting library?
Since we are doing a project predominantly using JavaScript based technologies, it’s a no-brainer that any charting library that we choose for our project should be a native of the JavaScript world. With that basic premise in mind, we should consider the following before zeroing down on any particular library:
- Support for the frameworks of our choice, which in this case, is Vue.js. A project can be developed in other popular JavaScript frameworks like React, or Angular — check the support of the charting library for your favorite framework. Also, support for other popular programming languages like Python, Java, C++, .Net (AS and VB), especially when the project involves some serious backend stuff, must be considered.
- Availability of charts types and features, since it is almost impossible to know beforehand what will be final shape and purpose of the data in the project (especially if the requirements are regulated by your clients in a professional setting). In this case, you should cast your net wide, and choose a charting library that has the widest collection of charts. More importantly, to differentiate your project from others, the library should have have enough features in the form of configurable chart attributes, so that you can fine-tune and customize most aspects of the charts and the right level of granularity. Also, the default chart configurations should be sensible, and the library documentation has to be top notch, for reasons that’s obvious to professional developers.
- Learning curve, support community, and balance must also be taken into consideration, especially when you are new to data visualization. On one end of the spectrum, you have proprietary tools like Tableau and Qlickview that costs a bomb, has smooth learning curve, but also comes with so many limitations in terms of customizability, integration, and deployment. On the other end there is d3.js — vast, free (open source), and customizable to its core, but you have to pay the price of a very steep learning curve to be able to do anything productive with the library.

What you need is the sweet spot — the right balance between productivity, coverage, customizability, learning curve, and off course, cost. We nudge you to take a look at FusionCharts — the world’s most comprehensive and enterprise-ready JavaScript charting library for the web and mobile, that we will be using in this project for creating charts.

Introduction To FusionCharts

FusionCharts is used worldwide as the go-to JavaScript charting library by millions of developers spread across hundreds of countries around the globe. Technically, it’s as loaded and configurable as it can be, with support for integrating it with almost any popular tech stack used for web based projects. Using FusionCharts commercially requires a license, and you have to pay for the license depending on your use case (please contact sales if you are curious). However, we are using FusionCharts in this projects just to try out a few things, and therefore the non-licensed version (comes with a small watermark in your charts, and a few other restrictions). Using the non-licensed version is perfectly fine when you are trying out the charts and using it in your non-commercial or personal projects. If you have plans to deploy the application commercially, please ensure that you have a license from FusionCharts.

Since this is a project involving Vue.js, we will need two modules that needs to be installed, if not done earlier:

The fusioncharts module, because it contains everything you will need for creating the charts
The vue-fusioncharts module, which is essentially a wrapper for fusioncharts, so that it can be used in a Vue.js project

If you have not installed them earlier (as instructed in the third section), install them by executing the following command from the project’s root directory:

npm install fusioncharts vue-fusioncharts --save

Next, ensure that the src/main.js file of the project has the following code (also mentioned in section 3):

import Vue from 'vue'; import App from './App.vue'; import FusionCharts from 'fusioncharts'; import Charts from 'fusioncharts/fusioncharts.charts'; import Widgets from 'fusioncharts/fusioncharts.widgets'; import PowerCharts from 'fusioncharts/fusioncharts.powercharts'; import FusionTheme from 'fusioncharts/themes/fusioncharts.theme.fusion'; import VueFusionCharts from 'vue-fusioncharts';  Charts(FusionCharts); PowerCharts(FusionCharts); Widgets(FusionCharts); FusionTheme(FusionCharts);  Vue.use(VueFusionCharts, FusionCharts);  new Vue({  el: '#app',  render: h => h(App) })

Perhaps the most critical line in the above snippet is the following:

Vue.use(VueFusionCharts, FusionCharts)

It instructs Vue to use the vue-fusioncharts module for making sense of many things in the project that are apparently not explicitly defined by us, but is defined in the module itself. Also, this type of statement implies global declaration, by which we mean that anywhere Vue encounters anything strange in the code of our project (things that we have not explicitly defined about using FusionCharts), it will at least look once in the vue-fusioncharts and fusioncharts node modules for their definitions, before throwing up errors. If we would have used FusionCharts in an isolated part of our project (not using it in almost all of the component files), then perhaps local declaration would have made more sense.

With that, you are all set to use FusionCharts in the project. We will be using quite a few variety of charts, the choice being dependent on the aspect of the weather data that we want to visualize. Also, we will get to see the interplay of data binding, custom components, and watchers in action.

General Scheme For Using Fusioncharts In `.vue` Files

In this section, we will explain the general idea of using FusionCharts for creating various charts in the .vue files. But first, let’s see the pseudocode that schematically illustrates the core idea.

<template>   <div>     <fusioncharts       :attribute_1="data_object_1"       :attribute_2="data_object_2"          …          …          ...     >     </fusioncharts>   </div> </template>  <script> export default {   props: ["data_prop_received_by_the_component"],   components: {},   data() {     return {       data_object_1: "value_1",       data_object_2: "value_2",           …           …     };   },   methods: {},   computed: {},   watch: {     data_prop_received_by_the_component: {       handler: function() {         // some code/logic, mainly data manipulation based       },       deep: true     }   } }; </script>  <style>   // component specific special CSS code here </style>

Let’s understand different parts of the above pseudocode:

In the <template>, within the top level <div> (that’s pretty much mandatory for the template HTML code of every component), we have the custom component <fusioncharts>. We have the definition of the component contained in the vue-fusioncharts Node module that we have installed for this project. Internally, vue-fusioncharts relies on the fusioncharts module, which have also been installed. We imported the necessary modules and resolved their dependencies, instructed Vue to use the wrapper globally (throughout the project) in the src/main.js file, and therefore there is no lack of definition for the custom <fusioncharts> component that we have used here. Also, the custom component has custom attributes, and each of the custom attribute is bound to a data object (and in turn, their values), by the v-bind directive, for which the shorthand is the colon (:) symbol. We will learn about the attributes and their associated data objects in a greater detail, when we discuss some of the specific charts used in this project.
In the <script>, first you declare the props that the component is supposed to receive, and then go on defining the data objects that are bounded to the attributes of <fusioncharts>. The values assigned to the data objects are the values that the attributes of <fusioncharts> pulls in, and the charts are created on the basis of those pulled in values. Apart from these, the most interesting part of the code is the watch { } object. This is a very special object in Vue’s scheme of things — it essentially instructs Vue to watch over any changes happening to certain data, and then take actions based on how the handler function for that data has been defined. For example, we want Vue to keep a watch on the prop received, i.e., data_prop_received_by_the_component in the pseudocode. The prop becomes a key in the watch { } object, and the value of the key is another object — a handler method that describes what needs to be done whenever the prop changes. With such elegant mechanisms to handle the changes, the app maintains its reactivity. The deep: true represents a boolean flag that you can associate with watchers, so that the object being watched is watched rather deeply, i.e., even the changes made in the nested levels of the object are tracked.
(For more information on watchers, consult the official documentation).

Now that you are equipped with an understanding of the general scheme of things, let’s dive into the specific implementations of the charts in the .vue component files. The code will be pretty self-explanatory, and you should try to understand how the specifics fit in the general scheme of things described above.

Implementation Of Charts In .vue Files

While the very specifics of the implementation varies from one chart to another, the following explanation is applicable for all of them:

<template>
As explained previously, the <fusioncharts> custom component has several attributes, each of them being bound to corresponding data object defined in the data() function by using the v-bind: directive. The attribute names are quite self-explanatory for what they mean, and figuring out the corresponding data objects is also trivial.
<script>
In the data() function, the data objects and their values are what makes the charts work, because of the binding done by the v-bind (:) directives used on the attributes of <fusioncharts>. Before we dive deep into the individual data objects, it’s worth mentioning some general characteristics:
- The data objects whose values are either 0 or 1 are boolean in nature, where 0 represents something not available/turned off, and 1 represents availability/turned on state. However, be cautious that non-boolean data objects can also have 0 or 1 as their values, besides other possible values — it depends on the context. For example, containerbackgroundopacity with its default value as 0 is boolean, whereas lowerLimit with its default value as 0 simply means the number zero is its literal value.
- Some data objects deals with CSS properties like margin, padding, font-size, etc. — the value has an implied unit of “px” or pixel. Similarly, other data objects can have implicit units associated with their values. For detailed information, please refer to the respective chart attributes page of FusionCharts Dev Center.
In the data() function, perhaps the most interesting and non-obvious object is the dataSource. This object has three main objects nested within it:
- chart: This object encapsulates lots of chart attributes related to the configuration and cosmetics of the chart. It is almost a compulsory construct that you will find in all the charts you will create for this project.
- colorrange: This object is somewhat specific to the chart under consideration, and is mainly present in charts that deals with multiple colors/shades to demarcate different sub-ranges of the scale used in chart.
- value: This object, again, is present in charts that has a specific value that needs to be highlighted in the range of the scale.
The watch { } object is perhaps the most crucial thing that makes this chart, and the other charts used in this project, spring to life. The reactivity of the charts, i.e., the charts updating themselves based on the new values resulting from a new user query is controlled by the watchers defined in this object. For example, we have defined a watcher for the prop highlights received by the component, and then defined a handler function to instruct Vue about the necessary actions that it should take, when anything changes about the object being watched in the entire project. This means that whenever App.vue yields a new value for any of the object within highlights, the information trickles down all the way down to this component, and the new value is updated in the data objects of this component. The chart being bound to the values, also gets updated as a result of this mechanism.

The above explanations are quite broad strokes to help us develop an intuitive understanding of the bigger picture. Once you understand the concepts intuitively, you can always consult the documentation of Vue.js and FusionCharts, when something is not clear to you from the code itself. We leave the exercise to you, and from the next subsection onward, we will not explain stuff that we covered in this subsection.

src/components/TempVarChart.vue

A diagram showing Hourly Temperature — (Large preview)

<template>  <div class="custom-card header-card card">    <div class="card-body pt-0">      <fusioncharts        type="spline"        width="100%"        height="100%"        dataformat="json"       dataEmptyMessage="i-https://i.postimg.cc/R0QCk9vV/Rolling-0-9s-99px.gif"        dataEmptyMessageImageScale=39        :datasource="tempChartData"      >      </fusioncharts>    </div>     </div> </template>  <script> export default {  props: ["tempVar"],  components: {},  data() {    return {      tempChartData: {        chart: {          caption: "Hourly Temperature",          captionFontBold: "0",          captionFontColor: "#000000",          captionPadding: "30",          baseFont: "Roboto",          chartTopMargin: "30",          showHoverEffect: "1",          theme: "fusion",          showaxislines: "1",          numberSuffix: "°C",          anchorBgColor: "#6297d9",          paletteColors: "#6297d9",          drawCrossLine: "1",          plotToolText: "$ label<br><hr><b>$ dataValue</b>",          showAxisLines: "0",          showYAxisValues: "0",          anchorRadius: "4",          divLineAlpha: "0",          labelFontSize: "13",          labelAlpha: "65",          labelFontBold: "0",          rotateLabels: "1",          slantLabels: "1",          canvasPadding: "20"        },        data: [],      },    };  },  methods: {    setChartData: function() {      var data = [];      for (var i = 0; i < this.tempVar.tempToday.length; i++) {        var dataObject = {          label: this.tempVar.tempToday[i].hour,          value: this.tempVar.tempToday[i].temp        };        data.push(dataObject);      }      this.tempChartData.data = data;    },  },  mounted: function() {    this.setChartData();  },  watch: {    tempVar: {      handler: function() {        this.setChartData();                                         },      deep: true    },  }, }; </script>  <style> </style>

src/components/UVIndex.vue

This component contains an extremely useful chart — the Angular Gauge.

The code for the component is given below. For detailed information on the chart attributes of Angular Gauge, refer to FusionCharts Dev Center page for Angular Gauge.

<template>  <div class="highlights-item col-md-4 col-sm-6 col-xs-12 border-top">    <div>      <fusioncharts        :type="type"        :width="width"        :height="height"        :containerbackgroundopacity="containerbackgroundopacity"        :dataformat="dataformat"        :datasource="datasource"      ></fusioncharts>    </div>  </div> </template>  <script> export default {  props: ["highlights"],  components: {},  data() {    return {      type: "angulargauge",      width: "100%",      height: "100%",      containerbackgroundopacity: 0,      dataformat: "json",      datasource: {        chart: {          caption: "UV Index",          captionFontBold: "0",          captionFontColor: "#000000",          captionPadding: "30",          lowerLimit: "0",          upperLimit: "15",          lowerLimitDisplay: "1",          upperLimitDisplay: "1",          showValue: "0",          theme: "fusion",          baseFont: "Roboto",          bgAlpha: "0",          canvasbgAlpha: "0",          gaugeInnerRadius: "75",          gaugeOuterRadius: "110",          pivotRadius: "0",          pivotFillAlpha: "0",          valueFontSize: "20",          valueFontColor: "#000000",          valueFontBold: "1",          tickValueDistance: "3",          autoAlignTickValues: "1",          majorTMAlpha: "20",          chartTopMargin: "30",          chartBottomMargin: "40"        },        colorrange: {          color: [            {              minvalue: "0",              maxvalue: this.highlights.uvIndex.toString(),              code: "#7DA9E0"            },            {              minvalue: this.highlights.uvIndex.toString(),              maxvalue: "15",              code: "#D8EDFF"            }          ]        },        annotations: {          groups: [            {              items: [                {                  id: "val-label",                  type: "text",                  text: this.highlights.uvIndex.toString(),                  fontSize: "20",                  font: "Source Sans Pro",                  fontBold: "1",                  fillcolor: "#212529",                  x: "$ gaugeCenterX",                  y: "$ gaugeCenterY"                }              ]            }          ]        },        dials: {          dial: [            {              value: this.highlights.uvIndex.toString(),              baseWidth: "0",              radius: "0",              borderThickness: "0",              baseRadius: "0"            }          ]        }      }    };  },  methods: {},  computed: {},  watch: {    highlights: {      handler: function() {        this.datasource.colorrange.color[0].maxvalue = this.highlights.uvIndex.toString();        this.datasource.colorrange.color[1].minvalue = this.highlights.uvIndex.toString();        this.datasource.annotations.groups[0].items[0].text = this.highlights.uvIndex.toString();      },      deep: true    }  } }; </script>

src/components/Visibility.vue

In this component, we use a Horizontal Linear Gauge to represent the visibility, as shown in the image below:

A screenshot of the Horizontal Linear Gauge representing Air Visibility (16km) — (Large preview)

The code for the component is given below. For an in depth understanding of the different attributes of this chart type, please refer to FusionCharts Dev Center page for Horizontal Linear Gauge.

<template>  <div class="highlights-item col-md-4 col-sm-6 col-xs-12 border-left border-right border-top">    <div>      <fusioncharts        :type="type"        :width="width"        :height="height"        :containerbackgroundopacity="containerbackgroundopacity"        :dataformat="dataformat"        :datasource="datasource"      >      </fusioncharts>      </div>  </div> </template>  <script> export default {  props: ["highlights"],  components: {},  methods: {},  computed: {},  data() {    return {      type: "hlineargauge",      width: "100%",      height: "100%",      containerbackgroundopacity: 0,      dataformat: "json",      creditLabel: false,      datasource: {        chart: {          caption: "Air Visibility",          captionFontBold: "0",          captionFontColor: "#000000",          baseFont: "Roboto",          numberSuffix: " km",          lowerLimit: "0",          upperLimit: "40",          showPointerShadow: "1",          animation: "1",          transposeAnimation: "1",          theme: "fusion",          bgAlpha: "0",          canvasBgAlpha: "0",          valueFontSize: "20",          valueFontColor: "#000000",          valueFontBold: "1",          pointerBorderAlpha: "0",          chartBottomMargin: "40",          captionPadding: "30",          chartTopMargin: "30"        },        colorRange: {          color: [            {              minValue: "0",              maxValue: "4",              label: "Fog",              code: "#6297d9"            },            {              minValue: "4",              maxValue: "10",              label: "Haze",              code: "#7DA9E0"            },            {              minValue: "10",              maxValue: "40",              label: "Clear",              code: "#D8EDFF"            }          ]        },        pointers: {          pointer: [            {              value: this.highlights.visibility.toString()            }          ]        }      }    };  },  watch: {    highlights: {      handler: function() {        this.datasource.pointers.pointer[0].value = this.highlights.visibility.toString();      },      deep: true    }  } }; </script>

src/components/WindStatus.vue

This component displays the wind speed and direction (wind velocity, if you are physics savvy), and it is very difficult to represent a vector using a chart. For such cases, we suggest representing them with the aid of some nice images and text values. Since the representation we have thought about is entirely dependent on CSS, we will implement it in the next section that deals with the CSS. However, take a look at what we are aiming to create:

Wind Status: Wind Direction (left) and Wind Speed (right) — (Large preview)

<template>  <div class="highlights-item col-md-4 col-sm-6 col-xs-12 border-top">    <div>    <div class="card-heading pt-5">Wind Status</div>    <div class="row pt-4 mt-4">      <div class="col-sm-6 col-md-6 mt-2 text-center align-middle">        <p class="card-sub-heading mt-3">Wind Direction</p>        <p class="mt-4"><img src="../assets/winddirection.svg" height="40" width="40"></p>        <p class="card-value mt-4">{{ highlights.windStatus.derivedWindDirection }}</p>      </div>      <div class="col-sm-6 col-md-6 mt-2">        <p class="card-sub-heading mt-3">Wind Speed</p>        <p class="mt-4"><img src="../assets/windspeed.svg" height="40" width="40"></p>        <p class="card-value mt-4">{{ highlights.windStatus.windSpeed }} km/h</p>      </div>    </div>    </div>  </div> </template>  <script> export default {  props: ["highlights"],  components: {},  data() {    return {};  },  methods: {},  computed: {} }; </script>

Wrapping Up With Highlights.vue

Recall that we have already implemented code with CSS for all the components — except Content.vue and Highlights.vue. Since Content.vue is a dumb component that just relays data, the minimal styling it needs has already been covered. Also, we have already written appropriate code for styling the sidebar and the cards containing the charts. Therefore, all we are left to do is add some stylistic bits to Highlights.vue, which primarily involves using the CSS classes:

<template>   <div class="custom-content-card content-card card">     <div class="card-body pb-0">     <div class="content-header h4 text-center pt-2 pb-3">Highlights</div>       <div class="row">         <uv-index :highlights="highlights"></uv-index>         <visibility :highlights="highlights"></visibility>         <wind-status :highlights="highlights"></wind-status>       </div>     </div>   </div> </template>  <script> import UVIndex from "./UVIndex.vue"; import Visibility from "./Visibility.vue"; import WindStatus from "./WindStatus.vue";  export default {   props: ["highlights"],   components: {     "uv-index": UVIndex,     "visibility": Visibility,     "wind-status": WindStatus,   }, }; </script>

Deployment And Source Code

With the charts and style in order, we are done! Take a moment to appreciate the beauty of your creation.

It’s now time for you to deploy your application, and share it with your peers. If you don’t have much idea about deployment and expect us to help you, look here about our take on deployment ideas. The linked article also contains suggestions on how to remove the FusionCharts watermark at the left bottom of every chart.

If you mess up somewhere and want a reference point, the source code is available on Github.

(ms, ra, il)

Articles on Smashing Magazine — For Web Designers And Developers

17 Jan

Understanding And Using REST APIs

by TBSCategories: News

There’s a high chance you came across the term “REST API” if you’ve thought about getting data from another source on the internet, such as Twitter or Github. But what is a REST API? What can it do for you? How do you use it? In this article, you’ll learn everything you need to know about REST APIs to be able to read API documentations and use them effectively.
Articles on Smashing Magazine — For Web Designers And Developers

07 Feb

HTML APIs: What They Are And How To Design A Good One

by TBSCategories: News

As JavaScript developers, we often forget that not everyone has the same knowledge as us. It’s called the curse of knowledge: When we’re an expert on something, we cannot remember how confused we felt as newbies. We overestimate what people will find easy.

Therefore, we think that requiring a bunch of JavaScript to initialize or configure the libraries we write is OK. Meanwhile, some of our users struggle to use them, frantically copying and pasting examples from the documentation, tweaking them at random until they work.

The post HTML APIs: What They Are And How To Design A Good One appeared first on Smashing Magazine.

Smashing Magazine

20 Sep

Understanding REST And RPC For HTTP APIs

by TBSCategories: News

For the last few years, whenever somebody wants to start building an HTTP API, they pretty much exclusively use REST as the go-to architectural style, over alternative approaches such as XML-RPC, SOAP and JSON-RPC. REST is made out by many to be ultimately superior to the other “RPC-based” approaches, which is a bit misleading because they are just different.

This article discusses these two approaches in the context of building HTTP APIs, because that is how they are most commonly used. REST and RPC can both be used via other transportation protocols, such as AMQP, but that is another topic entirely.

The post Understanding REST And RPC For HTTP APIs appeared first on Smashing Magazine.

Smashing Magazine

19 Mar

Making A WordPress Plugin That Uses Service APIs, “From Soup To Nuts”

by TBSCategories: News

An increasingly large number of publicly available APIs provide powerful services to expand the functionality of our applications. WordPress is an incredibly dynamic and flexible CMS that powers everything from small personal blogs to major e-commerce websites and everything in between. Part of what makes WordPress so versatile is its powerful plugin system, which makes it incredibly easy to add functionality.

We will walk through how I made GitHub Pipeline, a plugin that allows you to display data from the GitHub API on WordPress pages using shortcodes. I’ll give specific examples and code snippets, but consider the technique described here a blueprint for how to consume any service API with a plugin. We’ll start from the beginning, but a degree of familiarity with WordPress and plugin development is assumed, and we won’t spend time on beginner topics, like installing WordPress or Composer.

The post Making A WordPress Plugin That Uses Service APIs, “From Soup To Nuts” appeared first on Smashing Magazine.

Smashing Magazine

Tag: APIs

Consuming REST APIs In React With Fetch And Axios

What Is A REST API

The Benefits Of REST APIs

An Example Of A REST API Response

Consuming APIs Using The Fetch API

The Difference Between The Fetch API And jQuery Ajax

Parameters For The Fetch API

Basic Syntax for Using the Fetch() API

Using Fetch API In React Apps

Let’s Consume A REST API With Fetch Method

Consuming APIs With Axios

Features Of Axios

Making Requests With Axios

Making Multiple Requests With Axios

Let’s Consume A REST API With Axios Client

Fetch vs Axios

Conclusion

Related Resources

Get Started With Node: An Introduction To APIs, HTTP And ES6+ JavaScript

What Is Node.js

Blocking/Non-Blocking And Synchronous/Asynchronous

Callback Functions

Promises Over Callbacks

ES6 Const vs. Let

ES6 Arrow Functions

ES6 Classes

JavaScript Events

The Node Package Manager

APIs & JSON

HTTP And HTTP Requests

MongoDB

Building A Command Line Node Application

Conclusion

Further Reading on SmashingMag:

Using Vue.js To Create An Interactive Weather Dashboard With APIs

Prerequisites

Expected Learnings

1. The Dashboard Workflow

Requirements

Structure

Data

Visualization

2. Creating The Project

Brief Explanation Of The Default Project Structure

3. Customizing The Default Project Structure

Modify Existing Files

index.html

package.json

webpack.config.js

src/main.js

src/App.vue

Additional Directories And Files

src/css/style.css

src/assets/

src/components/Content.vue

Summary

src/components/TempVarChart.vue

src/components/Highlights.vue

src/components/UVIndex.vue

src/components/Visibility.vue

src/components/WindStatus.vue

4. Data Acquisition And Processing

Preparing Child Components To Receive And Process Real Data

Content.vue

TempVarChart.vue

Highlights.vue

UVIndex.vue

Visibility.vue

WindStatus.vue

Testing With Dummy Data

Code For Data Acquisition And Processing

Input From The User

Text Information Display Controlled By App.vue

The data() Method

Methods in App.vue

Utility Methods

Action/Event Oriented Methods

Data Acquisition Methods

Data Processing Methods

The `data()` Method

General Scheme For Using Fusioncharts In `.vue` Files