[Feature]: When a feature is experimental, there should be a better migration mechanism, and using unstable_xxx is a bad way to do it

[skypesky]

If you use unstable_xxx to express experimental functionality,then you may have problems when upgrading

I think we should

For a smooth transition

• useBlocker is an experimental feature

# Method 1 (recommended): Add @experimental to indicate that he is experimental
import { useBlocker } from 'react-router-dom';
# Method 2
import { useBlocker } from 'react-router-dom/experimental';

• useBlocker is an official release feature

import { useBlocker } from 'react-router-dom';

Argument

1. It's impossible for a developer not to know why he is using useBlocker, but he should also know that it is an experimental feature. If he's not sure about that, then he has no reason to use it. If the experimental version of useBlocker does not meet the requirements, there is no reason for developers to actively use it, but to use other solutions
2. More friendly, smooth transition, the whole process is basically no feeling

[kiliman]

Hmm... I think the unstable_ prefix is pretty explicit that this is experimental API.

By the way, this doesn't mean that it's buggy. It just means that the API may change based on user feedback. Typically, once they settle on an official version, the release notes will contain instructions on how to migrate to the new API.

[brophdawg11]

Agreed, I don't see any material difference between these two options - both are quite explicit to me that it's an unstable/experimental API intended for early adopters who are OK to follow release notes closely and adopt breaking changes should they need to happen.

import { unstable_useBlocker } from 'react-router-dom';
import { useBlocker } from 'react-router-dom/experimental';