Private APIs: Improve the unlocking mechanism when paired with data stores

[gziolo]

What problem does this address?

Part of #47786.

It's based on the observation I shared after studying the refactoring applied by @talldan in #47375 to use hide the experimental APIs with the locking/unlocking system. The comment is available at #47375 (comment):

One potential drawback to calling unlock on the entire data store exists. After a couple of refactorings, it will be impossible to tell which selectors/actions are experimental. In the case of promoting an experiment to a stable API, the unlock call will stay in place as there won't be any incentive to refactor the code. In addition, it's going to be difficult to tell whether this proxy can be safely removed without running the code, because several more than one selector/action could be experimental.

What is your proposed solution?

Two solutions were proposed by @adamziel in #47375 (comment):

1. Don't expose stable selectors on the unlocked store. Drawback: Now you need two useSelect() calls.
2. Use a prefix like __internal to make the difference apparent. Drawback: There's still a prefix.

I don't like either of these solutions. This issue could use a separate discussion thread.

@talldan commented on the idea (1) in #47375 (comment) with:

I don't think it'd require two useSelect calls, it'd look a bit like this:

const { public, private } = useSelect( select ) => {
  const { publicSelector } = select( myStore );
  const { privateSelector } = unlock( select( myStore ) );
  return { public: publicSelector, private: privateSelector };
} );

I responed to the idea (2) in #47375 (comment) with:

It might help if the prefix was automatically prepended by the lock call. Still, not ideal 😄

[adamziel]

cc @youknowriad @jsnajdr @talldan

[youknowriad]

No strong opinion for me. I'm not sure it's very important personally to distinguish between locked and unlocked selectors in core components but regardless, @talldan's idea is fine by me.

[gziolo]

Actually, my only concern was that we would end up with lingering unlock calls on stores, but it might be partially covered with the following line:

gutenberg/packages/private-apis/src/implementation.js

Lines 174 to 178 in a0ef113

	if ( ! ( __private in object ) ) {
	throw new Error(
	'Cannot unlock an object that was not locked before. '
	);
	}

We will see how it looks in practice.