They bring together the best parts of using a website (easy to access, no need to install anything) with the great features of mobile apps (fast, can work offline), offering a high-quality user experience.

The core of a PWA's usefulness lies in the offline-first approach, where applications are designed to function seamlessly without a constant internet connection. This means you can still use these apps even when your internet is slow or not available, and makes PWAs very user-friendly and accessible, even where an internet connection is not always reliable.

Graphic showing a native app vs a web application vs a PWA

5 Reasons to Use a PWA Instead of a Native app

Progressive Web Apps (PWAs) are reshaping the landscape of digital interaction. They offer a hybrid experience that combines the best features of web and mobile apps.

Let's delve deeper into why PWAs are often a superior choice compared to native apps:

1. Speed and Ease of Installation

PWAs eliminate the lengthy download and installation process typical of native apps. You can access a PWA as swiftly as you'd load a web page, making it as straightforward as bookmarking your favorite site – no waiting for downloads or navigating through app stores.

Consider Twitter Lite, a PWA version of the popular social media platform, which offers the full Twitter experience without the need to wait for a separate app download.

2. Minimal Storage Requirements

One of the most significant advantages of PWAs is their minimal storage requirements. Since they primarily store data online, much like cloud services, they occupy significantly less space on a user’s device.

This feature is particularly beneficial for users with limited device storage or expensive data plans. For example, Pinterest’s PWA takes up less space than its native counterpart but still provides a rich, engaging user experience.

3. Reliable Offline Performance

A PWA's ability to function offline is like having a good book downloaded to your e-reader, ready to enjoy even when you're out of range of a good signal.

PWAs can function effectively even in areas with poor or no internet connectivity, using cached data from previous online activities. This ensures that users have uninterrupted access to essential features.

A notable example is the Starbucks PWA, which allows customers to browse the menu and customize orders, regardless of their internet connection for a consistent user experience.

4. Cost-Effective Development and Cross-Device Compatibility

Developing a PWA can be more cost-effective than building native apps for various platforms. This unified approach not only saves significant development time and resources but also simplifies maintenance and updates.

Businesses like Uber have leveraged PWAs to provide a seamless user experience across all devices without the need for multiple native apps.

5. Automatic Updates and Push Notifications

PWAs update themselves seamlessly, much like a web page loading the latest content each time it’s visited. Users always have access to the most current version of the app without going through the process of manual updates. This feature ensures that users are not hindered by outdated versions, a common issue with native apps.

For instance, Google Maps’ PWA automatically incorporates the latest features and improvements without user intervention. In addition to staying current, PWAs can engage users with push notifications, just like native apps, keeping them informed and involved without the need for a visit to the app store.

Infographic of a Progressive Web App (PWA) showcasing its features: adaptability across devices, security, offline functionality, fast performance, updates, and push notifications.

PWA Core Concepts

To fully grasp the potential and functionality of Progressive Web Apps, it's essential to understand their foundational components. These core concepts not only define the structure and behavior of PWAs but also distinguish them from traditional web applications.

Service Workers: The Backbone of PWAs

Service workers are scripts that run in the background, separate from your web page. They act as a proxy between the web application and the network.

Think of service workers as behind-the-scenes helpers for your web app. Their main job is to manage how your app talks to the internet.

They can save important parts of your app on the user's device, which means your app can work even when there's no internet. They're also in charge of quietly updating app content and can send notifications, just like a native app on your phone.

The App Manifest: Your PWA's Identity

The web app manifest is a JSON file which is essential because it tells the user's device how your app should look and behave.

It's like your app's ID card – it includes the app's name, the icons it uses, the first page it should open, and how it should display (like in full screen). This file makes your web app feel more like a regular app, allowing users to 'install' it on their home screen.

Caching: The Key to Offline Functionality

Effective caching is vital for a robust offline experience. Caching is like your app's memory. It stores important parts of your app so they can be quickly loaded later, even if there's no internet. It's crucial for making your app work offline.

There are different ways to handle caching, such as cache-first (where the app checks the cache before the internet), network-first (the opposite), and stale-while-revalidate (a mix of both). The choice depends on what your app does and what kind of information it handles, affecting how your app stores and retrieves its data.

Icons representing key components of a PWA: Service worker, Manifest and HTTPS

Overview of Building a PWA

Building a Progressive Web App (PWA) might sound complex, but it's quite manageable when you break it down into steps. In this article, I'll give you an overview of the process – and in my next tutorial, I'll go into the process in more detail.

1. Start with a Basic Webpage:

Create a simple website using HTML for structure, CSS for style, and JavaScript for functionality.

<!DOCTYPE html>
<html>
<head>
    <title>Ophy's To-Do List PWA</title>
</head>
<body>
    <h1>Ophy's To-Do List</h1>
    <input type="text" id="todo-input" placeholder="Add a new task...">
    <button onclick="addTask()">Add</button>
    <ul id="todo-list">
        <!-- Tasks will go here -->
    </ul>

    <script src="app.js"></script>
</body>
</html>

body {
    font-family: 'Arial', sans-serif;
}

#todo-list {
    list-style-type: none;
}

#todo-list li {
    padding: 5px;
    margin: 5px;
    background-color: #f2f2f2;
    border-radius: 3px;
}

function addTask() {
    var input = document.getElementById('todo-input');
    var newTask = input.value;
    if (newTask) {
        var listItem = document.createElement('li');
        listItem.textContent = newTask;
        document.getElementById('todo-list').appendChild(listItem);
        input.value = ''; // Clear the input
    }
}

2. Create a Manifest File:

In the manifest file, write down your app's name, the icons it uses, and the first page it should open. This makes your website act more like an app you can install.

{
    "name": "Ophy's To-Do List",
    "short_name": "OphyToDo",
    "icons": [
        {
            "src": "favicon.ico",
            "sizes": "64x64 32x32 24x24 16x16",
            "type": "image/x-icon"
        }
    ],
    "start_url": "/",
    "display": "standalone",
    "theme_color": "#000000",
    "background_color": "#ffffff"
}

3. Set Up a Service Worker:

In your main JavaScript file, add a service worker. This is a special script that works separately from your website.

The service worker's job is to handle how your app stores and retrieves data, especially for offline use.

self.addEventListener('install', function(event) {
    // Perform install steps
    var CACHE_NAME = 'ophy-todo-cache-v1';
    var urlsToCache = [
        '/',
        '/styles.css',
        '/app.js'
    ];

    event.waitUntil(
        caches.open(CACHE_NAME)
            .then(function(cache) {
                console.log('Opened cache');
                return cache.addAll(urlsToCache);
            })
    );
});

Following these steps will help you build a simple PWA that users can install and use, even when they're offline.

Real World Use Cases for PWAs

These real-world examples demonstrate the practical benefits and impact of offline-first strategies:

1. Starbucks: Starbucks has a PWA that lets customers look at the menu and order drinks and food even when they're offline. This not only makes the experience better for customers but also helps increase sales and customer interaction with the brand, as they can order anytime, anywhere.
2. Khan academy: Khan Academy, a well-known educational site, has a PWA allowing students to download and access lessons and courses without an internet connection. This feature is particularly helpful for those in areas with unreliable internet, ensuring uninterrupted learning. Just like the Starbucks PWA, Khan Academy's use of this technology improves the user experience, making education more accessible and flexible.
3. Trivago: Trivago, a popular hotel search engine, developed a PWA to enhance user experience, especially for travelers with unstable internet connections. The PWA allows users to browse hotel deals and information offline, making trip planning more flexible and accessible. This has led to increased user engagement and higher conversion rates, as travelers can continue interacting with the app even in areas with poor connectivity.
4. Forbes: Forbes, a leading global media company, launched a PWA to improve the mobile experience for its readers. The PWA significantly reduced loading times and allowed offline reading of articles. This innovation not only enhanced user engagement but also resulted in a noticeable increase in readership and time spent on the site. The Forbes PWA demonstrates how media outlets can leverage offline-first strategies to reach and retain a wider audience, regardless of their internet connectivity.

Conclusion

PWAs are changing the game in web development, bringing features we usually see in native apps to the web.

They offer a blend of the accessibility of web applications with the engaging user experience of native apps. They represent a forward-thinking solution for businesses and developers looking to maximize reach and functionality while minimizing costs and complexity.

PWAs aren't just a passing trend – they're the next big thing in how we make and use web apps. By focusing on working offline, PWAs provide a more reliable and user-friendly experience.

Whether you're just curious or ready to start building, the following resources remain great places to begin exploring the possibilities of offline-first web applications.

• Google's PWA Checklist
• MDN Web Docs on Service Workers
• Web.dev for PWA tutorials

Let's say you need to order food – you can do so instantly via the company's app. Maybe you need government services – the same thing applies. You can even get medical emergency dial services via an app.

There's an app for everything – from banking to studying and from trading to shopping. Every business has an app, and even our governments have simplified their services into app form.

Hold on, building and maintaining an app is cumbersome, and it's quite expensive for small businesses, so how do they manage?

Well it's simple: with the help of advancements in technology there is an option that helps small businesses out. This option combines the features of an app with the technology used in web development to build affordable services for businesses – I'm talking about Progressive Web Apps.

Let's dive in and get a better understanding of what PWAs are all about.

What is a Progressive Web App?

Progressive Web Applications (PWAs) are apps built with web technologies that we probably all know and love, like HTML, CSS, and JavaScript. But they have the feel and functionality of an actual native app. Wait a minute! Native Apps, what do we mean by this?

A Native App is a software application built in a specific programming language for a specific device platform, either IOS or Android.
PWAs are built with the capabilities like push notifications and the ability to work offline. They are also built on and enhanced with modern APIs which makes it easy to deliver improved capabilities along with reliability and the ability to install them on any device.

PWAs takes advantage of the huge web ecosystem this is inclusive of the plugins, and community and the relative ease of deploying and keeping a website contrary to a native application which is pretty difficult to develop. This means you can build a PWA quickly and easily.

With its popularity many companies have shifted into the product, I tend to believe that this is because of its ability to run on an android and iOS without much difference. Some good examples of top companies who have their products as PWAs include: Twitter, Pintrest, Uber, Tiktok, Spotify, Jumia (a leading e-commerce site in Africa) etc...

A common feature about this products is that they are all installable on your home screen, able to work offline from where you last left and offer a comparable experience and features to their native apps.

Just like when building a native mobile app there are some expectations that should be met to make a good product for consumer use, the same thing applies to PWAs. Let's discuss what makes a good PWA.

Characteristics of PWAs

Below is what should be considered when developing a PWA:

Responsiveness

Different companies produce gadgets with different screen sizes, and as a developer it's your responsibility to ensure all the different users enjoy the product regardless the device they are using. So it's a good idea to make sure your app can be used on any screen size and it's content is available at any view-port size.

Installable

Research has shown that users tend to engage more with installed apps compared to visiting the official sites. Having a PWA as your product gives the users the look, feel and engagement of a normal app.

Independent Connectivity

By keeping a user engaged to your app even while they are offline, provides a more consistent experience than dropping them back to a default offline page.

A good example to illustrate this will be that of a music app, your users should be able to access offline playback and listen to saved music even without internet connection. Another good example is twitter app, a user is able to go back a read through tweets which they might have missed.

Discoverability

Since most PWAs are converted websites, it is fair to make them discoverable on the search engines, this will help generate extra traffic to your app. This also acts as an advantage over native apps which can't be discovered over the search engines.

Appearance

The appearance of the app should feel and look like that of a normal app, so be sure to include things like an app icon, this will help make it easily recognizable also things like splash screen will add the touch and feel of an app.

Cross Platform

PWAs are developed as web app first, which means that they need to work on all browsers/systems and not just a selected few. Users should be able to use them in any browser before they decide to install them.

So folks! there you have it, the general info about PWAs. Along the way you might have noticed occasionally a comparison between PWAs and Native App and this might have confused you a bit, Well let's clear the airwaves by checking the comparison between the two to get a clear understanding.

Differences Between PWAs and Native Apps

Development Cost

PWAs are cheaper to develop compared to Native AppsWhen you're developing a native app, you'll have to learn a certain programming language and then build a version of the app for each type of device, Android and iOS. On the other hand you can choose to hire a experienced professional to do the work for you which will even turn out to be more costly.

Down the road, you will also need resources to maintain and update the app, which means lots of money and time is required.

In the case of a PWA, you can have a single codebase for the different platforms. It's also time-saving since you will not need to develop it from scratch you can configure your current web site to fit.

And if you choose to hire developer it will only be one compared to native where you can hire up-to two depending on where you need your app.

Discoverability

Native apps cannot be indexed by the search engines, they can just be found through the App/Play store's website. You can make your app more discoverable on the App/Play store by using App Store Optimization(ASO), but that's another story.

Unlike native apps, PWAs work like websites so they can be indexed by search engines. This helps them rank better in search results.

Safety

Nowadays in order to run a website, it should be encrypted with a SSL certificate, this adds an extra layer of security. Now, as we already know PWAs are site converted into app which means they are more secure because they run on HTTPS. These are security protocols that allow safe exchange of data between client and server so that is doesn't get tampered with.

To secure your native apps, you need to implement various security measures, like multi-factor authentication and so on.

Installation and Download

Native apps need to be downloaded and installed from an app store. This requires some commitment from the user to do it from start to finish. Users have to pass and check multiple permissions before installing an app.

On the other hand, PWAs don't require any of those steps. From the browser you can bookmark it and add the app to your home screen with just a few taps.

Benefits of PWAs

A lot of organizations both private and public are switching to PWAs not only because they are cheap to develop but also because they offer greater engagement.
Now let's look at a quick summary of the benefits of a PWA:

• They are responsive and work with many different screen sizes.
• They can run on multiple platforms and any device with a modern web browser.
• They function just like normal Native Apps.
• The updates are independent, you don't need to visit the play store for an update.
• They're built with common web technologies.
• They're fast and lightweight.
• They work offline unlike other sites.
• They are discoverable via search engine.
• They are easily installable.
• Low maintenance cost.

Requirements to Get Started with PWA Development

It does not take much to get started building a PWA. You just need a few things and you are good to go.

Tools
The best known technology stack to develop PWAs is AngularJS. Speaking of Angular, here is a resourceful guide on how you can convert your already existing Angular app into PWA. Others stacks include ReactJS and Polymer.

HTTPS
You will need a server with a HTTPS connection. This makes sure your user's data is secure. It adds an extra layer of security to you site.

Application Shell
It provides a good first impression when your app loads. In simpler words this is what the user sees when they interact with your app for the first time.

Service workers
This is one of the key technologies behind PWAs. They help support your app work offline, and they perform advanced caching and run background tasks. Service workers can complete tasks even when your PWA is not running.Some other functions associated with Service Worker include:

• Sending push notification
• Badging icons
• Running background fetch tasks etc...

Manifest file
This is a JSON file that is created with a Web App Manifest Generator. This file contains the information that tells how your PWA should appear and function. It allows you to determine the name, description, icon, colors and other features of your PWA. Here's an example of a manifest file:

{
"short_name": "DevBlogger",  
"name": "DevBlogger",  
"description": "All dev stories under one roof",
"theme_color": "#eb5252",  
"background_color": "#000000",  
"display": "fullscreen",  
"Scope": "/",  "orientation": "portrait",  
"icons": [    
    {
        "src": "images/android/android-launchericon-48-48.png",      
        "type": "image/png",      
        "sizes": "48x48"
    },
    {      
        "src": "images/android/android-launchericon-96-96.png",
        "type": "image/png",      
        "sizes": "96x96"    
    },    
    {      
        "src": "images/android/android-launchericon-192-192.png",
        "type": "image/png",      
        "sizes": "192x192"    
    }  
   ],  
       "start_url": "index.html?utm_source=homescreen"
  }

• Audit your App
  This is possible using the Google Lighthouse tool. Google Lighthouse is a open-source software that anyone can use on any webpage. Google is a big champion of PWAs and pushes them as the future of the web. You can use Lighthouse to help you see how fast, accessible, and SEO readiness your PWA is.

How to Build a PWA

By following the steps below, you can easily create a fully functional PWA that offers an mazing user experience across all devices.

Step 1 - Plan your app

Before diving into development, you should consider the goals of your PWA, what features you want to include, priorities and user experience. You can create first design concepts and wireframes for the app to visualize the structure and layout.
In most scenarios, this is often referred to as a ‘discovery phase’. You get the opportunity to ideate and gather user and stakeholder feedback as well as considering the functionalities of your to be product.

Step 2 - Designing the User Interface

After getting everything right from planning, you can now proceed to designing the UI of your app. During this stage consider things like responsiveness, compatibility with different platforms etc.. Be sure to capture all details that are crucial to the user including their interaction and engagement during usage.

Step 3 - Developing the Front-End

Using the web technologies that is HTML, CSS, JavaScript and frameworks like Angular. React or Vue.js develop a visually appealing interface for the users. And always remember they key principle in development using this stack implement a mobile first approach while ensuring responsiveness for larger screens too.

