Tag: Routes

Lazy Load Routes in Vue with webpack Dynamic Comments

The way routing works in JavaScript is usually that you specify which relative URL pattern you want for which component to render. So for /about you want the <About /> component to render. Let’s take a look at how to do this in Vue/Vue Router with lazy loading, and do it as cleanly as possible. I use this little tip all the time in my own work.

A repo that includes everything covered in this post is available on GitHub.

You’ve probably seen Vue routes (URLs) like this:

import Vue from 'vue' import VueRouter from 'vue-router'  import Home from '../views/Home.vue' import About from '../views/About.vue' import Login from '../views/Login.vue'  Vue.use(VueRouter)  const routes = [   { path: '/', name: 'Home', component: Home },   { path: '/about', name: 'About', component: About },   { path: '/login', name: 'Login', component: Login } ]  const router = new VueRouter({   routes })  export default router

That will load the <Home /> component at the / route, the <About /> component at the /about route, and the <Login /> component at the /login route.

That doesn’t do a very good job of code splitting though, since all three of those components will be bundled together rather than loaded dynamically as needed.

This is a terminal screenshot with a dark purple background with text in white green and blue. The content shows the final build after compiling.

Here’s another way to do the same, only with code splitting with dynamic import statements and webpack chunk names:

const routes = [   {     path: '/',     name: 'Home',     component: () => import(/* webpackChunkName: "Home" */ '../views/Home.vue')   },   {     path: '/about',     name: 'About',     component: () => import(/* webpackChunkName: "About" */ '../views/About.vue')   },   {     path: '/login',     name: 'Login',     component: () => import(/* webpackChunkName: "Login" */ '../views/Login.vue')   } ]

This is perfectly fine and doesn’t have any major downsides, other than being a bit verbose and repetitive. Since we’re awesome developers, let’s do a bit of abstraction to help, using an array that we’ll .map over.

const routeOptions = [   { path: '/', name: 'Home' },   { path: '/about', name: 'About' },   { path: '/login', name: 'Login' } ]  const routes = routeOptions.map(route => {   return {     ...route,     component: () => import(`@/views/$ {route.name}.vue`)   } })  const router = new VueRouter({   routes })

Now we’ve reduced the use of the component key by using the route name as param in the import function.

But what happens if we want to set the chunk name?

As far as I know, you can’t have dynamic comments in JavaScript without some kind of build step. So, we are sacrificing comments (webpackChunkName) in favor of having to write less code in this case. It’s entirely up to you which you prefer.

Just kidding, let’s fix it.

As of webpack 2.6.0 , the placeholders [index] and [request] are supported, meaning we can set the name of the generated chunk like this:

// ...  const routeOptions = [   { path: '/', name: 'Home' },   { path: '/about', name: 'About' },   { path: '/login', name: 'Login' } ]  const routes = routeOptions.map(route => {   return {     ...route,     component: () => import(/* webpackChunkName: "[request]" */ `../views/$ {route.name}.vue`)   } })  const router = new VueRouter({   routes })

Nice! Now we have all the power, plus dynamically loaded routes with named chunks. And it works with Vue 2 and Vue 3. You can check it out by running npm run build in the terminal:

This is the same terminal screenshot as before, but with three of the JavaScript built files highlighted with the words "Named Chunks" annotated beside them.
See that? Now the components are chunked out… and the build did all the naming for us!

Buuuuut, we can still take this one step further by grouping the lazy loaded routes into named chunks rather than individual components. For example, we can create groups that group our most important components together and the rest in another “not so important” group. We merely update the webpack chunk name in place of the [request] placeholder we used earlier:

const routes = [   {     path: "/",     name: "Home",     component: () =>       import(/* webpackChunkName: "VeryImportantThings" */ "../views/Home.vue")   },   {     path: "/about",     name: "About",     component: () =>       import(/* webpackChunkName: "VeryImportantThings" */ "../views/About.vue")   },   {     path: "/login",     name: "Login",     component: () =>       import(/* webpackChunkName: "NotSoImportant" */ "../views/Login.vue")   },   {     path: "/contact",     name: "Contact",     component: () =>       import(/* webpackChunkName: "NotSoImportant" */ "../views/Contact.vue")   } ];

