-
Notifications
You must be signed in to change notification settings - Fork 1k
feat[RSC]: [ENG-8936] Add LiveEdit
support for client-side updates using BuilderContext.Provider
#4022
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
base: main
Are you sure you want to change the base?
Conversation
|
|
GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
---|---|---|---|---|---|
11707119 | Triggered | Generic High Entropy Secret | 6b6b74a | packages/sdks/snippets/react/src/routes/blueprints/ProductEditorial.tsx | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secret safely. Learn here the best practices.
- Revoke and rotate this secret.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
View your CI Pipeline Execution ↗ for commit 6bacd53.
☁️ Nx Cloud last updated this comment at |
…components, removing unnecessary code
…angular error reverted mitosis change. Instead of using spread operator in LiveEdit using assignment operator to handle undefined
LiveEdit
support for client-side updates using BuilderContext.Provider
LiveEdit
support for client-side updates using BuilderContext.Provider
@@ -949,7 +949,7 @@ const QWIK_FORCE_RENDER_COUNT_FOR_RENDERING_CUSTOM_COMPONENT_DEFAULT_VALUE = | |||
json: { | |||
post: (json) => { | |||
if (json.name === 'InteractiveElement') { | |||
json.children[0].meta.else.bindings['key'] = { | |||
json.children[0].meta.else.meta.else.bindings['key'] = { |
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.
Would it be possible to record a loom to explain this bit?
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.
Noted! Will surely record a loom around it before merging this PR
_findBlockById( | ||
blocks: BuilderBlock[] | undefined, | ||
id: string | ||
): BuilderBlock | null { | ||
if (!blocks) return null; | ||
for (const block of blocks) { | ||
if (block.id === id) return block; | ||
|
||
if (block.children) { | ||
const child = this._findBlockById(block.children, id); | ||
if (child) return child; | ||
} | ||
} | ||
return null; | ||
}, |
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.
We could use just findBlockById()
instead of having a separate _findBlockById()
. Also by removing _findBlockById()
we reduce the future possibility of a developer calling state._findBlockById()
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.
If _findBlockById()
was a private function in useStore
then we could keep it.
const _ = { | ||
a: props.id, | ||
b: props.Wrapper, | ||
c: props.attributes, | ||
d: props.children, | ||
}; |
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.
Would it be possible to record a loom to explain this part?
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.
Noted!
key: newContentValue.id!, | ||
url: window.location.pathname, | ||
}); | ||
// console.log('DEBUG: SDK: RECEIEVED editType: ', editType); |
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.
can remove this
@@ -242,7 +249,7 @@ export default function EnableEditor(props: BuilderEditorProps) { | |||
}, | |||
}); | |||
|
|||
setContext(builderContext, props.builderContextSignal); | |||
setContext(builderContext, props.builderContextSignal) |
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.
nitpick but we can add the ; back
@yash-builder Would it be possible to add tests for the changes? |
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.
with this change, many existing visual editing tests (like the ones that edit text blocks) should now work on nextjs SDK.
- For
'client'
updates (like editing texts, images): Can we enable those tests for nextjs sdk and make any other changes needed to confirm that editing works as expected? - For
'server'
updates (like editing Columns, which is an RSC), can we dig into getting those tests working for nextjs SDK too to make sure the server updates also work as expected? I never got around to doing so, but it would be useful as part of this work to make sure all editing works well going forward.
/** | ||
* Whether the component is a React Server Component | ||
*/ | ||
isRSC?: boolean; |
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.
On second thought i would prefer we don't have this type here. Some customers might see this and set it to true
in their React Gen1 SDK implementation, and then they'll be confused as to why it doesn't do anything
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.
Any suggestions on where shall we add the type isRSC
? Since we will be needing this type in our builder-internal
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.
Another note: would be good to see & test whole flow end-to-end for both PRs (webapp + SDK) combined and make sure it works well before merging SDK changes, otherwise those might themselves in an SDK release if someone else has changes queued up.
Absolutely |
Description:
This PR introduces client-side live editing support by extending the existing context and rendering logic in the SDK.
What changes were made:
BuilderContext.Provider
insideEnableEditor
to consume a derived state from thebuilderContextSignal
prop inContent
.LiveEdit
wrapper component that:InteractiveElement
to conditionally renderLiveEdit
when in editing mode.editType: 'server'
andeditType: 'client'
:'server'
, retain existing behavior—push updates to LRU cache and re-render on the server.'client'
, trigger a context update that re-rendersLiveEdit
components on the client side.Why these changes were made:
To support hybrid editing in the SDK where developers can opt into either server-side or client-side editing behavior, depending on the use case.
Additional context:
editType: 'client'
.builder-internal
Screenshot
OTW