Web dashboards are a commonplace tool on the internet nowadays. With a plethora of apps and services, you need a way to monitor your data anywhere and be up to date. The same applies to the Rave dashboard which serves over 24,000 businesses and individuals using our product. 

Merchants who use our dashboard today, use it because they’d like to get information or carry out any of the following tasks:
  • View transaction details.
  • View their customer’s details.
  • Carry out transfers to over 33 countries in the world.
  • Create a payment link to get paid instantly.

Therefore, it’s important to make sure that your dashboard is usable and optimized for speed. In this article, we’ll look at three strategies that were used to optimize the dashboard.
Before we begin, I’d like to point out that the Rave dashboard is built using Vue.js. We chose Vue.js because of its simplicity, short learning curve and a low barrier to getting started. This means anybody can come on onboard tomorrow and start pushing code.
It’s also important to note that the Rave dashboard is relatively new and a refresh from the previous dashboard. You can read all about the design process here.
Without further ado, here are the three strategies being employed to make the dashboard more usable and faster.

Lazy Loading components

As with every JavaScript app, the JavaScript bundle can become quite large, and that in turn can affect the page load time. It would be really rad if we only loaded what we needed. This means if I’m on the Rave dashboard and I’m viewing the transactions page, the app knows to only load the files needed for the transaction route and then do the same for the other routes.

This is known as code-splitting. Code-splitting in Vue apps can be easily configured by using webpack which already ships with the Vue app (This only applies if if your Vue app was installed through the Vue CLI). It allows you to split your code into various bundles which can then be loaded on demand or in parallel.
Here’s how routes are lazy loaded in the dashboard.

First, an async component that returns a Promise is created, CustomersMain , then we use the dynamic import syntax from webpack to indicate a code-split point. This results in an asynchronous component that will be automatically code-split by webpack.
That’s all that needed! webpack will now know to load the component/route asynchronously. If this is applied to all routes and components, a huge increase in page load time is guaranteed.

Caching Data

We are in an emerging market, therefore, it’s important to cater to the needs of everyone and that ranges from someone with access to a 4G LTE connection to a smartphone user with a 2G connection.
One other thing we do is caching data locally so that it may be viewed later. Why? This helps to always present some sort of data to the user even if a 2G connection is being used.
Data is stored in the localStorage and then displayed when appropriate.
localStorage makes it possible to store values in the browser which can survive the browser session. It is one type of the Web Storage API, which is an API for storing key-value pairs of data within the browser.
So how do we do it? Let’s see a short example below in which we are making external API calls and saving the response from the API to localStorage. First, create a data instance like below.

The function above makes a fictitious API call to fetch the list of customers. It saves the data gotten from API to the localStorage in the then() callback.

In the code block above, the computed function contains the customersList() function which is essentially a way of fetching data reactively. The first conditional checks if the data instance customers has any data in it, if it doesn’t it moves on to check the localStorage and display what’s in the localStorage.
The best part about this is, if the first check was made when the network call is in process, it gets updated to the result of the network call.
The customersList function can then be used to display data like so:
This results in users always having some data to see on the screen as long as that route has been viewed before. Also, it’s important to note that we only cache data just for presentational purposes and the cache is cleared every time a user logs out.

Mobile Responsive

This goes without saying, that your dashboard should be somewhat mobile responsive so that your users will be able to get access to info even when they are away from the computers.
Our product data and industry trends point to the fact that users are now becoming more mobile as almost everyone has a smartphone nowadays. It was only wise that we act on that data and make something actionable.
Traditionally, web dashboards are not known to be mobile responsive however we went the extra mile for the users to create a mobile responsive dashboard across all browsers.

With the mobile responsive dashboard, users can log into their dashboard, track their transactions, see their balance and do a host of other things that they would be able to do on their computers.
In the next post, we’ll explore the new Checkout form and highlight some of the processes that went into creating and building it.
In the meantime, have you checked out Rave? It is the easiest way to make and accept payments from customers anywhere in the world. We currently cater to the needs of over 24,000 businesses and individuals across the African continent and we’d be pleased to have you onboard.
 
— Yomi Eluwande

]]>

Published by Wendy

Head, Branding and Storytelling