Pathname Environment, History API and a double click in the back button to go back?

[SofiaGR]

I apologize if this isn't the correct place to ask my question, but I can't seem to figure this out.

I'm currently using version 0.32.2 of the react-router-component and I'm having difficulties with using the History API along with the react-router-component.

I know I'm using the PathnameEnvironment as the default environment since I didn't set hash as true in the Locations, as shown below:

 onBeforeNavigation() {
    var stateObj = { title: '', url: window.location.pathname };
    this.state = stateObj;
    console.log('stateObj pushed: ', stateObj);
    //window.history.pushState(stateObj, stateObj.title, stateObj.url);
  },
onNavigation() {
    console.log('onNavigation: ', this.state);
    window.history.pushState(this.state, this.state.title, this.state.url);
  },
 <Locations onBeforeNavigation={this.onBeforeNavigation} onNavigation={this.onNavigation}>
        <Location path={'/'} handler={Bootstrap} component="Login"/>
        <Location path={'/demo'} handler={Bootstrap} component="Demo"/>
        <Location path={'/test'} handler={Test}/>
 </Locations>

I was looking at one of the tests for PathEnvironment, and tried to somewhat mimic its behavior, but while the react-router-component detects a popstate event, the path isn't changing (I confirmed it by placing a console.log in the popstate listener of PathnameEnvironment)...it only changes if I click twice in the back button. I can also see that whenever I navigate, only one entry is added to the browser's back history button. Am I doing anything wrong or missing anything? :/

[jsg2021]

The history api is used by default as you follow links. Just make links as you normally would (or use the Link component) to pages, and setup a <CaptureLinks> wrapper around your root app element.

[SofiaGR]

Can you provide more information on your solution? I'm not sure how to implement what you described.

I have a component handling redirects that I call when I want to navigate in the app so I'm not using the Link component:

import React from 'react';
import Router from 'react-router-component';

export default React.createClass({
  displayName: 'Redirect',
  mixins: [Router.NavigatableMixin],
  propTypes: {
    force: React.PropTypes.bool,
    location: React.PropTypes.string
  },
  performRedirect (props) {
    this.navigate(props.location, {replace: true});
  },
  startRedirect(p) {
    clearTimeout(this.pendingRedirect);
    this.pendingRedirect = setTimeout(()=> this.performRedirect(p), 0);
  },
  componentDidMount () {
    this.startRedirect(this.props);
  },
  componentWillReceiveProps (props) {
    this.startRedirect(props);
  },
  render () {
    return (
      <div className="loading_logo_div loading_logo_animation">

      </div>
    );
  }
});

Would this component be the reason why the history api isn't working as it should? Perhaps the replace true?

This Redirect component wasn't added by me, hence the odd questions. :/

[SofiaGR]

Looking at the implementation of navigate...it definitely seems like the replace: true is the reason why the back fails...
I'll test that.

[jsg2021]

Redirects are supposed to replace the current entry of history, if you redirect from a route, you aren't supposed to be able to go back... If you are forwarding someone after a condition, you may want to add a prop (defaulted to true) that allows you to use Redirect but not replace history.

[jsg2021]

Nonetheless, you don't need to directly access or use the history api with this component... it handles it for you.

[SofiaGR]

Putting replace as false did allow the history api to work as planned. In this case the redirect is being used to navigate in the app, what could be used instead then?

[jsg2021]

You are using Links primarily to navigate, right? You shouldn't need to programmatically navigate 99% of the time.

Using Redirect to navigate your app in this fashion is fine, I was just suggesting that you make your Redirect optionally not replace history for this (seemingly) one off case. (Redirects are typically route replacements, not additional routes...and you typically don't want the back button landing you on that route again)