Include navigation state in request sent to loader

[RoBackman]

When navigating to a page, one can currently add "state" to the navigation that then becomes available in useLocation().state

I would like to suggest an improvement to this by making it available in the loader function.

Browsed the underlying code a bit, and some of my thoughts following:

• In case state is set when navigating, the request that is forwarded to the loader could be of type "post" with the state included in the request body.
• As the history state spec also requires the passed data to be serializable -> would fit quite nicely json-serialized in the body.
• By using the native requests this would probably not break any SSR functionality in remix.
• This could in part be used to limit user from tampering with statefull things that would otherwise need to be included in the url (dates etc.).
• useLocation().state appears stable between refreshes and back/forward navigation -> possible to include it again when navigating forward/back

Sorry for the messy explanation, feel free to restructure it and ask if anything is unclear.

[kberridge]

We were hoping for exactly this too. I have a scenario where a page has a loader request to load information about how the page should initially be rendered, but when a user clicks certain buttons on the page that navigate, we know we want to clear that state, so we do not need to load it. It seemed like passing history state to navigate would be a great way to accomplish this, but we haven't found a way to access that state in the loader.

Our workaround for now was to set and check global state on window. We're fully client side rendered, no SSR, so I was hoping to find an optional historyState parameter to loader.

[rubber-duck-software]

Linking #11274 .

A general ability to read/write history.state has tons of uses!