How do I navigate to another page in React or Vue?

Congratulations, you started working with one of the popular front-end frameworks. Both Vue and React are excellent choices to create rich and reactive applications. But sometimes, you ‘just’ want to show the user another page. Whether it is a simple about page, or another ‘section’ in the app. In this post I will cover both Vue en React and, little bonus, “React on steroids”, NextJS.

It is important to know that you need a router to make in-app pagination work. If you look up router and your favourite framework you’re probably find a way to do it, accompanied with some ways to actually not do it. Hence, here I’ll focus on the right way.

The basics of every link

While you can make everything clickable (or touch-able), it is important that enabling navigation between pages was already a core concept when the web was invented. Even when writing webpages using React, Vue, or most other JavaScript frameworks, it ends up as HTML to the browser (with JavaScript & CSS). HTML stands for Hyper Text Markup  Language and HyperText is text with hyperlinks. Hyperlinks in HTML are written as follows:

<a href="https://example.com">Example link</a>

So why is this important? On parsing code presented as above, the browser does the following:

  • It colours the links (typically) blue & underlines them (styles them as links).
  • On mouse-over you get a little hand-pointer
  • When using the keyboard you can ‘tab’-to the link.
  • Text-to-speech engines can announce it as being a link
  • Search engines can follow the link (may, but not always, require server-side rendering)

While the code above looks easy, it is easy with modern frameworks to create something like this:

<div onclick="open('https://example.com')">Example link</div>

This is clickable, and yes, it might navigate you to example.com, but shares none of the desirable characteristics of the well known hyperlink.

The boring fact

The boring fact is that the above code, yes with the <a href=..., works in every framework. In the next few posts I’ll dive into the ways to make it  work more natively in the frameworks mentioned earlier, often resulting in much faster page loads when you stay within your React/Vue or whatever application. Also, I’ll give a bit of a review of the good parts of these and make sure you don’t use the bad parts (if any). To stay up to date, make sure you subscribe to my mailinglist!




Should I use styled components?

You may have asked yourself if you shouldn’t invest more time getting started with this thing called styled components (or CSS-in-JS). They get heavily promoted in modern front-end application frameworks. And sure, they look interesting.

While it depends may be the only right answer, sometimes you might be simply making things more difficult than really needed. You’re fixing the wrong problem.

Take for example the SCSS code.

$blue = #5DBCD2;

@mixin button-styles($bg-color, $color) {
  background: $bg-color;
  color: $color;
  border: none;
  border-radius: 0.20em;
  &:hover{
      background: darken($bg-color, 6%);
      cursor: pointer;
  }
}

.button {
  @include button-styles(#ddd, black)
}

.button--primary {
  @include button-styles($blue, white)
}

To pair with a simple component along the lines of:

const Buttons = props => (
  <>
    <button className="button">Default</button>
    <button className="button--primary">Primary</button>
  </>
)
export default Buttons

It looks like smart reuse of a button-style mixin, saving you to type things twice. It also looks smart, because it seems to follow a well established naming convention called BEM (although is it really BEM?).

The code above was inspired by an online discussion. The author suggested something along the lines of:

import themeVars from "myTheme"
import styled from "styled-components"
import { darken } from "polished"

const Button = styled.button`
  background: ${({ background }) => background || "#ddd"};
  color: ${({ color }) => color || "black"};
  border: none;
  border-radius: 0.25em;
  :hover {
    background: ${({ background }) => darken(0.05, background || "#ddd")};
  }
`

const Buttons = () => {
  const { blue } = themeVars.colors;
  return (
    <>
      <Button>Default</Button>
      <Button background={blue} color={"white"}>Primary</Button>
    </>
  )
}
export default Buttons

You might think this is better when you’re used to writing the earlier mentioned SCSS/SASS, because it skips the ‘unnecessary’ translation to primary/default button classes. It may not be smaller in line length, but everything is nicely packed together as a single component. Ready for re-use. By including a theme object, it is easy to reuse elements and colours, useful to keep things consistent. You could even use it to pull out default margin’s and radia.

Well. Learn CSS again. There is a C in CSS, the cascade. Inheritance is built-in.

With good ol’ CSS you’d write:

.button {
  background: #ddd;
  color: #000;
  border: none;
  border-radius: 0.25em;
  &:hover{
      background: #ccc; /*estimation*/
      /* cursor: pointer; <- also don't: another discussion */
  }
}

.button--primary {
  background: #5DBCD2;
  color: #fff;
  &:hover{
      background: #4DACC2; /*estimation*/
  }
}

The HTML would be:

<button class="button"></button>
<button class="button button--primary”></button>

I also fixed classes here to make it proper BEM. In BEM, what the original author seems to be using, learns that modifiers modify, they are not the full styled element itself. Let’s not over duplicate & complicate things.