DEV Community: Jeremias Menichelli

How to write a go back button for JavaScript applications

Jeremias Menichelli — Tue, 30 Jun 2020 10:30:48 +0000

Going to the previous screen is such a common action on the web it has a dedicated button in baked in all browsers. Still, some web apps benefit from indicating this action in their interface, but writing a back button that avoids race conditions and hydration issues might be more complicated than it looks like.

We don’t need back and forward actions to be present in our applications, but in some cases, it makes sense to include a back button, Chris Coyer puts this better than me.

Browsers already have “back” buttons, so you’d better have a darn good reason

In previous articles, I described a progressive enhancement approach for React applications including form validation, taking care of accessibility from the very first moment we start developing.

The application I built for these examples has a specific view for a single search result, without a button to go back to the previous results, the context of a previous search action felt missing.

Writing the go back button

To build this component we are going to start with the HTML, as it is a navigation action it makes sense for this back button to be represented with an anchor element.

import React from 'react'
const BackButton = () => {
  return <a href="/">Go back</a>
}

Though we are going to override the behavior of the anchor with JavaScript, it’s important to put something inside its href attribute.

If you are doing server-side rendering, this will be the fallback route the user will navigate to in case they click it before the bundle is ready.

Back in history with JavaScript

There’s more than one way to achieve this, as all of them are similar let’s go with the basic one you might find while searching.

function goBack(evt) {
  // ignore the native anchor action
  evt.preventDefault()
  history.back()
}

If you are using a routing library like React Router or even routers present in frameworks like Next.js you might be able to do something similar to the following.

import Router from 'next/router'
function goBack(evt) {
  // ignore the native anchor action
  evt.preventDefault()
  Router.back()
}

Check the documentation of the routing library or framework you are using, but big chances are their back method is just wrapping internally history.back anyways.

The next thing to do is bind this method to our component.

const BackButton = () => {
  return (
    <a href="/" onClick={goBack}>
      Go back
    </a>
  )
}

If you are relying completely on client-side rendering and giving your users a white screen until your bundle loads, then this is all you are going to need. The article might as well end here.

But following the same tone of previous articles I wrote, I don’t want to take JavaScript for granted. Even if I think all my users will have JavaScript enabled, building solutions not depending on it usually leads to more foolproof outcomes, covering edge cases, and providing better accessibility.

Navigation and request headers

Every time navigation —or any network request— takes place in browsers headers are sent to the server, and the response from the server comes with headers too.

HTTP Headers are a set of keys and content we can send to or read from the server request, these parameters describe more in-depth the network transaction.

One of those headers is the referer, indicating which URL requested the page you are navigating to, which might come handy here to know the location to go back to.

Reading headers in Next.js

In Next.js, when the getInitialProps method runs on the server it receives a request object names req containing a headers property.

We can check for a referer value to pass it down to the page component.

import React from 'react'
import BackButton from '../components/back-button'
export default const SearchResultPage = ({ data, referrer }) = {
  return (
    <>
      <BackButton referer={referrer} />
      <SearchResult data={data} />
    </>
  )
}
SearchResultPage.getInitialProps = ({ req }) => {
  let referrer
  if (req) {
    // referer is a known mispelling in the spec
    referrer = req.headers.referer
  }
  const response = await fetch('your.api/endpoint')
  const data = await response.json()
  return { data, referrer }
}

When defined, this newly added referrer prop is used as the href fallback value in our back button component.

const BackButton = ({ referrer }) => {
  const href = referrer ? referrer : '/'
  return (
    <a href={href} onClick={goBack}>
      Go back
    </a>
  )
}

You might have noticed we check if req is defined inside the getInitialProps method. As I said, this header is present when the request reaches the server.

If the navigation happens with JavaScript already loaded then client-side routing will handle it, and the request object won’t be there because the server didn’t play any part.

The good thing is, it would mean the user has JavaScript enabled and they are on a decent connection, and our initial goBack function will probably take care of the situation without the need of the referrer value.

Accessibility improvements

A bit of quick advice to improve accessibility for this component would be to add an aria-label extending the context of the navigation.

const BackButton = ({ referrer, searchQuery, resultPage }) => {
  const href = referrer ? referrer : '/'
  const ariaLabel = `Go back to page ${resultPage} of ${searchQuery} search`
  return (
    <a href={href} ariaLabel={ariaLabel} onClick={goBack}>
      Go back
    </a>
  )
}

