fixup! change snippet markup for tutorial

docs/tutorial.md

@@ -16,20 +16,25 @@ plain JavaScript.
 
 To begin with, let's define that has nothing but an initial state.
 
-[filename](tutorial-1.test.ts ':include :type=code :fragment=tut1')
+```
+--8<- "docs/tutorial-1.test.ts:tut1"
+```
 
 Congrats! You have written your first Updux object. It
 doesn't do a lot, but you can already create a store out of it, and its
 initial state will be automatically set:
 
-[filename](tutorial-1.test.ts ':include :type=code :fragment=tut2')
+```
+--8<- "docs/tutorial-1.test.ts:tut2"
+```
 
 ## Add actions
 
 This is all good, but very static. Let's add some actions!
 
-
-[filename](tutorial-actions.test.ts ':include :type=code :fragment=actions1')
+```
+--8<- "docs/tutorial-actions.test.ts:actions1"
+```
 
 ### Accessing actions
 
@@ -37,14 +42,18 @@ Once an action is defined, its creator is accessible via the `actions` accessor.
 This is not yet terribly exciting, but it'll get more interesting once we begin using
 subduxes.
 
-[filename](tutorial-actions.test.ts ':include :type=code :fragment=actions2')
+```
+--8<- "docs/tutorial-actions.test.ts:actions2"
+```
 
 ### Adding a mutation
 
 Mutations are the reducing functions associated to actions. They
 are defined via the `addMutation` method.
 
-[filename](tutorial-actions.test.ts ':include :type=code :fragment=addMutation')
+```
+--8<- "docs/tutorial-actions.test.ts:addMutation"
+```
 
 
 Note that in the mutation we take the liberty of changing the state directly.
@@ -61,7 +70,9 @@ The `getState` and `dispatch` functions are augmented with the dux selectors,
 and actions, respectively. The selectors and actions are also available
 from the api object.
 
-[filename](tutorial-effects.test.ts ':include :type=code :fragment=effects-1')
+```
+--8<- "docs/tutorial-effects.test.ts:effects-1"
+```
 
 ## Selectors
 
@@ -70,7 +81,9 @@ The `getState` method of a dux store will be augmented
 with its selectors, with the first call for the state already
 curried for you.
 
-[filename](tutorial-selectors.test.ts ':include :type=code :fragment=sel1')
+```
+--8<- "docs/tutorial-selectors.test.ts:sel1"
+```
 
 ## Subduxes
 
@@ -83,7 +96,9 @@ Upduxes can be divided into sub-upduxes that deal with the various parts of
 the global state. This is better understood by working out an example, so
 let's recap on the Todos dux we have so far:
 
-[filename](tutorial-monolith.test.ts ':include :type=code :fragment=mono')
+``` title="todos-monolith.ts"
+--8<- "docs/tutorial-monolith.test.ts:mono"
+```
 
 This store has two main components: the `nextId`, and the `todos` collection.
 The `todos` collection is itself composed of the individual `todo`s. Let's
@@ -91,19 +106,27 @@ create upduxes for each of those.
 
 ### NextId dux
 
-[filename](nextId.ts ':include :type=code :fragment=dux')
+``` js title="nextId.ts"
+--8<- "docs/nextId.ts:dux"
+```
 
 ### Todo updux
 
-[filename](todo.ts ':include :type=code')
+``` title="todo.ts"
+--8<- "docs/todo.ts"
+```
 
 ### Todos updux
 
-[filename](todos.ts ':include :type=code')
+``` title="todos.ts"
+--8<- "docs/todos.ts"
+```
 
 ### Main store
 
-[filename](todoList.ts ':include :type=code')
+``` title="todoList.ts"
+--8<- "docs/todoList.ts"
+```
 
 Tadah! We had to define the `addTodo` effect at the top level as it needs to
 access the `getNextId` selector from `nextId` and the `addTodoWithId`