docs: extract 11 key Loro concepts into dedicated concept documents

Extracted and reorganized key Loro concepts for better accessibility:

High Priority Concepts:
- Frontiers: Compact version representation using operation IDs
- OpLog and DocState Separation: Architecture split between state and history
- Attached/Detached States: Document version state and container association
- Operations and Changes: How operations group and form changes

Medium Priority Concepts:
- Event Graph Walker: Novel CRDT algorithm using simple indices
- Cursor and Stable Positions: Position references surviving concurrent edits
- Import Status: Tracking successful imports and pending operations
- Version Representations: Comparison between Version Vectors and Frontiers

Low Priority Concepts:
- Shallow Snapshots: Partial history snapshots with content redaction
- PeerID Management: ID assignment and conflict avoidance strategies
- Transaction Model: Operation bundling for event emission

Changes made:
- Created 11 new concept documents with beginner-friendly explanations
- Set up redirects from original locations in advanced section
- Updated navigation structure in _meta.js
- Migrated relevant images and diagrams
- Made documentation more progressive, starting simple and building complexity

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <[email protected]>

Author: zxch3n

pages/docs/advanced/doc_state_and_oplog.mdx

@@ -1,88 +1 @@
----
-keywords: "crdt, oplog, snapshot, doc state, checkout, version"
-description: "Introducing Loro's DocState and OpLog concepts"
----
-
-# DocState and OpLog
-
-Although not explicitly exposed in the WASM interface, internally in Loro, we
-distinctly differentiate between:
-
-- The current state of the document: DocState
-- The edit history of the document: OpLog
-
-During local operations, we update the DocState and record the operations in
-OpLog. When merging remote updates, we add the new Ops to OpLog and compute a
-Delta. This Delta is applied to DocState and also emitted as an event.
-
-DocState can switch between different versions, similar to Git's checkout. In
-this case, we calculate the Delta based on the edit history. The same mechanism
-applies: the Delta is emitted as an event and applied to DocState.
-
-Impact on the encoding schema:
-
-- When calling `doc.export({ mode: "update" })` or
-  `doc.export({ mode: "update-in-range" })`, we only encode the operations that
-  occurred after the specified version.
-- When calling `doc.export({ mode: "snapshot" })` or
-  `doc.export({ mode: "shallow-snapshot" })`, we encode both OpLog and DocState,
-  providing rapid loading speed (as it doesn't require recalculating the state
-  of DocState).
-
-## Attached/Detached LoroDoc Status
-
-As we aim to support version control and the ability to load OpLog without
-state, the version of DocState and the latest version recorded in OpLog may not
-always match. When they align, it is in an _attached_ state; otherwise, it's in
-a _detached_ state.
-
-```ts twoslash
-import { LoroDoc } from "loro-crdt";
-// ---cut---
-const doc = new LoroDoc();
-doc.setPeerId(1);
-doc.getText("text").insert(0, "Hello");
-const doc2 = doc.fork(); // create a fork of the doc
-console.log(doc.version().toJSON());
-// Map(1) { "1" => 5 }
-console.log(doc.oplogVersion().toJSON());
-// Map(1) { "1" => 5 }
-
-doc.checkout([{ peer: "1", counter: 1 }]);
-console.log(doc.version().toJSON());
-// Map(1) { "1" => 2 }
-console.log(doc.oplogVersion().toJSON());
-// Map(1) { "1" => 5 }
-
-doc2.setPeerId(2);
-doc2.getText("text").insert(5, "!");
-doc.import(doc2.export({ mode: "update" }));
-console.log(doc.version().toJSON());
-// Map(1) { "1" => 2 }
-console.log(doc.oplogVersion().toJSON());
-// Map(2) { "1" => 5, "2" => 1 }
-
-console.log(doc.isDetached()); // true
-doc.attach();
-console.log(doc.version().toJSON());
-// Map(2) { "1" => 5, "2" => 1 }
-console.log(doc.oplogVersion().toJSON());
-// Map(2) { "1" => 5, "2" => 1 }
-
-```
-
-![DocState and OpLog Detached Example](./images/version-4.png)
-
-The doc cannot be edited in the detached mode. Users must use `attach()` to
-return to the latest version to continue editing.
-
-### Attached/Detached Container Status
-
-This refers to whether a container is associated with a document. If not, it's a
-detached container created by methods like `new LoroText()`. The `.isAttached()`
-state never changes for an instance of a container.
-
-When you insert a detached container into an attached one, you get a new
-attached container that has the same content as the detached one.
-
-> This is different from the LoroDoc's attached/detached status
+export const redirect = '/docs/concepts/oplog_docstate'

