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.

Sign up for GitHub

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

Jump to bottom

Stabilize __experimentalDefaultBlock and __experimentalDirectInsert APIs #52068

Closed
3 tasks done
sethrubenstein opened this issue Jun 28, 2023 · 2 comments
Closed
3 tasks done

Stabilize __experimentalDefaultBlock and __experimentalDirectInsert APIs #52068

sethrubenstein opened this issue Jun 28, 2023 · 2 comments
Labels
[Type] Task Issues or PRs that have been broken down into an individual action to take

Comments

@sethrubenstein
Copy link
Contributor

sethrubenstein commented Jun 28, 2023 •
edited
Loading

What problem does this address?

As __experimentalDefaultBlock and __experimentalDirectInsert are in use across a few blocks now and have been in use for some time it's agreed that it's time to stabilize these APIs.

The big driver for this is to support the inclusion of defaultBlock as an attribute starting with the core/navigation in #50982.

What is your proposed solution?

Stabilize the __experimentalDefaultBlock and __experimentalDirectInsert by completing the following:

  • Remove __experimental prefix in codebase and replace with defaultBlock and directInsert.
  • Add deprecated calls where existing implementations are found.
  • Write small doc explaining usage and usage of associated other api's/selectors like __experimentalGetDirectInsertBlock
@sethrubenstein
Copy link
Contributor Author

@getdave Originally we were planning on two pr's for each of these API's per your comment, however after closer examination I realize that __experimentalGetDirectInsertBlock is dependent on both, and I want to stabilize that as well so its easiest on us to just work out of one branch and update all this in one go. Just wanted to make sure that wasn't an absolute no-no?

@sethrubenstein sethrubenstein mentioned this issue Jun 28, 2023
Merged
@jordesign jordesign added the [Type] Task Issues or PRs that have been broken down into an individual action to take label Jul 7, 2023
@annezazu
Copy link
Contributor

Closing this out with #52083 merged. Feel free to reopen if wrong!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
[Type] Task Issues or PRs that have been broken down into an individual action to take
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@sethrubenstein @jordesign @annezazu