-
Notifications
You must be signed in to change notification settings - Fork 374
Subgraph widget promotion - Part 2 #5617
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
Conversation
🎭 Playwright Test Results⏰ Completed at: 09/25/2025, 01:50:55 AM UTC 📈 Summary
📊 Test Reports by Browser
🎉 Click on the links above to view detailed test results for each browser configuration. |
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.
Could we move all the files to src/core/graph/subgraph
Sorry Claude review went haywire. |
The lint staged should pass if you rebase, since the knip config file was added to tsconfig |
Wrap onConfigure instead of _internalConfigureAfterSlots Use previously set proxyWidgets property instead of calculating Fix canvas preview image support Split proxy handlers into individual functions. Add additional tests
The code to reset display of proxied widgets before adding or removing wasn't being filtered to just proxy widgets. This would cause other promoted DOMWidgets to be hidden Resolves a playwright test
286832e
to
49bb39d
Compare
🔧 Auto-fixes AppliedThis PR has been automatically updated to fix linting and formatting issues.
Changes made:
|
const w = addProxyWidget(this, `${nodeId}`, widgetName) | ||
if (w instanceof DOMWidgetImpl) { | ||
const widgetState = widgetStates.get(w.id) | ||
if (!widgetState) continue |
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.
question (non-blocking): What would it mean if the condition if (!widgetState)
is true?
At this point in the code, we have already called addProxyWidget
, so if it turns out w
is a DOM widget but isn't in the widgetStates
map, what does that mean for us? Do we need some sort of transaction logic or to move the check for this before we create the proxy?
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.
While the check was added to satisfy type guards and this shouldn't ever come up, it does make a good question. Particularly for the subsequent "set active" code.
A DOMWidget that somehow doesn't exist in the store can't be displayed. Ignoring a widget was fine previously when the getter was calculating from the actual widgets, but now it causes a desync of state. 🤔
Will think on it a bit more, but I'm ever-so-slightly leaning towards throwing an error. If this ever comes up in the future, we'd want to be notified either when testing or through sentry.
Adds additional documentation Moves modifications to widget state into functions in the domWidgetStore Moves types to the start of the file Throw an error on failed validation of a proxyWidget property
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.
Only got a nit.
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.
LGTM
Implements proxyWidget support on subgraph nodes. This registers a special proxyWidgets property on subgraph nodes which is directly mapped to the proxyWidgets displayed on the node. Each proxyWidget directly maps to a real widget inside the subgraph. ┆Issue is synchronized with this [Notion page](https://www.notion.so/PR-5617-Subgraph-widget-promotion-Part-2-2716d73d3650813d8621fefdce6ae518) by [Unito](https://www.unito.io) --------- Co-authored-by: GitHub Action <[email protected]>
Implements proxyWidget support on subgraph nodes.
This registers a special proxyWidgets property on subgraph nodes which is directly mapped to the proxyWidgets displayed on the node
with no duplication of state. Each proxyWidget directly maps to a real widget inside the subgraph.Areas of concern
on every access. Litegraph fully supports leaving this as a list, but this is safer than risking breakage by changing types, is 3-4 orders of magnitude less important than the performance of the proxying code, and provides a chance to slot in validationThe code is applied by patchingSubgraphNode._internalConfigureAfterSlots
. SubgraphNodes are a little jank because they sometimes areconfigured
twice on initialization and this call deletes all widgets on the node each time. As there is no duplication of state, if the code is applied after the first call, all widgets are cleared from the node on the second.setTimeout
was previously utilized, but makes for a much uglier workaround.Don't be fooled by theTypescript doesn't seem to bother checking types on reflection and the degree of wrapping is rather heavy handed.any
cast.The location where this code is stored. Placing code in scripts isn't great, but it puts it adjacent to the similar DOMWidget code and is consistent with simple act of importing the code applying side effects. Placing the code inside litegraph itself was originally attempted, but non-viable. The code requires access to multiple stores, including the domWidgetstore in order to manage state.┆Issue is synchronized with this Notion page by Unito