[gatsby-plugin-react-next] <Link>'s activeClassName not respected, when pathPrefix is used

Description

When using gatsby-plugin-react-next and pathPrefix, activeStyle or activeClassName are not taken into account when page is initial loaded. Only after manual triggering navigation, activeStyle or activeClassName are respected.

Environment

Gatsby version: 1.9.135 Node.js version: 8.7.0 Operating System: macOS 10.13.2

File contents (if changed):

gatsby-config.js:

module.exports = {
  siteMetadata: {
    title: `Gatsby Default Starter`,
  },
  plugins: [
      `gatsby-plugin-react-helmet`,
      `gatsby-plugin-react-next`,
    ],
  pathPrefix: `/my-gatsby-site`,
}

package.json:

{
  "name": "gatsby-starter-default",
  "description": "Gatsby default starter",
  "version": "1.0.0",
  "author": "Kyle Mathews <[e-mail]>",
  "dependencies": {
    "gatsby": "^1.9.135",
    "gatsby-link": "^1.6.32",
    "gatsby-plugin-react-helmet": "^1.0.8",
    "gatsby-plugin-react-next": "^1.0.6"
  },
  "keywords": [
    "gatsby"
  ],
  "license": "MIT",
  "main": "n/a",
  "scripts": {
    "build": "gatsby build",
    "develop": "gatsby develop",
    "format": "prettier --trailing-comma es5 --no-semi --single-quote --write \"src/**/*.js\"",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "devDependencies": {
    "prettier": "^1.9.2"
  }
}

Actual result

Active Links should be styled bold - also on initial page load and not only after navigation did occur. Testlink: http://gatsbynext-router.surge.sh/my-gatsby-site/page-2

Expected behavior

Same example as above, but without gatsby-plugin-react-next. Testlink: http://gatsbynext-router-react15.surge.sh/my-gatsby-site/page-2

Steps to reproduce

1. Setup new vanilla gatdbyJS project

2. Add gatsby-plugin-react-next plugin

3. Make use of activeStyle or activeClassName at the <Link> components, that come with the gatsbyJS boilerplate. Eg page-2.js:

<Link activeStyle={{ fontWeight: 'bold' }} to="/">
  Go back to the homepage
</Link>
<br />
<Link activeStyle={{ fontWeight: 'bold' }} to="/page-2/">
  Go to page 2
</Link>

1. Add a pathPrefix (see gatsby-config.js above) and build a production version of the project using gatsby build --prefix-paths

2. See result using eg. gatsby serve and test it by initialting page refreshes and navigation

mv public my-gatsby-site                                                                                                                                                                                    
mkdir public                                                                                                                                                                                               
mv my-gatsby-site public                                                                                                                                                                                    
gatsby serve

[th0th]

Link’s behaviour has changed when reach/router has replaced react-router. @KyleAMathews mentioned here that new Link won’t get that capability. So I wrote my custom Link wrapper, here it is in case someone else needs:

import React from 'react';
import PropTypes from 'prop-types';
import {
  Link as GatsbyLink,
} from 'gatsby';

export default function Link(props) {
  const {
    exact,
    className,
    activeClassName,
    children,
  } = props;

  return (
    <GatsbyLink
      {...props}
      getProps={({ isCurrent, isPartiallyCurrent }) => ({
        className: [
          className,
          (exact && isCurrent) ? activeClassName : '',
          (!exact && isPartiallyCurrent) ? activeClassName : '',
        ].join(' ').trim(),
      })}
    >
      {children}
    </GatsbyLink>
  );
}

Link.propTypes = {
  exact: PropTypes.bool,
  className: PropTypes.string,
  activeClassName: PropTypes.string,
  children: PropTypes.node.isRequired,
};

Link.defaultProps = {
  exact: false,
  activeClassName: 'active',
  className: '',
};

[zebapy]

Also encountering this (active links don’t get styles on page refresh until client route changes happen). @ooloth’s problem is something other than the original issue I believe.