You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The URL looks like this /agenda/2
Since we're on page 2, that means 1 must be completed, so it should have a strikethrough.
That also means "eat" should be BOLD, since that's active.
This is an example of merging local state with domain state.
I have a goal to declaratively put house all data requirements inside a GraphQL query
to do this one, the query might look like this:
agenda(teamId: $teamId) @live {
id
content
isComplete
sortOrder
teamMemberId
status @computed
}
The problem is that GraphQL doesn't provide the index to each child. We could do it internally & give it something like source.__idx.
Relying on index is fascinating because the sort/filter doesn't happen until after the index, which means we'd have to denormalize the values, perform a sort/filter, then go back & fill in the computed values.
This is actually pretty easy. When resolving a scalar, see if it's computed. If so, don't write a value yet. Instead, push a function that will write a value to the field to an computedValQueue. Then, after sort/filter, run through the computedValueQueue stack. We'll only run this once, in case people get cute & try to sort on a computed value.
The text was updated successfully, but these errors were encountered:
let's say you have a bunch of agenda items
The URL looks like this
/agenda/2
Since we're on page 2, that means 1 must be completed, so it should have a strikethrough.
That also means "eat" should be BOLD, since that's active.
This is an example of merging local state with domain state.
I have a goal to declaratively put house all data requirements inside a GraphQL query
to do this one, the query might look like this:
The problem is that GraphQL doesn't provide the index to each child. We could do it internally & give it something like
source.__idx
.Relying on index is fascinating because the sort/filter doesn't happen until after the index, which means we'd have to denormalize the values, perform a sort/filter, then go back & fill in the computed values.
This is actually pretty easy. When resolving a scalar, see if it's computed. If so, don't write a value yet. Instead, push a function that will write a value to the field to an
computedValQueue
. Then, after sort/filter, run through thecomputedValueQueue
stack. We'll only run this once, in case people get cute & try to sort on a computed value.The text was updated successfully, but these errors were encountered: