Does v6 drop support for class components?

[AbrahamLopez10]

First of all, thank you for making react-router available to the world :)

I'm not sure if this is the best place to ask about this but given that this is monitored by the maintainers I figured I could put my question here.

My question is around the fact that based on the currently available documentation for v6 (the migration/upgrade guide) react-router v6 seems to drop out-of-the-box support for class components and all the codebases that already have plenty of them (like ours) due to the following changes:

1. Dropping support for the render prop in the Route component, which we are using with react-router v5 to pass params to the component (through props.match.params) of the route.

2. Replacing the use of History (which was passed as a prop to our components automatically in v5) with the new NavigateFunction and the fact that it's only available through the useNavigate hook which of course is not accessible to class components.

Could someone shed the light on this and the future of react-router for all of us who are using class components and will most likely stick with using them for the foreseeable future?

Thanks in advance.

[afoures]

I think that they are aware of this, and willing to do their best to make the transition as smooth as possible, check this tweet: https://twitter.com/mjackson/status/1448107013741989888?s=20

[timdorr]

Hooks are the preferred API nowadays and are the main API surface in v6. The easiest way to get access to them is the same as any other hook, just wrap your class component with a functional component that passes along hook values as props:

const WrappedComponent = props => {
  const history = useHistory()
  const location = useLocation()

  return <Component history={history} location={location} {...props} />
}

You can also use more generic HOCs, like withRouter from v5, to pass along hooks to any component. This applies to any hook, not just React Router's.

[AbrahamLopez10]

@timdorr Thanks. So will withRouter still be available in v6? My concern was around having some kind of support or adapter like this HOC for class components in v6, as introducing backwards incompatibility with class components or making it unnecessarily difficult to integrate with would be a serious regression for v6 when compared to v5.

BTW, "preferred" is relative to who you ask, though. It may be popular with several groups of developers but many other developers that come from backgrounds where classes are heavily used (e.g. .NET, Java, iOS development, etc.) are still working with and prefer class components. I see the value in using hooks in some scenarios but it's not a silver bullet and class components are a better approach in several cases.

[timdorr]

I don't know if it will be available in v6. Likely it will be provided in some sort of support package to aid with the transition to the v6 APIs (react-router-compat, react-router-extras, or something like that).

[mjackson]

We are absolutely not dropping support for class-based components, @AbrahamLopez10, but I think the API changes you pointed out do tend to illustrate some of the value of hooks.

For example, in a world without hooks it makes a lot of sense to use render props instead of a hook. This is because the router knows some state and it needs a way to expose it to you so it can pass it through to your component, so a render prop makes it easy to do so.

<Route
  path="posts/:id"
  render={({ match }) => <BlogPost id={match.params.id} />}
/>

class BlogPost extends React.Component {
  render() {
    let { id } = this.props;
    // ...
  }
}

However, in a world with hooks, we don't need a render prop for exposing state. Instead, you can just use the hook in your component directly.

<Route path="posts/:id" element={<BlogPost />} />

function BlogPost() {
  let { id } = useParams();
  // ...
}

In addition to eliminating the need for render props for sharing state, hooks also eliminate a lot of other prop-passing boilerplate code in other components that are rendered by <BlogPost>. For instance, without hooks if you wanted to pass the id URL param down to another component, you'd probably do something like this:

class BlogPost extends React.Component {
  render() {
    return (
      <div>
        <PostHeader id={this.props.id} />
        {/* ... */}
      </div>
    );
  }
}

class PostHeader extends React.Component {
  render() {
    let { id } = this.props;
    // ...
  }
}

But with hooks, it's as simple as:

function BlogPost() {
  return (
    <div>
      <PostHeader />
      {/* ... */}
    </div>
  );
}

function PostHeader() {
  let { id } = useParams();
  // ...
}

Anyway, that's my sales pitch for using hooks. I totally understand if you don't want to use them, but I think you could probably eliminate some of the boilerplate from your code if you did.

As for shipping a withRouter-style HOC with v6, we can probably do that if you really need one. But we would probably spend a bunch of time bike-shedding all the stuff you want to include in your HOC props (do you want the history? the match? just the params?) when in reality it's really easy to just make your own HOC that is custom designed for the pieces you need.

For example, you could make your own withNavigation or withParams HOC in a one-liner (again, thanks to the power of hooks!):

// in hocs.js
function withNavigation(Component) {
  return props => <Component {...props} navigate={useNavigate()} />;
}

function withParams(Component) {
  return props => <Component {...props} params={useParams()} />;
}

// in BlogPost.js
class BlogPost extends React.Component {
  render() {
    let { id } = this.props.params;
    // ...
  }
}

export default withParams(BlogPost);

