docs: add usage documentation for data access, resource management, and tags

Author: jeremy-code

docs/usage/data.md

@@ -0,0 +1,30 @@
+# Data
+
+There are three ways to access the data of an `ExifEntry`.
+
+1. `toString()`
+
+`toString()` internally calls `exif_entry_get_value()` and returns a string. This will be context dependent (i.e. tag-aware). It's most useful for `ASCII` types or for human usage.
+
+2. `.data`
+
+`.data` returns the `ExifEntry`'s data as a Uint8Array. Since it is using the buffer's byte order rather than the byte order of the `ExifEntry` (see [byte-order.md](byte-order.md)), this may be difficult to manipulate or read, but it is the most direct access to the `ExifEntry`'s data. It is indepdenent of format, tag, and byte order.
+
+One note is that when updating it, the previous `.data` will be freed automatically. Furthermore, while `.size` will be updated for you, `.components` will not, and you will have to update it yourself.
+
+3. `toTypedArray`/`fromTypedArray`
+
+These methods did not exist in the original API. They require both the format and the byte order to have already been set correctly. However, they internally use the utility functions that read libexif data structures in `exifUtils.ts` to ensure the data is interepreted properly. The output is based on the format, being:
+
+- ASCII, UNDEFINED, BYTE: Uint8Array
+- SBYTE: Int8Array
+- SHORT: Uint16Array
+- SSHORT: Int16Array
+- LONG, RATIONAL: Uint32Array
+- SLONG, SRATIONAL: Int32Array
+
+If using `fromTypedArray`, the input typedArray will be converted to the correct byte order.
+
+Since RATIONAL and SRATIONAL return a TypedArray for convenience, if one wants to convert them into rational objects with numerator and denominators, `mapRationalFromObject` and `mapRationalToObject` exist.
+
+Unlike `.data`, `.components` will be set for you.

docs/usage/resource-management.md

@@ -0,0 +1,29 @@
+# Resource Management
+
+By default, most classes implement the the TypeScript `Disposable` interface, which uses the [`Symbol.dispose` well-known symbol](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/dispose). Hence, for those using TypeScript or in browsers that support it, one can use the [`using`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/using) keyword to automatically clean up any memory allocated.
+
+```ts
+using exifData = ExifData.from(data);
+// Cleaned up automatically after use
+```
+
+Suppose you intend on interacting with a resource from one of these classes. You should generally do it like this:
+
+```ts
+using exifData = ExifData.from(data);
+const exifContent = exifData.ifd[0];
+```
+
+This is because when `exifData.free()` is ran, it automatically frees the resources it relies on, including its exifContent IFD memory allocations.
+
+However, if you intend on changing it, you will need to free the one you are no longer using:
+
+```ts
+using exifData = ExifData.from(data);
+const exifContent = ExifContent.new();
+const prevExifContent = exifData.ifd[0];
+exifContent.ifd = exifContent.ifd.with(0, exifContent);
+prevExifContent.free();
+```
+
+The generally holds true for most data structures in this library, with the exception of ExifEntry.data, which will automatically free itself.

docs/usage/tags.md

@@ -0,0 +1,12 @@
+# Tags
+
+Tags are represented by two enums: `ExifTag` and `ExifTagGps`. For simplicity, these are merged into the enum `ExifTagUnified`. You can generally use it the same way you would any other enum with the exception of four tags:
+
+- `LATITUDE_REF`: 1
+- `INTEROPERABILITY_INDEX`: 1
+- `LATITUDE`: 2
+- `INTEROPERABILITY_VERSION`: 2
+
+These tags have different meanings in different ifds.
+
+`.tagVal` is avaliable in `ExifEntry` if one needs the value directly. Alternatively, `getExifTagTable` also offers the whole array of `TagEntry[]` with their tag value, name, title, description, and support level, if necessary.