Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 0 additions & 1 deletion docs/_guide/abilities.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,6 @@
---
chapter: 14
subtitle: Abilities
hidden: true
---

Under the hood Catalyst's controller decorator is comprised of a handful of separate "abilities". Each of these abilities is created with the `createAbility` function. An "ability" is essentially a mixin or perhaps "higher order class". An ability takes a class and returns an extended class that adds additional behaviours. Importantly abilities are idempotent, meaning applying an ability to a class multiple times is safe and the ability is only applied once. By convention all abilities exported by Catalyst are suffixed with `able` which we think is a nice way to denote that something is an ability and should be used as such. Catalyst also exposes all of the tooling to create your own abilities in your own code which we'd encourage if you find yourself repeating patterns within components (if you think you've got a really useful ability, we'd love for you to contribute it)!
Expand Down
1 change: 0 additions & 1 deletion docs/_guide/create-ability.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,6 @@
---
chapter: 16
subtitle: Create your own abilities
hidden: true
---

Catalyst provides the functionality to create your own abilities, with a few helper methods and a `controllable` base-level ability. These are explained in detail below, but for a quick summary they are:
Expand Down
1 change: 0 additions & 1 deletion docs/_guide/providable.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,6 @@
---
chapter: 15
subtitle: The Provider pattern
hidden: true
---

The [Provider pattern](https://www.patterns.dev/posts/provider-pattern/) allows for deeply nested children to ask ancestors for values. This can be useful for decoupling state inside a component, centralising it higher up in the DOM heirarchy. A top level container component might store values, and many children can consume those values, without having logic duplicated across the app. It's quite an abstract pattern so is better explained with examples...
Expand Down