Step 4 - Implementing Service Workers

As mentioned previously, service workers are a key component of PWAs. They are JavaScript files that run in the background, enabling offline functionality, push notifications, and caching. To make sure your PWA works to its fullest potential, you’ll need to register and implement a service worker. The way on how you can do this massively depends on which framework you are using.

Step 5 - Adding Push Notifications

Leverage the Push API and service workers to implement push notifications. Obtain the necessary user consent and use a push notification service to send notifications to users.

Step 6 - Optimizing Performance

Optimization is a very important step in development in general. This is how you provide a seamless experience to your users. by ensuring you reduce loading times. by leveraging techniques such as code splitting and caching we should be able to achieve a fast and efficient operation for our PWA.

Step 7 - Testing and Debugging

Test your PWA on different devices, browsers and network condition to be sure that it meets the objective. Also be sure to gather user feedback and make necessary improvements when necessary.

Resources to Get Started with PWA Development

If you want to learn and move with the trend, finding resources to help you might be a bit tedious, to help you get started here are some of the best resources listed for you:
Online Tutorials and Guides

• Google Developers - Progressive Web Apps
• MDN Web Docs - Progressive Web Apps
• freeCodeCamp - Frontend Technologies
• Learn PWA

Documentation and Reference Materials

• Service Workers API Documentation
• Progressive Web Apps (PWAs)

PWA Development Tools

• Workbox - Offline Caching and Service Worker Library
• PWA Builder - PWA Generation Platform

Conclusion

Keeping in mind that PWAs are new to the industry and haven't yet been fully utilized, they can be a great addition to add to your toolkit.

With the latest technologies and the right tools getting started with PWAs can ultimately increase sales and monetary gain for your product either as an individual or organization. With it's many features including they are fast, able to work offline, and also they perform like normal native apps. This offers your users a great experience and keeps them satisfied.

If you have read this far I really appreciate it.

Enjoy Coding ❤.

It's natural to get excited about launching something new, but it's also important to remember the basics of website security. As a developer, you know it’s important to protect your web app from malicious users, attackers, hackers, and other cyber threats.

You've put in a lot of hard work building the perfect user experience and now it's time to keep it secure.

In this tutorial, we'll walk through some simple yet powerful strategies that help you protect your PWA. Let’s get started!

What is a PWA?

PWA Illustration by undraw.co

Are you interested in bringing a native mobile app experience to your users without the headache of app development? Progressive Web App is the way.

PWAs are a type of web application that uses the latest web tech to deliver a user experience similar to that of a native mobile app.

They are built to take advantage of native mobile device features and work for apps regardless of whether the user has poor or no internet connection.

Additionally, PWAs are reliable, fast, and engaging — plus, they’re easier to develop and maintain than traditional apps.

The best part about PWAs is that they offer the same experience on all major browsers like Chrome, Firefox, Edge and Safari — so you don’t have to be concerned about compatibility issues.

Also, since PWAs don’t require installation from an app store, users don’t have to wait for their device manufacturer to approve or update them.

All these factors make PWAs ideal for businesses looking for cost-effective mobile solutions.

How to Secure a PWA

Authentication and Authorization in PWAs

authentication illustration by undraw.co

If you're building a Progressive Web App (PWA), you need to ensure that it is properly secured. In order to do this, you'll need to understand the basics of authentication and authorization.

Authentication is the process by which users prove their identity and verify that they have the proper authorization to access the app.

Authorization, on the other hand, ensures that those users have access only to areas and content that they are allowed to see, while enforcing restrictions on what they can do.

In order to implement effective authentication and authorization within your PWA, there are some best practices you should follow.

1. Firstly, use secure passwords that are difficult for hackers or bots to guess or crack, as well as two-factor authentication (2FA) for added security.
2. Secondly, use roles-based access control (RBAC) for authorization. This establishes user permissions based on roles which can be quickly adjusted when needed.
3. Lastly, use HTTPS with SSL/TLS encryption for all web traffic from your PWA. This will ensure that all data sent between clients and servers is encrypted, protecting user information from malicious actors.

It is important to keep in mind that authentication and authorization can also be vulnerable to attack by malicious users if not implemented correctly. So it is essential to stay aware of common attack vectors like SQL injection threats and cross-site scripting (XSS) attacks.

By implementing proper security measures such as input validation and penetration testing, you can protect your PWA from these threats.

How to Use HTTPS and SSL/TLS to Secure Your PWAs

HTTPs and SSL/TLS are two of the most important tools when it comes to securing PWAs.

Let's see what exactly they are:

What is HTTPS?

HTTPS stands for Hyper Text Transfer Protocol Secure. It's a protocol used for secure communication between a web server and a web browser, and is vital for protecting data from being intercepted by third parties.

To put it simply, HTTPS helps ensure that the data you send and receive from your PWA is always secure.

What is SSL/TLS?

SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are cryptographic protocols that provide authentication, encryption and data integrity.

These protocols allow secure connections between web browsers, applications, and servers over the internet via an encrypted handshake process.

As such, they play an important role in ensuring that your web app's data remains safe and secure.

Best Practices for Implementing HTTPS and SSL/TLS in PWAs

To protect your PWA effectively, you should make sure that you're following some best practices for implementing HTTPS and SSL/TLS in PWAs:

1. Use HTTPS Everywhere: Make sure that all of your pages are served over HTTPS, rather than insecure HTTP connections. This will help ensure your users' data is protected while they're on your website or application.
2. Install an SSL Certificate: This will enable HTTPs connections on your site and provide authentication between the server hosting your PWA and the users visiting it.
3. Regularly Test Connections: Ensure that all of your connections are still secure by testing them regularly for any vulnerabilities or risks to security
4. Implement Certificate Pinning: Certificate pinning is an important security measure that involves binding a host domain to a specific SSL certificate. This prevents man-in-the-middle attacks and will help protect your PWA from malicious actors.
5. Keep Your Security Protocols Up to Date: Regularly update your web server's security protocols to ensure that you're always running the most secure version.
6. Configure Appropriate Firewall Rules: Configure your firewall rules to allow only secure connections and block any suspicious traffic. This will help protect your PWA from malicious attacks.

Once you've implemented these best practices, you can feel pretty confident that your PWA is as secure as possible.

But, security isn't just about preventing malicious attacks. It's about ensuring that your users' data is always kept safe and secure.

By taking the above steps, you can ensure that your PWA is always compliant with the latest security standards and guidelines. This will help protect your users' data from unauthorized access and potential security threats.

How to Protect against Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF)

Cross-site scripting and cross-site request forgery are both security threats that can cause serious damage to PWAs.

XSS works by injecting malicious code into the browser via a vulnerable web application.

This code can be used to exfiltrate data from the PWA, like passwords or credit card numbers, or to execute any other malicious code.

CSRF, on the other hand, is a form of attack that manipulates a user's browser into sending forged requests without them knowing.

This can be used to execute actions within an application, such as transferring money or deleting data.

Fortunately, there are steps you can take to protect your PWA against XSS and CSRF attacks:

• Sanitize all user input: Sanitizing user input is one of the best ways to protect against XSS and CSRF attacks. Make sure that you always validate and filter out any potentially harmful content before it’s added to your database.
• Use CAPTCHA protection: Adding CAPTCHA protection to web forms will help ensure that any requests from users are coming from real people rather than malicious bots or scripts.
• Use secure cookies: Secure cookies allow you to store data about your users in an encrypted format and limit access only to authorized users. This can help make sure that data isn’t exposed in case of a compromise.

By taking these steps, you can help protect your PWA against XSS and CSRF attacks.

How to Develop a Content Security Policy (CSP)

Content Security Policy (CSP) is an important web security mechanism designed to prevent malicious attacks.

To put it simply, a CSP is a set of rules that specify what sources are allowed when loading resources such as scripts, images, and stylesheets. By defining the sources of these content types, CSP helps protect your applications from cross-site scripting (XSS) and data injection attacks.

By implementing a CSP on your PWA, you can add an extra layer of protection against malicious attacks.

Some best practices for implementing CSP include:

• Defining allowed origins: This makes sure that only authorized sources can access content on your application.
• Whitelisting inline styles: When possible, use the nonce attribute to whitelist specific inline scripts and styles so that the code is only executed if the nonce matches what is specified in the policy.
• Disallowing unsafe methods: Include a directive that blocks dangerous methods such as eval() in order to protect against code injection attacks.
• Setting up reporting/logging: Configure reporting/logging so you can track incoming requests and flag any suspicious activity.

By following these best practices and setting up CSP properly, you can effectively protect your PWAs from malicious attacks while ensuring they remain secure and performant.

Conclusion

In short, if you want to keep your web app secure, it’s important to follow best practice security protocols such as robust authentication and encryption, regular security patch updates, and secure APIs. It's also essential to have a secure development process in place to ensure that only the most secure code is being deployed.

Finally, user education is key when it comes to web apps. Providing users with a secure platform is only half the battle, as ultimately it’s up to the user to stay vigilant about their online security.

Read more on PWAs:

• What is a PWA? Progressive Web Apps for Beginners
• How to build a PWA from scratch with HTML, CSS, and JavaScript

• What are we going to build?
• What is Next.js?
• Step 0: Setting up a new Next.js app
• Step 1: Fetching Rick and Morty characters with an API in Next.js
• Step 2: Displaying Rick and Morty characters on the page
• Step 3: Loading more Rick and Morty characters
• Step 4: Adding the ability to search for Rick and Morty characters
• Step 5: Using dynamic routes to link to Rick and Morty character pages
• Bonus Step: Deploy your Rick and Morty wiki to Vercel!

What are we going to build?

We’re going to have some fun and build out a web app that serves as a basic wiki for Rick and Morty characters.

Rick and Morty Wiki Demo

Our app is going to consist of a few things:

• A list of characters on the front page
• A button that can load more characters, as the API is paginated
• A search box to look up characters
• A character page with basic details

We’ll learn some concepts like:

• How to spin up a web app with Next.js
• How to fetch and use data from an API
• How to pre-render data from an API
• How to set up dynamic routing

What is Next.js?

Next.js is a React framework from Vercel. It let’s you easily build lightweight dynamic web apps with a ton of modern features you’d expect out-of-the-box.

Vercel, the company that supports Next.js, is a service that allows you to automate continuous development pipelines to easily deploy web apps to the world. We’ll also use Vercel’s command line tool to optionally deploy our new wiki demo.

Step 0: Setting up a new Next.js app

To get started, let’s spin up our Next.js project. We’ll use npm or yarn to get started:

yarn create next-app
# or
npx create-next-app

Creating a new Next.js app

Once you run that command, it will ask you a few questions. I’m going to call my project my-rick-and-morty-wiki, but you can name it whatever you’d like.

It will then ask you which template to choose — go ahead and select the default template.

Finally, it will install all of the dependencies.

Successfully created a new Next.js app

When it’s finished, you can navigate to that new directory and run:

yarn dev
# or
npm run dev

Starting Next.js development server

You should now have a local server running at http://localhost:3000!

Default Next.js template

Step 1: Fetching Rick and Morty characters with an API in Next.js

Now that we have our app set up, the first thing we need to actually build out our wiki is a list of characters.

To do this, we’re going to start off in our home page in pages/index.js.

Next.js scaffolds this page for us automatically. It’s the first page someone will hit on our website and has some basic features in the default template like a title, a simple grid, and some styles.

Currently, this page isn’t requesting any data. To get our characters, we’re going to jump right into requesting this server side.

To do this, Next.js allows us to export an async getServerSideProps function right next to our page, which it will use to inject our page with any data that we fetch.

Let’s start off by adding the following snippet above our Home function component:

const defaultEndpoint = `https://rickandmortyapi.com/api/character/`;

export async function getServerSideProps() {
  const res = await fetch(defaultEndpoint)
  const data = await res.json();
  return {
    props: {
      data
    }
  }
}

Here’s what we’re doing:

• We’re setting a variable called defaultEndpoint that simply defines our default API endpoint
• We’re defining our getServerSideProps function that we’ll use to fetch our data
• In that function, we first use the fetch API to make a request to our endpoint
• With it’s response, we run the json method so that we can grab the output in JSON format
• Finally, we return an object where we make our data available as a prop in the props property

Now that we’re making that request, we need to make it available to use.

Our data is made available as a prop, so let’s create an argument in our Home component function to grab that:

