A score changes and the scoreboard redraws. A door unlocks and three things react. Written by hand that is a field, a setter, a list of things to poke, and a bug the first time somebody forgets to poke one.

Udonite Observables is that pattern, once, in ordinary C#:

```csharp
using Udonite.Observables;

public class Scoreboard : UdoniteBehaviour
{
    public TextMeshProUGUI label;

    private Observable<int> score = new Observable<int>();

    public override void Start()
    {
        score.Subscribe(OnScoreChanged, true);
        score.Value = 10;
    }

    private void OnScoreChanged(int value)
    {
        label.text = value.ToString();
    }
}
```

**Setting the same value again notifies nobody.** That is the point of it. A behaviour that assigns every frame costs one comparison per frame instead of a round of callbacks, and a subscriber that redraws a label is never asked to redraw an unchanged one.

## What is in it

| Type | Notifies when |
|---|---|
| `Observable<T>` | the value is set to something different |
| `ObservableList<T>` | an element is added, removed, replaced or cleared |
| `ObservableDictionary<TKey, TValue>` | a key is set to something different, removed, or cleared |

`ISubscribable<T>` is the read side. A field typed that way can be subscribed to and not written, which is the difference between reading a score and being allowed to change it. The collections implement it against themselves, so all three subscribe the same way.

## Where to go next

[Getting started](/docs/observables/getting-started) goes from an empty behaviour to a value two other behaviours react to.

[Reference](/docs/observables/reference) is every member of the three types, and what each one notifies.

[Notification rules](/docs/observables/notification-rules) is the part worth reading before shipping: what happens when a subscriber subscribes, unsubscribes or writes back during a notification, and which of those Udon will not let you do at all.