Implementing Hot Module Replacement (HMR) for Vue Components in TypeScript

This challenge focuses on understanding and implementing the core mechanics of Hot Module Replacement (HMR) specifically for Vue.js applications using TypeScript. HMR is a crucial feature for modern web development, allowing developers to update code without a full page reload, preserving application state and significantly speeding up the development workflow. You will simulate the HMR process by creating a simplified version of a Vue HMR client and server.

Problem Description

Your task is to build a rudimentary simulation of a Hot Module Replacement (HMR) system for Vue components written in TypeScript. This involves creating two main parts:

A "Server" Component: This part will simulate the HMR server responsible for detecting code changes and notifying the "client" about updates. It will maintain a registry of modules and their content.
A "Client" Component: This part will simulate the HMR client running in the browser. It will listen for update notifications from the server, fetch updated module code, and attempt to "hot update" the Vue application.

You need to implement the logic for module identification, change detection, and the process of replacing a module's code while attempting to maintain the component's state.

Key Requirements:

Module Registry: The "server" needs to keep track of registered modules, identified by a unique ID (e.g., a file path or a generated ID). Each module should store its current code.
Change Detection: The "server" should simulate changes to module code.
Update Propagation: When a change is detected, the "server" should notify the "client" about which module(s) have been updated.
Module Loading: The "client" needs to be able to "request" updated code for a specific module from the "server".
Hot Updating Logic: The "client" will receive the new code and attempt to replace the old code of a component instance. For this simulation, we'll simplify the state preservation aspect: if a component is active, we'll assume its instance needs to be re-rendered with the new code.
Vue Component Simulation: You'll simulate Vue components using a simplified structure, perhaps a class with a render method and a state property.

Expected Behavior:

Initial registration of a few Vue components on the "server".
The "client" initializes and registers these modules.
The "server" simulates a code change in one of the registered components.
The "server" sends an update notification to the "client".
The "client" receives the notification, fetches the new code for the changed module.
The "client" attempts to "hot update" the corresponding Vue component. This might involve re-rendering or re-initializing the component with the new code.

Edge Cases to Consider:

Module Not Found: What happens if the client requests an update for a module that isn't registered on the server?
Multiple Updates: How would your system handle multiple modules being updated simultaneously? (For this challenge, focus on single module updates first).
State Preservation (Simplified): While full state preservation is complex, consider how you might conceptually approach it. For this simulation, imagine you have a way to access the active instance of a component to re-render it.

Examples

Let's define a simplified Vue component structure for demonstration:

// Simulated Vue Component Class
class VueComponent {
    id: string;
    state: any;
    render: () => string; // Returns a string representation of the component's output

    constructor(id: string, initialState: any, renderFn: () => string) {
        this.id = id;
        this.state = initialState;
        this.render = renderFn;
        console.log(`[VueComponent ${this.id}] Initialized with state:`, this.state);
    }

    update(newState: any) {
        this.state = { ...this.state, ...newState };
        console.log(`[VueComponent ${this.id}] State updated to:`, this.state);
        this.rerender();
    }

    rerender() {
        console.log(`[VueComponent ${this.id}] Rendering output: ${this.render()}`);
    }
}

Example 1: Basic Update

Scenario: A component MyComponent with a counter is updated to increment the counter.
Simulated Server State:
- Module comp-a: Contains code for MyComponent version 1.
- MyComponent instance is active with state = { count: 0 }.
Simulated Server Action: The code for comp-a is changed to MyComponent version 2, which includes logic to increment count on render.
Expected Client Behavior:
- The client receives an update for comp-a.
- It fetches the new code.
- It applies the new code, effectively re-initializing or updating the existing MyComponent instance.
- The component's state.count should now be 1 (due to the simulated increment on re-render).

Example 2: Update with Different State

Scenario: A component MyComponent is updated with new props, and the HMR process should apply these new props.
Simulated Server State:
- Module comp-a: Contains code for MyComponent version 1, expecting a message prop.
- MyComponent instance is active with state = { message: "Hello" }.
Simulated Server Action: The code for comp-a is changed to MyComponent version 2, which now expects a title prop instead of message.
Expected Client Behavior:
- The client receives an update for comp-a.
- It fetches the new code.
- It applies the new code. The mechanism for passing new props (or managing the component's internal state updates based on new code) will be part of your implementation. In a real Vue scenario, this would involve how the parent passes new props or how the component itself reinitializes. For this simulation, assume the HMR client can somehow trigger an update with new state/props.

Constraints

Language: TypeScript
Vue Version (Simulated): You are not expected to integrate with a real Vue runtime. Simulate component behavior and HMR concepts.
HMR Protocol: You will define your own simple communication protocol between the "server" and "client" for update notifications. This could be via function calls or event emitters.
State Preservation (Simplified): Focus on the mechanism of replacing code and re-triggering a render. Actual deep state cloning and restoration are out of scope for this challenge, but you should acknowledge the concept.
Module IDs: Module IDs can be simple strings (e.g., file paths).
Performance: Not a primary concern for this simulation. Focus on correctness.

Notes

Think about how tools like Webpack Dev Server or Vite handle HMR. They have a server that watches files, a client that receives messages (often via WebSockets), and a runtime that applies updates.
For the "client" part, you'll need a way to store references to active Vue component instances that can be updated. A simple map from module ID to component instance would work.
When a module is updated, the HMR runtime needs to determine if the new code can be hot-swapped. If not, it might trigger a full reload. For this challenge, assume all updates are hot-swappable.
Consider a HmrRuntime class on the client that manages module updates and interacts with simulated Vue component instances.
The "server" can be as simple as a class with methods like registerModule and updateModuleCode.
The "client" would have methods like listenForUpdates and applyUpdate.