Now our four components are groups into two separate chunks.

The same terminal with different compiled JavaScript files.

There you have it! A technique for lazy loading routes in Vue, plus some ideas for how to name and group them together at build.

The post Lazy Load Routes in Vue with webpack Dynamic Comments appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, , , , ,

Creating Dynamic Routes in a Nuxt Application

In this post, we’ll be using an ecommerce store demo I built and deployed to Netlify to show how we can make dynamic routes for incoming data. It’s a fairly common use-case: you get data from an API, and you either don’t know exactly what that data might be, there’s a lot of it, or it might change. Luckily for us, Nuxt makes the process of creating dynamic routing very seamless.

In the last post, we showed how to set up stripe payments with Netlify Functions, which allow us to create serverless lambda functions with ease. We’ll use this same application to show another Nuxt-specific functionality as well.

Let’s get started!

Creating the page

In this case, we’ve got some dummy data for the store that I created in mockaroo and am storing in the static folder. Typically you’ll use fetch or axios and an action in the Vuex store to gather that data. Either way, we store the data with Vuex in store/index.js, along with the UI state, and an empty array for the cart.

import data from '~/static/storedata.json'  export const state = () => ({  cartUIStatus: 'idle',  storedata: data,  cart: [] })

It’s important to mention that in Nuxt, all we have to do to set up routing in the application is create a .vue file in the pages directory. So we have an index.vue page for our homepage, a cart.vue page for our cart, and so on. Nuxt automagically generates all the routing for these pages for us.

In order to create dynamic routing, we will make a directory to house those pages. In this case, I made a directory called /products, since that’s what the routes will be, a view of each individual product details.

In that directory, I’ll create a page with an underscore, and the unique indicator I want to use per page to create the routes. If we look at the data I have in my cart, it looks like this:

[  {    "id": "9d436e98-1dc9-4f21-9587-76d4c0255e33",    "color": "Goldenrod",    "description": "Mauris enim leo, rhoncus sed, vestibulum sit amet, cursus id, turpis. Integer aliquet, massa id lobortis convallis, tortor risus dapibus augue, vel accumsan tellus nisi eu orci. Mauris lacinia sapien quis libero.",    "gender": "Male",    "name": "Desi Ada",    "review": "productize virtual markets",    "starrating": 3,    "price": 50.40,    "img": "1.jpg"  },   … ]

You can see that the ID for each entry is unique, so that’s a good candidate for something to use, we’ll call the page:


Now, we can store the id of the particular page in our data by using the route params:

data() {  return {    id: this.$  route.params.id,   } },

For the entry from above, our data if we looked in devtools would be:

id: "9d436e98-1dc9-4f21-9587-76d4c0255e33"

We can now use this to retrieve all of the other information for this entry from the store. I’ll use mapState:

import { mapState } from "vuex";  computed: {  ...mapState(["storedata"]),  product() {    return this.storedata.find(el => el.id === this.id);  } },

And we’re filtering the storedata to find the entry with our unique ID!

Let the Nuxt config know

If we were building an app using yarn build, we’d be done, but we’re using Nuxt to create a static site. When we use Nuxt to create a static site, we’ll use the yarn generate command. We have to let Nuxt know about the dynamic files with the generate command in nuxt.config.js.

This command will expect a function that will return a promise that resolves in an array that will look like this:

export default {   generate: {     routes: [       '/product/1',       '/product/2',       '/product/3'     ]   } }

To create this, at the top of the file we’ll bring in the data from the static directory, and create the function:

import data from './static/storedata.json' let dynamicRoutes = () => {  return new Promise(resolve => {    resolve(data.map(el => `product/$  {el.id}`))  }) }

We’ll then call the function within our config:

generate: {   routes: dynamicRoutes },

If you’re gathering your data from an API with axios instead (which is more common), it would look more like this:

import axios from 'axios' let dynamicRoutes = () => {  return axios.get('https://your-api-here/products').then(res => {    return res.data.map(product => `/product/$  {product.id}`)  }) }

And with that, we’re completely done with the dynamic routing! If you shut down and restart the server, you’ll see the dynamic routes per product in action!

