feat(client): module update track for graph page

[LoTwT]

description

This PR is intended to close #177.

[netlify]

✅ Deploy Preview for vue-devtools-docs canceled.

Name	Link
🔨 Latest commit	3946972
🔍 Latest deploy log	https://app.netlify.com/sites/vue-devtools-docs/deploys/65b3203d7c4bce00080c4202

[LoTwT]

Hi, @webfansplz.

This is a draft PR including the codes that may cause RPC communications timeout.

Some other problems need to be resolved now. It's just a draft PR now to communicate issues.

It now completes a minimal implementation because vite-plugin-inspect hasn't released a new version yet.

This PR uses server.ws to send a custom event when some other URLs are requested which means some new resource will be loaded. In the client, it uses a pre-defined vite hot context to listen to the custom event and do something. When using bridgeRpc in the vite hot context, the RPC communications will always be timeout.

steps to start:

• nr dev
• nr play
• check the console in the terminal ( server side )
• open the chrome devtool in the browser ( client side )
• click Toggle Langs to mock a new request for resources
• wait and see the console on the client side

[LoTwT]

@webfansplz

This version uses moduleUpdated defined in the vite-plugin-inspect.

When using bridgeRpc, it still comes in a timeout error. It results in a first render error in graph.vue, there will be no graph in the network. If a repo uses multiple RPCs defined by vite-dec-rpc and they are in nested use, will it come in error? 🤔

Using vite-plugin-inspect's RPC functions is hard to reuse the bridge in the core. Should the logic that triggers a custom event from the server be integrated into vite-plugin-vue-devtools? If so, should it be more high-level and powerful?

[LoTwT]

Hi, @webfansplz.

This PR is ready to review now.

Your codes on the RPC communications are cleverly designed. I think they have resolved the scopes referred to in #177. Thank you! ♥️

For the better design of RPC communications, I will later create a new issue.