more docs love

docs/articles/auto-async.md

@@ -1,4 +1,4 @@
-## Asynchronous Auto-Observable
+# Asynchronous Auto-Observable
 
 In addition to normal [`auto-observables`](auto.md), it is also possible to create auto-observables using `async` computation functions. Auto-observable will take care of starting and awaiting asynchronous computation while tracking observable access at their every execution step.
 

docs/articles/auto-run.md

@@ -1,4 +1,4 @@
-## Auto-Runs
+# Auto-Runs
 
 Sometimes we simply want to run some code that depends on observable values and have it automatically re-invoked in case any of the used values is changed. We could use an [auto-observable](auto.md) with some dummy value for that, however if there's no need for an actual value it can get a bit awkward.
 

docs/articles/auto.md

@@ -1,4 +1,4 @@
-## Auto-Observable
+# Auto-Observable
 
 Auto-observables are the main way to derive observable data from a number of *source* observables by providing a *computation* function.
 

docs/articles/binding-batching.md

@@ -1,4 +1,4 @@
-## Binding batching
+# Binding batching
 
 The binding mechanism is designed to support *batching*. This means that the binding callbacks are not executed directly when an observable value is changed, instead they are scheduled for execution all together in a batch once per *frame*.
 

docs/articles/binding.md

@@ -1,4 +1,4 @@
-## Bindings
+# Bindings
 
 We briefly mentioned the `Bind` method in the [`Observable`](observable.md) article, which allows for subscribing to `Observable<T>` value changes to bind your code to it.
 

docs/articles/collections-dict.md

@@ -1,3 +1,3 @@
-## Observable Dictionary
+# Observable Dictionary
 
 > TODO: document

docs/articles/collections-list.md

@@ -1,4 +1,4 @@
-## Observable List
+# Observable List
 
 `ObservableList<T>` is an observable wrapper around the standard `List<T>`, providing the same API for managing the collection.
 

docs/articles/collections.md

@@ -1,4 +1,4 @@
-## Observable Collections
+# Observable Collections
 
 In addition to single-value observables, there are also a number of observable collections, such as `ObservableList` and `ObservableDictionary`.
 

docs/articles/comparers.md

@@ -1,4 +1,4 @@
-## Custom Comparers
+# Custom Comparers
 
 Observables are smart enough not to trigger bindings and recalculations when the value hasn't actually changed. This is handled on two levels:
 

docs/articles/const.md

@@ -1,4 +1,4 @@
-## Constant Observable
+# Constant Observable
 
 The most simple and lightweight kind of observable is the  *const* observable for values that never change.
 

docs/articles/godot.md

@@ -1,4 +1,4 @@
-## Godot Specifics
+# Godot Specifics
 
 > **NOTE**: Godot support is currently fairly barebones and to be considered experimental. It seems to work pretty well, but it requires some amount of manual setup before using.
 

docs/articles/observable.md

@@ -1,4 +1,4 @@
-## Observable
+# Observable
 
 The core type of this library is `Observable<T>`. It represents observable data and its definition is pretty straightforward:
 
@@ -19,4 +19,4 @@ So there's a getter for the current value and a way to bind a callback for its c
 
 There are multiple implementations of `Observable<T>` and most of them can be created using static methods in the [`Observable`](xref:TinkState.Observable) helper class.
 
-See further articles about specific kinds of observables.
+See further articles about specific kinds of observables.

docs/articles/best-practices.md → docs/articles/remarks.md

@@ -1,8 +1,9 @@
+# Remarks & Advices
+
 ## Thread-safety
 
 This library is currently NOT thread-safe. There's no synchronization code and it uses some mutable static fields.
 
 ## Other (TODO)
 
 > TODO: state updates from bindings and computations, splitting auto-observables, binding and subscription lifetimes
-

docs/articles/state.md

@@ -1,4 +1,4 @@
-## State
+# State
 
 One important variation of `Observable<T>` is `State<T>`, which is a mutable observable, meaning you can also set the value:
 

docs/articles/toc.yml

@@ -41,8 +41,8 @@
     - name: Dictionary
       href: collections-dict.md
 
-- name: Best Practices & Cautions
-  href: best-practices.md
+- name: Remarks & Advices
+  href: remarks.md
 
 - name: Unity Specifics
   href: unity.md

docs/articles/unity-lifetime-helper.md

@@ -1,4 +1,4 @@
-## Binding Lifetime
+# Unity Binding Lifetime
 
 It is very important to dispose bindings to observables when they are no longer needed for two main reasons:
 
@@ -81,4 +81,4 @@ var itemPool = new ObjectPool<PooledItem>(
 );
 
 itemPool.Get().Init(myData);
-```
+```

docs/articles/unity.md

@@ -1,4 +1,4 @@
-## Unity Specifics
+# Unity Specifics
 
 While the base library itself is very generic and does not have any dependencies, one of the main motivations for its creation was to assist Unity developers with handling their models and view models. So this library also integrates with Unity out-of-the-box.
 

docs/index.md

@@ -6,9 +6,9 @@ We want to structure our data nicely, as well as combine, transform and cache it
 
 TinkState# aims to simplify and streamline this. In essence, it provides:
 
-- Observable data structures (meaning you can read values and subscribe to changes).
-- Means to define derived live-computed data from those observables (meaning changes to source values automatically updates derived values).
-- Efficient binding mechanism for your code to react to changes (e.g. update the UI).
+ - Observable data structures (meaning you can read values and subscribe to changes).
+ - Means to define derived live-computed data from those observables (meaning changes to source values automatically updates derived values).
+ - Efficient binding mechanism for your code to react to changes (e.g. update the UI).
 
 In other worlds, TinkState# implements reactive state handling. In terms of [MVVM](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel) architecture, it covers both model and viewmodel components.