Hopefully that helps you understand what we are thinking with v6. It's a low-level library and the hooks are a nice low-level abstraction that should allow you to build whatever you can think of and use whatever API you're most comfortable with, even if you decide to stick with class components.

[AbrahamLopez10]

@mjackson Many thanks for the detailed clarification and the specific examples you provided, they were really helpful to clear my doubts.

I think if this info could be included in the v6 documentation to give peace of mind and direction to other developers who want or need to stick with class components it would be awesome so no one is left confused or discouraged by the hooks-centric approach in v6 😄

[paztis]

It is easy to type it in javascript.
But less in typescript. Can you provide the correct signature for this ?

something like this ?

type TParamsProps = {
    params: Params<string>;
}

function withParams<P extends TParamsProps> (Component: ComponentType<P>): ComponentType<Omit<P, keyof TParamsProps>> {
    return props => <Component {...props} params={useParams()} />;
};

[yazdog8]

We are absolutely not dropping support for class-based components, @AbrahamLopez10, but I think the API changes you pointed out do tend to illustrate some of the value of hooks.

For example, in a world without hooks it makes a lot of sense to use render props instead of a hook. This is because the router knows some state and it needs a way to expose it to you so it can pass it through to your component, so a render prop makes it easy to do so.

<Route
  path="posts/:id"
  render={({ match }) => <BlogPost id={match.params.id} />}
/>

class BlogPost extends React.Component {
  render() {
    let { id } = this.props;
    // ...
  }
}

However, in a world with hooks, we don't need a render prop for exposing state. Instead, you can just use the hook in your component directly.

<Route path="posts/:id" element={<BlogPost />} />

function BlogPost() {
  let { id } = useParams();
  // ...
}

In addition to eliminating the need for render props for sharing state, hooks also eliminate a lot of other prop-passing boilerplate code in other components that are rendered by <BlogPost>. For instance, without hooks if you wanted to pass the id URL param down to another component, you'd probably do something like this:

class BlogPost extends React.Component {
  render() {
    return (
      <div>
        <PostHeader id={this.props.id} />
        {/* ... */}
      </div>
    );
  }
}

class PostHeader extends React.Component {
  render() {
    let { id } = this.props;
    // ...
  }
}

But with hooks, it's as simple as:

function BlogPost() {
  return (
    <div>
      <PostHeader />
      {/* ... */}
    </div>
  );
}

function PostHeader() {
  let { id } = useParams();
  // ...
}

Anyway, that's my sales pitch for using hooks. I totally understand if you don't want to use them, but I think you could probably eliminate some of the boilerplate from your code if you did.

As for shipping a withRouter-style HOC with v6, we can probably do that if you really need one. But we would probably spend a bunch of time bike-shedding all the stuff you want to include in your HOC props (do you want the history? the match? just the params?) when in reality it's really easy to just make your own HOC that is custom designed for the pieces you need.

For example, you could make your own withNavigation or withParams HOC in a one-liner (again, thanks to the power of hooks!):

// in hocs.js
function withNavigation(Component) {
  return props => <Component {...props} navigate={useNavigate()} />;
}

function withParams(Component) {
  return props => <Component {...props} params={useParams()} />;
}

// in BlogPost.js
class BlogPost extends React.Component {
  render() {
    let { id } = this.props.params;
    // ...
  }
}

export default withParams(BlogPost);

Hopefully that helps you understand what we are thinking with v6. It's a low-level library and the hooks are a nice low-level abstraction that should allow you to build whatever you can think of and use whatever API you're most comfortable with, even if you decide to stick with class components.

For some of us it's a matter of transitioning a code base that had used class to use hooks and it all can't be transitioned at once. We need the support for classes until we can remove them in favor of all hooks. This is common for a multitude of code bases.

[tumisangStarfire]

if you ever get stuck

import React,{ Component} from "react";
import { useNavigate } from "react-router-dom";

export const  withNavigation = (Component : Component) => {
  return props => <Component {...props} navigate={useNavigate()} />;
} 

//classComponent  
class LoginPage extends React.Component{

submitHandler =(e) =>{
    //successful login 
    this.props.navigate('/dashboard');
  }
}
 export default withNavigation(LoginPage);

[jefferson-liew]

if you ever get stuck

import React,{ Component} from "react";
import { useNavigate } from "react-router-dom";

export const  withNavigation = (Component : Component) => {
  return props => <Component {...props} navigate={useNavigate()} />;
} 

//classComponent  
class LoginPage extends React.Component{

submitHandler =(e) =>{
    //successful login 
    this.props.navigate('/dashboard');
  }
}
 export default withNavigation(LoginPage);

Is there a javascript alternative for this?