Implement feedback on docs

This commit is contained in:
bonbud-macryg 2024-06-10 14:11:54 +01:00
parent eb7fbda674
commit f2cebb1ec6
3 changed files with 55 additions and 66 deletions

View File

@ -3,12 +3,13 @@
/- feather-icons
:: declare that this is a conversion from task to HTMX
:- [%task %$ %htmx]
:: gate takes a task and a bowl:neo,
:: so we can access here.bowl and kids.bowl
:: outer gate takes a task, inner gate takes a bowl:neo,
:: so we can access here.bowl and kids.bowl in the ui
|= t=task
|= =bowl:neo
::
:: all sail rendering happens in helper arms
:: in this case, all sail rendering
:: happens in helper arms
|^
shell
::
@ -120,8 +121,8 @@
::
++ form-ordered-kids
::
:: <form> that keeps track of tasks order, sends
:: %reorder poke if tasks are manually reordered
:: <form> that keeps track of tasks order, sends %reorder
:: poke if tasks are manually reordered by the user
;form.fc.g1
=hx-post "/neo/hawk{(pith-tape here.bowl)}?stud=task-diff"
=head "reorder"
@ -129,9 +130,8 @@
=hx-swap "none"
;*
::
:: iterates over the list of piths,
:: turning through the kids' data
%+ turn
:: iterates over the list of piths in order.task
%+ turn
order.t
|= =pith
:: extract kid information at pith from kids.bowl
@ -234,7 +234,7 @@
;
==
::
:: combining class logic with
:: combining class logic with
:: manx below and make it in to an XML node
;+ =; that
=/ classes

View File

