-
Notifications
You must be signed in to change notification settings - Fork 531
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Clone to SharedTree Revertible #23044
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Coverage Summary
↓ packages.dds.tree.src.shared-tree:
Line Coverage Change: -0.03% Branch Coverage Change: -0.15%
Metric Name | Baseline coverage | PR coverage | Coverage Diff |
---|---|---|---|
Branch Coverage | 90.88% | 90.73% | ↓ -0.15% |
Line Coverage | 97.28% | 97.25% | ↓ -0.03% |
↑ packages.dds.tree.src.simple-tree.api:
Line Coverage Change: 0.01% Branch Coverage Change: No change
Metric Name | Baseline coverage | PR coverage | Coverage Diff |
---|---|---|---|
Branch Coverage | 88.76% | 88.76% | → No change |
Line Coverage | 82.35% | 82.36% | ↑ 0.01% |
Baseline commit: cfb6838
Baseline build: 306774
Happy Coding!!
Code coverage comparison check passed!!
⯅ @fluid-example/bundle-size-tests: +919 Bytes
Baseline commit: cfb6838 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copilot reviewed 5 out of 6 changed files in this pull request and generated no suggestions.
Files not reviewed (1)
- packages/dds/tree/src/core/index.ts: Evaluated as low risk
Comments skipped due to low confidence (2)
packages/dds/tree/src/shared-tree/treeCheckout.ts:634
- [nitpick] The method name 'clone' might be ambiguous. Consider renaming it to 'createClone' or 'duplicate' for better clarity.
clone: (forkedBranch?: TreeBranch) => {
packages/dds/tree/src/shared-tree/treeCheckout.ts:639
- [nitpick] The error message 'Unable to dispose a revertible that has already been disposed.' could be more descriptive. Consider providing more context about why this error might occur.
throw new UsageError("Unable to dispose a revertible that has already been disposed.");
Tip: Copilot code review supports C#, Go, Java, JavaScript, Markdown, Python, Ruby and TypeScript, with more languages coming soon. Learn more
|
||
it("clone revertible fails if trees are different", () => { | ||
const viewA = asTreeViewAlpha(createLocalSharedTree("testSharedTreeOne")); | ||
const viewB = asTreeViewAlpha(createLocalSharedTreeTwo("testSharedTreeTwo")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For this test case, it's not important that the two trees have different schema - the part that matters is that they are different instances of a SharedTree. So, it should be perfectly fine to initialize viewB
using a second call to createLocalSharedTree()
rather than createLocalSharedTreeTwo()
. And then you can delete createLocalSharedTreeTwo()
.
@@ -453,6 +464,137 @@ describe("Undo and redo", () => { | |||
revertible.revert(); | |||
assert.equal(view.root.foo, 1); | |||
}); | |||
|
|||
it("reverts original & forked revertibles after making change to the original view", () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you write these tests within the loop that all of the other tests (except 1 - "can undo while detached") in this file are in? If you look at the describe block at the top of the file, you will see that it runs all the tests in "attached" and "detached" modes. If you adapt your tests here to use the getCheckout
helper, it should be easy to have them do the same thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, actually, it's a little weird. You have a couple of options.
- Write your tests in the pattern already established in this file. So, you don't define a schema, and instead you do what all the other tests do and use
createCheckout
andtree.editor
to do edits. This isn't the best way to edit the tree, but it's consistent with how the rest of the file is doing it. So when somebody goes to convert this file later to the "better way", it won't really add any more work to change your tests since they'll all be updated in the same way. - Write your tests in a newer, better pattern - kind of what you are already doing, although I'd recommend you use something like
TestTreeProviderLite
rather than writing the factory/runtime code yourself. This is nice because it uses a real schema, and the better APIs for editing. However, then we end up with two different patterns in this file - the existing ones, and your new ones. And somebody coming along later to fix this file will have to deal with both patterns.
My vote would be for (1). We should either convert this whole file to a better test pattern first, and then do this PR. Or, we should write new tests in the same way as the current pattern, and then convert them all at once.
Curious what you think. Either way, having your tests run against both "attached" and "detached" scenarios is valuable - and doing that and also (2) will mean some duplicated/divergent code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I can go along with case (1) and I've noticed that there are skipped cases with // TODO: unskip once forking revertibles is supported
comment.
I can un-skip these pre-written test cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've tried to use createCheckout()
and tree.editor
but realized clone: (branch?: TreeBranch)
, thus I can't (and shouldn't) pass TreeCheckout
. Unless there is a way to convert TreeCheckout
to TreeBranch
prior to calling clone()
, I think I should rewrite the skipped tests with my test design.
What do you think?
@@ -409,7 +409,7 @@ export class SchematizingSimpleTreeView< | |||
* @remarks Currently, all contexts are also {@link SchematizingSimpleTreeView}s. | |||
* Other checkout implementations (e.g. not associated with a view) may be supported in the future. | |||
*/ | |||
function getCheckout(context: TreeBranch): TreeCheckout { | |||
export function getCheckout(context: TreeBranch): TreeCheckout { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@noencke should using this function be established as the normal pattern? there are a bunch of places I know of that are just getting the checkout directly but also, are we really that concerned about checking that it's a schematizing simple tree view?
revertible.dispose(); | ||
} | ||
}, | ||
clone: (forkedBranch?: TreeBranch) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what was the reasoning behind allowing forkedBranch to be optional? why not just make it required and not allow clone to be called without a fork? the behavior for cloning a revertible onto the same checkout doesn't seem obvious to me and i'm not sure why we'd want to do so
assert.equal(clonedUndoOriginalPropertyTwo?.status, RevertibleStatus.Disposed); | ||
}); | ||
|
||
it("reverts cloned revertible on original view", () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you should add a test that expects clone to throw if the view doesn't have the revision (also in the case where the view already reverted something)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think clone revertible fails if trees are different
already tests "no revision in view" scenario?
The test tries to clone(viewB).revert()
on a revertible created from viewA
. Since, viewA
and viewB
but fails since the revertible
passed to the viewB
doesn't exist in its revertibleCommitBranch
.
Added test case cloned revertible fails if already applied
for view already reverted something
scenario. Thanks.
Co-authored-by: Jenn <[email protected]>
Co-authored-by: Jenn <[email protected]>
Co-authored-by: Jenn <[email protected]>
🔗 No broken links found! ✅ Your attention to detail is admirable. linkcheck output
|
Description
13864
This PR adds forkable revertible feature to the
Revertible
object of SharedTree.DisposableRevertible
and replaced byRevertibleAlpha
.clone()
method to the new interface.TreeBranch
(which is subset ofTreeCheckout
) to access data necessary for revert operation.