[ui] Initialize CodeMirror on a div instead of textarea #16878
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Current dependencies on/for this PR: This comment was auto-generated by Graphite. |
|
Deploy preview for dagit-storybook ready! ✅ Preview Built with commit f4c2a66. |
yuhan
pushed a commit
that referenced
this pull request
Sep 29, 2023
## Summary & Motivation Handling a bug reported by a user: https://dagster.slack.com/archives/C01U954MEER/p1695890039223599. When viewing the "Configuration" page under "Deployment", the read-only CodeMirror renders correctly. If you navigate away, however, the CodeMirror remains rendered in the DOM, though unstyled and jammed into the top of the page. This is because we're using `CodeMirror.fromTextArea`, which creates a target div for the CodeMirror instance independent of the `textarea` we render for the component. This div is uncontrolled by React, so when we navigate away, the React-controlled textarea is unmounted, but the CodeMirror target div remains in the DOM. To resolve this, use the CodeMirror constructor API instead. In this way, we can pass a div to serve as the CM target, which will be unmounted correctly when navigating away. Also switch to using a `useRef` instead of the ref function, which is currently being executed every time any of the prop values changes -- which is a lot. The ref function re-execution leads to mounting/unmounting the rendered node, which isn't useful to us and could be problematic. The CodeMirror instantiation now takes place within in an effect instead. ## How I Tested These Changes View Configuration page, then navigate to Daemons. Verify that the CodeMirror doesn't linger in the DOM. View Launchpad, verify that editable CodeMirrors continue to behave correctly.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary & Motivation
Handling a bug reported by a user: https://dagster.slack.com/archives/C01U954MEER/p1695890039223599.
When viewing the "Configuration" page under "Deployment", the read-only CodeMirror renders correctly. If you navigate away, however, the CodeMirror remains rendered in the DOM, though unstyled and jammed into the top of the page.
This is because we're using
CodeMirror.fromTextArea, which creates a target div for the CodeMirror instance independent of thetextareawe render for the component. This div is uncontrolled by React, so when we navigate away, the React-controlled textarea is unmounted, but the CodeMirror target div remains in the DOM.To resolve this, use the CodeMirror constructor API instead. In this way, we can pass a div to serve as the CM target, which will be unmounted correctly when navigating away.
Also switch to using a
useRefinstead of the ref function, which is currently being executed every time any of the prop values changes -- which is a lot. The ref function re-execution leads to mounting/unmounting the rendered node, which isn't useful to us and could be problematic.The CodeMirror instantiation now takes place within in an effect instead.
How I Tested These Changes
View Configuration page, then navigate to Daemons. Verify that the CodeMirror doesn't linger in the DOM.
View Launchpad, verify that editable CodeMirrors continue to behave correctly.