It might not seem necessary, but a more complete announcement in screen readers will help assisted users to know exactly where they are heading if they hit the link.

Is this worth it?

I started this quest as an experiment to push myself to learn new patterns, but I also mentioned the number of users with JavaScript disabled might just be none for your project. Then, is all of this needed?

A situation, where the referrer approach will action, might be rare. For example, imagine user taps a link of a search result when the application bundle is still loading, then the navigation will happen without client-side routing, a full reload will trigger and the server will be in charge of resolving the request.

The new page will include the referrer value and have a working back button, even if the user taps the link before the JavaScript for that new page is ready.

If in this result page the JavaScript gets the chance to load, then our click event will catch it.

Gotchas

The solution proposed in this article is more resilient, but it’s still not perfect. Here are some reasons why.

History discrepancy

If we disable JavaScript entirely while testing this approach, going through a search result, click the link with the referer value and then pressing the back button from the browser will take the user back to the result page instead of the previous search page.

This is a scenario that JavaScript handles better.

Hopefully, your users won’t adhere much to this specific list of actions. A solution to this doesn’t exist right now, I would love for a way to define this behavior by an attribute in the anchor, though I admit it can open possibilities for anti-patterns in user experience around navigation.

Security

This approach won’t affect the security status of your application, whether it is already good or bad, but security measures can make it not possible to implement.

There is a Referrer-Policy one which defines the content of the Referer header. If the value of the policy header is no-referrer for example, then Referer won’t be present at all in the requests.

Wrap-up

Using the browser’s navigation buttons on content sites comes naturally as a user to me, but when sites have more an application goal, a back button might help by highlighting a clearer action to the user.

When doing so, we can make use of web technologies to make sure we provide a resilient component that handles edge cases combining headers and server-side logic.

You can see this working in the repository of the application I built to explore progressive patterns inside React applications.

CSS-only form validation, the required attribute and the valid selector

Jeremias Menichelli — Tue, 26 May 2020 12:02:55 +0000

Article originally posted at jeremenichelli.io

A common issue in server-side rendered applications is the effects of late hydration. While users wait for JavaScript to be parsed and run, buttons don't work even though they are present, leading to a frustrating experience.

Usually, the initial state of a form is invalid, how do you re-enable a disabled button on a server-side rendered React application?

Validation is needed, we want to make sure we have all the data we need in the right shape before sending it to our services. In addition, we want to provide visual hints to the user about what actions can be taken or not at a certain moment in a form.

In my previous article I explored an approach for progressive enhancement in a React application. There I’m using a third-party service that has a rate limit and I have no control over, so preventing unwanted calls was necessary.

The hydration paradox

The easiest way to make sure a button doesn’t work is by disabling it. An given the only case I want to prevent a submit is when the search input is empty it’s tempting to disable the button when the value is falsy.

const Index = () => {
  const [search, setSearch] = useState('')

  return (
    <form action="?" onSubmit={onSubmit}>
      <input
        name="search"
        value={search}
        onChange={(evt) => setSearch(evt.target.value)}
      />
      <button disabled={!search} type="submit">
        Search
      </button>
    </form>
  )
}

In the input element, when the search state is an empty string the button will get disabled and the user won’t be able to trigger a submission.

There are two issues in this approach:

The first one is, we previously made sure the form was accessible and keyboard friendly, so the user can still trigger a request by pressing the return key.
Even more important, the second issue is what happens if your user gets our server-side rendered application, and while the bundle is still loading writes something on the input but the button is still shown as disabled.

This is a typical hydration issue, the interface is painted but needs JavaScript to be interactive. We think we are improving the user experience by sending something ahead of time, but we are creating this uncanny valley of user interaction until the bundle loads.

This behavior can be observed by disabling JavaScript on the live example from the code above. The button is disabled forever because the server sent this initial markup, but React never has the chance to re-evaluate the state of our application.

The premise in my previous article was to not rely on the main bundle for the application to work. How can we toggle this button state without JavaScript? How can we make sure keyboard behavior matches the cursor one?

Native form validation in the browser

It is possible to circumvent the need for JavaScript to block our search form submission. A while ago the Constraint Validation API was released and implemented in browsers.