For the last bit of this post, we’ll keep going, showing how the rest of the page was made and how we’re adding items to our cart, since that might be something you want to learn, too.

Populate the page

Now we can populate the page with whatever information we want to show, with whatever formatting we would like, as we have access to it all with the product computed property:

<main>  <section class="img">    <img :src="`/products/$  {product.img}`" />  </section>  <section class="product-info">    <h1>{{ product.name }}</h1>    <h4 class="price">{{ product.price | dollar }}</h4>    <p>{{ product.description }}</p>  </section>  ... </main>

In our case, we’ll also want to add items to the cart that’s in the store. We’ll add the ability to add and remove items (while not letting the decrease count dip below zero

<p class="quantity">  <button class="update-num" @click="quantity > 0 ? quantity-- : quantity = 0">-</button>  <input type="number" v-model="quantity" />  <button class="update-num" @click="quantity++">+</button> </p> ... <button class="button purchase" @click="cartAdd">Add to Cart</button>

In our methods on that component, we’ll add the item plus a new field, the quantity, to an array that we’ll pass as the payload to mutation in the store.

methods: {  cartAdd() {    let item = this.product;    item.quantity = this.quantity;    this.tempcart.push(item);    this.$  store.commit("addToCart", item);  } }

In the Vuex store, we’ll check if the item already exists. If it does, we’ll just increase the quantity. If not, we’ll add the whole item with quantity to the cart array.

addToCart: (state, payload) => {  let itemfound = false  state.cart.forEach(el => {    if (el.id === payload.id) {      el.quantity += payload.quantity      itemfound = true    }  })  if (!itemfound) state.cart.push(payload) }

We can now use a getter in the store to calculate the total, which is what we’ll eventually pass to our Stripe serverless function (the other post picks up from here). We’ll use a reduce for this as reduce is very good at retrieving one value from many. (I wrote up more details on how reduce works here).

cartTotal: state => {  if (!state.cart.length) return 0  return state.cart.reduce((ac, next) => ac + next.quantity * next.price, 0) }

And there you have it! We’ve set up individual product pages, and Nuxt generates all of our individual routes for us at build time. You’d be Nuxt not to try it yourself. 😬

The post Creating Dynamic Routes in a Nuxt Application appeared first on CSS-Tricks.


, , , ,

Protecting Vue Routes with Navigation Guards

Authentication is a necessary part of every web application. It is a handy means by which we can personalize experiences and load content specific to a user — like a logged in state. It can also be used to evaluate permissions, and prevent otherwise private information from being accessed by unauthorized users.

A common practice that applications use to protect content is to house them under specific routes and build redirect rules that navigate users toward or away from a resource depending on their permissions. To gate content reliably behind protected routes, they need to build to separate static pages. This way, redirect rules can properly handle redirects.

In the case of Single Page Applications (SPAs) built with modern front-end frameworks, like Vue, redirect rules cannot be utilized to protect routes. Because all pages are served from a single entry file, from a browser’s perspective, there is only one page: index.html. In a SPA, route logic generally stems from a routes file. This is where we will do most of our auth configuration for this post. We will specifically lean on Vue’s navigation guards to handle authentication specific routing since this helps us access selected routes before it fully resolves. Let’s dig in to see how this works.

Roots and Routes

Navigation guards are a specific feature within Vue Router that provide additional functionality pertaining to how routes get resolved. They are primarily used to handle error states and navigate a user seamlessly without abruptly interrupting their workflow.

There are three main categories of guards in Vue Router: Global Guards, Per Route Guards and In Component Guards. As the names suggest, Global Guards are called when any navigation is triggered (i.e. when URLs change), Per Route Guards are called when the associated route is called (i.e. when a URL matches a specific route), and Component Guards are called when a component in a route is created, updated or destroyed. Within each category, there are additional methods that gives you more fine grained control of application routes. Here’s a quick break down of all available methods within each type of navigation guard in Vue Router.

Global Guards

  • beforeEach: action before entering any route (no access to this scope)
  • beforeResolve: action before the navigation is confirmed, but after in-component guards (same as beforeEach with this scope access)
  • afterEach: action after the route resolves (cannot affect navigation)

Per Route Guards

  • beforeEnter: action before entering a specific route (unlike global guards, this has access to this)

Component Guards

  • beforeRouteEnter: action before navigation is confirmed, and before component creation (no access to this)
  • beforeRouteUpdate: action after a new route has been called that uses the same component
  • beforeRouteLeave: action before leaving a route

Protecting Routes

To implement them effectively, it helps to know when to use them in any given scenario. If you wanted to track page views for analytics for instance, you may want to use the global afterEach guard, since it gets fired when the route and associated components are fully resolved. And if you wanted to prefetch data to load onto a Vuex store before a route resolves, you could do so using the beforeEnter per route guard.

Since our example deals with protecting specific routes based on a user’s access permissions, we will use in component navigation guards, namely the beforeEnter hook. This navigation guard gives us access to the proper route before the resolve completes; meaning that we can fetch data or check that data has loaded before letting a user pass through. Before diving into the implementation details of how this works, let’s briefly look at how our beforeEnter hook fits into our existing routes file. Below, we have our sample routes file, which has our protected route, aptly named protected. To this, we will add our beforeEnter hook to it like so:

const router = new VueRouter({   routes: [     ...     {       path: "/protected",       name: "protected",       component: import(/* webpackChunkName: "protected" */ './Protected.vue'),       beforeEnter(to, from, next) {         // logic here       }   ] })

Anatomy of a route

The anatomy of a beforeEnter is not much different from other available navigation guards in Vue Router. It accepts three parameters: to, the “future” route the app is navigating to; from, the “current/soon past” route the app is navigating away from and next, a function that must be called for the route to resolve successfully.

Generally, when using Vue Router, next is called without any arguments. However, this assumes a perpetual success state. In our case, we want to ensure that unauthorized users who fail to enter a protected resource have an alternate path to take that redirects them appropriately. To do this, we will pass in an argument to next. For this, we will use the name of the route to navigate users to if they are unauthorized like so:

next({   name: "dashboard" })

Let’s assume in our case, that we have a Vuex store where we store a user’s authorization token. In order to check that a user has permission, we will check this store and either fail or pass the route appropriately.

beforeEnter(to, from, next) {   // check vuex store //   if (store.getters["auth/hasPermission"]) {     next()   } else {     next({       name: "dashboard" // back to safety route //     });   } }

In order to ensure that events happen in sync and that the route doesn’t prematurely load before the Vuex action is completed, let’s convert our navigation guards to use async/await.

async beforeEnter(to, from, next) {   try {     var hasPermission = await store.dispatch("auth/hasPermission");     if (hasPermission) {       next()     }   } catch (e) {     next({       name: "dashboard" // back to safety route //     })   } } 

Never forget where you came from

So far our navigation guard fulfills its purpose of preventing unauthorized users access to protected resources by redirecting them to where they may have come from (i.e. the dashboard page). Even so, such a workflow is disruptive. Since the redirect is unexpected, a user may assume user error and attempt to access the route repeatedly with the eventual assumption that the application is broken. To account for this, let’s create a way to let users know when and why they are being redirected.

We can do this by passing in a query parameter to the next function. This allows us to append the protected resource path to the redirect URL. So, if you want to prompt a user to log into an application or obtain the proper permissions without having to remember where they left off, you can do so. We can get access to the path of the protected resource via the to route object that is passed into the beforeEnter function like so: to.fullPath.

async beforeEnter(to, from, next) {   try {     var hasPermission = await store.dispatch("auth/hasPermission");     if (hasPermission) {       next()     }   } catch (e) {     next({       name: "login", // back to safety route //       query: { redirectFrom: to.fullPath }     })   } }


The next step in enhancing the workflow of a user failing to access a protected route is to send them a message letting them know of the error and how they can solve the issue (either by logging in or obtaining the proper permissions). For this, we can make use of in component guards, specifically, beforeRouteEnter, to check whether or not a redirect has happened. Because we passed in the redirect path as a query parameter in our routes file, we now can check the route object to see if a redirect happened.

beforeRouteEnter(to, from, next) {   if (to.query.redirectFrom) {     // do something //   } }

As I mentioned earlier, all navigation guards must call next in order for a route to resolve. The upside to the next function as we saw earlier is that we can pass an object to it. What you may not have known is that you can also access the Vue instance within the next function. Wuuuuuuut? Here’s what that looks like:

next(() => {   console.log(this) // this is the Vue instance })

You may have noticed that you don’t technically have access to the this scope when using beforeEnter. Though this might be the case, you can still access the Vue instance by passing in the vm to the function like so:

next(vm => {   console.log(vm) // this is the Vue instance })

This is especially handy because you can now create and appropriately update a data property with the relevant error message when a route redirect happens. Say you have a data property called errorMsg. You can now update this property from the next function within your navigation guards easily and without any added configuration. Using this, you would end up with a component like this:

<template>   <div>     <span>{{ errorMsg }}</span>     <!-- some other fun content -->     ...     <!-- some other fun content -->   </div> </template>
<script> export default {   name: "Error",   data() {     return {       errorMsg: null     }   },   beforeRouteEnter(to, from, next) {     if (to.query.redirectFrom) {       next(vm => {         vm.errorMsg =           "Sorry, you don't have the right access to reach the route requested"       })     } else {       next()     }   } } </script>


The process of integrating authentication into an application can be a tricky one. We covered how to gate a route from unauthorized access as well as how to put workflows in place that redirect users toward and away from a protected resource based on their permissions. The assumption thus far has been that you already have authentication configured in your application. If you don’t yet have this configured and you’d like to get up and running fast, I highly recommend working with authentication as a service. There are providers like Netlify’s Identity Widget or Auth0’s lock.

The post Protecting Vue Routes with Navigation Guards appeared first on CSS-Tricks.


, , ,

Using React Loadable for Code Splitting by Components and Routes

In a bid to have web applications serve needs for different types of users, it’s likely that more code is required than it would be for one type of user so the app can handle and adapt to different scenarios and use cases, which lead to new features and functionalities. When this happens, it’s reasonable to expect the performance of an app to dwindle as the codebase grows.

Code splitting is a technique where an application only loads the code it needs at the moment, and nothing more. For example, when a user navigates to a homepage, there is probably no need to load the code that powers a backend dashboard. With code splitting, we can ensure that the code for the homepage is the only code that loads, and that the cruft stays out for more optimal loading.

Code splitting is possible in a React application using React Loadable. It provides a higher-order component that can be set up to dynamically import specific components at specific times.

Component splitting

There are situations when we might want to conditionally render a component based on a user event, say when a user logs in to an account. A common way of handling this is to make use of state — the component gets rendered depending on the logged in state of the app. We call this component splitting.

Let’s see how that will look in code.

See the Pen
by Kingsley Silas Chijioke (@kinsomicrote)
on CodePen.

As a basic example, say we want to conditionally render a component that contains an <h2> heading with “Hello.” Like this:

const Hello = () => { 	return ( 		<React.Fragment> 			<h2>Hello</h2> 		</React.Fragment> 	) }

We can have an openHello state in the App component with an initial value of false. Then we can have a button used to toggle the state, either display the component or hide it. We’ll throw that into a handleHello method, which looks like this:

class App extends React.Component { 	state = { 		openHello: false 	}  	handleHello = () => { 		this.setState({ openHello: !this.state.openHello }) 	} 	render() { 		return ( 			<div className="App"> 				<button onClick={this.handleHello}> 					Toggle Component 				</button>  				{ 					this.state.openHello ? 						<Hello /> 					: null 				} 			</div> 		); 	} }

Take a quick peek in DevTools and take note the Network tab:

Now, let’s refactor to make use of LoadableHello. Instead of importing the component straight up, we will do the import using Loadable. We’ll start by installing the react-loadable package:

## yarn, npm or however you roll yarn add react-loadable

Now that’s been added to our project, we need to import it into the app:

import Loadable from 'react-loadable';

We’ll use Loadable to create a “loading” component which will look like this:

const LoadableHello = Loadable({ 	loader: () => import('./Hello'), 	loading() { 		return <div>Loading...</div> 	} })

We pass a function as a value to loader which returns the Hello component we created earlier, and we make use of import() to dynamically import it. The fallback UI we want to render before the component is imported is returned by loading(). In this example, we are returning a div element, though we can also put a component in there instead if we want.

Now, instead of inputting the Hello component directly in the App component, we’ll put LoadableHello to the task so that the conditional statement will look like this:

{ 	this.state.openHello ? 		<LoadableHello /> 	: null }

Check this out — now our Hello component loads into the DOM only when the state is toggled by the button:

And that’s component splitting: the ability to load one component to load another asynchronously!

Route-based splitting

Alright, so we saw how Loadable can be used to load components via other components. Another way to go about it is us ing route-based splitting. The difference here is that components are loaded according to the current route.

So, say a user is on the homepage of an app and clicks onto a Hello view with a route of /hello. The components that belong on that route would be the only ones that load. It’s a fairly common way of handling splitting in many apps and generally works well, especially in less complex applications.

Here’s a basic example of defined routes in an app. In this case, we have two routes: (1) Home (/) and (2) Hello (/hello).

class App extends Component { 	render() { 		return ( 			<div className="App"> 				<BrowserRouter> 					<div> 						<Link to="/">Home</Link> 						<Link to="/hello">Hello</Link> 						<Switch> 							<Route exact path="/" component={Home} /> 							<Route path="/hello" component={Hello} /> 						</Switch> 					</div> 				</BrowserRouter> 			</div> 		); 	} }

As it stands, all components will render when a use switches paths, even though we want to render the one Hello component based on that path. Sure, it’s not a huge deal if we’re talking a few components, but it certainly could be as more components are added and the application grows in size.

Using Loadable, we can import only the component we want by creating a loadable component for each:

const LoadableHello = Loadable({ 	loader: () => import('./Hello'), 	loading() { 		return <div>Loading...</div> 	} }) const LoadableHome = Loadable({ 	loader: () => import('./Home'), 	loading() { 		return <div>Loading...</div> 	} }) class App extends Component { 	render() { 		return ( 			<div className="App"> 				<BrowserRouter> 					<div> 						<Link to="/">Home</Link> 						<Link to="/hello">Hello</Link> 						<Switch> 							<Route exact path="/" component={LoadableHome} /> 							<Route path="/hello" component={LoadableHello} /> 						</Switch> 					</div> 				</BrowserRouter> 			</div> 		); 	} }

Now, we serve the right code at the right time. Thanks, Loadable!

What about errors and delays?

If the imported component will load fast, there is no need to flash a “loading” component. Thankfully, Loadable has the ability to delay the loading component from showing. This is helpful to prevent it from displaying too early where it feels silly and instead show it after a notable period of time has passed where we would expect to have seen it loaded.

To do that, our sample Loadable component will look like this;

const LoadableHello = Loadable({ 	loader: () => import('./Hello'), 	loading: Loader, 	delay: 300 })

Here, we are passing the Hello component as a value to loading, which is imported via loader. By default, delay is set to 200ms, but we’ve set ours a little later to 300ms.

Now let’s add a condition to the Loader component that tells it to display the loader only after the 300ms delay we set has passed:

const Loader = (props) => { 	if (props.pastDelay) { 		return <h2>Loading...</h2> 	} else { 		return null 	} }

So the Loader component will only show if the Hello component does not show after 300ms.

react-loader also gives us an error prop which we can use to return errors that are encountered. And, because it is a prop, we can let it spit out whatever we want.

const Loader = (props) => { 	if (props.error) { 		return <div>Oh no, something went wrong!</div>; 	} else if (props.delay) { 		return <h2>Loading...</h2> 	} else { 		return null; 	} }

Note that we’re actually combining the delay and error handling together! If there’s an error off the bat, we’ll display some messaging. If there’s no error, but 300ms have passed, then we’ll show a loader. Otherwise, load up the Hello component, please!

That’s a wrap

Isn’t it great that we have more freedom and flexibility in how we load and display code these days? Code splitting — either by component or by route — is the sort of thing React was designed to do. React allows us to write modular components that contain isolated code and we can serve them whenever and wherever we want and allow them to interact with the DOM and other components. Very cool!

Hopefully this gives you a good feel for code splitting as a concept. As you get your hands dirty and start using it, it’s worth checking out more in-depth posts to get a deeper understanding of the concept.

The post Using React Loadable for Code Splitting by Components and Routes appeared first on CSS-Tricks.


, , , , , ,