Branching APIs

[noencke]

Description

This exposes the branching APIs on the SharedTree checkout objects as alpha APIs.

See the changeset for more details.

[github-actions]

🔗 No broken links found! ✅

Your attention to detail is admirable.

linkcheck output

> [email protected] ci:linkcheck /home/runner/work/FluidFramework/FluidFramework/docs
> start-server-and-test ci:start 1313 linkcheck:full

1: starting server using command "npm run ci:start"
and when url "[ 'http://127.0.0.1:1313' ]" is responding with HTTP status code 200
running tests using command "npm run linkcheck:full"


> [email protected] ci:start
> http-server ./public --port 1313 --silent


> [email protected] linkcheck:full
> npm run linkcheck:fast -- --external


> [email protected] linkcheck:fast
> linkcheck http://localhost:1313 --skip-file skipped-urls.txt --external

Crawling...

Stats:
  406238 links
    3158 destination URLs
       2 URLs ignored
       0 warnings
       0 errors

[msfluid-bot]

⯅ @fluid-example/bundle-size-tests: +1.98 KB

Metric Name	Baseline Size	Compare Size	Size Diff
aqueduct.js	460.43 KB	460.47 KB	⯅ +35 Bytes
azureClient.js	559.03 KB	559.08 KB	⯅ +49 Bytes
connectionState.js	680 Bytes	680 Bytes	■ No change
containerRuntime.js	261.68 KB	261.69 KB	⯅ +14 Bytes
fluidFramework.js	402.58 KB	403.47 KB	⯅ +906 Bytes
loader.js	134.17 KB	134.19 KB	⯅ +14 Bytes
map.js	42.43 KB	42.44 KB	⯅ +7 Bytes
matrix.js	145.87 KB	145.88 KB	⯅ +7 Bytes
odspClient.js	526.18 KB	526.23 KB	⯅ +49 Bytes
odspDriver.js	97.8 KB	97.82 KB	⯅ +21 Bytes
odspPrefetchSnapshot.js	42.76 KB	42.78 KB	⯅ +14 Bytes
sharedString.js	162.83 KB	162.84 KB	⯅ +7 Bytes
sharedTree.js	393.05 KB	393.92 KB	⯅ +899 Bytes
Total Size	3.3 MB	3.3 MB	⯅ +1.98 KB

---

Baseline commit: 1d9f4c9

Generated by 🚫 dangerJS against feda7f6

[Josmithr]

Honestly, these private remarks probably want to be public (standard remarks). @privateRemarks don't end up in our API docs, and I think this information is potentially useful to end-users experimenting with this API.

[noencke]

I don't want to promise anything more than we need to regarding the future public API.

[Josmithr]

The point isn't to make promises about what the API will look like. It's to note to users that the current API shape is not what we expect it to look like long term.

[noencke]

Sorry - I thought I had added a line that says "This API is subject to change...", and I did, but only on the second overload. Either way though, are we expected to write a disclaimer along with every alpha API we expose? I don't think it's a bad idea, but we should probably have something standard if so.

[Josmithr]

I think it depends on the kind of experimental API. In some cases, we'll be adding an API that we actually potentially expect to promote more or less as-is. In other cases, we're forced to do things like this (adding a free function, rather than a method on some existing type) to avoid breaking changes. In the latter case, I think it's helpful to note that API is exposed in a less-than-ideal format to avoid breaking changes, so users are prepared for the shape to change when it gets promoted.

I don't think it's critical, but I think it helps set some useful expectations for users and for other devs on the team.