-
Notifications
You must be signed in to change notification settings - Fork 11
⚛️ Refactor directives and make them work inside client components #74
⚛️ Refactor directives and make them work inside client components #74
Conversation
I don't like having to traverse all the |
Well, there are actually options to avoid the double traverse:
I think I like the first option better because with the second the static vnodes won't have props until our options hook runs. |
For future reference, a couple of perf tests: I tested it in Chrome desktop and mobile, Firefox desktop and mobile and Safari desktop.
|
Oh, something is going on with the block context. It doesn't work after hiding+showing. I'll take a look. Screen.Capture.on.2022-09-26.at.18-15-39.mp4 |
I also tested it in EDIT: my bad, I was in the wrong commit (9057066). 🤦 In the latest commit, the issue is reproducible. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@luisherranz, the code seems great. 👍
Regarding the issue, I don't know where it could be TBH. 😕 Maybe it is related to the attributes being processed now inside the wpType
directive, or re-processing the wp
directives on non-static nodes...
No idea. 🙃
I've taken another quick look at the block context issue, and I think it should be related to the way sourced attributes are computed after the refactoring (inside the It is like the |
Thanks, David. I'll take a look later today 🙂 |
It disappears because it's a sourced attribute and needs to look at the DOM to get the value. At the beginning of the application, we have a DOM and create a vDOM. So we go DOM-> vDOM and the sourced attribute values can be found. But when Preact components add nodes, we go in the other direction, vDOM-> DOM. So there's no DOM to search for the sourced attribute values. I'm not sure why or how this was working previously. I'll take a look. |
Ok, it makes sense now. You were processing the sourced attributes in the I'll think about how we can do this without hardcoding that behavior into the |
To see them in the Preact devtools.
I've finally exposed the I've also added support for returning components. This should be ready for review! https://www.loom.com/share/e71a9867720542eaa5812d70741ae4fd cc: @DAreRodz |
EDIT: The video is finally loading fine. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great refactoring, thanks @luisherranz!! 👏
PS: I left a comment below.
src/directives/wp-block.js
Outdated
if (!vnode._blockAttributes) { | ||
vnode._blockAttributes = blockAttributes || {}; | ||
useMemo(() => { | ||
for (const attr in blockSourcedAttributes) { | ||
vnode._blockAttributes[attr] = matcherFromSource( | ||
blockSourcedAttributes[attr] | ||
)(initialRef); | ||
} | ||
}, [blockAttributes, blockSourcedAttributes]); | ||
} | ||
props.attributes = vnode._blockAttributes; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was intrigued by that useMemo
, and I think we may be able to get rid of it.
We are using vnode
as a container to store_blockAttributes
. That vnode
—the original one returned by toVdom()
— is not recreated and always exists. So, once you set the _blockAttributes
prop, I guess that code won't run again, am I right? 🤔
Apart from that, useMemo
is used conditionally, and that's not supposed to be the way. 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're totally right. Fixed.
I've also added a comment to explain why we're doing such a weird thing.
I'm also curious how sourced attributes will play out with the initially hidden blocks (the ones that will use <template>
in the future).
Thanks, David!! 🎉 |
Fixes #73.
For now, I've just added a simple directive to reproduce the problem. I'll continue working on the solution.