automerge / automerge-swift-archived

Wrapper around Swift types that can be modified concurrently by different users, and merged again automatically (a CRDT).
MIT License
159 stars 14 forks source link

Enabling initial DocC documentation of Automerge-swift #43

Closed heckj closed 2 years ago

heckj commented 2 years ago

As I was starting in on using Automerge through swift, I thought I might contribute back some basic documentation. This PR has the working elements to enable DocC rendering of the documentation - right now just within Xcode (and any projects that use Automerge-swift as a dependency).

I replicated the content of the repositories README into an article within the documentation, made links to the relevant methods, and generally stubbed out a structure.

lightsprint09 commented 2 years ago

This looks fantastic. Really looking forward to have proper DocC Support and even see how it works.

heckj commented 2 years ago

I think this is about as far as I can take things for an initial cut - and would make most sense to remove and rebase after #49 and #46 have been merged.

The coverage this provides based on the (experimental) doc coverage metrics from docc:

   --- Experimental coverage output enabled. ---
                | Abstract        | Curated         | Code Listing
Types           | 68% (17/25)     | 96% (24/25)     | 0.0% (0/25)
Members         | 11% (55/507)    | 82% (415/507)   | 0.20% (1/507)
Globals         | 5.7% (2/35)     | 97% (34/35)     | 0.0% (0/35)

I have a general intention of using the APIs more, working them end to end, and perhaps against another Automerge API endpoint (something I cobble as an experiment) - and from that I think I could create more "how to use" information.

The general pattern of the articles loosely follows the examples in the README, with some of that content having been integrated down into the relevant classes or structs. The notable lack is anything really detailing how to use a more "raw" document type of Map, List, Text, or Counter.