Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop "cannot go" invariant in createMemoryHistory #165

Closed
petrbrzek opened this issue Nov 30, 2015 · 25 comments
Closed

Drop "cannot go" invariant in createMemoryHistory #165

petrbrzek opened this issue Nov 30, 2015 · 25 comments

Comments

@petrbrzek
Copy link
Contributor

Is it important to throw an error if I cannot goBack? It seems to me that returning null should be just fine.

@taion
Copy link
Contributor

taion commented Nov 30, 2015

Ref #89, and transitively remix-run/react-router#767 and remix-run/react-router#843.

I don't think this can be resolved by #36.

I don't have the time right now to fully read through those refs to understand why history.length isn't possible, but if that's not possible, then this might not be possible as well.

@petrbrzek
Copy link
Contributor Author

Well, there is the canGo function. Can't we just expose it?
Or, do we really need the invariant call below? I think it's cool for dev mode but not for production.

invariant(
  canGo(n),
  'Cannot go(%s) there is not enough history',
  n
)

@taion
Copy link
Contributor

taion commented Nov 30, 2015

Are you using createMemoryHistory?

@petrbrzek
Copy link
Contributor Author

Yep.

@taion
Copy link
Contributor

taion commented Nov 30, 2015

Ah! Okay. That's quite relevant!

@taion
Copy link
Contributor

taion commented Nov 30, 2015

Can you just wrap the whole thing in try / catch then?

@petrbrzek
Copy link
Contributor Author

I can, but it's kinda ugly.

@taion
Copy link
Contributor

taion commented Nov 30, 2015

I'm on board with replacing the invariant with a warning. It'd be more consistent with what browser histories do (in doing nothing if you're already at the beginning of the history stack).

This is technically a breaking change, though, so we'd have to defer it for 2.x.

@rackt/routing, what do we think of dropping that invariant to make createMemoryHistory behave more like the others?

@taion taion changed the title Can I check if I can goBack? Otherwise the invariant crashes my app in Electron. Drop "cannot go" invariant in createMemoryHistory Nov 30, 2015
@taion
Copy link
Contributor

taion commented Nov 30, 2015

I like your suggestion of dropping the invariant, BTW. Maybe a warning. I edited the title of the issue as appropriate.

@petrbrzek
Copy link
Contributor Author

warning is okay. 👍

@mjackson
Copy link
Member

mjackson commented Dec 2, 2015

The invariant is meant to help you find errors in your code. A warning would serve the same purpose, I guess. But if you're trying to e.g. go(-5) and you're only on the first page, you should probably not do that ;)

I'd like to expose canGo, but we can't actually do it in real browser histories, so the API wouldn't be consistent. See the issues @taion mentioned for the looooooong backstory.

@taion
Copy link
Contributor

taion commented Dec 2, 2015

I'll look at replacing it with a warning. Gets you the best of both.

@taion
Copy link
Contributor

taion commented Dec 2, 2015

Actually, @petrbrzek, do you want to put together a PR? I'm a bit busy the next few weeks, have a conference and a deadline coming up.

@petrbrzek
Copy link
Contributor Author

@taion Sure. What about this?

if (!canGo(n)) {
  warning(
    false,
    'Cannot go(%s) there is not enough history',
    n
  )
  return null
}

@taion
Copy link
Contributor

taion commented Dec 2, 2015

Just return - this function has no return value anyway.

@taion
Copy link
Contributor

taion commented Dec 2, 2015

But otherwise that's exactly what I was thinking. I don't know what test coverage around that looks like though - not sure what we need there either.

@mjackson
Copy link
Member

mjackson commented Dec 2, 2015

Shouldn't need a test. Simple replace with a warning is fine.

On Wed, Dec 2, 2015 at 8:02 PM Jimmy Jia [email protected] wrote:

But otherwise that's exactly what I was thinking. I don't know what test
coverage around that looks like though - not sure what we need there either.


Reply to this email directly or view it on GitHub
#165 (comment).

@taion
Copy link
Contributor

taion commented Dec 2, 2015

👍

@tommoor
Copy link

tommoor commented Jul 19, 2016

if you're trying to e.g. go(-5) and you're only on the first page, you should probably not do that ;)

@mjackson how can we avoid this if the history doesn't expose a length or a canGo method? Geniunely asking - there seem to be 100 different issues related to this but no real solution.

@mjackson
Copy link
Member

@tommoor What are you trying to do? As in, what feature or app are you trying to build? The reason I ask is because we're too far down in the weeds of this discussion when we start talking about API that we need but that we just can't provide.

@tommoor
Copy link

tommoor commented Jul 19, 2016

@mjackson - that's fair - I'm trying to provide back and forward buttons in our app that are disabled correctly when you wouldn't be able to navigate in the direction because you are at the start or end of the history.

@mjackson
Copy link
Member

Maybe we could just expose canGo for memory histories, with the caveat that browser histories won't ever have it?

@tommoor
Copy link

tommoor commented Jul 19, 2016

That would certainly resolve it for us as we're using the memory history - it's an Electron app in this case. Is there a lot of work to achieve that?

@taion
Copy link
Contributor

taion commented Jul 19, 2016

You'd get something like this with location.index and something like a history.getMaxIndex().

@mjackson
Copy link
Member

Mmmmmm, yes. If we had location.index and history.length this would be trivial. Let's follow up in #334.

@lock lock bot locked as resolved and limited conversation to collaborators Jun 5, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants