feat: Add static build mechanism #1440
Conversation
The richtext package was also updated to use these mechanisms, although only a small subset of its public API was reimplemented.
| return WithoutHydration; | ||
| }; | ||
|
|
||
| export const withoutHydration: WithoutHydrationFunction = (options) => { |
| @@ -0,0 +1,6 @@ | |||
| #!/usr/bin/env node | |||
| @@ -0,0 +1,67 @@ | |||
| # Bodiless-JS CLI | |||
There was a problem hiding this comment.
but we should add an accurate readme describing how to use the static thing. I have one in progress - i will issue apr.
| @@ -0,0 +1,33 @@ | |||
| { | |||
| "name": "@bodiless/hydration", | |||
| "version": "0.3.7", | |||
There was a problem hiding this comment.
We'll hve to update the version now that there has been a release.
…tic-builds-cx Update static-builds-cx
WIP on activating token shadow and static builds for cx
… into feature/static-builds
|
Test summary
Run details
View run in Cypress Dashboard ➡️ This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard |
…hub.com/marcopagliarulo/Bodiless-JS into feature/static-builds
| const id = `${path.join('-')}-${nodeKey}`; | ||
|
|
||
| return ( | ||
| <WrapperElement data-no-hydrate id={id}> |
There was a problem hiding this comment.
@marcopagliarulo should we use a different attribute here or even just mke this the value of the data-no-hydrate ttribute? i'm a bit worried about using id.
There was a problem hiding this comment.
this is required because then the element is retrieved using document.getElementById. Using the attribute data-no-hydrate means that we should traverse the whole tree to retrieve the element. What's your concern about using id?
There was a problem hiding this comment.
my concern is that id's must be unique, and we are using one here without concern for what other code might do to the dom. Couldn't we just use document.querySelector? Or are you concerned that will be significantly less performant? Anyway, I guess this is not a critical concern.
There was a problem hiding this comment.
actually querySelector is faster than getElementById, I am fine to use data attribute to store the Id and then querySelector
| const [shouldHydrate, setShouldHydrate] = useState<boolean | undefined>(undefined); | ||
|
|
||
| const { path } = useNode().node; | ||
| const { nodeKey = ''} = {...props}; | ||
| const id = `${path.join('-')}-${nodeKey}`; |
There was a problem hiding this comment.
It would probably be better if the logic that sets the id were encpsulated rather than repeated
| @@ -16,7 +16,8 @@ import { HOC } from '@bodiless/fclasses'; | |||
|
|
|||
| type WithoutHydrationOptions = { | |||
| onUpdate?: (props: Record<string, any>, element: HTMLElement | null) => void | |||
| disableFallback?: boolean | |||
| disableFallback?: boolean, | |||
| WrapperElement?: 'div'|'span', | |||
There was a problem hiding this comment.
@marcopagliarulo and @lucas-varela are we happy with limiting this to div or span, or should any element be allowed?
There was a problem hiding this comment.
I think it's fine. It will prevent issues with dangerouslySetInnerHTML that doesn't allow to set inner html containing unallowed tags, e.g. set p tag withing a p wrapper.
| @@ -61,27 +79,80 @@ const withoutHydrationClientSide: WithoutHydrationFunction = ({ | |||
| onUpdate(props, rootRef.current); | |||
| }); | |||
|
|
|||
| useLayoutEffect(() => { | |||
There was a problem hiding this comment.
Would be great to have a comment here explaining what we are doing...
Remove gatsby link, minor cleanup of withoutHydration.
No description provided.