@ -1,15 +1,13 @@
# Tutorial 4: Tasks
Lets take a look at the Tasks shrub. From within the Sky frontend, you can create, edit, reorder, and delete nested tasks and subtasks. Checking off all subtasks will mark the parent as complete, which involves some interaction between parent and child shrubs.
This time there are no new concepts on the backend, but theres much more going on in the UI than weve looked at in previous tutorials.
In this lesson well see how shrubs keep their parents informed of state changes using the `%gift` poke. This is the most complex UI weve looked at yet, so well also focus on the `/con` files.
## /imp/task.hoon
Tasks only needs one `/imp` file: `task.hoon`. The Tasks frontend shows you some tasks that may or may not have other tasks as children.
```hoon
/@ task :: [text=cord done=? order=(list path]
/@ task :: [text=cord done=? order=(list path)]
::
:: $task-diff
:: $%  [%new =task prepend=?]
@ -63,26 +61,18 @@ Tasks only needs one `/imp` file: `task.hoon`. The Tasks frontend shows you some
:: state is a %task
++ state pro/%task
::
:: we accept %gift and %task-diff pokes
:: we accept %task-diff and %gift pokes
++ poke (sy %task-diff %gift ~)
::
:: we define one generation of kids at
:: /path/to/this/task/<@ud> which are
:: also tasks like their parent, which
:: means those kids also define one
:: generation of kids below them, and so on
:: we define one generation of
:: kids at /path/to/this/task/<@ud>
++ kids
:+ ~ %y
%- ~(gas by *lads:neo)
:~ :- [|/%ud |]
[pro/%task (sy %task-diff %gift ~)]
==
++ deps
::
:: we don't need dependencies to negotiate
:: state between parent and children tasks,
:: but it would be valid to do so
*deps:neo
++ deps *deps:neo
++ form
::
:: inner core
@ -111,9 +101,8 @@ Tasks only needs one `/imp` file: `task.hoon`. The Tasks frontend shows you some
=/ name=@ud (assign-name bowl)
=. order.this
?: prepend.diff
:: XX do we really need to do this? bad look if so
`(list pith)`[~[ud/name] order.this]
`(list pith)`(snoc order.this `pith`[ud/name ~])
[~[ud/name] order.this]
(snoc order.this `pith`[ud/name ~])
=. done.this |
:_ task/!>(this)
:~ :- (welp here.bowl ~[ud/name])
@ -147,9 +136,9 @@ Tasks only needs one `/imp` file: `task.hoon`. The Tasks frontend shows you some
```
## The %gift poke
In the `+poke` arm we declare this shrub takes a `%gift` as well as a `%task-diff`, but we dont have to import `%gift` with a `/@` rune. This is a special poke like `%rely` that `/app/neo` gives us when another shrubs state changes.
In the `+poke` arm we declare this shrub takes a `%gift` as well as a `%task-diff`, but we dont have to import `%gift`. This is a special poke like `%rely` that `/app/neo` gives us when another shrubs state changes.
Our shrub receives a `%gift` poke every time the state of one of its {kids / descendants} changes. Unlike `%rely`, we have to declare that we accept `%gift` pokes in the `+poke` arm.
Our shrub receives a `%gift` poke every time the state of one of its descendants changes: only kids in the `%y` case, all descendants in the `%z` case.
```hoon
++ state pro/%task
@ -172,17 +161,18 @@ Lets look at the Tasks frontend in detail.
### Converting tasks to HTMX
```hoon
/@ task :: [text=cord done=? order=(list pith)]
/@ task :: [text=cord done=? kids-done=? order=(list pith)]
:: import /lib/feather-icons
/- feather-icons
:: declare that this is a conversion from task to HTMX
:- [%task %$ %htmx]
:: gate takes a task and a bowl:neo,
:: so we can access here.bowl and kids.bowl
:: outer gate takes a task, inner gate takes a bowl:neo,
:: so we can access here.bowl and kids.bowl in the ui
|= t=task
|= =bowl:neo
::
:: all sail rendering happens in helper arms
:: in this case, all sail rendering
:: happens in helper arms
|^
shell
::
@ -282,20 +272,20 @@ Lets look at the Tasks frontend in detail.
++ kids-check
::
:: check if all subtasks are completed
|= [parent-pith=pith order=(list pith)]
|= =pith
~& > pith
^- ?
%+ levy order
|= p=pith
=/ =task
!< task
q.pail:(need (~(get by ~(tar of:neo kids.bowl)) (weld parent-pith p)))
done.task
=/ t
!< task
q.pail:(~(got of:neo kids.bowl) pith)
~& >> t
kids-done.t
::
::
++ form-ordered-kids
::
:: <form> that keeps track of tasks order, sends
:: %reorder poke if tasks are manually reordered
:: <form> that keeps track of tasks order, sends %reorder
:: poke if tasks are manually reordered by the user
;form.fc.g1
=hx-post "/neo/hawk{(pith-tape here.bowl)}?stud=task-diff"
=head "reorder"
@ -303,16 +293,16 @@ Lets look at the Tasks frontend in detail.
=hx-swap "none"
;*
::
:: iterates over the list of piths,
:: turning through the kids' data
%+ turn order.t
|= =pith
:: extract kid information at pith from kids.bowl
:: and runs +part-kid on pith and kid data
=/ kid (~(get of:neo kids.bowl) pith)
?~ kid
;div: does not exist {(pith-tape pith)}
(part-kid [pith (need kid)])
:: iterates over the list of piths in order.task
%+ turn
order.t
|= =pith
:: extract kid information at pith from kids.bowl
:: and runs +part-kid on pith and kid data
=/ kid (~(get of:neo kids.bowl) pith)
?~ kid
;div: does not exist {(pith-tape pith)}
(part-kid [pith (need kid)])
==
::
++ part-kid
@ -361,9 +351,8 @@ Lets look at the Tasks frontend in detail.
:: a task from being marked as done if it
:: has untoggled kids
::
:: combining m named noun and
:: attribute logic with manx below
=- =/ m -
:: combining attribute logic with manx below
=; m
:: checks if the task toggled as done
?. done.t
:: if it's not done, does it have kids?
@ -375,7 +364,8 @@ Lets look at the Tasks frontend in detail.
:: the rest of its data
m(a.g [class a.g.m])
=/ kc
(kids-check pith order.t)
(kids-check pith)
~& >>> kc
?: kc
:: assigning class attribute to
:: the rest of manx data
@ -407,10 +397,9 @@ Lets look at the Tasks frontend in detail.
;
==
::
:: combining that named noun and class name
:: logic with manx below and make it in to an XML node
;+ =-
=/ that -
:: combining class logic with
:: manx below and make it in to an XML node
;+ =; that
=/ classes
%+ weld
"grow p2 br2 text bold"

View File

@ -1,6 +1,6 @@
/@ task
/@ task-diff
=>
=>
|%
++ check-kids
|= =bowl:neo
@ -36,7 +36,7 @@
|%
++ state pro/%task
++ poke (sy %task-diff %gift ~)
++ kids
++ kids
:+ ~ %y
%- ~(gas by *lads:neo)
:~ :- [|/%ud |]
@ -59,16 +59,16 @@
::check if all kid tasks are done
=/ dun (check-kids bowl)
[~ task/!>(this(done dun, kids-done dun))]
::
::
%task-diff
=/ diff !<(task-diff vax)
?- -.diff
%new
=/ name=@ud (assign-name bowl)
=. order.this
=. order.this
?: prepend.diff
`(list pith)`[~[ud/name] order.this]
`(list pith)`(snoc order.this `pith`[ud/name ~])
[~[ud/name] order.this]
(snoc order.this `pith`[ud/name ~])
=. done.this |
=. kids-done.this |
:_ task/!>(this)