-
Notifications
You must be signed in to change notification settings - Fork 11
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
Investigate IInvokableCommand.Invoke(object sender)
#307
Comments
Open question: What is the
|
Open question: Does this make sense for a
|
Open Question: What if we took it a step even further
May just do like a, I bet we could even wrap things up so that we had like interface IBigListPage requires IPage, INotifyItemsChanged
{
string[] ItemIds { get; };
IListItem GetItem(string id);
} and then, I bet we could have I bet we could do that to silently make the x-proc part less chatty, though it would still instantiate all those objects in the extension. A more clever extension could wait to instantiate the item until when |
I think I'm going to keep this change, but I also don't think this is the load-bearing hot path here. My notes in #388 seem to suggest that it's just the raw number of x-proc calls needed to build the context menu that lead to the icons page taking so long to load. This change could help in the sense that we could still build a command item cache, and try to look up the properties from that cache first for a given command. With this change, the context menu of each item would already be in the cache. But more importantly is the "don't load the context items till we need them" bit. |
## BREAKING API CHANGES APPROACHING Closes #307 Closes #238 Removes `Command` from `ITag` Adds `IDetailsCommand` (to achieve the same goal as the above originally had) Adds `ITreeContent`, based on a hunch Adds `ShowToast` and `Confirm` to `CommandResult` too, but without UX yet Extensions from before this change will need to be updated. * The `InvokableCommand` change should be trivial - the helpers should abstract that delta away for you. * The `ContentPage` change should be pretty easy to make. * Both `MarkdownPage` and `FormPage` are now just `ContentPage` * `FormPage.Forms()` -> `ContentPage.GetContent()` * `MarkdownPage.Bodies()` -> `ContentPage.GetContent()` * `IForm`s become `IFormContent`. Methods become properties (not that bad) * I'm only deprecating the old Markdown and Form pages - I'll fully remove them before we OSS, but I'll give everyone a couple weeks to port them. * No one was using `Tag.Command` and it always seemed iffy at best - better not.
Look at this:
https://github.com/zadjii/CmdPalExtensions/blob/f946ff79ddad4777dccd2860e60ef652ccf66837/src/extensions/SegoeIconsExtension/Pages/SegoeIconsExtensionPage.cs#L68-L91
Each of those list items all creates 4 nested commands within it (the default action, and three more).
That kinda seems like a lot of memory?
What if instead, we could create just four commands:
and each of those commands implemented
Invoke
with asender
parameter. That's only four commands for all however many thousand icons there are.Then in the host, we'd pass in the
IListItem
1 toInvoke
.Back in the extension, they could cast the sender back to the
IconListItem
, get theIconData
back out of it, then copy the thing that's relevant to that particular sender.For a bunch of lists of things that can all do the same thing, this seems like it would save a bunch of effort.
The limitation is that the verbs for each of these items would necessarily be limited to the same
Title
/Subtitle
/Icon
for every single item, but that seems very acceptable as a tradeoff.Footnotes
Not sure what object to pass in quite yet. That's the open question here. ↩
The text was updated successfully, but these errors were encountered: