Move Json domain from test to internal

[CraigMacomber]

Description

Export Json domain as internal. This is a step toward making it alpha, but that will involve more tweaking of naming/scoping.

This makes it easy for users to embed JSON content in their trees.

This could be followed up with a similar domain for fluid serializable content which is the same but allows handles: this will be needed for map -> tree adapters.

Reviewer Guidance

The review process is outlined on this wiki page.

[msfluid-bot]

Code Coverage Summary

↓ packages.dds.tree.src:
Line Coverage Change: -6.14%    Branch Coverage Change: No change

Metric Name	Baseline coverage	PR coverage	Coverage Diff
Branch Coverage	100.00%	100.00%	→ No change
Line Coverage	100.00%	93.86%	↓ -6.14%

---

Baseline commit: aa84db1
Baseline build: 305550
Happy Coding!!

Code coverage comparison check failed!!
More Details: Readme

• Skip This Check!!

What to do if the code coverage check fails:

• Ideally, add more tests to increase the code coverage for the package(s) whose code-coverage regressed.

• If a regression is causing the build to fail and is due to removal of tests, removal of code with lots of tests or any other valid reason, there is a checkbox further up in this comment that determines if the code coverage check should fail the build or not. You can check the box and trigger the build again. The test coverage analysis will still be done, but it will not fail the build if a regression is detected.

• Unchecking the checkbox and triggering another build should go back to failing the build if a test-coverage regression is detected.

• You can check which lines are covered or not covered by your tests with these steps:

  • Go to the PR ADO build.
  • Click on the link to see its published artifacts. You will see an artifact named codeCoverageAnalysis, which you can expand to reach to a particular source file's coverage html which will show which lines are covered/not covered by your tests.
  • You can also run different kind of tests locally with :coverage tests commands to find out the coverage.

[noencke]

My vote would be to call this Json or JsonTree. The term "Union", while correct, is more mechanical than it is semantic.

[CraigMacomber]

I don't think having a top level package export called Json is a great idea. JS already has JSON, and our package has lots of Json related stuff other than this. JsonTree also seems questionable as VerboseTree and ConciseTree are both Json tree formats, and this is nothing like them. If changing this, I'd lean in the direction of making it more explicitly not named like that.

[Josmithr]

If we want to be more careful / explicit with the naming, we could possibly do something like JsonDomainTree. I agree that JsonUnion doesn't really convey the semantics we want here.

But of the existing suggestions, I like JsonTree the best personally.

[CraigMacomber]

I don't think JsonDomain really does it either. Its perfectly reasonable to think of VerboseTree and ConciseTree as projections of trees into the JSON domain. This format on the other hand isn't even a JSON style object since it uses maps for objects.

Maybe JsonAsTree for JsonUnion, and JsonObjectAsTree for JsonObject?

Another approach would be to go with a namespace. Since everything in it needs the same release tag, I think we can make that work. In that case maybe JsonDomain, with a big doc comment on the namespace, would work, then the members could have short names like Object, Union/Tree, Array, etc.?

[Josmithr]

I think namespaces will break re-exports in fluid-framework 😕
microsoft/rushstack#4807

[Josmithr]

Or, well, maybe not, since we're generating our own rollups now. I'm not sure.

[Josmithr]

But I do like namespaces for things like this. JsonAsTree also seems reasonable to me.

[noencke]

I think this is a good addition to our available toolset.

We may want to consider writing a short guide on how to use this domain (kind of like the examples you provided, but a little more comprehensive) and which also clarifies how this "JSON" domain is a different thing than merely the fact that a SharedTree's data is, to some degree, natively compatible with "JSON" in its API and exposed data model - to avoid any confusion. That's something we can think about later, when this API is promoted to beta.

[github-actions]

🔗 Found some broken links! 💔

Run a link check locally to find them. See
https://github.com/microsoft/FluidFramework/wiki/Checking-for-broken-links-in-the-documentation for more information.

linkcheck output

> [email protected] ci:check-links /home/runner/work/FluidFramework/FluidFramework/docs
> start-server-and-test "npm run serve -- --no-open" 3000 check-links

1: starting server using command "npm run serve -- --no-open"
and when url "[ 'http://127.0.0.1:3000' ]" is responding with HTTP status code 200
running tests using command "npm run check-links"


> [email protected] serve
> docusaurus serve --no-open

[SUCCESS] Serving "build" directory at: http://localhost:3000/

> [email protected] check-links
> linkcheck http://localhost:3000 --skip-file skipped-urls.txt

Crawling...

http://localhost:3000/docs/data-structures/tree
- (36:97) 'the Shar..' => http://localhost:3000/docs/api/tree (HTTP 404)

http://localhost:3000/docs/data-structures/tree/
- (36:97) 'the Shar..' => http://localhost:3000/docs/api/tree (HTTP 404)

http://localhost:3000/docs/data-structures/tree/schema-definition
- (30:128) 'SharedTr..' => http://localhost:3000/docs/api/tree (HTTP 404)

http://localhost:3000/docs/start/tree-start
- (44:4) 'the API ..' => http://localhost:3000/docs/api/tree/schemafactory-class (HTTP 404)
- (61:7) 'the API' => http://localhost:3000/docs/api/tree/treechangeevents-interface (HTTP 404)


Stats:
  158264 links
    1304 destination URLs
    1535 URLs ignored
       0 warnings
       3 errors

 ELIFECYCLE  Command failed with exit code 1.