Bumping this to prevent it from getting stale – had to put it off to get the clipboard fixes/tests done faster, but I will be getting back to this

Nearly got this thing done. The tests should be stable now, but one thing I do want to do is remove therenderHookWithAuth's reliance on internal React Router implementation details

(The React Router router objects have a ton of properties that you can freely access, but they're all marked as 'for internal use only'. Not sure if those comments got added after I made the initial version of the helper, or if I missed them)

our testing code seems to differ substantially from the sort of stuffhttps://v5.reactrouter.com/web/guides/testing recommends

@aslilac So there's a couple of things this is trying to get around. Sorry for the walls of text, and I want to be very clear: this isn't directed at you, but I'm also trying to get this put into writing before I forget anything:

1. MemoryRouter just isn't nearly as ergonomic ascreateMemoryRouter for testing setup
   • WhileMemoryRouter still works, the main issue for it is that it's incredibly hard to generalize into a single test helper.MemoryRouter needs you to supply an individualRoute component for every single path segment you want to test for, and make sure that eachRoute has some kind of component associated with it. This is because under the hood, React Router is processing and stripping the children JSX it receives into a JSON object of what routes to set up. You can't just go "I want to setup a component for/a/b/c, and I'm okay if going anywhere else causes an error"
   • createMemoryRouter doesn't have this limitation – you can go "make me a route for/a/b/c and ignore everything else", and it'll fill in the missing pieces behind the scenes. But the tradeoff is that the component that receives the router no longer acceptschildren
   • It would be possible to make a helper to help interface our tests with the originalMemoryRouter, but it's going to require recursive components and a bunch of dummy components. I considered it for a little bit, but I stopped myself because that felt like it'd be even more complex
2. The test examples you linked are for React Router v5 – and v6 is notorious for its breaking changes from v5 (as in, genuinely made a lot of people mad)
   • The very first example they show in the v5 docs is no longer valid (and that's on them). Trying to haveSidebar be a direct child ofMemoryRouter will immediately break
   • Though the real issue is that despite v6 being 2.5 years old, they don't have any modern testing documentation at this point
3. Honestly, I feel like the React Router people haven't really been concerned about ergonomics outside of Remix that much
   • They don't stabilize the function references for any of their custom hooks
   • They just expect you to ignore the ESLint rules around dependency arrays all over the place, and even codify that assumption into their docs
4. The problem of testing React Router custom hooks has been a problem for ages, and the Remix team just doesn't seem that interested in supporting the use case
   • I scoured StackOverflow and GitHub for ages, and the very few solutions I found were also hacks, but they didn't address every possible thing you would want from a custom hook test
   • This issue just got updated because other people are still struggling with this:

     # Formatting link like this to avoid pinging themhttps://github.com/remix-run/react-router/issues/7759

5. Also, just making sure: were you looking at the docs for v5? The page forRouterProvider is right here

Now all that said, I can go back to the drawing board on this. What are your main concerns, either from an interface, or an implementation standpoint?

gotta love that the top google search result was the docs for a 3 year old version of the library 🙃 sorry about that. let me go read the right docs and rereview with that in mind.

@aslilac Yeah, believe me – I would throw this into a fire if I could