Sure is odd that a good number of react-and-friends websites can’t manage to support it all then.

Just like how routing and history is “solved” but I encounter websites every other day that completely break my browser history.

> Sure is odd that a good number of react-and-friends websites can’t manage to support it all then.

I don't think that's true. More likely, you use react websites all the time and don't even think about it because the links work as you expect.

I'm familiar with React. And no, links in React often don't work without extra attention.

It's way too easy to put some state information into the context and then have your pages depend on it. For example, you have a page with a filter that is implemented via a simple state, and then a list of widgets that pass the filter. The widgets have a click handler that opens the widget details.

Now you right click on it. If you're lucky, it opens the widget details in a separate tab. However, the filter information is lost.

> And no, links in React often don't work without extra attention

Links work fine, out of the box, react treats them the same way vanilla js does. JavaScript onClick events aren't links, and that's true whether you're using react or vanilla js.

> It's way too easy to put some state information into the context and then have your pages depend on it.

What do you mean it's too easy? If someone makes poor engineering choices because that's the "easy" thing to do, that's their fault, the tool didn't make them do that.

> Now you right click on it. If you're lucky, it opens the widget details in a separate tab. However, the filter information is lost.

This is true of JavaScript in general, it has nothing to do with react. In order for links to work, the server has to render pages that correspond to the link, whether that means encoding state in the url or pulling it from a session, this is required whether you're using react or literally anything else.

> I'm familiar with React. And no, links in React often don't work without extra attention.

^ These two statements are at odds with each other.

React will return a pure browser link that behaves exactly as a browser link:

   function Comp() { return <a href="some-link">text</a>;  }

> The widgets have a click handler that opens the widget details. > > Now you right click on it. If you're lucky, it opens the widget details in a separate tab. However, the filter information is lost.

So, the problem isn't React. The problem is people overriding default browser behaviour for their widgets. It was a problem before React, and it will be a problem long after React.

For example, here's Google's premier site about web technologies: https://web.dev/articles Check out the pagination links at the bottom. There's no React on the page

> React will return a pure browser link that behaves exactly as a browser link

No it doesn't (in practice). React is typically used with something like React Router that takes over the whole sub-tree of paths. So links are handled by the single-page app itself, and this can lead to the state leaking through.

Yes, you don't _have_ to do it this way.

> No it doesn't (in practice).

Yes , yes it does, in practice.

> React is typically used with something like React Router that takes over the whole sub-tree of paths. So links are handled by the single-page app itself,

"Taken over by Router", "handled by SPA itself" .... "React is to blame"

> Yes, you don't _have_ to do it this way.

Yes, you don't have to it this way, and this isn't React-specific. See Google's web.dev site built with web components