It contains a set of methods and properties in form elements to know if they pass a set of patterns and configurations.

For example, we can set any type of input as required.

<input type="text" required />

We can go further and require a minimum length and even pass a regular expression as a pattern to be tested against the value of the element.

<input type="text" required minlength="2" pattern="\[A-Z\][a-z]+" />

In this case, we are requiring at least two characters and the first one to be uppercase.

In JavaScript, we have a set of methods to check if the current value of a given element is valid and set a custom error message. The Constraint Validation API is a powerful one, and I strongly encourage developers to read and remember for projects.

Along with its release, a useful set of new selectors came to the CSS spec. We can detect which elements are valid or not, and even if forms are valid.

We definitely can’t change the value of an attribute in a form element with CSS, but now with the :valid and the :invalid selectors in combination with other operators we can prevent actions in the button.

const Index = () => {
  const [search, setSearch] = useState('')

  return (
    <form action="?" onSubmit={onSubmit}>
      <input
        required
        name="search"
        value={search}
        onChange={(evt) => setSearch(evt.target.value)}
      />
      <button type="submit">Search</button>
    </form>
  )
}

First in our form, we need to mark the search input as required.

Later, in our styles we set a button with an invalid input as a previous sibling should show as disabled and not trigger actions.

input:invalid + button {
  opacity: 0.5;
  pointer-events: none;
}

If you have a form with a more complex structure, you might want to use more specific selectors and better check the validation state of the form itself.

form.form__with-validation:invalid button.submit__button {
  opacity: 0.5;
  pointer-events: none;
}

See this example in action

This is indeed a really simple case to solve. Gladly, this specification contains a pretty wide range of attributes to combine and helpful JavaScript methods in case you want to provide a more custom experience.

Important to mention all of this has pretty decent browser support too.

Wrap-up

Following the trend of my previous article, and probably the next one, ruling out JavaScript as a given commodity opens a lot of exploration on what we are given out-of-the-box by the browser, and build on top of it.

You can see this validation strategy working in the application I’m using as a base for this series of articles.

If you are interested in going more in-depth into this, I strongly suggest the Client-side form validation article on MDN. It goes step by step on a more complete approach and covers more features from this specification.

A progressive search experience in Next

Jeremias Menichelli — Sun, 24 May 2020 15:08:30 +0000

Article originally posted at jeremenichelli.io

One of the most controversial topics in web development today is the amount of client code we send with our applications. Some people put frameworks to blame, but is the solution to stop using them or should we think better how we build features on top of them?

In this article I will explore the idea of a progressively enhanced approach for a search experience, using the browser's native behavior first, giving control back to JavaScript only when needed.

We will see how using the web platform as a base is a great option to write less code on the client while providing a good experience for users, even without JavaScript enabled.

A world with no JavaScript

It sounds horrifying, isn't it? But don't worry, JavaScript is going nowhere.

And it shouldn't, it’s one of the reasons why building on the web is great today, but it's not the only tool we have available and it's usually a pretty critical one.

Nevertheless, we keep building sites and implementing new features with the thought that JavaScript will always be there. I remember talking about this with Harry Roberts and he said to me:

"I’m willing to bet you have more IE6 visitors than disabled-JavaScript-on-purpose visitors. Your IE6 policy is probably ‘forget it’, so why would your disabled-JavaScript-on-purpose policy be any different?"

There are a lot of chances this is true for most of the projects out there, and it makes you question why we should even bother to support a JavaScript-disabled scenario. Later, he closes his quote with this:

"As Jake Archibald said, ‘[…] all your users are non-JavaScript while they're downloading your JavaScript’. So while I don’t think we should build or optimize for visitors who have disabled JavaScript, we shouldn’t make too many assumptions that our JavaScript will always work as we expect."

We do rely more and more on client code, and it's a trend that seems to not stop soon. It gave me a lot of thinking as someone who started coding when frameworks weren't a big thing.

What if we lean back on the platform while still using them only to fill the gaps and improve things? Will that strategy translate into less and even better code or will this impact negatively the user experience?

Back to the progressive mindset

When I became a web developer, there were two terms which got repeated pretty often, like mantras to have present every time you were building something.

One was graceful degradation, a concept in computing and electronic systems where they are still useful or functional even if some parts are not working correctly or have been removed.

The second one was progressive enhancement, a strategy of prioritizing web content delivery first and start adding improvements to the experience as the user could afford them or as they were supported.

Keeping these two concepts close, let's dive into a search application with form submission, data fetching, paged results, and URL persistence.

To start, let's disable JavaScript in the browser.

Form submission and accessibility

As a first building block, I'm choosing Next, a framework built on top of React. Since I won't have JavaScript available on the client I need a stack that gives me control on the server-side.

On the index page, we start with the basic set of elements to get input from the user and fetch data later. If we forget about our premise in this article and assume JavaScript is there, we only need an input element and a button.

import React, { useState } from 'react'

const Index = () => {
  const [search, setSearch] = useState('')

  function onSubmit(search) {}

  return (
    <>
      <input value={search} onChange={(evt) => setSearch(evt.target.value)} />
      <button onClick={() => onSubmit(search)}>Search</button>
    </>
  )
}

export default Index

Is the name attribute in our input necessary? Do we need to wrap everything in a form? What about setting the action on the form? The short answer is, to fetch data with JavaScript, you don't need any of those.

But in the same way you have to write back all the native functionality of a button element when using a div, writing a semantically correct form will save you from a lot of heavy lifting while enabling a better and more accessible experience at the same time.

import React, { useState } from 'react'

function onSubmit() {}

const Index = () => {
  const [search, setSearch] = useState('')

  return (
    <form action="?" onSubmit={onSubmit}>
      <input
        name="search"
        value={search}
        onChange={(evt) => setSearch(evt.target.value)}
      />
      <button type="submit">Search</button>
    </form>
  )
}

export default Index

See this example in action

A button alone does nothing without JavaScript, like in the first code example.

In the second one, things are different. Users can submit by clicking, and even by using a keyboard. More importantly, we moved from an inert application to one that does something, all without a single line of code on the client.

Right now our application does one thing, after the user submits the page refreshes but now with the search value appended to the URL, which gives us back the control on the server-side.

We can see now the importance of the name and action attributes.

Fetching data on the server side

After a search submission, a page request hits the server. There we can inspect the new parameters in the URL to know what data to fetch.

For this, we are going to use a method called getInitialProps provided by Next, really convenient as it runs on each page request but also on route changes, useful to enhance the experience for users with JavaScript.

Index.getInitialProps = async ({ query }) => {
  const currentSearch = query.search
}

getInitialProps receives a context argument, this object holds a collection of properties including the query section of the URL, which here contains the information from the form submitted by the user.

We use the search value of the query to request data from another service and return an object with the result, Next passes this object to the page component as props.

As an example, we use the Open Movie Database API service.

import unfetch from 'isomorphic-unfetch'

Index.getInitialProps = async ({ query }) => {
  const currentSearch = query.search

  if (!currentSearch) return {}

  const searchUrl = `//www.omdbapi.com/?s=${currentSearch}`
  const response = await unfetch(searchUrl)
  const results = await response.json()

  return {
    currentSearch,
    pageResults: results.Search
  }
}

An undefined search value indicates we aren’t coming from a form submission, so we return an empty object.

Inside our Index page component we inspect the value of the current search passed by the getInitialProps method and iterate over the data to show the results.

import React, { useState } from 'react'
import Link from 'next/link'

function onSubmit() {}

const Index = (props) => {
  const { pageResults, currentSearch } = props
  const [search, setSearch] = useState('')

  return (
    <>
      <form action="?" onSubmit={onSubmit}>
        <input
          name="search"
          value={search}
          onChange={(evt) => setSearch(evt.target.value)}
        />
        <button type="submit">Search</button>
      </form>
      {currentSearch && (
        <ul>
          {pageResults.map((result) => (
            <li>
              <Link key={result.id} href={`/movie/${result.id}`}>
                {result.Title}
              </Link>
            </li>
          ))}
        </ul>
      )}
    </>
  )
}

Enhancing this for JavaScript-ready users is surprisingly straight-forward.

Because we have the logic already set in place, instead of re-implementing everything again we prevent the submit default behavior, serialize the form data and push a route change, getInitialProps handles the rest.

import Router from 'next/router'

