-
Notifications
You must be signed in to change notification settings - Fork 0
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
Add developer menu #1029
Add developer menu #1029
Conversation
useEffect(() => { | ||
// eslint-disable-next-line @typescript-eslint/ban-ts-comment | ||
// @ts-ignore | ||
window.toggleDevtools = () => setShowDevtools((old) => !old); | ||
window.toggleDevtools = | ||
// This comment forces a line break to limit the scope of `@ts-ignore`. | ||
() => setEnableDevtools((old) => !old); | ||
}, []); |
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.
What's going on here with the linting stuff?
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.
Oh yeah, it is kind of unrelated, but it's an improvement. @ts-ignore
is a very big hammer. So without this change, even, say, a typo in the name of setEnableDevtools
wouldn't be flagged.
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.
And, to be clear, the only error we want to ignore is Property 'toggleDevtools' does not exist
.
I think this is a good idea, and I like the new ability to view node IDs, but I think "always show labels" should be a student-visible preference, or at least another tree/text button toggle state until we have a proper preference system, and not fobbed off into the developer tools menu; so this doesn't solve my objection to #1023. |
src/App.tsx
Outdated
<input | ||
type="checkbox" | ||
id="showIDs" | ||
onChange={(e) => setShowIDs(e.target.checked)} | ||
className="mr-1" | ||
/> | ||
<label htmlFor="showIDs">show node IDs</label> |
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.
You mention in your commit message that
Note that, for now at least, we only show these for the "primer", "primer-simple" and "primer-box" nodes. For others, it's less obvious where to put them, since we don't have labels as such.
Some off-the-cuff ideas on where to put them if we want:
- mouse over/hover text
- some sort of popup on click
- click toggles display of normal node or just its id
- in the sidebar or info display when node is selected
Having said that, I don't currently see a pressing need for them. Maybe leave it as-is until there is a situation where we want to see them?
FTR, one (painful!) way to access these IDs is to inspect the node in your browser's devtools and then find the data-id
attribute on the containing react-flow__node
node. (At least, I think this works, I haven't tested it much)
window.toggleDevtools = () => setShowDevtools((old) => !old); | ||
window.toggleDevtools = |
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.
It might be nice to explicitly say (in the commit message) something to the effect that the "new" devtools are accessed the same way as the "old" react-query ones? (At least, I had forgotten how to access the tools prior to this pr!)
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.
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.
Oh, actually, ignore me, that probably is obvious. I'd forgotten that running window.toggleDevtools()
only enables that button, rather than directly opening the panel.
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 had also forgotten how to enable this! Just a mention in the commit message would be fine.
What if we switch the default to "always show labels", so that #1023 has no actual end-user-visible effects? The idea was that we can also use this for temporary features which we haven't found a place for in the UI, rather than just stuff that will always be developer-facing. This avoids blocking the likes of #1023 on unspecified future UI work. |
Yes, that would be my preference, and then I would have no objection either to #1023 or this PR. See #1023 (comment) for my reasoning. |
01c5b34
to
74b3f0e
Compare
Expert-mode label hiding is now off by default. One more thought before I re-request a review: should I put #1005 behind this menu as well, instead of the ugly |
Thanks! I suppose it makes sense to do the same with inline labels, but it may not be worth the effort. IMO, both hiding labels and inline labels should be available to the student, as it would be interesting to observe their preferences during testing. So before we start serious testing, we'll want to add a proper preferences UI, anyway, where both of those options could go. |
Wasn't much effort. I've just pushed this change. |
1efb83b
to
fade269
Compare
</div> | ||
</div> | ||
); | ||
|
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 would prefer that this were a separate component, not inlined in App, but I can take care of that refactoring later.
This retains the ReactQuery devtools panel, but also has an extra area to the right (unused right now) in which we can add further controls. We can use this for gating features which are experimental or which help with debugging. In production builds, this can be triggered as before, by running `window.toggleDevtools()` in a browser console. Signed-off-by: George Thomas <georgefsthomas@gmail.com>
One allows us to display node IDs, which can be useful for debugging. Note that, for now at least, we only show these for the "primer", "primer-simple" and "primer-box" nodes. For others, it's less obvious where to put them, since we don't have labels as such. And they'd be less useful anyway, since the mentioned node types happen to be the ones whose IDs are backend-generated. The other allows us to enable the expert-mode syntax-label-hiding feature. Signed-off-by: George Thomas <georgefsthomas@gmail.com>
This makes it easier to see where dev opts are set. We also control the checkbox state, making it easier to set an initial value to `true`, should we ever wish to. Signed-off-by: George Thomas <georgefsthomas@gmail.com>
Signed-off-by: George Thomas <georgefsthomas@gmail.com>
The button needs to be above the sessions page panel. And the others are actually unnecessary now that we introduce scrollbars to the main canvas instead of overlaying it. Signed-off-by: George Thomas <georgefsthomas@gmail.com>
fade269
to
aac4a7b
Compare
Discussions in #1005 and #1023 about how to toggle experimental features led me to finally look in to something I've long-thought we could do with: an area in the UI for developers only.
We had something similar in the bottom-right corner in Vonnegut, except that IIRC, while that was only intended for development use, it also appeared in the production build. And I can't remember quite what we actually used it for altogether (I think there was an option to dump a JSON serialisation of the current program?).
We already added a dev-only menu in #1002. But that was specifically for React Query. This PR essentially extends that with a bespoke menu for Primer-specific settings.
For convenience in avoiding potential conflicts, this is currently based on #1023.
Feel free to bikeshed. This is currently just a quick idea without much thought given to the design. Although I haven't marked as a draft, since I do consider it to be in a mergeable state.