-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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.
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
Interactivity API: add tests for the getElement() attributes #63126
base: trunk
Are you sure you want to change the base?
Conversation
Size Change: +241 B (+0.01%) Total Size: 1.75 MB
ℹ️ View Unchanged
|
I gave it some thought, and I don't have any definite answers but rather just some loose thoughts. I'm still getting re-acquainted with the internals of the Interactivity API after a long time away from it, so there's a chance I got sth wrong :)
|
I have been reviewing this with @DAreRodz carefully and we think the current logic is fine since it only contains the attributes of the original element. In that case, it seems correct to keep calling it attributes and not props. Now then, since these properties are present in the Virtual DOM, they are actually the attributes that the Interactivity API is aware of. Initially, this might seem incorrect because if someone modifies the DOM imperatively, they could become unsynchronized. But after careful consideration, we believe it's safer this way because it will force people not to make imperative modifications to the DOM but to use the Interactivity API ( Similarly, we believe that making the attributes reactive is not a good idea since it's a client-side feature and could cause problems with server-side rendering. Thus, we think the best approach is to keep them read-only and to ensure that the modification of the DOM is done with a part of the state linked to the In summary, there isn't much more to do in this pull request except to add some tests to confirm the current behavior. |
What?
It is still unclear how the attribute object returned by
getElement()
works. We should reconsider how it functions:data-wp-bind
)?Why?
We've only considered the main use case (read
data
attributes on getters) so far, and it'd be good to think about all its implications to finalize this API.How?
I've only added a couple of e2e tests so far. We can add more and change the implementation as we decide how to move forward.