function onSubmit (evt) {
    evt.preventDefault()
    const formData = new FormData(evt.target)
    const searchQuery = formData.get('search')
    const url = `/?search=${searchQuery}`
    Router.push(url)
}

Relying completely on the event dispatching and its target, which both come built-in, and delegating the navigation to Next’s router keeps the client side of the code minimal.

The web does the heavy lifting, our client code is there to enhance the experience

Approaches like these aren’t seen much because we tend to build solutions with JavaScript first in mind. Shifting that initial approach changes drastically the outcome in code for similar or identical tasks, tasks as common as fetching data and URL persistence.

Pagination of data results

Similar to how we look up inside the context parameter to extract the search query, to enable specific page results we need to inspect this object and look for a page key.

Back inside getInitialProps we check for this value in the query property and construct the correct URL to hit the service.

Index.getInitialProps = async ({ query }) => {
  const currentSearch = query.search

  if (!currentSearch) return {}

  const currentPage = query.page ? +query.page : 1

  const searchUrl = `//www.omdbapi.com/?s=${currentSearch}&page=${currentPage}`

  const response = await unfetch(searchUrl)
  const results = await response.json()

  const RESULTS_PER_PAGE = 10
  const hasNextPage = RESULTS_PER_PAGE * currentPage < results.totalResults
  const hasPrevPage = currentPage > 1

  return {
    pageResults,
    totalResults: results.totalResults,
    currentSearch,
    nextPage: hasNextPage ? currentPage + 1 : null,
    prevPage: hasPrevPage ? currentPage - 1 : null
  }
}

By making page an optional key we still support our initial flow as we obtain the same result with ?search=batman and ?search=batman&page=1, later in the method we use the totalResults number to determine if there’s a next page, and a previous page in case the current page is higher than one.

We use again the data returned by getInitialProps in the page component to construct those links to different results pages.

import Link from 'next/link'

const Index = (props) => {
  const { pageResults, currentSearch, prevPage, nextPage } = props
  const [search, setSearch] = useState('')

  return (
    <>
      <form action="?" onSubmit={onSubmit}>
        <input
          name="search"
          value={search}
          onChange={(evt) => setSearch(evt.target.value)}
        />
        <button type="submit">Search</button>
      </form>
      {currentSearch && (
        <ul>
          {pageResults.map((result) => (
            <li>
              <Link key={result.id} href={`/movie/${result.id}`}>
                {result.Title}
              </Link>
            </li>
          ))}
        </ul>
      )}
      {prevPage && (
        <Link href={`/?search=${currentSearch}&page=${prevPage}`}>
          {`Page ${prevPage}`}
        </Link>
      )}
      {nextPage && (
        <Link href={`/?search=${currentSearch}&page=${nextPage}`}>
          {`Page ${nextPage}`}
        </Link>
      )}
    </>
  )
}

Link components are rendered as anchor elements, so navigation through page results will work perfectly without client code.

For users with JavaScript, links will trigger a route change in Next's router logic, passing through getInitialProps in a single page application experience.

Wrap-up

One of the motivations for writing this was the constant battle I see around frameworks and their impact in accessibility and performance.

I don’t think frameworks are evil, though I do believe we need to advocate and educate more around the fundamentals of the web and how it works. This will help us developers make smarter decisions, write better code and create more accessible products.

Writing better HTML might help you by having to write less JavaScript in the end

Though it is a simplified case, the experience of tackling common features in a web application with a more incremental approach did produce better and simpler client code.

This as a starting point is better than breaking or reinventing web fundamentals and try to patch them back again with even more client code.

I encourage you to explore its code base here in its repository or even try the full application experience at muvi.now.sh, or what’s better do it with JavaScript disabled.

It’s the web, built using a framework, and it just works.

DEV Community: Jeremias Menichelli

How to write a go back button for JavaScript applications

Writing the go back button

Back in history with JavaScript

Navigation and request headers

Reading headers in Next.js

Accessibility improvements

Is this worth it?

Gotchas

History discrepancy

Security

Wrap-up

Further reading

CSS-only form validation, the required attribute and the valid selector

The hydration paradox

Native form validation in the browser

Wrap-up

A progressive search experience in Next

A world with no JavaScript

Back to the progressive mindset

Form submission and accessibility

Fetching data on the server side

Pagination of data results

Wrap-up