React-router: [v6] <Link> crashes if "to" prop is undefined

Created on 24 Aug 2020  路  8Comments  路  Source: ReactTraining/react-router

Version

6.0.0-beta.0

Test Case

https://codesandbox.io/s/loving-hugle-4321b?file=/src/App.js

Steps to reproduce

Run the sandbox above, or try <Link to={undefined}>Text</Link>

Expected Behavior

Ideally, provide a warning and render anyway; or just ignore the problem and render, as per the v5 behaviour.

Actual Behavior

It crashes with the unhelpful error c is undefined.

Most helpful comment

I think my point is that if to _is_ undefined due to a developer's silliness, then crashing completely with c is undefined can be hard to debug in any non-trivial application, and it's not a great developer experience.

If it's the intention of the library authors that it should crash with an indecipherable error message, then that's fine. But I don't think it is - it smells like a bug - and I think the issue should be reopened.

All 8 comments

I'm curious what the maintainers think about this issue. I haven't experienced it myself, and it may be intentional so we don't accidentally create anchor tags with no href attribute. If the maintainers want to change this behavior to render even without the to prop (maybe make it default to "#") I'd be happy to work up a PR

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
You can add the fresh label to prevent me from taking any action.

this is not a bug, because actually, the Link needs to know where should it go. Therefore, as long as the to prop is required, it can't be undefined

@timdorr could you close it?

@renatobenks then it would be better with a more descriptive message instead of just crashing.

@timdorr Please reopen, as it is a bug. Although it does need a to prop work, the to prop may be dynamically assigned at runtime. If something goes wrong, I wouldn't expect it to just crash completely with an indecipherable error message.

If something goes wrong, I wouldn't expect it to just crash completely with an indecipherable error message.

What about then dealing with the possible undefined value on your side ? You are pushing the problem that starts in your application, to be dealt by the library. As stated by @renatobenks , if it says that it doesn't take in undefined, you shouldn't provide undefined. Now if the library maintainers have time to deal with that. good luck.

I think my point is that if to _is_ undefined due to a developer's silliness, then crashing completely with c is undefined can be hard to debug in any non-trivial application, and it's not a great developer experience.

If it's the intention of the library authors that it should crash with an indecipherable error message, then that's fine. But I don't think it is - it smells like a bug - and I think the issue should be reopened.

I suggested to close it because once you have static types covering it, you actually don't need a double-check, but maybe, I guessed wrong, what do you think @timdorr?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ArthurRougier picture ArthurRougier  路  3Comments

ryansobol picture ryansobol  路  3Comments

andrewpillar picture andrewpillar  路  3Comments

Waquo picture Waquo  路  3Comments

yormi picture yormi  路  3Comments