docs(tree): split shared tree doc into more specialized pages #23380
Conversation
There was a problem hiding this comment.
Copilot reviewed 1 out of 5 changed files in this pull request and generated no comments.
Files not reviewed (4)
- docs/docs/data-structures/tree/node-types.mdx: Language not supported
- docs/docs/data-structures/tree/reading-and-editing.mdx: Language not supported
- docs/docs/data-structures/tree/schema-definition.mdx: Language not supported
- docs/docs/start/tree-start.mdx: Language not supported
github-actions
bot
added
area: website
base: main
Can you provide some context on why you are doing this and what are the docs supposed to look like? |
| @@ -0,0 +1,44 @@ | |||
| --- | |||
| title: Events | |||
| sidebar_position: 4 | |||
There was a problem hiding this comment.
There is another page with the same sidebar_position.
| sidebar_position: 1 | ||
| --- | ||
|
|
||
| Information is stored on a [SharedTree](./index.mdx) in the form of tree nodes. |
There was a problem hiding this comment.
Does information mean the same as the data in the shared tree? I guess I am not sure what's the difference is between this line and the first line in node_types.mdx. Do they mean the same thing?
There was a problem hiding this comment.
They do, I changed this so that it's not duplicated.
There was a problem hiding this comment.
I think it's okay for it to be duplicated if it makes it less confusing.
|
|
||
| import { PackageLink } from "@site/src/components/shortLinks"; | ||
|
|
||
| A `SchemaFactory` object is created by passing a unique string such as a UUID to the constructor. |
There was a problem hiding this comment.
You should add some context here on what this doc is about. It starts talking about schemaFactory which seems kind of abrupt.
| Additionally, all changes in a transaction will be reverted together as a single unit by [undo/redo code](./undo-redo.mdx), because changes within a transaction are exposed through a single `Revertible` object. | ||
| It is also more efficient for SharedTree to process a large number of changes in a row as a transaction rather than as changes submitted separately. | ||
|
|
||
| To create a transaction use the `Tree.runTransaction()` method. You can cancel a transaction from within the callback function by returning the special "rollback object", available via `Tree.runTransaction.rollback`. Also, if an error occurs within the callback, the transaction will be canceled automatically before propagating the error. |
There was a problem hiding this comment.
Note that there is a new API for transaction - TreeViewAlpha:runTransaction.
So, this section needs to be updated. Maybe in a follow-up PR.
|
|
||
| If you want the `SharedTree` to treat a set of changes atomically, wrap these changes in a transaction. | ||
| Using a transaction guarantees that (if applied) all of the changes will be applied together synchronously (though, note that the Fluid Framework guarantees this already for any sequence of changes that are submitted synchronously). However, the changes may not be applied at all if the transaction is given one or more constraints. | ||
| If any constraint on a transaction is not met, then the transaction and all its changes will ignored by all clients. |
There was a problem hiding this comment.
It also needs to include a section about nested transactions similar to how it is described here.
Co-authored-by: Navin Agarwal <45832642+agarwal-navin@users.noreply.github.com>
|
🔗 No broken links found! ✅ Your attention to detail is admirable. linkcheck output |
This change splits up content on the tree page on the fluid framework website into subpages and changes the current page into an introductory page that links to the more detailed subpages. This change is not meant to make any significant changes to the current content and is instead, mainly an organizational change.