Persisting booking request details across authentication

[ollieh-m]

Currently, if you start a booking without being signed in, the booking request details are not persisted for when you are eventually redirected to the checkout page. This means you have to sign in then fill in the booking form again.

The reason is this line: const hasNavigatedThroughLink = history.action === 'PUSH'
It returns false when the authentication redirects to the checkout page.

I've fixed it on our fork with const hasNavigatedThroughLink = history.action === 'PUSH' || history.action === 'REPLACE' instead.

I'd be interested if there's a better fix!

[Gnito]

Thank you for reporting this. We have not thought enough about replace action, it seems.

Your suggestion is a good solution for now, but I was starting to think if we could avoid that variable altogether.

That ”hasNavigatedThroughLink” is added to prevent user from navigating back (and making duplicate booking) after successful order. I haven’t tested this, but maybe the same thing could be achieved better by using history.replace instead of history.push in handleSubmit method.

[pcm211]

i need an api key

[kpuputti]

Hi @pcm211 ! Thanks for your interest in Sharetribe Flex!

Sharetribe Flex is currently in Closed Preview mode. This means that we are currently unable to open the access to everyone. We will be handing out API keys slowly to more and more people.

In order to get your API key, I'd suggest you to Request early access, keeping in mind that you may need to wait some time to get the API key, or you may be even rejected from the early access. This is unfortunate, but as mentioned, we are not yet able to open Flex to everyone who is interested.

[Gnito]

Now that I finally had time to look this a bit more, I have to say that my idea of playing with history.replace didn't sound good. That would require strange logic in all the places where we need a user to be authenticated (checkout & create new listing).

So, for now, I ended up making suggested changes to CheckoutPage.js. See #852

If there's more demand for this kind of prevent-back-navigation, bigger changes could be done so that RouteConfiguration.js and Routes.js can handle flags like "preventBackNavigation: true".