React Conflict Resolution: Optimizing Collaborative Editing

Imagine a scenario where multiple users are editing the same document or data simultaneously in a React application. To ensure data integrity and a smooth user experience, we need a robust mechanism to handle and resolve conflicts that arise when different users make conflicting changes. This challenge will focus on building a foundational conflict resolution system in React using TypeScript.

Problem Description

Your task is to build a React component that simulates collaborative editing and implements a basic conflict resolution strategy. The component should allow users to input text into a shared "document" and display the current state of that document. When a conflict is detected (e.g., two users trying to edit the same piece of text simultaneously), the system should apply a defined resolution strategy.

Key Requirements:

1. Shared Document State: Maintain a central state representing the shared document content.
2. User Edits: Simulate multiple users making edits to the document. For this challenge, you can simulate concurrent edits by having multiple input fields that all modify the same underlying document state.
3. Conflict Detection: Implement a mechanism to detect conflicts. A simple conflict can be defined as two or more edits targeting the same character position or range within a short timeframe. For this challenge, we'll simplify conflict detection: if two edits arrive for the exact same character index and the new content overwrites the old, it's a conflict.
4. Conflict Resolution Strategy: Implement a "Last Write Wins" strategy. In case of a conflict, the edit that arrives later will overwrite the earlier one.
5. Display Document: Render the current, conflict-resolved state of the document.
6. TypeScript: The entire solution must be written in TypeScript.

Expected Behavior:

• Users can type into multiple input fields, each contributing to the same document.
• When a user types, their change is applied to the document state.
• If two edits happen at the exact same character index, the one processed last will be the one that persists.
• The displayed document should always reflect the latest, resolved state.

Edge Cases to Consider:

• Empty document.
• Rapid, rapid edits from multiple sources.
• Edits that delete text vs. edits that insert text.

Examples

Example 1:

Scenario: A single user is editing the document.

Input (Conceptual):

• Initial document state: "" (empty string)
• User 1 edits at index 0 with content "Hello"

Output (Rendered Document):

Hello

Explanation: No conflicts, the edit is directly applied.

Example 2:

Scenario: Two "users" are editing the document concurrently.

Input (Conceptual):

• Initial document state: "World"
• User 1 edits at index 0 with content "Hello" (overwriting 'W')
• User 2 edits at index 6 with content "!" (appending to 'd')

Output (Rendered Document):

HelloWorld!

Explanation: Both edits are independent and applied without conflict.

Example 3:

Scenario: Two "users" attempt to edit the exact same character index with different content, simulating a conflict. We will simulate "User 1" sending their edit slightly before "User 2" in our internal processing.

Input (Conceptual):

• Initial document state: "Test"
• User 1 proposes edit: Index 1, Content "a" (aiming to change 'e' to 'a')
• User 2 proposes edit: Index 1, Content "o" (aiming to change 'e' to 'o')

Internal Processing Order (simulated):

1. User 1's edit arrives and is processed. Document becomes: "Tast"
2. User 2's edit arrives and is processed. Document becomes: "Tost"

Output (Rendered Document):

Tost

Explanation: Both edits targeted index 1. User 2's edit arrived and was processed last, implementing the "Last Write Wins" strategy.

Constraints

• The application should be built using React functional components and hooks.
• All types must be defined using TypeScript.
• The simulation of concurrent edits should be handled within a single React component's state management. You do not need to implement actual network requests or separate browser tabs.
• The conflict resolution logic should be contained within a single function or hook.
• Performance is not a primary concern for this challenge, but the solution should be reasonably efficient for typical text editing scenarios.

Notes

• You can simulate "concurrent" edits by using setTimeout with small, different delays when processing edits from different simulated users. This will help you test the "Last Write Wins" logic more effectively.
• Consider how you will represent an "edit." A simple object with index, content, and perhaps a timestamp (for more advanced scenarios, though not strictly required for "Last Write Wins" if processing order is controlled) could work.
• Think about how to manage the state of the document and the queue of incoming edits.
• The focus is on the logic of conflict detection and resolution, not on building a full-fledged rich text editor UI.