-
Notifications
You must be signed in to change notification settings - Fork 35
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
migrate commands to command palette (Closes #389) #391
migrate commands to command palette (Closes #389) #391
Conversation
Also, the docs seem to strongly recommend against setting a default shortcut. |
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 should also make sure the removeCommand
is added in roamjs-components
Struggling with Typescript definition and console error with the Typescript error:
Console error:
|
src/features/decorators.tsx
Outdated
@@ -263,7 +264,7 @@ const settings = [ | |||
"Context Enabled", | |||
"Hex Color Preview Enabled", | |||
] as const; | |||
const DecoratorSettings = ({ isOpen, onClose }: RoamOverlayProps) => { | |||
const DecoratorSettings = ({ isOpen, onClose, extensionAPI }: RoamOverlayProps) => { |
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'll need to fix the type here: RoamOverlayProps<{ extensionAPI: OnloadArgs["extensionAPI"]}>
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 went a different route and removed the addCommand
from toggleFeature
It made more sense to me to not "turn on and off" the feature every decoration save.
It also removes the need for type updates. And this makes more sense to me as well, as extensionAPI
shouldn't be required for Decorations
3eb2707#diff-ea4e85188fe94af5ae70fed25db2d64551b1b568075d213927ed8f69a97fb202
Maybe this isn't actually from the code change. Looks like something similar exists in the current version.
Steps to replicate:
|
Yea this looks like a current bug from when the context decorator is enabled - I'd try to ignore this for now as its a separate issue |
for b21a052 Removed the toggle right/left sidebar, as those are built into Roam now. Also, let me know how you feel about code formatting I went with that because if felt more readable to me than the 200+ lines from the Prettier extension. |
Issues found with current jumpNav (Hot Keys)
And these appear to not work:
|
Well here's an unfortunate side effect of Added timeout here: 4629860 But I feel it is bordering an unreasonable length of time. |
…into command-palette-commands-389
The useful part of the prettier extension is the standardization, not necessarily the decisions it comes with by default. The problem with making exceptions is that someone else working on the team will eventually edit the file, hit save, then prettier will auto format. If you disagree with prettier defaults, the scalable solution would be to change the prettier rules, so that it gets formatted automatically. If it's unable to be encoded, then the opinion is subjective, which means it will inevitably be overwritten by somebody else's subjective experience, and now time on the PR is being spent on code formatting instead of code content.
Man the problem here is I think this API from Roam is actually not very reliable - ideally we don't need a setTimeout at all. This should be fine for now Gonna start reviewing PR now |
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.
My biggest question is why did we remove all of the hotkeys to the commands?
The goal of the task was to make all of the commands have configurable hotkeys, while still retaining the default value we had so that there's no interruption in functionality
}); | ||
|
||
return () => { | ||
FEATURES.forEach(({ module }) => module.toggleFeature(false)); | ||
FEATURES.forEach(({ module }) => module.toggleFeature(false, extensionAPI)); |
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.
One meta comment for future PRs - Big refactors like this are more digestable for reviewers as small as possible. This also helps on the engineering front as well.
I still struggle with this mightily (just look at some SamePage commits). But we should always ask ourselves: What is the smallest PR that we could submit that accomplishes our goal?
For example, PR 1 could have just been this file + 1 module. The rest of the modules will ignore the param and we would be able to iterate on convention before applying it to the rest of the modules
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.
Ah, smaller PR's makes sense.
But at the same time, I was discovering it as I went. So I wouldn't have know that the first PR wouldn't have had to be overwritten / changed.
And when I think:
What is the smallest PR that we could submit that accomplishes our goal?
If the goal is to migrate all workbench commands to command palette, that first PR wouldn't have achieved that.
I guess I should have spent more time scoping the problem.
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.
Making a note to clarify more on Monday 👍
addCommand( | ||
{ | ||
label: "Create New Alert", | ||
callback: createNewAlert, | ||
}, | ||
extensionAPI |
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.
No need to change for this PR, but a note for future reference.
In typescript, when there's more than one parameter I often prefer a single object instead of multiple params. So for example, I probably would have done:
addCommand(
{
label: "Create New Alert",
callback: createNewAlert,
extensionAPI
},
)
The reason being is life becomes way easier for consumers:
- Order of parameters no longer matters
- We could freely make any of the parameters optional
- Easier to refactor in the future: adding/removing parameters doesn't involve changing all consumers in most cases
- Parameters are named, giving the consumer extra context on what the function expects
src/features/deepnav.tsx
Outdated
@@ -382,6 +370,7 @@ const endNavigate = () => { | |||
if (document.body.classList.contains(NAVIGATE_CLASS)) { | |||
document.body.classList.remove(NAVIGATE_CLASS); | |||
} | |||
window.removeEventListener("keydown", keyDownListener); |
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're using isNavigating
to control whether we do deepnav stuff or not, so seems like we should be able to add/remove this event listener during just the toggleFeature
method
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.
This is additionally poor on my part because the listener is added on activeDeepNav()
and toggleFeature()
So are you saying it is better to have an event listener always on vs only turning it on when needed?
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's more a comment that isNavigating
is already doing this work. If we want to do the smart listener approach you suggest (this is probably better, but harder to get right), then we should prob get rid of isNavigating
since it will add confusion
src/features/deepnav.tsx
Outdated
endNavigate(); | ||
document.getElementById(STYLE_ID)?.remove?.(); | ||
document.removeEventListener("keydown", keyDownListener, true); | ||
window.removeEventListener("keydown", keyDownListener); |
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.
why did we switch from document
to window
?
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.
Unintentional mistake.
src/features/workBench.ts
Outdated
|
||
export const removeCommand = (label: string, extensionAPI: OnloadArgs["extensionAPI"]) => { | ||
extensionAPI.ui.commandPalette.removeCommand({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.
With big files like this, one tactic I like to do is leave a comment like this:
This is the only substantive change to the file, the rest just add
extensionAPI
as an argument toaddCommand
. Any other differences I flag below
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.
Sorry, I don't follow.
That would be a comment in the code or on the commit?
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.
On the commit to make it easier for reviewers looking over big files how to read it going in
This makes sense, but if someone else were to contribute to this code, how would they be made aware of the prettier / format on save convention? |
Speaking of which, I'm not using the "on save feature". Should I be? |
This is somewhat implicit by seeing prettier in a repo in the industry at this point. Sortof like if you see a testing library you can assume that the project is running tests in Github in some capacity and they should all be passing before merging
I highly recommend it, it's life changing 👍
That's okay bc of two reasons:
|
A few notes / questions on default hotkeys:
As a matter of fact, I can't set any hotkey using the UI to
The docs say
I don't believe we can set more than one hotkey as a default.
I coded it to stay in line with the docs
|
Ok so I'm going to double back and what I said before and make an exception for this and jumpnav. Let's remove the defaults, and be sure to make announcements in
Works for me - Sometimes chrome extensions could conflict with hot keys |
It might be prudent to not merge this until the docs have been updated.
🤦♂️ That was it! |
Let me know if I'm on the right track 👍 @dvargas92495
components PR: RoamJS/roamjs-components#3