Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: window.location is not equal to useLocation() with loader in react 17 #10446

Closed
holynewbie opened this issue May 4, 2023 · 6 comments
Closed
Labels

Comments

@holynewbie
Copy link
Contributor

holynewbie commented May 4, 2023

What version of React Router are you using?

6.11.1

Steps to Reproduce

package.json

{
  "name": "codesandbox-template-vite",
  "private": true,
  "version": "0.0.0",
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "tsc && vite build",
    "preview": "vite preview"
  },
  "dependencies": {
    "react": "^17.0.0",
    "react-dom": "^17.0.0",
    "react-router-dom": "^6.11.1"
  },
  "devDependencies": {
    "@types/react": "^17.0.0",
    "@types/react-dom": "^17.0.0",
    "@vitejs/plugin-react": "^2.0.0",
    "typescript": "^4.6.4",
    "vite": "^4.3.0"
  }
}

main.tsx

import React from "react";
import ReactDOM from "react-dom";
import {
  createBrowserRouter,
  RouterProvider,
  useNavigate,
  Outlet,
  useLocation,
} from "react-router-dom";

const App = () => {
  const nav = useNavigate();
  return (
    <div>
      <button onClick={() => nav("/abc?query=123")}>跳转</button>
      <Outlet />
    </div>
  );
};
const Abc = () => {
  const location = useLocation();
  console.log(
    "window.location: {pathname: %s, search: %s}",
    window.location.pathname,
    window.location.search
  );
  console.log(
    "useLocation(): {pathname: %s, search: %s}",
    location.pathname,
    location.search
  );

  return <div>abc</div>;
};

const router = createBrowserRouter([
  {
    path: "/",
    element: <App />,
    children: [
      {
        path: "abc",
        element: <Abc />,
        loader() {
          // whatever code here
          return null;
        },
      },
    ],
  },
]);

ReactDOM.render(
  <React.StrictMode>
    <RouterProvider router={router} />
  </React.StrictMode>,
  document.getElementById("root") as HTMLElement
);

the result is wrong,window.location get older state。 But if I annotate the loader, it turns right.

Expected Behavior

window.location has same pathnamesearch ... with useLocation

Actual Behavior

screenshot-20230504-145110

2023-05-04.14.50.39.mov
@sash9696
Copy link

Hi @brophdawg11 , I would like to work on this issue. It would be of great help if you could assign it .

@timdorr
Copy link
Member

timdorr commented May 20, 2023

Issues don't get assigned on public projects unless only one person can solve it. @holynewbie already submitted a PR.

@brophdawg11
Copy link
Contributor

I think we can go ahead and merge the linked PR, but want to document here just for clarity that apps should not be relying on window.location and should always reference useLocation when possible. No matter what we do window.location will always be out of sync at one point or another (popstate events, concurrent mode, etc.) so this will fix this specific React 17 issue - but it will not make window.location a reliable source of data in a React Router app :)

@brophdawg11 brophdawg11 added the awaiting release This issue have been fixed and will be released soon label Jun 2, 2023
@brophdawg11
Copy link
Contributor

This is fixed by #10448 but didn't quite get merged in time for the pending 6.12.0 release, so it will be available on the next release after that goes out - likely 6.12.1 or 6.13.0

@github-actions
Copy link
Contributor

🤖 Hello there,

We just published version 6.14.0-pre.0 which involves this issue. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!

@github-actions
Copy link
Contributor

🤖 Hello there,

We just published version 6.14.0 which involves this issue. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!

@brophdawg11 brophdawg11 removed the awaiting release This issue have been fixed and will be released soon label Aug 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants