-
Notifications
You must be signed in to change notification settings - Fork 14
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
Lazy-docs #919
base: lazy-loading
Are you sure you want to change the base?
Lazy-docs #919
Conversation
To avoid SQLAlchemy session conflicts, the process node MUST be fetched on each request (not locally stored) to ensure any given thread will handle its OWN fetched process node.
- Only use `refresh()` on render where necessary - Discard initial `_defaults` definition in models
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## lazy-loading #919 +/- ##
=============================================
Coverage 67.15% 67.15%
=============================================
Files 78 78
Lines 5392 5392
=============================================
Hits 3621 3621
Misses 1771 1771
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
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.
Thanks for the docs, it's very helpful to get the whole picture of the design, and for reviewing the PR.
I added some quick comments. I am going to review the lazy-loading PR, and may add more comments later.
It is also used by the advanced panel to register the sub-sections of the advanced settings (e.g. magnetization, hubbard, etc.). | ||
|
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 you explain a bit more?
# Controller methods | ||
# EXAMPLE | ||
def _on_trait_change(self, change): | ||
# Update widgets based on model 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.
I think you also need to show how the widgets in the UI trigger the model update.
@tl.observe(tl.All) | ||
def _on_any_change(self, change): | ||
if change and change["name"] != "confirmed": | ||
self._unconfirm() |
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 you also explain _on_any_change
? What is any
?
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.
tl.All
watches ALL traits. So ANY trait change triggers this, hence _on_any_change
🙂 Will make it more verbose in the docs 👍
Co-authored-by: Xing Wang <[email protected]>
4f6a21e
to
578a997
Compare
This PR provides documentation to accompany the changes made in the lazy-loading PR (#802)