Deprecate previousInterval/nextInterval APi from IntervalCollection

[clarenceli-msft]

AB#5288

According to https://github.com/clarenceli-msft/FluidFramework/blob/596f777e38fbf2b7474196b4c65a80b4dfc16333/.changeset/happy-dreams-sing.md

As title, the functionality of previousInterval and nextInterval are shifted to endpointIndex. The only usage of these functionalities occurs in table-document fluid example, some workarounds are included

[msfluid-bot]

⯅ @fluid-example/bundle-size-tests: +14 Bytes

Metric Name	Baseline Size	Compare Size	Size Diff
aqueduct.js	450.63 KB	450.63 KB	⯅ +2 Bytes
connectionState.js	680 Bytes	680 Bytes	■ No change
containerRuntime.js	240.94 KB	240.94 KB	■ No change
loader.js	167.41 KB	167.41 KB	⯅ +2 Bytes
map.js	48.05 KB	48.05 KB	⯅ +2 Bytes
matrix.js	141.84 KB	141.84 KB	⯅ +2 Bytes
odspDriver.js	90.35 KB	90.36 KB	⯅ +2 Bytes
odspPrefetchSnapshot.js	41.82 KB	41.82 KB	⯅ +2 Bytes
sharedString.js	162.77 KB	162.77 KB	■ No change
sharedTree2.js	284.23 KB	284.23 KB	■ No change
Total Size	1.74 MB	1.74 MB	⯅ +14 Bytes

---

Baseline commit: 4100024

Generated by 🚫 dangerJS against 5d6b8fe

[Abe27342]

Do we have test coverage if you break this function?

Assuming yes, let's avoid changing the public API of SparseMatrix: you already need to make a cast of something that isn't SharedString to a SharedString.

Instead, you should create the endpoint interval index inside the DataObject here and use nextInterval directly.

[Abe27342]

if you wanted, you could change the signature of the index creation methods to only take in SharedSegmentSequence instead of SharedString, which would legitimize this call and still work, but I'm not sure the distinction is something we really want long-term considering we kind of want to deprecate all of the other shared sequences. So I think just doing the cast here is superior for now.

[Abe27342]

If we don't have test coverage for this method breaking, you should add such a test in table-document as it's plausible we could at some point break it.

[clarenceli-msft]

I found there existed the test coverage on this method (but not tested directly). The method is invoked when the tableDocument creates a slice. Additionally, it requires the label to obtain the intervalCollection, which is not externally accessible. I believe it should be acceptable as long as incorporating the interval index does not break the current tests.

[Abe27342]

Yeah, if intentionally breaking this method causes existing tests to fail, I think we're fine. Thanks for checking!