export default function Home({ data }) {

To test this, we can use console.log to see the results:

export default function Home({ data }) {
  console.log('data', data);

And once we save and reload the page, we can now see our results!

Logging out Rick and Morty character data in Next.js app

Follow along with the commit!

Step 2: Displaying Rick and Morty characters on the page

Now that we have our character data, let’s actually display it on our page.

To start, I’m going to make a few tweaks. I’m going to update:

• The <h1> title to “Wubba Lubba Dub Dub!”
• The <p> description to “Rick and Morty Character Wiki”

I’m also going to update the contents of <div clasName=“grid” to:

<ul className="grid">
  <li className="card">
    <a href="https://nextjs.org/docs">
      <h3>My Character</h3>
    </a>
  </li>
</ul>

What I’m doing here:

• I’m making the <div> a list as that will be better for accessibility
• I’m making the <li> of the <ul> the card
• And just changing the <h3> to “My Character” temporarily

To make sure our new <ul> doesn’t mess up the layout with it’s default styles, let’s also add the following to the bottom of the .grid CSS rules:

list-style: none;
margin-left: 0;
padding-left: 0;

And now if we look at the page, we should see our basic changes.

Updated title in Rick and Morty Wiki

Next, let’s make our grid load our characters.

At the top of our Home component function, let’s add:

const { results = [] } = data;

That will destructure our results array from our data object.

Next, let’s update our grid code:

<ul className="grid">
  {results.map(result => {
    const { id, name } = result;
    return (
      <li key={id} className="card">
        <a href="#">
          <h3>{ name }</h3>
        </a>
      </li>
    )
  })}
</ul>

Here’s what we’re doing:

• We’re using the map method to create a new list element for each of our results (or characters)
• Inside of that, we’re grabbing the id and name from each character result
• We’re using the ID as a key for our list element to make React happy
• We’re updating our header with the name

And once you save and reload the page, we should now see a new list of our characters from the API!

Dynamic list of Rick and Morty character names

We can also add an image for each character.

First, inside of our grid, let’s update our destructure statement to grab the image URL:

const { id, name, image } = result;

Next, let’s add the image above our header:

<img src={image} alt={`${name} Thumbnail`} />

And now each of our characters also shows their picture!

Adding character images on Rick and Morty Wiki

Follow along with the commit!

Step 3: Loading more Rick and Morty characters

Now if you notice, when we load the page, we only get a certain number of results. By default, the API won’t return the entire list of characters, which makes sense, because it’s really long!

Instead, it uses pagination and provides us with the “next” endpoint, or the next page of results, that will allow us to load in more results.

To start, we’re going to use React’s useState hook to store our results in state. We’ll then have the ability to update that state with more results.

First, let’s import useState from React:

import { useState } from 'react';

Next, let’s create our state by first renaming our original results variable and setting up our useState instance:

const { results: defaultResults = [] } = data;
const [results, updateResults] = useState(defaultResults);

If you save that and reload the page, you shouldn’t notice anything different yet.

Next, we want to be able to understand in our application what our current endpoint we’ve made a request is, what the next endpoint is, what the previous endpoint is, and how we can update all of that.

To do this, we’re going to create more state. First, we want to update our destructuring statement with our data to get the info value:

const { info, results: defaultResults = [] } = data;

Next, let’s set up some state using that:

const [page, updatePage] = useState({
  ...info,
  current: defaultEndpoint
});

Here, we’re:

• Creating a new page state that we can use to get our prev and next values
• We’re also creating a new value called current we’ll we start off by using our defaultEndpoint, which was the request made on the server

The idea here, is when we want to load more results, we’re going set up code to watch the value of current and update that value with the next, so when it changes, we’ll make a new request.

To do that, let’s add a useEffect hook to make that request:

const { current } = page;

useEffect(() => {
  if ( current === defaultEndpoint ) return;

  async function request() {
    const res = await fetch(current)
    const nextData = await res.json();

    updatePage({
      current,
      ...nextData.info
    });

    if ( !nextData.info?.prev ) {
      updateResults(nextData.results);
      return;
    }

    updateResults(prev => {
      return [
        ...prev,
        ...nextData.results
      ]
    });
  }

  request();
}, [current]);

Here’s what’s going on:

• First, we’re destructuring the current value from `page
• We’re creating a useEffect hook that uses current as a dependency. If they value changes, the hook will run
• If our current value is the same as defaultEndpoint, we don’t run the code, as we already have our request data. Prevents and extra on load request
• We create an async function that we’re able to run. This allows us to use async/await inside of our useEffect hook
• We make the request to the current endpoint. With that successful request, we update the page state with the new info like the new prev and next value
• If our request does not have a previous value, that means it’s the first set of results for the given request, so we should completely replace our results to start from scratch
• If we do have a previous value, concatenate our new results to the old, as that means we just requested the next page of results

Again, if you save and reload the page, this still shouldn’t do anything and your page should be where it was before.

Finally, we’re going to create a Load More button and use it to update the current value to fire off a new request when we want a new page.

To do that, let’s first add a new button below our grid:

<p>
  <button>Load More</button>
</p>

Added Load More button to Rick and Morty Wiki character list

Now we want something to happen when we click that button, so first add an event handler:

<button onClick={handleLoadMore}>Load More</button>

Then above the component return statement, let’s add that function:

function handleLoadMore() {
  updatePage(prev => {
    return {
      ...prev,
      current: page?.next
    }
  });
}

When triggered with our button click, this function will update our page state with a new current value, specifically with the next value which is the endpoint to fetch our next page of results.

Loading more results in Rick and Morty Wiki

And when we save and reload the page, it does just that!

Follow along with the commit!

Step 4: Adding the ability to search for Rick and Morty characters

One of the features out Rick and Morty API provides is the ability to filter results — so basically the ability to search. So let’s add that as a feature.

First, we need a search form. Let’s add the following snippet under the description paragraph:

<form className="search">
  <input name="query" type="search" />
  <button>Search</button>
</form>

Next, let’s add these styles to the bottom of the first <style jsx> block:

.search input {
  margin-right: .5em;
}

@media (max-width: 600px) {
  .search input {
    margin-right: 0;
    margin-bottom: .5em;
  }

  .search input,
  .search button {
    width: 100%;
  }
}

That’s going to give some spacing to our search input and button as well as make it mobile friendly. Feel free to add more styles if you’d like.

And if we save and refresh our page, we have a simple form.

Added search form to Rick and Morty Wiki

It doesn’t do anything yet, so let’s make it search when submit the form.

To start, let’s add an onSubmit attribute to our form:

<form className="search" onSubmit={handleOnSubmitSearch}>

And to go with that, let’s define our submit function above our return statement:

function handleOnSubmitSearch(e) {
  e.preventDefault();

  const { currentTarget = {} } = e;
  const fields = Array.from(currentTarget?.elements);
  const fieldQuery = fields.find(field => field.name === 'query');

  const value = fieldQuery.value || '';
  const endpoint = `https://rickandmortyapi.com/api/character/?name=${value}`;

  updatePage({
    current: endpoint
  });
}

Here’s what we’re doing:

• First we’re preventing default behavior from the form submission to prevent the page from reloading
• Next we grab the current target, which is our form
• We grab the fields from the form by using the elements property. We also turn this into an array so it’s easy to work with
• We search those fields for our query input
• We grab the value of that input
• We create a new endpoint where we filter by name using that query value
• Finally, we update our current property in our page state to trigger a new request to that endpoint

And once you save that and reload the page, you can now give search a try. You should be able to type in a name like “rick”, hit enter or click the search button, and you should now see filtered results with the various ricks across the universe!

Searching for Rick on Rick and Morty Wiki

Follow along with the commit!

Step 5: Using dynamic routes to link to Rick and Morty character pages

Now that we have all of our characters, we want to be able to click into those characters and display some additional details. To do that, we’re going to make use of Next.js’s dynamic routes.

The first thing we need to do is properly configure our directory structure so Next.js recognizes the dynamic path. In order to set up a dynamic route, we need to create our folder exactly like:

- pages
-- character
--- [id]
-- index.js

Yes, that means you’re literally creating a folder with the name of [id], that’s not meant to be replaced. Next.js recognizes that pattern and will let us use that to create a dynamic route.

To make creating the page easier, we’re going to simply duplicate our homepage by copying our pages/index.js file into our next directly.

So we should now have a new page at pages/character/[id]/index.js.

Next, let’s remove a bunch of stuff so we can get to a good starting point:

• Remove everything above the return statement in our page’s function component
• Rename the function component Character
• Remove the useState and useEffect imports
• Remove the description, search form, grid, and load more button
• Optional: remove the footer

Once you’re done, the top of our page’s function component should look like:

export default function Character({ data }) {
  return (
    <div className="container">
      <Head>
        <title>Create Next App</title>
        <link rel="icon" href="/favicon.ico" />
      </Head>

      <main>
        <h1 className="title">
          Wubba Lubba Dub Dub!
        </h1>
      </main>

While there is some CSS we don’t need, we’re going to leave it all there for this demo. Feel free to clean some of that out later.

If you navigate manually to /character/1, you should now see a simple page with just a title:

Simple character page

Next, let’s update the data we’re fetching. We can reuse most of the code in our getServerSideProps function.

We’re going to add a new argument to that getServerSideProps function:

export async function getServerSideProps({ query }) {

When our page is rendered, Next.js injects data into our page and the getServerSideProps function about the environment. Here, we’re destructuring that data to grab the query object which will include any dynamic routing attributes, such as the [id] we’re setting in the route.

Next, at the top of the getServerSideProps function, let’s destructure the ID:

const { id } = query;

And finally let’s use that ID to dynamically create an endpoint we’ll use to fetch our character data:

const res = await fetch(`${defaultEndpoint}${id}`);

Here, we’re using our character endpoint and appending the dynamic ID of our URL to the end of the URL.

To test this out, let’s add a console.log to the top of the Character function:

export default function Character({ data }) {
  console.log('data', data);

And if we hit save and reload our page, we should now see the user details about character number 1 logged out, which is Rick Sanchez!

Logging out individual Rick and Morty character data

So we have the data, let’s add it to our page.

At the top of the character function, let’s add this destructure statement:

const { name, image, gender, location, origin, species, status } = data;

This gives us a bunch of attributes we’re getting right from that data object we saw logged out.

To use that, we can start by updating the title to that name:

<title>{ name }</title>

Also the <h1>:

<h1 className="title">{ name }</h1>

At this point, we should now dynamically see Rick’s name.

Dynamic Rick and Morty character page title

Next, let’s add this block below our <h1> to include more of our character details:

<div className="profile">
  <div className="profile-image">
    <img src={image} alt={name} />
  </div>
  <div className="profile-details">
    <h2>Character Details</h2>
    <ul>
      <li>
        <strong>Name:</strong> { name }
      </li>
      <li>
        <strong>Status:</strong> { status }
      </li>
      <li>
        <strong>Gender:</strong> { gender }
      </li>
      <li>
        <strong>Species:</strong> { species }
      </li>
      <li>
        <strong>Location:</strong> { location?.name }
      </li>
      <li>
        <strong>Originally From:</strong> { origin?.name }
      </li>
    </ul>
  </div>
</div>

Here we’re using our characters image to display a picture of our character and other various metadata to add Character Details.

We can follow that up by adding this snippet of CSS to our styles:

.profile {
  display: flex;
  margin-top: 2em;
}

@media (max-width: 600px) {
  .profile {
    flex-direction: column;
  }
}

.profile-image {
  margin-right: 2em;
}

@media (max-width: 600px) {
  .profile-image {
    max-width: 100%;
    margin: 0 auto;
  }
}

And now we have our character bio!

Dynamic Rick Sanchez characer page

So a quick recap, we have our new dynamic page. We can go to /character/1 or any ID to see a specific character. Let’s now update our homepage to link to these pages.

Back on pages/index.js, our homepage, let’s first import the Link component from Next.js:

import Link from 'next/link'

Next, inside of our grid where we map through our list of results, let’s use our <Link> component and update our code:

<li key={id} className="card">
  <Link href="/character/[id]" as={`/character/${id}`}>
    <a>
      <img src={image} alt={`${name} Thumbnail`} />
      <h3>{ name }</h3>
    </a>
  </Link>
</li>

Here’s what we’re doing:

• First we’re wrapping our <a> element with a <Link> component
• We add a href and the as properties to describe to Next.js what page we want to link to. We need to use the as property as it’s a dynamic link
• We remove the href from our <a> element as it’s now being applied to the <Link> element

If we save and reload our homepage, we’ll notice that nothing changed, but when we click any of our characters, we now go to their bio page!

Navigating to Jerry Smith character page on Rick and Morty Wiki

Finally, let’s also add a button to our character bio page that links back to our homepage to make it easier to navigate.

First, let’s import the Link component:

import Link from 'next/link';

At the bottom of our <main> tag below our .profile div, let’s add this code:

<p className="back">
  <Link href="/">
    <a>
      Back to All Characters
    </a>
  </Link>
</p>

And we can add the following basic styles to simply make it look like a link:

.back a {
  color: blue;
  text-decoration: underline;
}

And if we reload the page, we now have link that we can click to go back to the main page with all of our characters!

Back to All Characters link on Rick and Morty character page

Follow along with the commit!

Bonus Step: Deploy your Rick and Morty wiki to Vercel!

Because we’re using Next.js, Vercel makes it super simple to deploy our app.

To do this, we need to install the Vercel CLI. We can do that by installing it as an npm module globally:

yarn global add vercel
# or 
npm i -g vercel

Now, you can run the vercel command in your terminal.

The first time you run this, you’ll be prompted to log in. You’ll want to use your Vercel account to do this. If you don’t have one, you’ll want to sign up for a free account.

Logging into Vercel CLI

With the Vercel CLI installed, we can simply run vercel in our project directory, fill out a few questions, and it will automatically deploy!

Deploying app with Vercel CLI

You can use pretty much all of the defaults, though you will probably need to use a different project name than I’m using.

But once finished, we now have successfully deployed our new app to Vercel!

Finished Rick and Morty Wiki app

What else can we do?

More dynamic pages

Every time you make a request to a character, the API returns other endpoints that you can use such as locations and episodes. We can utilize those endpoints and create new dynamic pages, just like our dynamic character profile pages, to allow people to see more information about a specific location or episode.

Add some styles

We stuck with some of the basic styles that Next.js included and added some basic ones just for demonstration purposes. But now that you’re finished, you can have some fun and make it your own!

Add character filters

In addition to filtering by name, the API also supports filtering by status. By adding a status parameter to the endpoint URL, just like our name parameter, you can add a new filter to make it easier to find characters that are still alive or not.

By Rohit Kumar

Here’s what we will build in this tutorial: a nice React card like this one.

In this tutorial, we’ll use server-side rendering to deliver an HTML response when a user or crawler hits a page URL. We’ll handle the latter requests on the client side.

Why do we need it?

Let me guide you to the answer.

What’s the difference between client-side rendering and server-side rendering?

In Client-side rendering, your browser downloads a minimal HTML page. It renders the JavaScript and fills the content into it.

Server-side rendering, on the other hand, renders the React components on the server. The output is HTML content.

You can combine these two to create an isomorphic app.

Cons of Rendering React on the Server

• SSR can improve performance if your application is small. But it can also degrade performance if it is heavy.
• It increases response time (and it can be worse if the server is busy).
• It increases response size, which means the page takes longer to load.
• It increases the complexity of the application.

When should you use Server Side Rendering?

Despite these consequences of SSR, there are some situations in which you can and should use it.

1. SEO

Every website wants to appear in searches. Correct me if I’m wrong.

Unfortunately, Search engine crawlers do not yet understand/render JavaScript.

This means they see a blank page, no matter how helpful your site is.

Many folks say that Google’s crawler now renders JavaScript.

To test this, I deployed the app on Heroku. Here is what I saw on the Google Search Console:

Google’s crawler does not render React

A blank page.

This was the biggest reason I explored server-side rendering. Especially when it is a cornerstone page such as a landing page, blog, and so on.

To verify if Google renders your site, visit:

Search Console Dashboard > Crawl > Fetch as Google. Enter the page URL or leave it empty for the homepage.

Select FETCH AND RENDER. Once complete, click to see the result.

2. Improve performance

In SSR, the application performance depends on the server’s resources and user’s network speed. This makes it very useful for content-heavy sites.

For Example, say that you have a medium-price mobile phone with slow internet speed. You try to access a site that downloads 4MB of data before you can see anything.

Would you be able to see anything on your screen within 2–4 seconds?

Would you visit that site again?

I don’t think you would.

Another major improvement is in First User Interaction Time. This is the difference in time from when a user hits the URL to when they see content.

Here’s the comparison. I tested it on a development Mac.

React Rendered on Server

SSR performance report (Chrome)

The first interaction time is 300ms. Hydrate finishes at 400ms. The load event exits at 500ms approximately. You can see this by checking out the image above.

React Rendered on Client’s Browser

Client side performance report (Chrome)

The first interaction time is 400ms. The load event exits at 470ms.

The result speaks for itself. There’s a 100ms difference in the First User Interaction Time for such a small app.

How does it Work? — (4 Simple Steps)

• Create a fresh Redux Store on every request.
• Optionally dispatch some actions.
• Get the state out of the Store and perform SSR.
• Send the state obtained in the previous step along with the response.

We will use the state passed in the response for creating the initial state on client-side.

Before you get started, clone/download the complete example from Github and use it for reference.

Getting Started by Setting up our App

First, open your favourite editor and shell. Create a new folder for your application. Let’s start.

npm init --yes

Fill in the details. After package.json is created, copy the dependencies and scripts below into it.

Install all dependencies by running:

npm install

You need to configure Babel and webpack for our build script to work.

Babel transforms ESM and react into Node and browser-understood code.

Create a new file .babelrc and put the line below in it.

{
  "presets": ["@babel/env", "@babel/react"]
}

webpack bundles our app and its dependencies into a single file. Create another file webpack.config.js with the following code in it:

const path = require('path');module.exports = {
    entry: {
        client: './src/client.js',
        bundle: './src/bundle.js'
    },
    output: {
        path: path.resolve(__dirname, 'assets'),
        filename: "[name].js"
    },
    module: {
        rules: [
            { test: /\.js$/, exclude: /node_modules/, loader: "babel-loader" }
        ]
    }
}

The build process output’s two files:

1. assets/bundle.js — pure client side app.
2. assets/client.js — client side companion for SSR.

The src/ folder contains the source code. The Babel compiled files go into views/. views directory will be created automatically if not present.

Why do we need to compile source files?

The reason is the syntax difference between ESM & CommonJS. While writing React and Redux, we heavily use import and export in all files.

Unfortunately, they don’t work in Node. Here comes Babel to rescue. The script below tells Babel to compile all files in the src directory and put the result in views.

"babel": "babel src -d views",

Now, Node can run them.

Copy Precoded & Static files

If you have already cloned the repository, copy from it. Otherwise download ssr-static.zip file from Dropbox. Extract it and keep these three folders inside your app directory. Here’s what they contain.

1. React App and components resides in src/components.
2. Redux files in src/redux/.
3. assets/ & media/: Contain static files such as style.css and images.

Server Side

Create two new files named server.js and template.js inside the src/ folder.

1. src/server.js

Magic happens here. This is the code you’ve been searching for.

import React from 'react';
import { renderToString } from 'react-dom/server';
import { Provider } from 'react-redux';
import configureStore from './redux/configureStore';
import App from './components/app';

module.exports = function render(initialState) {
  // Model the initial state  
  const store = configureStore(initialState);
  let content = renderToString(<Provider store={store} ><App /></Provider>);
  const preloadedState = store.getState();
  return {
    content,
    preloadedState
  };
};

Instead of rendering our app, we need to wrap it into a function and export it. The function accepts the initial state of the application.

Here’s how it works.

1. Pass initialState to configureStore(). configureStore()returns a new Store instance. Hold it inside the store variable.
2. Call renderToString() method, providing our App as input. It renders our app on the server and returns the HTML produced. Now, the variable content stores the HTML.
3. Get the state out of Redux Store by calling getState() on store. Keep it in a variable preloadedState.
4. Return the content and preloadedState. We will pass these to our template to get the final HTML page.

2. src/template.js

template.js exports a function. It takes title, state and content as input. It injects them into the template and returns the final HTML document.

To pass along the state, the template attaches state to window.__STATE__ inside a <script> tag.

Now you can read state on the client side by accessing window.__STATE__.

We also include the SSR companion assets/client.js client-side application in another script tag.

If you request the pure client version, it only puts assets/bundle.js inside the script tag.

The Client Side

The client side is pretty straightforward.

1. src/bundle.js

This is how you write the React and Redux Provider wrap. It is our pure client-side app. No tricks here.

import React from 'react';
import { render } from 'react-dom';
import { Provider } from 'react-redux';
import configureStore from './redux/configureStore';
import App from './components/app';

const store = configureStore();
render(
  <Provider store={store} > <App /> </Provider>,
  document.querySelector('#app')
);

2. src/client.js

Looks familiar? Yeah, there is nothing special except window.__STATE__. All we need to do is grab the initial state from window.__STATE__ and pass it to our configureStore() function as the initial state.

Let’s take a look at our new client file:

import React from 'react';
import { hydrate } from 'react-dom';
import { Provider } from 'react-redux';
import configureStore from './redux/configureStore';
import App from './components/app';

const state = window.__STATE__;
delete window.__STATE__;
const store = configureStore(state);
hydrate(
  <Provider store={store} > <App /> </Provider>,
  document.querySelector('#app')
);

Let’s review the changes:

1. Replace render() with hydrate(). [hydrate()](https://reactjs.org/docs/react-dom.html#hydrate) is the same as render() but is used to hydrate elements rendered by [ReactDOMServer](https://reactjs.org/docs/react-dom-server.html). It ensures that the content is the same on the server and the client.
2. Read the state from the global window object window.__STATE__. Store it in a variable and delete the window.__STATE__.
3. Create a fresh store with state as initialState.

All done here.

Putting it all together

Index.js

This is the entry point of our application. It handles requests and templating.

It also declares an initialState variable. I have modelled it with data in the assets/data.json file. We will pass it to our ssr() function.

Note: While referencing a file that is inside src/ from a file outside src/ , use normal require() and replace src/ by views/. You know the reason (Babel compile).

Routing

1. /: By default server-rendered homepage.
2. /client: Pure client-side rendering example.
3. /exit: Server stop button. Only available in development.

Build & Run

It’s time to build and run our application. We can do this with a single line of code.

npm run build && npm run start

Now, the application is running at http://localhost:3000.

Ready to become a React Pro?

I am starting a new series from next Monday to get your React skills blazing, immediately.

subscription link below ?

Thank you for reading this.

If you like it and find it useful, follow me on Twitter & Webflow.

Here the web app install banner is focused on web app, with the feature of add to homescreen.

Browser Support for Add To Homescreen

Add to Homescreen functionality is currently supported by:

• Chrome
• iOS Safari

You can see the latest status of browser support of this feature here.

On Android

On Android, the “add to homescreen” banner comes up automatically if you meet certain requirements. This is what it should look like on Android:

Add to homescreen promptWhen app launched

Requirements

include a manifest.json file with the following properties:

• short name
• name
• 192x192 size of png icon
• start_url
• include a service worker that is both registered and activated
• the website served over HTTPS (you can still try this with localhost without HTTPS)
• the website meets engagement heuristics defined by Chrome

manifest.json

{
  "name": "FreeCodeCamp",
  "short_name": "FreeCodeCamp",
  "theme_color": "#00FF00",
  "background_color": "#00FF00",
  "display": "standalone",
  "Scope": "/",
  "start_url": "/",
  "icons": [
    {
      "src": "assets/images/icons/icon-72x72.png",
      "sizes": "72x72",
      "type": "image/png"
    },
    {
      "src": "assets/images/icons/icon-96x96.png",
      "sizes": "96x96",
      "type": "image/png"
    },
    {
      "src": "assets/images/icons/icon-128x128.png",
      "sizes": "128x128",
      "type": "image/png"
    },
    {
      "src": "assets/images/icons/icon-144x144.png",
      "sizes": "144x144",
      "type": "image/png"
    },
    {
      "src": "assets/images/icons/icon-152x152.png",
      "sizes": "152x152",
      "type": "image/png"
    },
    {
      "src": "assets/images/icons/icon-192x192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "assets/images/icons/icon-384x384.png",
      "sizes": "384x384",
      "type": "image/png"
    },
    {
      "src": "assets/images/icons/icon-512x512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ],
  "splash_pages": null
}

• name is the name of the web app. (It will be shown in the launch screen)
• short name is the short name of the web app. (It will be shown below the icon of phone menu)
• theme_color is the color of the top of the browser.
• background_color is the background color of the launch screen.
• display is the way the web app should display once launched on the phone.
• start_url define the starting url of the website.
• icons is an array that store all the images location, sizes and type.

On other devices

Although this method does not work on iOS and Windows, there is a fallback method.

iOS

On iOS, the “add to homescreen” button must be added manually. Add the following meta tags to the head section of your HTML to support iOS web app icon.

<meta name="apple-mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-status-bar-style" content="green">
<meta name="apple-mobile-web-app-title" content="FreeCodeCamp">
<link rel="apple-touch-icon" href="/assets/images/icons/icon-72x72.png" sizes="72x72">
<link rel="apple-touch-icon" href="/assets/images/icons/icon-96x96.png" sizes="96x96">
<link rel="apple-touch-icon" href="/assets/images/icons/icon-128x128.png" sizes="128x128">
<link rel="apple-touch-icon" href="/assets/images/icons/icon-144x144.png" sizes="144x144">
<link rel="apple-touch-icon" href="/assets/images/icons/icon-152x152.png" sizes="152x152">
<link rel="apple-touch-icon" href="/assets/images/icons/icon-192x192.png" sizes="192x192">
<link rel="apple-touch-icon" href="/assets/images/icons/icon-384x384.png" sizes="384x384">
<link rel="apple-touch-icon" href="/assets/images/icons/icon-512x512.png" sizes="512x512">

Windows

On windows phone, add the following meta tags to the head section of your HTML:

<meta name="msapplication-TileImage" content="/assets/images/icons/icon-144x144.png">
<meta name="msapplication-TileColor" content="green">

My inbox has been filled with questions regarding PWAs after my last two articles.

My “Practical Tips on Progressive Web App Development” shared the actual advantages of the PWA technology, and my “Progressive Web Apps vs Native” further strengthened many people's belief that a progressive web app is exactly what they need.

I am exceptionally happy that I managed to convince them that PWAs are the future of web apps. I support the PWA technology as a path that the software development industry should take in the future. But progressive web apps are not a panacea, not a one-size-fits-all solution.

Since I have already explained what PWA means and why you need a PWA, today, I am going to finish the job and show why you may NOT need a PWA.

Making the choice between using and not using PWA is easier than you assume. Just answer four simple questions and you will see the right path yourself.

1. Do you have any ready-made developments?

The speed and simplicity of the progressive web app development have been mentioned among the major benefits of PWAs. However, this advantage can be negated by the fact that you already have some ready-made developments for a mobile app.

Converting a ready-made mobile app to a progressive web app cannot be done with a few simple clicks. Instead, a progressive web app has to be developed from scratch. If you had already gone through the lengthy and complicated process of native app development, why would you throw it out and start everything from the beginning?

Surely, your mobile app can be outdated or inefficient. In this case, you have to choose whether to revive it with the help of a mobile app development company or to build an entirely new application using the PWA technology.

For instance, Pinterest – one of the brightest examples of companies that implemented PWA – decided to choose both options. They have developed a progressive web app but did not forget about the traditional mobile application either.

Key idea: The PWA approach is a great solution if you have no ready-made developments. If you already have a native or cross-platform mobile version of your app, it will be easier and more productive to finish those rather than build a new application from scratch.

2. Do you plan to focus on mobile devices only?

The idea of PWA features is to improve the experience of a user accessing a web page from a mobile device. Until the PWA technology was introduced, the businesses willing to target both web and mobile had two options:

• to adapt a web page to mobile devices
• to develop a mobile app from scratch

The first option is clumsy and inconvenient from the perspective of a user. The second option is resource-consuming from the perspective of a business.

The advancement of PWAs brought the Golden Mean: convenience for the user and efficiency for the business. If you do not plan to enter the web or desktop niche but choose to focus solely on mobile apps, there is no need to build a PWA.

Surely, when developing progressive web apps, you win because you're developing one application for both Android and iOS. However, this is exactly what you can achieve with cross-platform development with Ionic, Cordova, or React Native.

Meanwhile, Pinterest has developed a progressive web app to augment their already existent web platform and mobile app.

Key idea: PWAs work best for the businesses targeting both web and mobile platforms. If you choose to focus on only one of those, there is no reason to choose progressive web app development.

3. Are you reluctant to let your users access the app via a web browser?

Another essential difference between mobile apps and progressive web apps rests in the fact that the former are downloaded from the store, while the latter – via a shared link or directly from a website as it is illustrated below.

Tastes differ. If you think that working with App Store or Google Play is easier than fighting the SEO competition on Google or inspiring users to share your links, you should feel free to choose mobile app development.

If you think that it is more difficult to be featured in top search results in Stores comparing to Google search results, go with PWA. Besides, if your website already has a sufficiently large target audience of devoted users, progressive web apps would work best for you.

Key idea: If you want your users to access the application via the App Store or Google Play rather than through a browser, or if app store optimization (ASO) sounds simpler than search engine optimization (SEO), you should go with a mobile app.

4. Do you need advanced mobile device features?

While PWAs can work with geolocation, a lot of advanced mobile device features remain beyond their reach. Progressive web apps do not work with proximity sensors, advanced camera controls, audio or video recording, fingerprint scanning, NFC, or even Bluetooth.

Ask your development team for the PWA checklist of features that they will not be able to implement. If you cannot do without at least one of these features, you should opt in favor of mobile development.

For instance, the progressive web app of Pinterest does not feature the function of taking photos, which is present in their mobile app.

Key idea: Incompatibility with native device features can hinder you from developing a PWA. While this issue may be solved in the future, for now, you should go with mobile apps instead.

To Wrap Up

Before asking for a PWA, you need to decide whether you really need the PWA approach. Start by answering four simple questions:

1. Do you have any ready-made developments, such as a native mobile app?
2. Do you want to focus on mobile devices only? No desktop or web platforms?
3. Are you reluctant to let your users access the app via a web browser?
4. Do you need advanced mobile device features? Are you going to use fingerprint scanning, NFC, or Bluetooth?

If you answer "yes" to the majority of these questions about progressive web apps, then, probably, you do not need a progressive web app. A mobile app will fully cover all your needs.

Do you have an idea for a PWA?

My company KeenEthics is an experienced progressive web app development company. In case you need the following services, feel free to get in touch.

You can read more of my articles on the KeenEthics blog: Four Questions to Understand If You Need PWA.

P.S.

Also, I would like to say "thank you" to Tetiana Matviiok for helping me edit this article.

The original article posted on KeenEthics blog can be found here: Progressive Web Apps vs Native: Which to Choose and When?.

And the development of traditional mobile apps is costly and time-consuming, while the user experience is slow and tangled.

To solve these issues and to provide optimal business opportunities and user experience, Progressive Web Apps enter the game. What is PWA technology? Why does progressive web application development constitute the future? What does a progressive web app development company do? We will answer all of these questions in this article.

What Are Progressive Web Applications?

In the simplest terms, a progressive web app is a website made to resemble an application installed on your smartphone, laptop, tablet, or desktop.

PWA development is a set of optimal software development practices aimed at making a web application function similarly to a mobile or desktop app. Similarly to a mobile application, PWAs send push notifications and have an icon on the home screen. At the same time, progressive web applications are simpler and faster than traditional mobile apps, and they can be shared through a URL.

Progressive web app developers optimize web applications since they provide app-like navigation and excellent visual content. This is implemented with the help of javascript files, called service workers, which enable offline execution of the app and offline information storage.

PWA development helps the developers and businesses bridge the gap between web and native experiences, which sometimes results in time-consuming, discouraging, or unreliable user experience.

A progressive web app development company understands that having to look for an app in the store is too much effort for modern-day users. People strive to save their time and effort and, at the same time, to find the most effective solutions. Therefore, PWA technology is applied to enable users to access a native-like mobile version of their favorite website with a single tap.

Progressive web app development companies employ the most recent web technology aimed at delivering the most amazing web experience to the user. By boosting the performance, accessibility, and user engagement, progressive web app developers ensure that these apps are fast, engaging, and reliable.

What Are the Benefits of Progressive Web Applications?

1. Speed of lightning: A progressive web app development company makes the application load faster than a regular website, which is pivotal for an excellent user experience.
2. Simplicity and perfection: A progressive web application may be installed easily and quickly with a few taps without leaving the webpage or opening the store.
3. Universality: Progressive web apps are compatible with all devices and platforms, namely Windows, MacOS, Linux, and Chrome OS.
4. Personal touch: PWA developers make sure that their apps are more personalized than regular mobile apps, which greatly boosts customer engagement and loyalty.
5. Striking balance: PWAs help to increase organic traffic and to decrease bounce rate.
6. No more Downasaur: By using cached data from the earlier online activities, progressive web app development company makes their applications able to perfectly work without access to the Internet.

The greatest benefit of a progressive web app is the ability to work offline and the absence of all the bars and buttons that a mobile browser has.

_Se_rgey Gornostaev, Full-Stack Developer

Not only progressive web applications are more convenient for the user, but also they are cheaper and faster to develop for the business. In fact, PWA developers have no need to write separate codes for different platforms, which greatly limits the overall cost of the final product and the time spent on its development. Also, since PWAs are installed from the website itself, developers do not need to mess with deploying the app to the app store, following all the requirements on design or logic of the app, improving the visibility of the app, etc. Such an app is offered only on the website itself, which spares users the feeling that it is a one-time install-click-and-delete app from the store.

What Are the Drawbacks of Progressive Web Applications?

1. Decentralized search: A user cannot just enter the app store and find the necessary app or stumble upon a random one. Either users know what they want or they are not likely to find it.
2. Bad news for Apple Lovers: While Microsoft and Google work to develop and encourage the development of PWAs, Apple does not seem very eager to play by their rules. Even though Safari already supports PWAs, the functionality is limited, and the users are unable to experience all the benefits of this technology.
3. Isolation: Different PWAs cannot share resources or data among themselves because they are highly separated.

Why Is PWA Development the Future?

Progressive app development is strongly patronized by Google Inc., which believes PWA development to be the future of software. According to Google articles, with progressive web apps, AliExpress has boosted the conversion rate for its new users by 104% and increased average time spent per session by about 74%.

PWA developers helped a Saudi retailer of electronics eXtra Electronics generate 100% more sales and to attract new users via web push notifications, which are also the part of a progressive web app.

Similarly, an American retailer 5miles has increased conversions by 60% and decreased bounce rate by 50%. Also, with the help of a PWA development company, a Nigerian e-commerce platform Konga has cut data usage by about 92%. A progressive web app is also actively used by The Washington Post, and it has enabled them to decrease page loading time by ten times.

Today, PWAs are already actively used by such user-favorite social networking platforms as Twitter, Instagram, Telegram, Pinterest, and Tinder. Three.js – a popular 3D model editor – is also available as a PWA. Taxi services Uber and Lyft also offer PWAs for their customers.

Progressive web apps can also be used to make games more enjoyable as in the case of 2048 or BreakLock. PWAs are also employed by such a well-known entertainment platform as 9GAG, a coffee retailer Starbucks, or a popular service Google Maps.

PWAs are equally loved by Google and Microsoft as both companies recognize great potential in this technology. It is rumored, however, that Microsoft has immense hopes for progressive web apps as it plans to reenter the smartphone market with its innovative Andromeda device. While the launch of this foldable smartphone is scheduled for late 2019, it is generally believed that Microsoft will bet not only on the revolutionary hardware solution but also on all-PWA software for the updated OS.

And yet, the niche is still almost free, and as of March 2019, there were only 32 PWAs published on Windows 10 Store. To compare, at the end of 2018, this very store featured about 700,000 regular apps. More than that, as of now, there are no PWAs for smart TVs or any other IoT devices, which yet could greatly benefit from such a technology. Therefore, progressive web apps are a perfect choice for those who want to make their business unique, to impress the customer, and to pioneer in such a promising field.

As long as mobile devices are gradually overtaking desktops, PWA is a perfect opportunity for a business to broaden its circle of influence and to take a firm position online. At the same time, one can greatly save on the development and maintenance of the app.

Anton Morya, Full-Stack Software Developer

What Does a Progressive Web App Development Company Do?

As in the case of mobile or web software, progressive web app developers start with the discovery stage, prototyping, POC, or MVP. After that, the PWA team should create a responsive design, which will look perfect at any platform and any device. The progressive app development process itself should be tailored to the needs of a specific business, and PWA developers should be fully aware of customer needs and interests. The product has to be continuously tested by a progressive web app development company in order to fix mistakes and prevent further errors from occurring.

If the business already has a website and wants to adapt it to the PWA technology, the progressive web app development company should provide a well-detailed and properly planned migration strategy.

A PWA development company may also offer SEO services to make sure that the website and, respectively, the progressive web application are easily searchable. An SEO-friendly PWA can considerably boost web-traffic and conversion rates.

After the progressive web application development is over and the final product is launched, a reliable PWA development company offers its customers a team of PWA developers for continuous support and maintenance.

Do you have an idea for a PWA?

My company KeenEthics is an experienced progressive web app development company. In case you need the following services, feel free to get in touch.

The original article posted on KeenEthics blog can be found here: Practical Tips on Progressive Web App Development.

P.S.

I would like to say thank you to everyone who contributed to this article including Sergey Gornostaev and Anton Moriia, full-stack software developers @ Keenethics, as well as Tetiana Matviiok, content manager @ KeenEthics.

The original article posted on KeenEthics blog can be found here: Practical Tips on Progressive Web App Development.

We all learn about web accessibility at different points in our career. That means a lot of time you are not on the same page as your teammates. I had the privilege a couple of months ago to speak at Pingboard about accessibility. Our goal was to get the whole team at the same knowledge starting point. If we all have a basic understanding of whom web accessibility affects and how it affects them, we can ship better experiences.

You probably find yourself in the same opportunity at your company to present on accessibility. So I would like to do two things to help: I am going to give you my presentation as a starting point and walk you through the points I like to touch on.

You probably find yourself in the same opportunity at your company to present on accessibility. …I am going to give you my presentation as a starting point and walk you through the points I like to touch on.

Remind the team that you are talking about real people.

When we read accessibility documentation, it is easy to forget the human element. It makes sense because you are reading technical docs meant to influence code. It is great to start with this shared definition:

A person with a disability: A person who has a physical or mental impairment that substantially limits one or more major life activity.

We use this to establish friendly dialog. People do not want to be called “disabled”. They want to be called their name. We also need to clarify how wide of a range disabilities can be. Try expanding past assumptions early on with these points:

• Some disabilities come at birth, some come later.
• Some disabilities are permanent, some are temporary.
• Some disabilities always affect, some come and go.
• Some disabilities are visible, some are invisible.

Go over some disability categories with emotional experiences and quick tips.

Now that we have established that we are talking about people, it is time to talk about their experiences. I like to mix this section with quick tips for common disability categories. Remind your audience that there are way more disabilities than you are covering. They are difficult to categorize, which is why the technical documentation focuses on the solutions.

Something you will notice about the presentation is that there is a lot of video and audio. I find it more effective to have those with disabilities speak more than me about the issue. The multimedia in the presentation makes it possible for those people to not even have to be there.

Visual

I love to share this video of Tommy Edison using a screenreader because he keeps things lighthearted, but also goes through the whole process of sending an email. After the video, you can point out that fellow Mac users can try their screenreader with CMD + F5 at anytime.

Quick tips:

• People with dyslexia prefer to override font settings.
• People with low vision need to be able to zoom correctly.
• People with color blindness need an overall color contrast ratio of 4.5:1. Text 19px or larger can have a ratio of 3:1.
• People with color blindness need labels and patterns for differentiations.

Auditory and Seizure

Auditory disabilities are easier to talk about with digital product teams. Remind your team that all audio should be paired with visual cues and captions. Encourage the team to do content audits to check all videos for closed captioning.

Strobing, flickering, and flashing can trigger seizures. Other triggers include animations longer than 250ms, parallax, and images moving under text.

Motor

There are two demos I like to show teammates when it comes to motor disabilities. The first is hidden inside a longer video. A fellow named Gordin Richins shows what it is like to use a mouth stick. It is an older video, but I try to point out that new technologies can be more expensive.

The second video is a wholesome video of an eye tracking product. These are great because they can provide mouse capabilities to those with motor disabilities. However, we should still make all experiences keyboard accessible to be safe.

Cognitive

Cognitive disabilities can be difficult to convey. For this last category, I stuck with quick tips to keep the presentation alternative between facts and emotion. Here are the quick tips I share:

• For memory, keep processes short and remind users of context as much as possible.
• For problem-solving, error messages should be as explanatory as possible.
• For attention, use visual cues to highlight the most important points or sections of content.
• For reading, linguistic, and verbal comprehension, provide supplemental media that helps processes.

Emphasize how common disabilities actually are.

Did you know that one out of five people in the US have at least a one disability? (source) It may not seem like that in the workplace, but we should consider why. This is the point of the presentation when people should understand invisible disabilities. Invisible disabilities can be hidden from the naked eye. Here is a great interview where Carly Medosch talks about working with an invisible disability:

NPR: People with 'Invisible Disabilities' Fight for Understanding

This story is a great transition to a big question: What can we as enterprise software teams do to help those with disabilities?

Well, 79% of people of a working age in the US have employment. Only 41% of people of a working age in the US that have disabilities have employment. (source) If more jobs were accessible, that gap would close. This means that we as enterprise software teams can make it our mission to close the gap!

End with the legal risk for those that need extrinsic motivation.

It may not feel great, but some people may still need more reasoning about why the team should work towards accessible experiences. This is why I like to close the presentation on the legal implications of accessibility.

ADA Title 3 lawsuits in federal court: 2722 in 2013, 4436 in 2014, 4789 in 2015, 6601 in 2016, 7663 in 2017, 10163 in 2018. https://www.adatitleiii.com/2019/01/number-of-ada-title-iii-lawsuits-filed-in-2018-tops-10000/

In 1990, the Americans with Disabilities Act was signed. This provides those with disabilities the same protection that’s given in the Civil Rights Act of 1964. Section 508 says digital experiences in government departments and agencies have accessibility requirements.

Lawsuits continue to grow saying that the ADA also covers digital experiences from any company. Over 10,000 lawsuits were filed in 2018 alone. In fact, one of those cases is headed towards supreme court.

Be a part of the good fight.

Are you considering presenting to your team on web accessibility? You really should. You don’t have to be an expert and it’s okay if not everyone listens to you. Every effort to make the web a more friendly place is worth it.

I hope these resources helped you shape a future presentation. Please steal everything from me (but keep the citations).

If you appreciate this, please consider voting for my SXSW talk idea. I want to teach product managers, designers, and everyone else about progressive web apps. The cool thing about PWAs, is that a lot of accessibility criteria is baked in! If you wanna learn more, check out the video below.

Please take minute to vote for my talk and share it with others.

Got any other good resources for accessibility presentations? Please share them in the comments or tweet me them at @seejamescode. I will retweet the best ones!

A carousel, slideshow, or slider — however you call it this class of UI — has become one of the core elements used in modern web development. Today, it’s almost impossible to find any Website or UI library which doesn’t come with one or another kind of carousel.

Why, though? In fact, carousels really deserve their popularity. They allow users to skim through available content without vertical scrolling or heavy mouse movements. Consequently, users save time and can focus on the displayed content as Carousels keep cognitive load to a minimum.

This is reason enough to learn how to build a Carousel in VueJS!

All my tutorials gravitate around Progressive Vue Apps. This one is no exception! Making progressive apps means delivering a UX for mobile users close to native apps, including excellent performance, native features like push notifications, offline experience and much more. In a world where the majority of users experience the Web via mobile devices, there is no excuse left to not build progressive apps!

Of course you can still use the Carousel in any Vue app. You also don’t need any prior experience with VueJS or Progressive Web Apps for this tutorial!

You find the full code here:

https://github.com/fh48/vue-pwa-carousel

What’s our Vision for the Carousel?

First thing we will do is to get an overview over what kind of components we want to build.

There are a few very straightforward ones:

• Card → it holds the information of each carousel element.
• Carousel → parent which holds all logic
• ArrowButton → helps to navigate between multiple cards.
• Indicator → shows the number of cards and which is currently visible.

Initial Setup

If you want to learn how to set up a project, this section is for you. In case you do not, just continue with the next section.

vue init pwa vue-pwa-carousel

We will be prompted to pick a preset — I recommend the following configuration:

? Project name vue-pwa-carousel? Project short name: fewer than 12 characters to not be truncated on homescreens (default: same as name) vue-pwa-carousel? Project description A simple tax calculator ? Author Fabian Hinsenkamp? Vue build runtime? Install vue-router? No? Use ESLint to lint your code? No? Pick an ESLint preset Standard? Setup unit tests with Karma + Mocha? No? Setup e2e tests with Nightwatch? No

Run yarn in the root folder of the project to install all dependencies. Now we have a project set-up which includes the basic technologies we need to build our carousel. Moreover, it already includes a Service Worker which pre-caches all our static files and allows users to access the app even when they are offline.

You can check out how the template app looks like by running yarn start.

To test how the carousel looks on mobile, we need to expose our development build to mobile devices through a public URL. There are many ways to do so, but here we use ngrok as it’s easy to set up and just does its job.

yarn global add ngrok

Next, we need to run our dev server and ngrok in two separate terminals.

Let’s build the Card!

To save you some boring adjustments to the template app, just check out this branch00_basicSetup. It includes all data and styles we need to make this app meaningful and pretty.

The Card really does one thing: it shows the currently selected data. Which is, in our case, an image, a headline and some text.

Clearly, we do not want to build multiple cards with hard-coded content. Instead, we want to dynamically pass the data to the card and simply render it.

Based on that knowledge, we can now create our Card.vue file in the src/components folder. Moreover, we can already define the basic html structure and names and their types of the properties we want to pass to the card.

Attention: we store all icons we want to display locally in our assets folder. That means that our path remains the same, but we need to dynamically change the file names which are supposed to be rendered. Consequently, all properties are of type String.

Next, we make the Card render the headline and the related text. Therefore, we use the most basic way of data-binding within VueJS — the mustache tag.

It’s basically just curly braces around our prop variables. As soon as data comes in, {{headline}} and {{text}} will be replace with the related data object. This is always true, also when new data comes in, after is has rendered other data before.

Rendering the image dynamically is a bit more tricky. Remember, we do not pass the actual icon but only its file name.

So we basically want to consume the image as a module, like any other component. A static image we could consume by importing it in the script block and assign it to a variable. However, we do have changing path. As our app uses webpack there is a fantastic shorthand available to load these dynamically as follows:

:src="require(`@/assets/svg/${imgName}`)"

The : syntax is the Vue-way to dynamically bind attributes to an expression. You might already have seen the v-bind: prefix which : is the shorthand for.

Now our template block is completed and looks as follows.

To finalise our Card component, we simply need to add the prepared styled to the bottom of the file.

<style src="../assets/styles/Card.css" scoped>

Last thing we need to do for this section is to check if the Card actually works.

So let’s simply add it the our App.vue component. However, keep in mind that we will have to move the component into the Carousel component in the next section.

We add the following to the <template>; and &lt;script>; blocks of App.vue.

What a fantastic result! Especially, since we can already dynamically change whatever the Card should display!

Next, we build the Carousel to have a dedicated component to manage all logic around showing different Cards based on user inputs.

Check out the branch 01_Card to if you want to start from here or compare your implementation.

Let’s build the Carousel

The Carousel will be our reusable parent component. It will encapsulate all relevant components and logic.

Like with the Card before, we should focus on building the component in a way that it can handle a change in data gracefully. For example, it should be capable of handling varying numbers of cards being passed to it.

Next we will see how this approach translates into Code. First we start with creating a Carousel component and make the Card a child of Carousel.

The template block of the new component hosts the Card, wrapped in two wrapper elements. We will see later why these are necessary.

As we will pass data of multiple Cards to the Carousel, we need to specify that only the currentElement is rendered.

In the following <script> block we need to define which of the passed Cards is the currentElement by default.

Therefore, we define the currentElementIndex initially to be 0. VueJS comes with a feature that allows us to compute variables dynamically. We use it to select the data of the card that should render initially.

Now we only need to replace the Card with the Carousel in our App.vue file. To put a bit more structure and meaning to our final page, let’s wrap the carousel in another section element and place it before the other section.

That’s our basic implementation. It is not quite a Carousel yet but we are about to change this by adding the arrow buttons to switch between the objects we pass in the cards array to our Carousel.

Check out the 02_Carousel to see the complete code for this section. If you coded along you should see the following in front of you.

Let’s build the ArrowButton

Now we build the ArrowButton component, which receives its methods and the type of arrow icon from its parent. The implementation itself is strait forward.

The component is only responsible for rendering the correct styles and the icon. All logic related to the Buttons is added to the Carousel. That way, we have created a truly generic component we could use in any context where we want to use a button with an arrow icon.

Now, within Carousel, we add two methods to navigate between our card data objects. Methods are just another exported object within the <script> block.

These simply increase or decrease the currentElementIndex by 1. We use the index to compute the currentElement variable, so every time one of the methods is called the next card is displayed. We also add some restrictive conditions, as we want the Carousel not to loop.

Now we only need to add the ArrowButtons to basically complete our Carousel!

Here you see how we use the methods and computed values to implement one of our ArrowButtons. Try to implement the second one below the Card component.

In case you get stuck or something just looks wrong, checkout the 03_ArrowButton branch. If everything worked out though, your carousel should look like the following:

Let’s build Indicators!

The last feature we’re going to add are the Indicators. These help users to understand how many Cards there are and which one they are currently looking at. Additionally, these allow the user to select individual Cards directly.

The component receives three properties. The array of elements we use to create a <_l_i> element for each card data object.

currentElementIndex is required to add a CSS class that highlights the indicator related to the current card. Moreover, it is used to disable the button for the current card. That way we prevent it from being selectable is via the tab keys. That way, we provide at least a minimum of accessibility.

showElement is the method which is called when a user clicks on an indicator. It’s passed from outside to keep the component as focused as possible. How an element is shown is clearly no concern of Indicators.

When we add the Indicators to Carousel.vue it becomes clear why we created two wrappers for the Card. Semantic and clear HTML is vital, especially for large projects with a high level of complexity.

You can check out the complete code at branch 04_Indicators.

Let’s add swipe

Last but not least, we make our Carousel mobile friendly. A good progressive web app doesn’t start by caching static files, but with responsiveness.

As we do lack space on small screens, we hide the ArrowButtons and allow users to swipe in order to browse the Cards. Here the Indicators also do pay off again, as they function in mobile as the main indicator that users can swipe to see more cards.

Therefore we add the following library:

yarn add vue2-touch-events

Next we add the new v-touch attribute and a handler method to the Card. This takes care of the events emitted by swipes.

Conclusion

Fantastic, we made it! We had the vision of building an encapsulated and reusable Carousel component, and we did!

What we still could add to improve the UX are some swipe animation when browsing the cards.

Thanks for reading! _If you like this blog post, Follow me on Twitter @Fa_Hinse and_ please clap?

Have you thought about making modern JavaScript applications with the simplest setup possible for your next project?

If so, you have come to the right place!

JavaScript frameworks exist to help us build applications in a generalized way with most of the common features. But most of the applications may not need all the powerful features of a framework. It may be overkill to just use a framework for specific requirements (especially small to medium scale projects).

Today I am going to show an approach to how you can use modern features and build your own customized Web Applications. You can also build your own framework on top of the sample applications if you want to. That is purely optional. The power of Vanilla JavaScript enables us to follow our own coding style irrespective of the tools used.

What We Need

Before starting out, let us quickly skim through the features we need.

Architectural Planning

To ensure fast loading and consistent experiences, we’ll use the following patterns:

• Application Shell Architecture
• PRPL (Push, Render, Pre-cache, Lazy loading) pattern

Build Setup

We need a good custom build setup, so we will be using Webpack with the following requirements:

• ES6 & Dynamic Imports support
• SASS & CSS support
• Custom development & production setup
• Custom Service Worker Build

Bare Minimum JavaScript Features

We will be touching on minimal JavaScript features to get us off the ground and produce the output we require. I will show you how we can use existing JavaScript ES6 features in our day to day vanilla applications. Here they are:

• ES6 Modules
• Dynamic Imports
• Object Literal Syntax Or ES6 Class Syntax
• ES6 Arrow Functions
• ES6 Template Literals

At the end of this article there is a sample application demo along with its source code on GitHub. Let’s dig deeper, shall we? ?

Architectural Planning

The advent of Progressive Web Applications has helped bring new architectures in order to make our first paint more effective. Combining App Shell and PRPL patterns can result in consistent responsiveness and app-like experiences.

What is App Shell & PRPL?

App Shell is an architectural pattern for building Progressive Web Applications where you ship the minimal critical resources in order to load your site. This basically consists of all the necessary resources for the first paint. You may cache the critical resources as well using a service worker.

PRPL refers to the following:

• Push critical resources (especially using HTTP/2) for the initial route.
• Render the initial route.
• Pre-cache remaining routes or assets.
• Lazy load portions of an application as and when required (especially when required by a user).

What Do These Architectures Look Like In Code?

The App Shell and PRPL pattern are both used together to achieve the best practices.

The App shell looks somewhat like the following piece of code:

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta http-equiv="X-UA-Compatible" content="ie=edge" />
    <!-- Critical Styles -->
    <style>
        html {
            box-sizing: border-box;
        }

        *,
        *:after,
        *:before {
            box-sizing: inherit;
        }

        body {
            margin: 0;
            padding: 0;
            font: 18px 'Oxygen', Helvetica;
            background: #ececec;
        }

        header {
            height: 60px;
            background: #512DA8;
            color: #fff;
            display: flex;
            align-items: center;
            padding: 0 40px;
            box-shadow: 1px 2px 6px 0px #777;
        }

        h1 {
            margin: 0;
        }

        .banner {
            text-decoration: none;
            color: #fff;
            cursor: pointer;
        }

        main {
            display: flex;
            justify-content: center;
            height: calc(100vh - 140px);
            padding: 20px 40px;
            overflow-y: auto;
        }

        button {
            background: #512DA8;
            border: 2px solid #512DA8;
            cursor: pointer;
            box-shadow: 1px 1px 3px 0px #777;
            color: #fff;
            padding: 10px 15px;
            border-radius: 20px;
        }

        .button {
            display: flex;
            justify-content: center;
        }

        button:hover {
            box-shadow: none;
        }

        footer {
            height: 40px;
            background: #2d3850;
            color: #fff;
            display: flex;
            align-items: center;
            padding: 40px;
        }
    </style>
    <title>Vanilla Todos PWA</title>
</head>

<body>

    <body>
        <!-- Main Application Section -->
        <header>
            <h3><a class="banner"> Vanilla Todos PWA </a></h3>
        </header>
        <main id="app"></main>
        <footer>
            <span>&copy; 2019 Anurag Majumdar - Vanilla Todos SPA</span>
        </footer>

        <!-- Critical Scripts -->
        <script async src="<%= htmlWebpackPlugin.files.chunks.main.entry %>"></script>

        <noscript>
            This site uses JavaScript. Please enable JavaScript in your browser.
        </noscript>
    </body>
</body>

</html>

You can see that the application shell consists of the bare minimum markup as a skeleton.

Lines 9–82: Critical styles have been introduced into markup to ensure direct parsing of CSS instead of linking it to another file.

Lines 89–96: Main application shell markup; these areas will be later manipulated by JavaScript (especially, the contents inside the main tag of line 93).

Line 99: This is where the scripts come into play. The async attribute helps in not blocking the parser while the scripts get downloaded.

The app shell also enforces Push & Render stages of the PRPL pattern. This happens when HTML is parsed by the browser to form pixels on the screen. It readily finds all the critical resources. Also, the critical scripts are responsible for showing the initial route by DOM manipulation (Render).

However, if we do not use a Service worker to cache the shell, it won’t be of any use for future reloads and performance benefits.

The following code snippet shows a service worker which caches the shell and all the static assets required for the application.

var staticAssetsCacheName = 'todo-assets-v3';
var dynamicCacheName = 'todo-dynamic-v3';

self.addEventListener('install', function (event) {
    self.skipWaiting();
    event.waitUntil(
      caches.open(staticAssetsCacheName).then(function (cache) {
        cache.addAll([
            '/',
            "chunks/todo.d41d8cd98f00b204e980.js","index.html","main.d41d8cd98f00b204e980.js"
        ]
        );
      }).catch((error) => {
        console.log('Error caching static assets:', error);
      })
    );
  });

  self.addEventListener('activate', function (event) {
    if (self.clients && clients.claim) {
      clients.claim();
    }
    event.waitUntil(
      caches.keys().then(function (cacheNames) {
        return Promise.all(
          cacheNames.filter(function (cacheName) {
            return (cacheName.startsWith('todo-')) && cacheName !== staticAssetsCacheName;
          })
          .map(function (cacheName) {
            return caches.delete(cacheName);
          })
        ).catch((error) => {
            console.log('Some error occurred while removing existing cache:', error);
        });
      }).catch((error) => {
        console.log('Some error occurred while removing existing cache:', error);
    }));
  });

  self.addEventListener('fetch', (event) => {
    event.respondWith(
      caches.match(event.request).then((response) => {
        return response || fetch(event.request)
          .then((fetchResponse) => {
              return cacheDynamicRequestData(dynamicCacheName, event.request.url, fetchResponse.clone());
          }).catch((error) => {
            console.log(error);
          });
      }).catch((error) => {
        console.log(error);
      })
    );
  });

  function cacheDynamicRequestData(dynamicCacheName, url, fetchResponse) {
    return caches.open(dynamicCacheName)
      .then((cache) => {
        cache.put(url, fetchResponse.clone());
        return fetchResponse;
      }).catch((error) => {
        console.log(error);
      });
  }

Lines 4–17: The install event of service workers helps to cache all the static assets. Here, you can cache the app shell resources (CSS, JavaScript, images, etc.) for the first route (as per App shell). Also, you can cache the remainder of the assets of the application ensuring the whole app can run offline too. This caching of static assets apart from the main app shell ensures the Pre-cache stage of the PRPL pattern.

Lines 19–38: The activate event is the place for cleaning up of unused caches.

Lines 40–63: These lines of code help in fetching resources from the cache if they are in cache or go to network. Also, if a network call is made, then the resource is not in cache and put into a new separate cache. This scenario helps to cache all dynamic data for an application.

All in all, most of the parts of the architecture have been covered. The only part left is the Lazy loading stage of the PRPL pattern. I will discuss this with regards to JavaScript.

Our Build Setup

What is a good architectural structure without a build setup? Webpack to the rescue. There are other tools like Parcel, Rollup etc. out there, but whatever concepts we apply to Webpack can be applied to any such tool.

I will map the concepts used to the plugins so that you can get hold of the basics used for setting up of the workflow. This is the most important step to getting started with a good reusable build config for your own application for the future.

I know how difficult it is for developers like us to configure Webpack or any tool for that matter from scratch. The following article was an inspiration which helped me to create my own build setup:

A tale of Webpack 4 and how to finally configure it in the right way. Updated.

Do refer to the above link if you get stuck anywhere with the build setup. For now let us check out the concepts required for the build.

ES6 & Dynamic Imports support

Babel is a popular transpiler which is there to help us with transpiling ES6 features down to ES5. We will need the following packages to enable babel working with webpack:

• @babel/core
• @babel/plugin-syntax-dynamic-import
• @babel/preset-env
• babel-core
• babel-loader
• babel-preset-env

Here is a sample babelrc for reference:

{
    "presets": ["@babel/preset-env"],
    "plugins": ["@babel/plugin-syntax-dynamic-import"]
}

During babel setup, we need to feed the following 2nd line in presets to enable babel to transpile ES6 down to ES5 and the 3rd line in plugins to enable the dynamic import support with Webpack.

Here is how babel is used with Webpack:

module.exports = {
    entry: {
        // Mention Entry File
    },
    output: {
        // Mention Output Filenames
    },
    module: {
        rules: [
            {
                test: /\.js$/,
                exclude: /node_modules/,
                use: {
                    loader: 'babel-loader'
                }
            }
        ]
    },
    plugins: [
        // Plugins
    ]
};

Lines 10–17: The babel loader is used to set up the babel transpilation process in webpack.config.js. For simplicity, the other parts of the config have been eliminated or commented out.

SASS & CSS Support

For setting up SASS and CSS you need the following packages:

• sass-loader
• css-loader
• style-loader
• MiniCssExtractPlugin

Here is how the config looks like:

module.exports = {
    entry: {
        // Mention Entry File
    },
    output: {
        // Mention Output Filenames
    },
    module: {
        rules: [
            {
                test: /\.js$/,
                exclude: /node_modules/,
                use: {
                    loader: 'babel-loader'
                }
            },
            {
                test: /\.scss$/,
                use: [
                    'style-loader',
                    MiniCssExtractPlugin.loader,
                    'css-loader',
                    'sass-loader'
                ]
            }
        ]
    },
    plugins: [
        new MiniCssExtractPlugin({
            filename: '[name].css'
        }),
    ]
};

Lines 17–25: This is the area where the loaders are registered.

Lines 29–31: Since we are using a plugin to extract a CSS file, we are using the MiniCssExtractPlugin here.

Custom Development & Production Setup

This is the most important section of the build process. We all know that we need a development and production build setup for developing applications and also deploying the final distributable to the web.

Here are the packages that will get used:

• clean-webpack-plugin: For cleanup of the dist folder contents.
• compression-webpack-plugin: For gzipping the dist folder file contents.
• copy-webpack-plugin: For copying static assets, files or resources from application source to dist folder.
• html-webpack-plugin: For creating an index.html file in the dist folder.
• webpack-md5-hash: For hashing application source files in the dist folder.
• webpack-dev-server: For running a local development server.

Here is the final Webpack config file:

const path = require('path');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const WebpackMd5Hash = require('webpack-md5-hash');
const CleanWebpackPlugin = require('clean-webpack-plugin');
const CopyWebpackPlugin = require('copy-webpack-plugin');
const CompressionPlugin = require('compression-webpack-plugin');

module.exports = (env, argv) => ({
    entry: {
        main: './src/main.js'
    },
    devtool: argv.mode === 'production' ? false : 'source-map',
    output: {
        path: path.resolve(__dirname, 'dist'),
        chunkFilename:
            argv.mode === 'production'
                ? 'chunks/[name].[chunkhash].js'
                : 'chunks/[name].js',
        filename:
            argv.mode === 'production' ? '[name].[chunkhash].js' : '[name].js'
    },
    module: {
        rules: [
            {
                test: /\.js$/,
                exclude: /node_modules/,
                use: {
                    loader: 'babel-loader'
                }
            },
            {
                test: /\.scss$/,
                use: [
                    'style-loader',
                    MiniCssExtractPlugin.loader,
                    'css-loader',
                    'sass-loader'
                ]
            }
        ]
    },
    plugins: [
        new CleanWebpackPlugin('dist', {}),
        new MiniCssExtractPlugin({
            filename:
                argv.mode === 'production'
                    ? '[name].[contenthash].css'
                    : '[name].css'
        }),
        new HtmlWebpackPlugin({
            inject: false,
            hash: true,
            template: './index.html',
            filename: 'index.html'
        }),
        new WebpackMd5Hash(),
        new CopyWebpackPlugin([
            // {
            //     from: './src/assets',
            //     to: './assets'
            // },
            // {
            //     from: 'manifest.json',
            //     to: 'manifest.json'
            // }
        ]),
        new CompressionPlugin({
            algorithm: 'gzip'
        })
    ],
    devServer: {
        contentBase: 'dist',
        watchContentBase: true,
        port: 1000
    }
});

Lines 9–77: The entire webpack config is a function which takes two arguments. Here I have used the argv i.e., the arguments sent while running the webpack or webpack-dev-server commands.

The below image shows the scripts section in package.json.

npm scripts in package.json

Accordingly, if we run npm run build it will trigger a production build, and if we run npm run serve it will trigger a development flow with a local development server.

Lines 44–77: These lines show how the plugins and the development server config needs to be setup.

Lines 59–66: These lines are any resources or static assets which need to be copied over from the application source.

Custom Service Worker Build

Since we all know how tedious it is to write the names of all the files again for caching, I made a custom service worker build script for catching hold of the files in the dist folder and then adding them as contents of the cache in the service worker template. Finally, the service worker file will get written to the dist folder.

The concepts regarding the service worker file we talked about will be the same. Here is the script in action:

const glob = require('glob');
const fs = require('fs');

const dest = 'dist/sw.js';
const staticAssetsCacheName = 'todo-assets-v1';
const dynamicCacheName = 'todo-dynamic-v1';

let staticAssetsCacheFiles = glob
    .sync('dist/**/*')
    .map((path) => {
        return path.slice(5);
    })
    .filter((file) => {
        if (/\.gz$/.test(file)) return false;
        if (/sw\.js$/.test(file)) return false;
        if (!/\.+/.test(file)) return false;
        return true;
    });

const stringFileCachesArray = JSON.stringify(staticAssetsCacheFiles);

const serviceWorkerScript = `var staticAssetsCacheName = '${staticAssetsCacheName}';
var dynamicCacheName = '${dynamicCacheName}';
self.addEventListener('install', function (event) {
    self.skipWaiting();
    event.waitUntil(
      caches.open(staticAssetsCacheName).then(function (cache) {
        cache.addAll([
            '/',
            ${stringFileCachesArray.slice(1, stringFileCachesArray.length - 1)}
        ]
        );
      }).catch((error) => {
        console.log('Error caching static assets:', error);
      })
    );
  });
  self.addEventListener('activate', function (event) {
    if (self.clients && clients.claim) {
      clients.claim();
    }
    event.waitUntil(
      caches.keys().then(function (cacheNames) {
        return Promise.all(
          cacheNames.filter(function (cacheName) {
            return (cacheName.startsWith('todo-')) && cacheName !== staticAssetsCacheName;
          })
          .map(function (cacheName) {
            return caches.delete(cacheName);
          })
        ).catch((error) => {
            console.log('Some error occurred while removing existing cache:', error);
        });
      }).catch((error) => {
        console.log('Some error occurred while removing existing cache:', error);
    }));
  });
  self.addEventListener('fetch', (event) => {
    event.respondWith(
      caches.match(event.request).then((response) => {
        return response || fetch(event.request)
          .then((fetchResponse) => {
              return cacheDynamicRequestData(dynamicCacheName, event.request.url, fetchResponse.clone());
          }).catch((error) => {
            console.log(error);
          });
      }).catch((error) => {
        console.log(error);
      })
    );
  });
  function cacheDynamicRequestData(dynamicCacheName, url, fetchResponse) {
    return caches.open(dynamicCacheName)
      .then((cache) => {
        cache.put(url, fetchResponse.clone());
        return fetchResponse;
      }).catch((error) => {
        console.log(error);
      });
  }
`;

fs.writeFile(dest, serviceWorkerScript, function(error) {
    if (error) return;
    console.log('Service Worker Write success');
});

Lines 8–18: This is the place where all the contents of the dist folder are captured as an array staticAssetsCacheFiles.

Lines 22–85: This is the service worker template we talked about before. The concepts are exactly the same, just that we are introducing variables into the template so that we can reuse the service worker template and make it handy for future use. This template was also required since we needed to add dist folder contents to the cache as per line 33.

Lines 87–90: Finally, a new service worker file will get written to the dist folder along with its contents from the service worker template serviceWorkerScript.

The command to run the above script is node build-sw and it should be run after webpack --mode production is done.

This service worker build script really helped me a lot in caching files easily. I am currently using this for my own side projects due to its simplicity and great ease of tackling the caching problem.

If you guys want to use a library for Progressive Web Application related features, you can go for Workbox. This library does some real neat stuff and has amazing features which you can take control of.

Final Look At The Packages

Here is a sample package.json file with all dependencies:

{
  "name": "vanilla-todos-pwa",
  "version": "1.0.0",
  "description": "A simple todo application using ES6 and Webpack",
  "main": "src/main.js",
  "scripts": {
    "build": "webpack --mode production && node build-sw",
    "serve": "webpack-dev-server --mode=development --hot"
  },
  "keywords": [],
  "author": "Anurag Majumdar",
  "license": "MIT",
  "devDependencies": {
    "@babel/core": "^7.2.2",
    "@babel/plugin-syntax-dynamic-import": "^7.2.0",
    "@babel/preset-env": "^7.2.3",
    "autoprefixer": "^9.4.5",
    "babel-core": "^6.26.3",
    "babel-loader": "^8.0.4",
    "babel-preset-env": "^1.7.0",
    "clean-webpack-plugin": "^1.0.0",
    "compression-webpack-plugin": "^2.0.0",
    "copy-webpack-plugin": "^4.6.0",
    "css-loader": "^2.1.0",
    "html-webpack-plugin": "^3.2.0",
    "mini-css-extract-plugin": "^0.5.0",
    "node-sass": "^4.11.0",
    "sass-loader": "^7.1.0",
    "style-loader": "^0.23.1",
    "terser": "^3.14.1",
    "webpack": "^4.28.4",
    "webpack-cli": "^3.2.1",
    "webpack-dev-server": "^3.1.14",
    "webpack-md5-hash": "0.0.6"
  }
}

Remember that Webpack gets updated frequently, and changes keep happening in the community with new plugins replacing existing ones. So it is important to keep a note of the concepts required for a build setup rather than the actual packages used.

JavaScript Features

We all have a choice: either to write our own framework for certain features to be used by our application such as change detection, routing, storage patterns, redux etc, or pull already existing packages for such features.

Now I’ll speak about the bare minimum features required in order to structure the layout of our application and get it going. Later on you can add your own frameworks or packages to the application.

ES6 Modules

We will use ES6 import and export statements and treat each file as an ES6 module. This feature is commonly used by popular frameworks like Angular and React and is pretty handy. With the power of our Webpack config, we can fully utilize the power of import and export statements.

import { appTemplate } from './app.template';
import { AppModel } from './app.model';

export const AppComponent = {
  // App Component code here...
};

Object Literal Syntax Or ES6 Class Syntax

Building components is a very important part of our application. We can choose to go with the latest web standards like Web Components too, but to keep things simple we can go ahead and use object literal syntax or ES6 class syntax.

The only thing with class syntax is that we need to instantiate it and then export it. So to keep things even simpler, I went ahead with object literal syntax for component architecture.

import { appTemplate } from './app.template';
import { AppModel } from './app.model';

export const AppComponent = {

    init() {
        this.appElement = document.querySelector('#app');
        this.initEvents();
        this.render();
    },

    initEvents() {
        this.appElement.addEventListener('click', event => {
            if (event.target.className === 'btn-todo') {
                import( /* webpackChunkName: "todo" */ './todo/todo.module')
                    .then(lazyModule => {
                        lazyModule.TodoModule.init();
                    })
                    .catch(error => 'An error occurred while loading Module');
            }
        });

        document.querySelector('.banner').addEventListener('click', event => {
            event.preventDefault();
            this.render();
        });
    },

    render() {
        this.appElement.innerHTML = appTemplate(AppModel);
    }
};

Lines 4–32: We export an object called AppComponent which is immediately available for use in other parts of our application.

You can go ahead and use ES6 class syntax or standard Web Components too and achieve a more declarative way of writing code here. For simplicity’s sake, I chose to write the demo application in a more imperative approach.

Dynamic Imports

Remember I talked about missing out on the “L” of the PRPL pattern? Dynamic import is the way to go ahead and lazy load our components or modules. Since we used the App Shell and PRPL together to cache the shell and other route assets, dynamic imports import the lazy component or module from the cache instead of the network.

Note that if we only used App Shell architecture, the remaining assets of the application i.e., the contents of chunks folder, would not have been cached.

Lines 15–19: Refer to App Component code; this is the place where dynamic imports shine. If we click on a button having the class btn-todo, then only this TodoModule gets loaded. By the way, TodoModule is just another JavaScript file which consists of a set of object components.

ES6 Arrow Functions & ES6 Template Literals

Arrow functions should be used especially where we want to make sure of the this keyword inside the function, which should refer to the surrounding context where the arrow function is declared. Apart from that, these functions really help in creating neat shorthand syntax.

export const appTemplate = model => `
    <section class="app">
        <h3> ${model.title} </h3>
        <section class="button">
            <button class="btn-todo"> Todo Module </button>
        </section>
    </section>
`;

The above example is a template function defined as an arrow function which accepts a model and returns an HTML string consisting of the model data in it. String interpolation is carried out with the help of ES6 template literals. The real benefit of template literals is multi-line strings and interpolation of model data into the string.

Here’s a micro tip for handling component templating and generation of reusable components: use the reduce function to accumulate all HTML strings as per the following example:

const WorkModel = [
    {
        id: 1,
        src: '',
        alt: '',
        designation: '',
        period: '',
        description: ''
    },
    {
        id: 2,
        src: '',
        alt: '',
        designation: '',
        period: '',
        description: ''
    },
    //...
];


const workCardTemplate = (cardModel) => `
<section id="${cardModel.id}" class="work-card">
    <section class="work__image">
        <img class="work__image-content" type="image/svg+xml" src="${
            cardModel.src
        }" alt="${cardModel.alt}" />
    </section>
    <section class="work__designation">${cardModel.designation}</section>
    <section class="work__period">${cardModel.period}</section>
    <section class="work__content">
        <section class="work__content-text">
            ${cardModel.description}
        </section>
    </section>
</section>
`;

export const workTemplate = (model) => `
<section class="work__section">
    <section class="work-text">
        <header class="header-text">
            <span class="work-text__header"> Work </span>
        </header>
        <section class="work-text__content content-text">
            <p class="work-text__content-para">
                This area signifies work experience
            </p>
        </section>
    </section>
    <section class="work-cards">
        ${model.reduce((html, card) => html + workCardTemplate(card), '')}
    </section>
</section>
`;

The above piece of code does a great deal of work indeed. Simple yet intuitive. It does follow a little inspiration from the frameworks out there.

Lines 1–19: This is a sample model array on which the reduce function can run in order to give the reusable template feature.

Line 53: This line does all the magic in generating multiple reusable components into one HTML string. The reduce function takes in the accumulator as the first argument, and each value of the array as the second argument.

Thanks to these simple features, we already have an application structure in place. The best way to learn a feature is to put it in action they say, so here we are. ?

Application Demo

Congratulations on reaching here!

This post covered a lot of features indeed and getting hold of all the concepts and techniques will take some time.

Here is a demo of the to-do application built with all the features as discussed in this article. Click here to visit the site.

Vanilla Todos Demo

Click here for the link to GitHub repository. Feel free to clone the repository and go through the code for a better understanding of the conceptual examples mentioned in the article.

Sample Production App

The production site is a portfolio which was designed, developed and engineered from scratch using the exact features as specified in this article. The Single Page Application is broken down into custom modules and components.

The flexibility and power that comes with Vanilla JavaScript is something unique and does help in producing some astonishing results.

Click here to go to the site. Here is the site in action:

Custom Portfolio

Do visit the site to get a feel for it. The colors are not accurately produced in the demo here. The engineering put into this site produced the following results:

Portfolio Lighthouse Results

Never scored a perfect 100 before in any subject. ?

Conclusion

There are several projects we might like to build using Vanilla JavaScript instead of frameworks in order to achieve certain results quickly. I wrote this article to help developers use a simple custom setup to build their future projects.

The best part about the Vanilla framework is that developers have the freedom to shape their engineering thought patterns according to various use cases. Be it Imperative or Declarative style of programming, creating or using of latest existing features. As long as we produce consistent and performant applications with good code maintainability, our job is done for the day.

Happy hacking! ?

Other Posts By Me

Find me at https://medium.com/@anurag.majumdar

➥ Web Development

• Progressive Web App Shell: The Key To Loading Your Site Under 1 Second!
• “Super” and “Extends” In JavaScript ES6 — Understanding The Tough Parts
• Introduction To Polyfills & Their Usage

➥ Life Event

• Udacity’s Google Mobile Web Scholarship Challenge and its glorious effects!

Note: This is the third in a series of posts about PWAs inside of React. For a quick primer, see the previous two posts here and here.

In this follow up post, I’m going to take you through how to build a custom Progressive Web App (PWA) using Google’s Workbox library without ejecting from the create-react-app (CRA) shell.

Workbox is a collection of libraries that make it easier to build offline functionality. Workbox is also considered the successor to the sw-precache library, which CRA uses to generate a default SW.

There has been some talk about CRA migrating from sw-precache to Workbox (reference this issue for details). Unfortunately, nothing seems to have come of it quite yet.

Goals

1. Configure the CRA build to use react-app-rewired. (react-app-rewired is a library to configure the default CRA build without ejecting)
2. Use react-app-rewired to customize the build to use Workbox to generate a service worker
3. Build a very simple todo app
4. Implement offline functionality for the todo app using Workbox.
   The offline functionality we will be targeting:
   a) Cache retrieved assets so they can be served offline
   b) Allow POSTing of data offline

Introducing Workbox into CRA

First, create a fresh CRA repository with the following command:

npx create-react-app react-app-rewire-workbox

This should set up a new folder with the relevant name. Once you have this folder set up, cd into the folder and create a service worker file in the public folder. I’ll call mine custom-service-worker.js.

Once, you’ve done this, go ahead and remove the check for NODE_ENV being set to PRODUCTION inside of registerServiceWorker.js

Finally, inside of the custom-service-worker.js file, paste the following code:

This code snippet is something I’ve picked up straight from the Workbox website. You use the importScripts line to inject a global variable named workbox into your file. The script your are importing is served via a CDN. You then have a simple check to see if the variable was loaded correctly by the script or not.

So, we now have Workbox working for us in a dev environment. Next, let’s figure out how to implement react-app-rewired into CRA.

Implementing react-app-rewired In CRA

Add the react-app-rewired package to your project folder by using the following command:

npm install --save-dev react-app-rewired

Now, if you read the docs, they mention that you need to set up a config-overrides.js file in the root directory of your project. Let’s figure out what this does first.

I’ll set up a barebones file and explain to you what it means. There is a very detailed explanation of this in the docs, if you wish to read that instead.

You can export an object from this file with three keys: webpack, jest, devServer. The respective functions allow you to configure the webpack production server configuration, the jest configuration, and finally the webpack development server configuration.

If you look at the devServer key in the config-overrides.js file, you will notice that we are logging configFunction.toString() instead of just configFunction . This is because if you try the latter, Node will just print [Function] to the console.

Open up your package.json file and replace the scripts command for start with react-app-rewired start .

Building The Todo App

So far, we have managed to introduce Workbox into our dev environment, and have also introduced react-app-rewired into our CRA shell. Let’s leave things as they are and build a sample todo app, and get it running in the dev environment.

The todo app is going to need a couple of moving pieces, just so we can actually make use of service workers.

It’s going to involve:

1. A basic UI layer (I’m going to completely ignore styling for this.)
2. A json-server we can request data from

I’m not going into too much detail about setting this up, because its all fairly straightforward. I’ll include a link to a git repo with a working version of this app at the end of this article, so you can have a look at that.

Here is the Todo component I have written.

The component makes a fetch request to a json-server I have set up, and gets a response consisting of an array of todos. The component then renders these todos. Like I said, extremely simple.

To set up the json-server run the following command:

npm install --save json-server

Create a file called db.json with the following structure

Finally, run the following command in the terminal:

json-server --watch db.json --port 8000

This runs a local server on port 8000, and watches the db.json file for any changes. In case anything changes, the server restarts itself. Its a very simple way to mock a server for testing your app.

Finally, update your App.js file to reflect your new Todo component, and remove the default JSX from that file.

Fire up the app (inside of an incognito window) and take a look at what it looks like now. You should see a list of todos and an input box below them with a button to submit. Like I said, very simple UI.

Once you’ve got all that set up, let’s figure out a way to make this stuff work offline using Workbox.

Note: While testing service worker functionality in a dev environment, always make sure you do so within a new incognito window each time. It makes testing and debugging much less of a headache because your data is not stored across sessions.

Implementing Caching With Workbox

Now, if you go ahead and open up the Chrome toolbar, you should see something that looks like the following under the Application tab.

Google Chrome Developer Toolbar

Check the offline checkbox and then try to reload your webpage. It will probably fail with an error saying there was no network connection detected. If you look at the network tab, you will see a bunch of failed network requests.

The most obvious one that will fail is the request to our json-server to fetch the list of todos. Let’s fix that one first. Open up the custom-service-worker.js file and add in the following code

workbox.routing.registerRoute(  'http://localhost:8000/todos',  workbox.strategies.networkFirst())

This is setting up a caching strategy of networkFirst for any requests made to thehttp://localhost:8000/todos endpoint. The image below gives you a clear explanation of what the networkFirst strategy implies. You always check the network first, and only in case of the network failing do you go to the cache to fetch the resource. This is a typical strategy you might use when querying an API that is likely to provide fresh data.

Network First strategy

Now, the app is still not going to load because we are still missing two important pieces. Namely, we are still not caching

1. The JS bundle that is being served by our local dev server.
2. The index.html file

Add the following code to custom-service-worker.js

workbox.routing.registerRoute(

  /\.(?:js|css|html)$/,

  workbox.strategies.networkFirst(),

)

workbox.routing.registerRoute(

  ‘http://localhost:3000',

  workbox.strategies.networkFirst()

)

If you notice, the first route in the above code snippet is a RegEx object. This is a clean and simple way to target multiple routes with the same strategy. However, if you are targeting a resource that doesn’t follow the same origin policy, make sure to specify the entire route.

This is, of course, not the ideal way to do things. Ideally, we want static assets like JS bundles, stylesheets and HTML files pre-cached as part of the Webpack build process. We will get to that, but its important to understand that there is no black magic going on. This is all just simple caching.

Go ahead and fire up the page again and open up your console. You should see a bunch of logs by Workbox about routing. Go into offline mode, and refresh the page. You should see everything load just like normal. If you open up the workbox logs in the console, you will see Workbox printing out whether the network request failed or succeeded, and workbox’s response to that failure (see screenshot below):

Workbox log in Chrome Dev Tools Window

Implementing Deferred POSTing Of Data With Workbox

Alright, next up: how do we POST data back to the server without a network connection?

First, let’s set up a way to POST data back online, and make sure it works. Update your addTodo function inside of your Todo component so it looks like the following:

All we’ve done is added a callback handler to setState so we can be notified when the state has updated. At this point, we’ve made a POST request to the json-server to update db.json with the new todo.

Try submitting a new todo, open up db.json and you should see the new todo added to your array of objects.

Now, try doing the exact same thing offline, and you should get a network error for obvious reasons. You will probably get a log statement that says: Failed to fetch.

To solve this, we’re going to make use of something called backgroundSync, the spec for which you can read up on here. The way its supposed to work is that whenever you make a request to a server for a specific resource (in our case a POST request), if no network is detected, Workbox will store this request in indexedDB and keep polling the request for a set period of time. When a network connection is detected, the request will be replayed. If no network connection is established within the pre-defined period of time, the request is discarded.

The backgroundSync API uses something called SyncManager under the hood. You can read about it in the MDN docs here. Unfortunately, as you can see, SyncManager is not on the standards track and Chrome is the only browser that has a fully implemented spec. What this means is that Chrome is the only browser where this is guaranteed to work reliably.

We need to add some code to custom-service-worker.js to get the backgroundSync stuff working for us. Add the following code to the file:

We are making use of a background sync plugin that Workbox provides us with. The first parameter you provide to the constructor is the name of the queue you want Workbox to create when storing failed requests. The second parameter is an options object, where we are defining the maximum amount of time to attempt to replay requests within.

Finally, we register a new route with the POST method, and set up the strategy we want to use for caching. This is very similar to what we have already done with the exception of defining the type of request being made, and also having a plugin defined for our strategy.

Now, try running through the same scenario of submitting a todo without any network connection and observe what happens in the log. You will get a log that looks like the following screenshot.

Workbox adds the failed request to a queue

You can look at the request that has been added by looking for indexedDB under the application tab in the Chrome DevTools window. Open up the listed subdirectories under the indexedDB dropdown menu, and you should see the request stored, waiting to be replayed.

Switch off the offline option in the DevTools window, and you should see a new Workbox log popup almost immediately. It will look like the following:

Workbox log detailing that the failed request has been replayed and submitted

The image above involves Workbox replaying the failed request the moment it receives a sync request, and giving you the confirmation that your request has been successful. If you look at db.json now, you will notice that the new todo has been added to the file.

Well, there we go. We have a way to replay failed requests through a service worker now.

What we need to do next is to integrate a Webpack plugin so Workbox can cache static assets as part of the build process. This will get rid of the need to explicitly have a route to cache static assets inside of our Service Worker file.

Precaching Static Assets

This is going to be the final step. In this section, we are going to make the changes to CRA’s build process to force it to generate the Service Worker file using Workbox instead of sw-precache.

First up, install the following packages: workbox-webpack-plugin and path.

Open up the package.json file and edit the build script to run with react-app-rewired instead of react-scripts the same way we did for the start script.

Finally, open up the config-overrides.js file and edit it to look like the following:

There’s a couple of things we’re doing in this file.

First, we check to see if it’s a production build. If it is, we create a Workbox config object and provide it with the path of our custom SW, and also the path of the output SW we want.

We also provide an option called importWorkboxFrom and set it to disabled.

This is an option specifying that we don’t want Workbox imported from anywhere, since we’re directly requesting it from a CDN in our SW script.

Finally, we have a function that is called removeSWPrecachePlugin . All this does is loop over the plugins listed in the Webpack config, find the correct one, and return the index so we can remove it.

Now, go ahead and run the build for the app, and open up the SW file generated in the build folder. In my case, this SW file has the name custom-service-worker.js

You will notice a new importScripts call at the top of the file, which seems to be requesting a precache manifest file. This file is stored in the build folder, and if you open it up, you should see the list of all static assets being cached by Workbox.

Conclusion

So, we’ve accomplished the following goals:

1. Configure the CRA build to use react-app-rewired
2. Use react-app-rewired to customise the build to use Workbox to generate a Service Worker — We accomplished this using workbox-webpack-plugin. The build process will now automatically cache all static assets.
3. Build a very simple todo app
4. Implement offline functionality for the todo app using Workbox.
   The offline functionality we will be targeting:
   a) Cache retrieved assets so they can be served offline
   b) Allow POSTing of data offline

Here is the link to the repo which has a working version of the app. You can clone that and have a play with it.

Follow me on twitter here. Follow me on GitHub here

Let’s do a quick recap of what we have learnt so far. For an app to be progressive, it needs to have the following requirements:

1. a manifest file — manifest.json
2. service worker with at least a fetch event — serviceworker.js
3. icon — icon.jpeg
4. served over HTTPS — https://www.myawesomesite.com

In this tutorial, I will be talking about requirements 1 and 2 — creating a manifest file and registering a service worker.

Objective

For this example, we are going to create a simple progressive web app. The complexity is kept intentionally simple so that we can focus on the concepts of a progressive web app. You should be able to take these concepts and apply them in your own Angular, React, Vue or vanilla JavaScript app.

We are going to create a meme engine. We will pull the latest trending memes from giphy.com and display them in our app. A user should be able to view the images even if the connection is down. Hence, we are providing a seamless offline experience.

Great! So now let's get to the important stuff.

Step 0: Build the app

Let’s start with a skeleton index.html:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>All the memes!</title>
    <link rel="stylesheet" href="/styles.css">
</head>
<body>
<header>
    <h1 class="center">Top trending memes today</h1>
</header>
<main>
    <div class="container"></div>
</main>
<script src="app.js"></script>

</body>
</html>

As you can see, it is a simple index.html that only prints out the text Top trending memes today. Nothing fancy.

Next, let’s add an ability to fetch trending memes from giphy.com. Here is what the fetch function looks like:

async function fetchTrending() {
    const res = await fetch(`https://api.giphy.com/v1/gifs/trending?api_key=${apiKey}&limit=25`);
    const json = await res.json();

    main.innerHTML = json.data.map(createMeme).join('\n');
}

Let’s make it progressive

Step 1: Manifest file

As you may recall from part 1, the manifest file is a json file. It has meta information about the app like icon name, background color, the name of the app, etc. Here is a manifest.json file with these parameters:

{
  "name": "Meme",
  "short_name": "Meme",
  "icons": [{
    "src": "images/icons/icon-128x128.png",
      "sizes": "128x128",
      "type": "image/png"
    }, {
      "src": "images/icons/icon-144x144.png",
      "sizes": "144x144",
      "type": "image/png"
    }, {
      "src": "images/icons/icon-152x152.png",
      "sizes": "152x152",
      "type": "image/png"
    }, {
      "src": "images/icons/icon-192x192.png",
      "sizes": "192x192",
      "type": "image/png"
    }, {
      "src": "images/icons/icon-256x256.png",
      "sizes": "256x256",
      "type": "image/png"
    }],
  "start_url": "/index.html",
  "display": "standalone",
  "background_color": "#3E4EB8",
  "theme_color": "#2F3BA2"
}

You can also use a tool to generate this. Here is a tool that I found useful:

Web App manifest generator

Adding it to our app is simple. Add the following line to index.html :

<link rel="manifest" href="/manifest.json">

Step 2: Service Worker

Let’s create the file serviceworker.js . First, we are going to register the service worker on install. Then we will cache some static assets such as styles.css and app.js. Next, we need to provide offline capability using fetch . Here is what the serviceWorker.js looks like:

const staticAssets = [
    './',
    './styles.css',
    './app.js'
];

self.addEventListener('install', async event => {
    const cache = await caches.open('static-meme');
    cache.addAll(staticAssets);
});

self.addEventListener('fetch', event => {
    const {request} = event;
    const url = new URL(request.url);
    if(url.origin === location.origin) {
        event.respondWith(cacheData(request));
    } else {
        event.respondWith(networkFirst(request));
    }

});

async function cacheData(request) {
    const cachedResponse = await caches.match(request);
    return cachedResponse || fetch(request);
}

async function networkFirst(request) {
    const cache = await caches.open('dynamic-meme');

    try {
        const response = await fetch(request);
        cache.put(request, response.clone());
        return response;
    } catch (error){
        return await cache.match(request);

    }

}

Let’s break this down. A service worker will help us cache data and fetch resources. If we have data in our cache, we return the data from cache or else fetch it from the network. For your own app, think of what functionality you will need to provide for offline access. Then, cache resources accordingly. For my case, I want to show previously cached images when the network is down.

We will need to add this to our index.html. To add it, we will register the service worker by leveraging the browser’s navigator library:

window.addEventListener('load', async e => {
    await fetchTrending();

    if ('serviceWorker' in navigator) {
        try {
            navigator.serviceWorker.register('serviceWorker.js');
            console.log('SW registered');

        } catch (error) {
            console.log('SW failed');

        }
    }
});

Let’s verify that it actually has been registered. Click on the network tab in the browser and go to application settings. This tab is really helpful when developing a progressive web app. Reload the page, and you will be able to see a service worker in this tab.

Service Worker has been registered

Now let’s refresh the browser. In the first load, data will be cached by the service worker. Try turning the connection off. We will still be able to view images.

Our app is now available even offline! If you have enabled HTTPS and uploaded an icon, congratulations you now have a Progressive Web App!

Next Steps

If you are interested in developing your own progressive web app, I would highly recommend checking out this codelabs by Google Developers.

Did you learn something new? Have comments? Know a DevJoke? Tweet me @shrutikapoor08

// When I wrote this, only God and I understood what I was doing
// Now, only God knows#devjoke #notajoke #development #javascript pic.twitter.com/4V6lMUdhdb

— Shruti Kapoor (@shrutikapoor08) August 9, 2018

Native apps have become hugely popular recently, mostly because of features such as working offline, transitions, easy distributability and of course push notifications. But unfortunately, you need a good knowledge of languages like Java or Swift to create a valuable native app.

Progressive Web Apps

Progressive Web Apps (PWAs) are JavaScript applications that run in the browser. They make the effort to bring some of the native app features to the web. PWAs are easy to develop if you have a fundamental knowledge of HTML, CSS, and in particular JavaScript. Moreover, if your service is already accessible for desktop devices on a website, it is easier to add the functionalities of a Web App, instead of developing a native mobile app.

Notifications

Notifications keep users informed about new messages, tell them about a new blog post, and so on.

Many native apps send push notifications to the user. But this is also possible using PWAs and the Notifications API.

_Photo by [Unsplash](https://unsplash.com/@jamie452?utm_source=medium&utm_medium=referral" rel="noopener" target="_blank" title="">Jamie Street on <a href="https://unsplash.com?utm_source=medium&utm_medium=referral" rel="noopener" target="blank" title=")

OneSignal

In this tutorial, we will be using OneSingal to send notifications to our web app. OneSignal is a powerful tool that provides a simple interface to push notifications. They also provide a Rest API, which we will be using to send notifications.

Setup OneSignal

To send push notifications, you need to setup OneSignal first. Therefor you need an account on OneSignal. Head over to their website and press “Log in” in the upper right corner.

Next you will have to create an app. Give it a name and choose “Setup platform”. Here you select “All Browsers”. After that, you choose “custom code” as the integration. Then you have to provide some information about your website.

In the settings area of your app, there is a tab called “Keys & IDs”. Copy both keys for later.

Important: Do not share you REST API Key. Keep it private!

That’s it for setting up OneSignal. That was easy!

Setup our website

In the next part, we will be adding the notification functionality to our website. The website will have to wait for notifications sent by OneSignal and display them to the user.

To let the browser know that you are creating a Progressive Web App, we will add a file called manifest.json to the root of our project.

{  "name": "My Application",  "short_name": "Application",  "start_url": ".",  "display": "standalone",  "background_color" : "#fff" ,  "description": "We send notifications to you",  "gcm_sender_id": "482941778795",  "gcm_sender_id_comment": "Do not change the GCM Sender ID"}

The first six key-value-pairs describe the appearance of the application. The gcm_send_id is important for sending notifications. If you want to know more about manifest.json, you can have a look in the Mozilla Documentation.

Your browser doesn’t automatically look for the manifest. You have to put the path to it in every HTML document in the _&_lt;h_e_ad> tag.

<head>    ...    <link rel="manifest" href="manifest.json">    ...</head>

Additionally, we need some JavaScript code to connect our website to OneSignal.

You can put the code for that in a script tag in the _&_lt;h_e_ad> part. Don’t forget to replace my-app-id with your own OneSignal app id.

<head>    <script src="https://cdn.onesignal.com/sdks/OneSignalSDK.js" async=""></script>        <script>        var OneSignal = window.OneSignal || [];        OneSignal.push(function () {            OneSignal.init({                appId: "my-app-id",                autoRegister: false,                notifyButton: {                    enable: true,                },            });        });    <script></head>

Prompt the user to subscribe to your notifications

When you want to prompt the user to subscribe to your notifications, you execute this piece of code.

OneSignal.push(function () {    OneSignal.showHttpPrompt();});

Moreover, you need a service worker, which listens in the background for notifications. Therefore, you need two files in the root directory of your project.

OneSignalSDKUpdaterWorker.js

importScripts('https://cdn.onesignal.com/sdks/OneSignalSDKWorker.js');

OneSignalSDKWorker.js

importScripts('https://cdn.onesignal.com/sdks/OneSignalSDKWorker.js');

Access the API using Python

OneSignal has an easy-to-use Rest API. The endpoints are documented in the OneSignal Developer Documentation.

_Photo by [Unsplash](https://unsplash.com/@maxcodes?utm_source=medium&utm_medium=referral" rel="noopener" target="_blank" title="">Max Nelson on <a href="https://unsplash.com?utm_source=medium&utm_medium=referral" rel="noopener" target="blank" title=")

To access it, we need to send HTTP requests. Therefore, we will use a library called requests. To install it, you can use pip, the package manager of Python.

pip install requests

This is the API endpoint we need to send a notification: https://onesignal.com/api/v1/notifications.

The HTTP protocol has several methods. In this case, we want to make a POST request. To do so, we need to import requests and execute a function.

import requests

requests.post("https://onesignal.com/api/v1/notifications")

OneSignal wants to verify that only you can send notifications to your website. So you have to add an HTTP header with your Rest API Key from OneSignal.

requests.post(    "https://onesignal.com/api/v1/notifications",    headers={"Authorization": "Basic my-rest-api-key"})

Remember to replace my-rest-api-key with your Rest API Key.

Moreover, you need some basic information about your notification.

data = {    "app_id": "my-app-id",    "included_segments": ["All"],    "contents": {"en": "Hello"}}

requests.post(    "https://onesignal.com/api/v1/notifications",    headers={"Authorization": "Basic my-rest-api-key"},    json=data)

Replace my-app-id with your own app id. Next you choose who will receive your notifications. Example values are "All", "Active Users", "Inactive Users”. But you can also create your own segments. And for the last one, you add some content of the message in English. If you need another language, you can add it here too.

That’s it! If you subscribed to the notifications, you should get a push notification.

Send notifications using an API Wrapper

Because my code became kind of messy with many different notifications, I created an API wrapper for OneSignal.

API Wrapper

But what is an API wrapper? An API wrapper makes it easier for you to access an API. You can say that it is an API for an API. You call the API wrapper instead of the API directly.

You can install the wrapper called OneSignal-Notifications from pip.

pip install onesignal-notifications

Now you can import it and setup your client.

from onesignal import OneSignal, SegmentNotificationclient = OneSignal("MY_APP_ID", "MY_REST_API_KEY")

To send a Notification, you have to initialize the class SegmentNotification and use the method send.

notification_to_all_users = SegmentNotification(    {        "en": "Hello from OneSignal-Notifications"    },    included_segments=SegmentNotification.ALL)client.send(notification_to_all_users)

Maybe this looks kind of unnecessary to you, because it takes even more lines of code. But if you have several notifications, it makes the process much easier and your code more beautiful.

For example if you want to send a notification, which is based on some conditions, the API wrapper has a custom class for that.

from onesignal import OneSignal, FilterNotification, Filterclient = OneSignal("MY_APP_ID", "MY_REST_API_KEY")

filter_notification = FilterNotification(    {        "en": "Hello from OneSignal-Notifications"    },    filters=[        Filter.Tag("my_key", "<", "5"),        "AND",        Filter.AppVersion(">", "5"),        "OR",        Filter.LastSession(">", "1"),    ])

There are many custom parameters you can provide to adapt your notification. For example, you can add buttons to the notification. All list of all parameters can be found here.

from onesignal import OneSignal, FilterNotification, Filterclient = OneSignal("MY_APP_ID", "MY_REST_API_KEY")

filter_notification = SegmentNotification(    {        "en": "Hello from OneSignal-Notifications"    },    web_buttons=[        {          "id": "like-button",          "text": "Like",          "icon": "http://i.imgur.com/N8SN8ZS.png",          "url": "https://github.com/Lanseuo/onesignal-notifications"}    ],    included_segments=SegmentNotification.ALL)

If you want to find out more about OneSignal-Notifications, you can have a look in the GitHub Repository or in the docs.

Note: This is not a primer on create-react-app or what a service worker is. This post assumes prior knowledge of both.

So, I recently had the opportunity to work on a React project which involved publishing the resulting web application as a Progressive Web Application (PWA).

I realised what a struggle it is to get a PWA with custom routes configured inside of a Create React App (CRA) build. Hopefully this helps out someone stuck in a similar position.

PWAs in Create-React-App

How exactly do we get a PWA running inside our CRA shell?

Now, the CRA shell bundles a service worker by default. You should have noticed that in a basic CRA shell, inside of the index.js file, there is a call to registerServiceWorker:

import React from 'react';
import ReactDOM from 'react-dom';
import './index.css';
import App from './App';
import registerServiceWorker from './registerServiceWorker';

ReactDOM.render(<App />, document.getElementById('root'));
registerServiceWorker();

You can create a new CRA app and look inside the registerServiceWorker file.

It looks quite complex, but it is really just checking to see if the environment variables are set for a production build and if a serviceWorker is supported in the current browser.

If you run a build with the command yarn build, you can open up the build folder and check inside to see that a service-worker.js file has been generated. This is the default service worker file CRA generates for you.

The formatting of the file is inline ES5 JavaScript, which makes it a little hard to read. But you can dump it into any prettifier, and you should see a more legible file.

Looking into the above file should show you that it is simply creating a static cache with the following cache name: sw-precache-v3-sw-precache-webpack-plugin-+(selg.registration ? self.registration.scope). It then caches all of your static files like index.html and your js and css files inside of that cache.

You should also see a fetch event listener in there that catches a fetch event and checks to see if the app is requesting one of the previously cached static assets.

Now comes the million dollar question: what if you want to configure a dynamic cache for a specific route? In essence, a cache that will update itself with data sent from the server when the user visits a specified route. Note that this means the data will not be available at build time, and therefore cannot be cached by the default service worker generated.

Limitations of default PWAs in CRA

Unfortunately, it’s not very easy to accomplish the above when using CRA. Unless you’re willing to eject, of course.

Take a look at these GitHub issues to see why the team at CRA won’t support customising the default service worker.

Custom ServiceWorker config · Issue #2237 · facebook/create-react-app
_1.0.0 added Progressive Web App support, is it possible to support custom config in near future? I really don't want to…_github.comImport scripts in Service Worker by piotr-cz · Pull Request #2714 · facebook/create-react-app
_This PR adds an ability to use importScripts option of SWPrecacheWebpackPlugin. How-to: create a file called…_github.com

So, given that we can’t seem to customise the default service-worker, how do we work our way around it?

Understanding How CRA Generates A Service Worker

The first step to finding a work around for the build system is to actually understand how the build system works.

So, let’s start with the library the build system uses to generate a service worker file.

sw-precache is a library that allows you to generate a service worker file based on a template. The template file is written using underscore’s templating engine.

Here is the link to the template file in the sw-precache source code.

Again, the template file looks complex, but it is quite straightforward once you manage to get your head around the templating language.

So, what happens when you run a build process in a CRA shell, in relation to generating a service worker, is:

1. The sw-precache library is executed internally
2. An options object is provided to sw-precache to allow generation of the service worker file from the template
3. The service worker file is generated in the build folder with the name service-worker.js

Overriding The Default Service Worker

Now, how do we override the above process to allow our own custom service worker file to be generated?

The answer is based on Jeff Posnick’s (a maintainer of sw-precache) stackoverflow answer.

First, we need to run thesw-precache CLI after the normal build process.

Install the sw-precache library by running the following command: npm install --save-dev sw-precache

Now, the sw-precache library runs on a config file, which is provided via an option on the CLI. This is the command: sw-precache --config=sw-precache-config.js , where sw-precache-config.js is the name of the config file.

Here is a sample config file.

module.exports = {
  staticFileGlobs: [
    'build/static/css/**.css',
    'build/static/js/**.js'
  ],
  swFilePath: './build/service-worker.js',
  templateFilePath: './service-worker.tmpl',
  stripPrefix: 'build/',
  handleFetch: false,
  runtimeCaching: [{
    urlPattern: /this\\.is\\.a\\.regex/,
    handler: 'networkFirst'
  }]
}

Note: It is important that you specify the swFilePath as ./build/service-worker.js This is so that the service worker generated as a result of your custom build process overwrites the one created by CRA (they both share the same name, in this instance). Otherwise, you will end up with two service worker files in your build directory!

There is extensive documentation on the object properties and what valid values can be assigned to them on the GitHub page for sw-precache.

Of special interest is the runtimeCaching option, because this is a very extensible solution to allow you to define custom rules for your service worker to respond to dynamic content.

The templateFilePath is an option for when you want the CLI to pick up your custom service worker template file. But you’re almost always going to be using the template file provided by the library itself.

Finally, we need to provide the script to signal to the CRA build system that we want our custom service worker to be generated. Go ahead and install the sw-precache library.

Next, update the package.json build script, with the following:

build: react-scripts build && sw-precache --config=sw-precache-config.js

Once you run the build process with npm run build, you can open up the build folder and see your generated service worker.

Run the build process with and without the custom service worker and notice the differences between the two.

Conclusion

While this may seem like a very verbose approach to something as simple as customising a service worker, this approach has the benefit of keeping you firmly within the create-react-app shell.

There are other approaches to generating a custom service worker (using a combination of react-app-rewire and workbox). I’ll try and get that approach up in a post as well.