fix: update state key references from 'key' to '__TSR_key'

[naoya7076]

Description

Currently, when using TanStack Router, if users define a property named key within the navigation state, its value is overridden by the router's internal logic, which assigns a random key.

For example:

#284 (comment)

const navigate = useNavigate();
navigate({ to: '/', state: { color: 'blue', key: 123 } });

// Defined type
declare module '@tanstack/react-router' {
  interface HistoryState {
    key?: number
    otherValue?: string
  }
}

// On navigation target
const location = useLocation();
console.log(location.state.color); // correctly "blue"
console.log(location.state.key);   // incorrectly overridden by a random string like "p7axhg"

Expected Behavior

When explicitly providing a key within the navigation state, it should preserve the user's defined value rather than being overridden by the router's internal random key.

[SeanCassiere]

@naoya7076 thanks for opening a PR for this, but we can't ship this in within the 1.0 release-cycle since this'd be considered a breaking change.
Since we have user-facing functions (like getScrollRestorationKey) which rely on location.state.key being defined/accessible.

I'll add this to the v2 list for it to be renamed to __TSR_key.

Edit: I've added this to the v2 list.

[naoya7076]

@SeanCassiere Thank you again for your feedback. I've changed __key to __TSR_key.  If merging it for v2 is not too much trouble, I would be very happy to see it included.

[SeanCassiere]

@SeanCassiere Thank you again for your feedback. I've changed __key to __TSR_key.  If merging it for v2 is not too much trouble, I would be very happy to see it included.

@naoya7076 we currently do not have a v2 development branch open. As I mentioned earlier, I have added it onto the v2 list so that it gets done for its development.

The only path forward here, in having this merged into main at the moment, would be to have both key and __TSR_key be added in and have their functionality/values be synced during the v1 cycle. The key property would be marked as TODO: Remove in v2 using a comment. Then, when it comes time to begin working on v2, we'd go ahead and act on the TODO.

[naoya7076]

@SeanCassiere Thank you for the guidance! I've updated the implementation as requested:

• Added both key and __TSR_key properties with synced values
• Marked key with TODO: Remove in v2 comments
• Updated all affected packages and documentation

Thanks for the clear direction! 🙏