Interactivity API: Refactor context proxies

[DAreRodz]

What?

Minor refactoring for the context proxies. This PR moves the related code to the /proxies folder inside the Interactivity API package and removes unnecessary code.

Follow up of #62734.

Why?

Code quality and maintainability.

How?

This PR keeps the previous logic; this means context objects still have two proxies. It's a bit tricky to merge the state proxies logic with the context proxies one, so we could address that in a future PR.

Testing Instructions

Current tests should pass as expected.

[luisherranz]

It looks good so far. Thanks for refactoring this, @DAreRodz!

I have left some minor comments and questions here.

[luisherranz]

Thanks, David. Let me know once it's ready for review.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: DAreRodz <darerodz@git.wordpress.org>
Co-authored-by: michalczaplinski <czapla@git.wordpress.org>
Co-authored-by: luisherranz <luisherranz@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[DAreRodz]

The error that you see in the wp-each tests (here) should be gone once the bug fix in #65135 is merged. ☝️

[michalczaplinski]

It's not clear to me that deepMerge is equivalent to the updateContext() function. Should it be equivalent or are we consciously changing the logic here? If it's the second one, then why do we do that?

[DAreRodz]

The idea here is to use deepMerge() with the override option set to false. This algorithm follows the same logic as updateContext but does not manipulate the reactive object directly and only updates the signals created beforehand.

That way, we avoid wp-context subscribing unnecessarily to the modified context and prevent wasteful signal instantiation. 🙂

[michalczaplinski]

ok, I see. Upon further inspection the logic does seem almost the same. The only 2 differences I see is:

1. We do not use peek() anymore. This I assume is because we the context is not wrapped in proxies anymore like you mentioned here.

2. I see that we're now assigning empty object here:
   

   gutenberg/packages/interactivity/src/proxies/state.ts

   Lines 298 to 301 in ce56700

   	} else if ( isPlainObject( source[ key ] ) ) {
   	if ( ! ( key in target ) ) {
   	target[ key ] = {};
   	}

   but previously we used to re-assign the property:

   } else if ( ! ( k in target ) ) {
     target[ k ] = source[ k ];
   }

[DAreRodz]

1. We do not use peek() anymore. This I assume is because we the context is not wrapped in proxies anymore like you mentioned here.

Exactly. 🙂

2. I see that we're now assigning empty object here [...] but previously we used to re-assign the property:

That was wrong. We don't want to copy a plain object's reference from source when calling deepMerge.

[michalczaplinski]

Nice work @DAreRodz !

This looks good to me! 👍 I hope it's okay I pushed a tiny improvement to the tests.