pages/docs/advanced/event_graph_walker.mdx

@@ -1,59 +1 @@
----
-keywords: "crdt, event graph walker, eg-walker, synchronization, collaboration"
-description: "introduction to Event Graph Walker, a crdt algorithm for real-time collaboration and synchronization."
----
-
-# Brief Introduction to Event Graph Walker (Eg-Walker)
-
-Eg-walker is a novel CRDT algorithm introduced in:
-
-> [Collaborative Text Editing with Eg-walker: Better, Faster, Smaller](https://arxiv.org/abs/2409.14252)  
-> By: Joseph Gentle, Martin Kleppmann
-
-import { ReactPlayer } from "../../../components/video";
-
-<ReactPlayer
-  url="/static/REG.mp4"
-  width={512}
-  style={{maxWidth: "calc(100vw - 40px)"}}
-  height={512}
-  muted={true}
-  loop={true}
-  controls={true}
-  playing={true}
-/>
-
-Whether dealing with real-time collaboration or multi-end synchronization, a 
-directed acyclic graph (DAG) forms over the history of these parallel edits,
-similar to Git's history. The Eg-walker algorithm records the history of user edits
-on the DAG. Unlike conventional CRDTs, Eg-walker can record just the original description
-of operations, not the metadata of CRDTs.
-
-For instance, in text editing scenarios, the [RGA algorithm] needs the op ID and
-[Lamport timestamp][Lamport] of the character to the left to determine the
-insertion point. [Yjs]/Fugue, however, requires the op ID of both the left and
-right characters at insertion. In contrast, Eg-walker simplifies this by only
-recording the index at the time of insertion. Loro, which uses [Fugue] upon Eg-walker,
-inherits these advantages.
-
-An index is not a stable position descriptor, as the index of an operation can
-be affected by other operations. For example, if you highlight content from
-`index=x` to `index=y`, and concurrently someone inserts n characters at
-`index=n` where `n<x`, then your highlighted range should shift to cover from
-`x+n` to `y+n`. However, Eg-walker can determine the exact position of this index and
-reconstruct the corresponding CRDT structure by replaying history.
-
-Reconstructing history might seem time-consuming, but Eg-walker can backtrack only
-some. When merging updates from remote, it only needs to replay the operations 
-between the current version and the remote version up to their lowest common ancestor,
-constructing a temporary CRDTs to calculate the effect of the remote update.
-
-The Eg-walker algorithm excels with its fast local update speeds and eliminates
-concerns about tombstone collection in CRDTs. For instance, if an operation has
-been synchronized across all endpoints, no new operations will occur
-concurrently with it, allowing it to be safely removed from the history.
-
-[Lamport]: https://en.wikipedia.org/wiki/Lamport_timestamp
-[Fugue]: https://arxiv.org/abs/2305.00583
-[RGA algorithm]: https://www.sciencedirect.com/science/article/abs/pii/S0743731510002716
-[Yjs]: https://github.com/yjs/yjs
+export const redirect = '/docs/concepts/event_graph_walker'

pages/docs/advanced/op_and_change.mdx

@@ -1,144 +1 @@
-# Operations and Change
-
-In Loro, every basic operation such as setting a key-value pair on a Map, adding
-a list item, or inserting/deleting a character in text is considered an
-individual op. (Don't worry about the cost, in Loro's internal memory
-representation and export format, consecutive ops are merged into a larger op,
-such as consecutive text insertions and deletions.)
-
-One or more local consecutive `Op`s constitute a `Change`, which includes the
-following information:
-
-- ID: ID of the Change is essentially the first op's ID
-- Timestamp: An optional timestamp, which can be enabled with
-  `setRecordTimestamp(true)`. If not enabled, there is no extra storage
-  overhead.
-- Dependency IDs: Used to represent the causal order, the Op IDs that the
-  current Change directly depends on.
-- Commit Message: An optional commit message (WIP not yet released); when not
-  enabled, there is no extra storage overhead.
-
-Each time `doc.commit()` is called, a new `Change` is generated, which will be
-merged with the previous local `Change` as much as possible to reduce the amount
-of metadata that needs to be stored.
-
-> Note: Each time you export, a `doc.commit()` is implicitly performed by the
-> Loro Doc.
-
-Unlike a Git commit, Loro's Change can be merged; it is neither atomic nor
-indivisible. This design allows Loro to better accommodate real-time
-collaboration scenarios (where each keystroke would have its own `doc.commit()`,
-which would be hugely costly if not merged) and asynchronous collaboration
-scenarios (like Git, which combines many modifications to form one).
-
-## When a New Change is Formed
-
-> Note: You may not need to understand the content of this section, and the
-> content may change in future versions. Unless you want to understand Loro's
-> internal implementation or want to achieve more extreme performance
-> optimization.
-
-By default, each commit-generated `Change` will merge with the previous local
-`Change`. However, there are exceptions in several cases:
-
-- The current Change depends on a Change from a different peer. This occurs when
-  local operations build upon recently applied remote operations. For example,
-  deleting a character sequence that was just inserted by a remote peer. These
-  causal relationships form a DAG (Directed Acyclic Graph). After importing
-  remote updates, the next local Change will have new dependency IDs,
-  necessitating a separate Change.
-- When `setRecordTimestamp(true)` is set, if the time interval between
-  successive Changes exceeds the "change merge interval" (default duration
-  1000s).
-- When the current Change has a different commit message from the previous
-  Change by the same peer.
-
-## Example
-
-```ts twoslash
-import { Change, LoroDoc } from "loro-crdt";
-// ---cut---
-const docA = new LoroDoc();
-docA.setPeerId("0");
-const textA = docA.getText("text");
-// This create 3 operations
-textA.insert(0, "123");
-// This create a new Change
-docA.commit();
-// This create 2 operations
-textA.insert(0, "ab");
-// This will NOT create a new Change
-docA.commit();
-
-{
-  const changeMap: Map<`${number}`, Change[]> = docA.getAllChanges();
-  console.log(changeMap);
-  // Output:
-  //
-  // Map(1) {
-  //   "0" => [
-  //     {
-  //       lamport: 0,
-  //       length: 5,
-  //       peer: "0",
-  //       counter: 0,
-  //       deps: [],
-  //       timestamp: 0
-  //     }
-  //   ]
-  // }
-}
-
-// Create docB from doc
-const docB = LoroDoc.fromSnapshot(docA.export({ mode: "snapshot" }));
-docB.setPeerId("1");
-const textB = docB.getText("text");
-// This create 2 operations
-textB.insert(0, "cd");
-
-// Import the Change from docB to doc
-const bytes = docB.export({ mode: "update" }); // Exporting has implicit commit
-docA.import(bytes);
-
-// This create 1 operations
-textA.insert(0, "1");
-// Because doc import a Change from docB, it will create a new Change for
-// new commit to record this causal order
-docA.commit();
-{
-  const changeMap: Map<`${number}`, Change[]> = docA.getAllChanges();
-  console.log(changeMap);
-  // Output:
-  //
-  // Map(2) {
-  //   "0" => [
-  //     {
-  //       lamport: 0,
-  //       length: 5,
-  //       peer: "0",
-  //       counter: 0,
-  //       deps: [],
-  //       timestamp: 0
-  //     },
-  //     {
-  //       lamport: 7,
-  //       length: 1,
-  //       peer: "0",
-  //       counter: 5,
-  //       deps: [ { peer: "1", counter: 1 } ],
-  //       timestamp: 0
-  //     }
-  //   ],
-  //   "1" => [
-  //     {
-  //       lamport: 5,
-  //       length: 2,
-  //       peer: "1",
-  //       counter: 0,
-  //       deps: [ { peer: "0", counter: 4 } ],
-  //       timestamp: 0
-  //     }
-  //   ]
-  // }
-}
-```
+export const redirect = '/docs/concepts/operations_changes'