-
Notifications
You must be signed in to change notification settings - Fork 12
feat: first communication between extension and webview #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
Closed
Closed
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or 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
This file contains hidden or 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
File renamed without changes.
This file contains hidden or 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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,35 @@ | ||
| /********************************************************************** | ||
| * Copyright (C) 2025 Red Hat, Inc. | ||
| * | ||
| * Licensed under the Apache License, Version 2.0 (the "License"); | ||
| * you may not use this file except in compliance with the License. | ||
| * You may obtain a copy of the License at | ||
| * | ||
| * http://www.apache.org/licenses/LICENSE-2.0 | ||
| * | ||
| * Unless required by applicable law or agreed to in writing, software | ||
| * distributed under the License is distributed on an "AS IS" BASIS, | ||
| * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
| * See the License for the specific language governing permissions and | ||
| * limitations under the License. | ||
| * | ||
| * SPDX-License-Identifier: Apache-2.0 | ||
| ***********************************************************************/ | ||
|
|
||
| import type { ContextsStatesDispatcher } from '/@/manager/contexts-states-dispatcher'; | ||
| import { API_DASHBOARD } from '/@common/channels'; | ||
| import type { DashboardApi } from '/@common/interface/dashboard-api'; | ||
| import type { ResourceCount } from '/@common/model/kubernetes-resource-count'; | ||
| import type { RpcChannel } from '/@common/rpc'; | ||
|
|
||
| export class DashboardImpl implements DashboardApi { | ||
| constructor(private contextsStatesDispatcher: ContextsStatesDispatcher) {} | ||
|
|
||
| getChannel(): RpcChannel<DashboardApi> { | ||
| return API_DASHBOARD; | ||
| } | ||
|
|
||
| async getActiveResourcesCount(): Promise<ResourceCount[]> { | ||
| return this.contextsStatesDispatcher.getActiveResourcesCount(); | ||
| } | ||
| } |
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
Oops, something went wrong.
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.
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.
AFAIK it should not be
<undefined>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 do you think? Should it be some 'empty' value (void?), or do you think it is expecting some real data? (I would prefer to not pass data from here, but let the frontend query the data when it wants, with some throttling/debouncing)
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.
RPC channel is used by the webview to call methods on the extension so I would not expect an undefined type at this level. It's providing at the end a Proxy.
I expect here to have an API (an interface) and then this interface can have Promise methods.
webview then say: Give me a proxy to counters API
and then I can ask:
startCounting(): Promise<void>(it's a dummy example)Uh oh!
There was an error while loading. Please reload this page.
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.
In the lightspeed extension (https://github.com/redhat-developer/podman-desktop-redhat-lightspeed-ext/blob/main/packages/common/src/channels.ts), I understand that the pattern you are describing is used for the RPC channels (first section), but not for the Broadcast events (second section), where the type is only the data the extension wants to send to the webview along with the event. Am I wrong?
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.
for broadcast sections, then it's broadcasting the value to be displayed
so for the case of counts for example it should be
ActiveResourcesCountInfointerface with for examplecount: numberfieldthe idea is that the frontend is never asking directly a data
frontend ask for a data, backend broadcast the value of the data, frontend receive the value and can display it.
Uh oh!
There was an error while loading. Please reload this page.
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 argument for doing the other way (webview asking for the data), is that the data provided by the extension will be massive (for some events, it will be the complete description of all the pods, for example). We will need to introduce some debouncing/throttling to limit how frequently we really want to transfer this data. Do you think that this should be done in the extension side instead of the webview?
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 idea is that we don't broadcast every 5s for example (or on every change) or we don't need to display the value
but the logic is: frontend ask when it's interesting, then extension/backend will send the data. Debouncing/throttling being done on the extension side, webview only taking care of displaying values.
webview side:
I want to monitor cluster 2 for "pod resource"
and then it receives value for "pods"
you change the page, then it's sending "I'm no longer interested" and the data are no longer sent.
overall idea is:
only quick calls from frontend to backend (we're almost never waiting for a result)
and sending data is only done asynchronously from backend to frontend.
logic = backend, display = frontend
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.
or in short: we ask for a value but we don't get it directly, it's received through another channel.
it avoids stores /states that follow the logic: if not intialized, asked for the data.
in fact, we don't have anymore
grabLatestEventsmethods at all that return the valuevalues are always received through the events
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.
ok, I'll move all the logic to the extension. Thanks