-
Notifications
You must be signed in to change notification settings - Fork 1k
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
fix[qwik]: ENG-7299 Default value not updating for custom components on ContentEditor #3947
base: main
Are you sure you want to change the base?
Conversation
🦋 Changeset detectedLatest commit: 3478c53 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
---|---|---|---|---|---|
2708648 | Triggered | Generic High Entropy Secret | 3c65c71 | examples/angular-gen2/src/environments/environment.ts | 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 3478c53.
☁️ Nx Cloud last updated this comment at |
packages/sdks/src/components/block/components/interactive-element.lite.tsx
Show resolved
Hide resolved
…rTimeout for locator assertion as recommended
packages/sdks/mitosis.config.cjs
Outdated
json: { | ||
post: (json) => { | ||
if (json.name === 'InteractiveElement') { | ||
console.log('json', JSON.stringify(json, null, 2)); |
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.
console.log('json', JSON.stringify(json, null, 2)); |
await expect( | ||
page.frameLocator('iframe').getByText('Item 1') | ||
).toBeVisible({ timeout: 5000 }); | ||
|
||
// Re-query the item1 element as it might have been recreated | ||
const updatedItem1 = page.frameLocator('iframe').getByText('Item 1'); | ||
await updatedItem1.click(); |
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 want to avoid hardcoded timeouts unless there's a special reason for them. Playwright has automated waiting and retrying so that we don't need to provide hardcoded timeout values all the time. Also, in this case, the default is already 5000 so this does nothing:
timeout: testType === 'snippet' ? 30000 : 5000, |
you also don't need to redefine the locator twice:
await expect( | |
page.frameLocator('iframe').getByText('Item 1') | |
).toBeVisible({ timeout: 5000 }); | |
// Re-query the item1 element as it might have been recreated | |
const updatedItem1 = page.frameLocator('iframe').getByText('Item 1'); | |
await updatedItem1.click(); | |
// Re-query the item1 element as it might have been recreated | |
const updatedItem1 = page.frameLocator('iframe').getByText('Item 1'); | |
await expect(updatedItem1).toBeVisible(); | |
await updatedItem1.click(); |
Description
This PR addresses a critical reactivity issue in the Qwik SDK where deeply nested content updates weren't properly triggering.
The core problem was that when content was updated through the Builder.io editor, the changes were correctly stored in state but weren't causing components to re-render.
I've implemented a key-based approach for the
InteractiveElement
component that uses a dynamic key derived from the component options, forcingQwik
to update it's component whenoptions
changes. This effectively bypasses limitations in Qwik's resumability model where prop changes to dynamic components aren't always detected. While usingJSON.stringify
in keys isn't ideal for performance, but it provides a reliable solution that ensures content updates are immediately reflected in the UI without requiring page refreshes.JIRA
https://builder-io.atlassian.net/browse/ENG-7299
Loom
https://www.loom.com/share/2b4d1b2872fe4151b1a9f2f131bab780?sid=7fc0f143-0623-41f4-aa94-e947530dde55