Implement front-end (React) routing library

@jessebaker Which of these options would you recommend?

Great summary and assessment, @jessebaker! Here are my thoughts in addition, hoping they could be helpful to make the final decision.

I think of the three libraries as three different options on a spectrum that goes from small and lean to robust and “enterprise” — wouter and TanStack Router being at those two endpoints, respectively.

Based on my understanding, the primary role of a routing library in XB will be the ability of deep linking. (Besides the code organization benefits that come from using a router instead of manually managing application state/context.)

Based on that, to me the easiest option to rule out first would be TanStack Router. It can do quite the heavy lifting, with its included devtools, its focus on type safety, all those things that are great when you’re working on a fully-featured app with complex data fetching logic.

Comparing wouter and React Router, I don’t think XB could go wrong with either, because the routing code in XB will be minimal, and since wouter already mimics some parts of React Router, it would be easy to switch between the two if that becomes necessary for any reason.

If I had to choose, my vote would go for React Router for the following reasons:

1. It’s a critical part of Remix, which is owned by Shopify. Hydrogen, Shopify’s headless stack is built on Remix. They invest heavily in the ecosystem (e.g. they recently announced Hydrogen Visual Editor — btw, there's probably some useful inspiration for XB there).
2. Many React devs already know React Router (or a version of it), as it existed long before Remix. (The team who built React Router built Remix.) For a long time, there wasn’t really a question of what router solution you choose if you have a React project, so many React devs have used a version of React Router in the past. I’ve heard from agencies that have older single-page applications they built for clients with React, that Remix is really great for them, because they can easily migrate, since the router solution they used is the same as what's in Remix. (Now, I realize this may not be as straightforward as it sounds due to the breaking changes between major versions.)

Seconding the @balintbrews comment, React Router is heavily used in modern React apps and is well-known by most React developers (who may eventually contribute?). Probably the best approach.

To expand on #3: @jessebaker built a PoC during the risk minimization early days of XB that used React Router: https://git.drupalcode.org/project/experience_builder/-/tree/poc_reactro...

Based on #3 + #4 + #5, it seems pretty clear that React Router is the strongest contender (especially given the swappability mentioned in #4).

@jessebaker, let's go? 😄😄

Aight, signaling that new issue status 😄

I don't have any specific feedback on which library is best, react router has generally done everything I've needed.

We'll want to make sure there's a good path for integrating Drupal's translations with whatever option is chosen. I've had challenges in the past making sure small SPA type components are able to effectively use Drupal's translations. From what I've found interface translations are heavily dependent on Drupal's html responses either through the initial page response or ajax responses rendering twig or using Drupal.t() in javascript which is dependent on drupalSettings being populated with the initial page response or an ajax response. This poses a challenge when you want to get the translated title for a pop up or component edit pane that is only rendered from JS without requiring an html request to Drupal.

Can you elaborate on why we need a router? At present all of the important parts are covered in the redux slices, eg selected component, open panes etc

We could easily add a listener middleware that used history.pushState and UrlSearchParams to represent these as url query Params. Then all we need to do is read these back when creating the store

I've got plenty of client projects I could adapt for a POC of this

@jessebaker https://git.drupalcode.org/project/experience_builder/-/merge_requests/84

Thanks, @larowlan! 😄

What's next here?

Reflecting #19 in the issue metadata — and the fact that @jessebaker is going on PTO tonight.

That means this issue is ready to be pushed to completion by writing the required tests documented in #19 👍

• The contextual form seems to be loading an older version of the form - I'm guessing the MR moved some stuff around which would up preserving some code that has since been refactored
• Clicking a component to make it active/selected takes us to /xb/component/ which is great, but refreshing a page on that URL results in a 404. While I'm very OK with incremental progress, refreshing the UI page is something I do frequently while developing for it and I'd like it to at least redirect back to /ui

Re #21

• The contextual form seems to be loading an older version of the form - I'm guessing the MR moved some stuff around which would up preserving some code that has since been refactored Turns out it was old stuff that was still there but we didn't see due to it being black text/black BG.
• Clicking a component to make it active/selected takes us to /xb/component/ which is great, but refreshing a page on that URL results in a 404. While I'm very OK with incremental progress, refreshing the UI page is something I do frequently while developing for it and I'd like it to at least redirect back to /ui I pushed a fix for this.

This caused a regression: #3465140: Regression: prop labels present on field widgets, but invisible.