►
Description
In this session we engage in a bit of discussion about the ideal user experience / maintainability of resolving TODO's and updating the relevant count.
A
A
A
lot
of
these
numbers
are
basically
just
updated
by
directly
manipulating
them,
so
they
are
loaded
like
on
load
and
then
you
have
like
certain
scripts.
Like
you
know,
Mark
has
done
added
to
do
that.
Just
update
those
numbers
straight
away
like
directly,
manipulating
that
stuff
right,
the
new
navigation
being
a
view
app
doesn't
necessarily
have
the
same
selectors.
A
So,
what's
interesting
about
this
thing,
that
updates
the
Mr
view
is
so
this
is
already
the
new
code,
so
it
actually
calls
the
API
gets
the
numbers
for
assigned
and
review
requests
and
updates
the
Dom
elements.
So
why
don't
we
do
it
smarter
in
the
new
in
the
new
sidebar
right
and
so
I've
already
put
an
MR
together
with
which
does
the
following?
It's
just
like
a
little
State,
Management,
thingy
I.
A
A
What's
I
mean
this
is
still
to
be
discussed
and
not
what
I
want
to
talk
about
just
wanted
to
give
some
context
right.
What's
pretty
cool
actually
about
the
solution
that
is
already
here?
Is
that
if
you
do
something
on
Mr
and
have
multiple
tabs
open,
it
actually
updates
the
numbers
in
the
the
other
tabs
right,
so
it
uses
a
broadcast
channel.
A
A
It
or
not,
really
wait.
It
could
be
that
the
mark,
all
done
feature
is
like
problematic.
No
I
actually
know
what
it
is
because
to
do.
This
is
the
thing
that
I
want
to
look
into
with
you
all
right.
That's
the
thing.
The
to-do
list
doesn't
work,
but
as
an
example,
if
I
I
have
six
Mrs
Right
and
if
I
unassign
myself.
A
Me
just
let
me
just
assign
myself
again
here:
cool
reviewer
if
I
reload
this
six
okay,
at
least
that
works
okay.
So
if
you,
if
you
reload
a
page,
it
broadcasts
its
numbers
to
the
other
pages
and
at
least
that
works.
So
there
is
a
bug
somewhere,
good,
doesn't
really
matter.
The
big
problem
that
I
wanted
to
look
into
is
for
updating
to
the
to-do's.
We
have
to
do
toggle,
so
we
have
it
to
the
toggle
event,
and
now
my
idea
was
so
basically
to
do.
A
Toggle
event
also
sets
sends
the
new
the
new
count
right,
the
new
count
for
to-do's.
The
problem
is
that
the
same
event
is
used
for
multiple
use
cases,
so
in
one
use
case,
people
send
like
an
optimistic
update.
So,
for
example,
if
you
click
the
mark,
As
done
button,
the
counter
goes
down
and
then
the
API
calls
are
made
that
actually,
you
know,
would
resolve
the
to-do
and
in
other
cases
the
call
is
made
and
the
to
do.
A
A
Yeah,
so
in
other
cases
you
can
see
that
we
are
basically
querying
the
existing
to-do's
count.
Right
then
we're
adding
or
removing
one,
and
then
we
send
a
new
number
while
in
the
place
where
we
actually
consume
the
whole
thing,
which
is
here,
we
are
pausing
the
to-do
count
again
right.
So
this
is
just
a
little
bit.
B
We've
run
into
multiple,
like
there's
so
many
issues
here,
like
even
like
I,
remember
running
until
one
of
my
first
months
at
gitlab,
picking
up
an
issue
regarding
when
the
to-do's
have
reached
like
past
a
thousand
or
something
and
somehow
that
affected
the
rendering
of
it
like
all
of
it
is,
is
doing
some
interesting
things
with
JavaScript
numbers
and
reading
from
the
Dom
and
yeah
yeah.
So
the
goal
is
right:
now
the
bug
you're
observing
is
it.
We
need
to
get
this
working
for
the
super
sidebar.
B
A
A
This
is
funny
so
like
there's
already
a
bug
in
the
old
implementation
as
well,
because
the
API
returns,
like
all
the
counts
right
and
if
you
have
more
than
99
issues
assigned,
we
would
render
99
plus,
but
looking
at
this
code,
we
wouldn't
do
that
right
like
so.
If
you
are
yeah,
99
and
I
was
assigned,
you
know,
and
these
are
the
subtle
bugs
that
we
have
and
where,
like
one
single
source
of
Truth,
for
the
data
would
make
sense
right.
B
A
So
that's
interesting,
and
this
is
what
I
want
to
untangle
on
the
in
a
toggle
to
do
so.
Mrs
actually
seems
pretty
consistent
because
they
call
refresh
Mr
accounts
like
on
all
kinds
of
your
occasions.
Right
I,
like
you
know,
side
part
Siamese
comment
form
like
you
know
they
they
do
it
like
toggle
issue,
State
I,
don't
know
like
they
do
it
like
in
all
kinds.
Oh
total
issues.
What
why
is
this
called
toggle
issue?
State
like?
Where
are
we?
A
A
B
B
A
At
all,
so
that's
that's
actually
an
interesting
use
case
because
you
can
actually
can
see
it
here.
It's
funny
you
can
see
a
Discounter
updating
and
discount
updating
already.
Unfortunately,
we
have
the
same
counter
here,
but
this
is
not
the
core
of
the
problem,
but
this
can
happen
anytime
right,
like
yeah
I
mean
you're
right
right,
like
it
would
feel
weird
I
do
an
action
that
decreases
my
to-do's,
but
my
to-do's
increase,
but
on
the
other
hand,
if
I
reload,
the
page
or
open
a
new
tab
to
to
do
count
is
different.
B
B
A
B
A
B
A
Are
always
updated
like
in
the
back
end
in
the
back?
If
something
happens
right
you
just
get
the
updated
numbers,
but
even
then
we
would
probably
would
need
to
untangle
the
init,
the
toggling
of
the
to-do's
and
differentiate
between
the
optimistic
update
that
happens
before
right
and
like
the
stuff
that
happens.
You
know,
after
an
API
call
yeah
all.
A
D
We
saying
we
kind
of
want
to
have
one
thing
so
that,
regardless
of
what
we
choose
to
do,
whether
we
get
the
real
counts,
whether
we
naively
update
them,
whether
we
have
a
graphql
subscription
whatever
like
they
all
do
the
same
thing.
I
think
the
confusing
thing
for
me
is
like
taking
Mark
has
done.
Does
one
thing
clicking
the
tick
on
the
to-do
page?
Might
do
another
thing?
Yes,
unassigning
an
epic
might
do
it
a
different
thing
again
like
if
we
have
one
function
that
says,
I
have
changed.
The
to-do's
go
update
everything.
A
Yeah,
and
so,
for
example,
like
my
gut
feeling,
is
like
this
seems
to
update
the
data
with
the
some
something
that
was
returned
by
the
API
right.
So
this
is
potentially
the
same
as
reloading
the
page,
assuming
that
in
those
in
this
in
that
second
of
reloading
the
page,
nobody
else
gave
you
a
new
to
do
right.
Yeah.
B
A
A
A
I
mean
like
it,
you
cannot
have
epics
on
a
personal
namespace,
yes
epics
there,
we
have
it
right
cool
in
the
meantime.
Let's
not
now,
just
you
know,
console
log
I
mean
we
don't
even
need
to
lock
the
data,
but
just
out
of
Interest
I
reset
my
GDK
this
morning.
So
probably
all
the
pages
are
compiling
cool,
but
that
should
be
a
quick
one
right.
A
A
C
A
A
A
B
A
A
B
B
A
B
A
B
B
A
A
Cool,
so
yes,
user
signed
in,
let's
just
see
epic
sidebar,
oh
cool,
so
this
one
definitely
so
cyber
to
do
with
it
toggle
to
do
okay,
so
they
swapped
out
to
do
implementation
right,
like
they
swapped
out
swapped
it
out
with
one
that
uses
graphql
under
the
hood
understood.
So
we
definitely
can
remove
this.
One
right
issues
assigned
in
seems
to
be
used
still
epic
to
do
toggle
in
progress.
We
just
want
to
have
a
look
if
this
one
is
like
foreign.
B
A
C
A
A
C
C
A
A
A
A
B
Can
we
then,
can
we
actually
I
mean
it'd,
be
great
to
Commit,
This
and,
like
you
know,
create
a
whole
Mr
just
for
this
little
delete,
but
can
we
can
we?
Can
we
pull
to
the
side
of
the
road
for
a
quick?
Second
yeah?
Is
it
that
that
graphql
monument
that
we
drove
by
quickly,
yes
and
one
curious
to
see
how
that
is
handled,
struggling
to-do's.
A
A
C
A
D
A
A
B
B
B
B
B
A
So
that's
also
the
thing
right
like
if
the
request
failed.
That's
a
good
point
yeah.
If
the
request
failed,
you
would
like
to
reset
the
thing
right,
and
so
one
of
the
things
that
I
was
thinking
about
was
why
don't
we
in
the
to-do
widget?
Is
this
the
that's
a
complicated
one
right?
We
have
a
finally
here
right
and
the
one
thing
that
we
could
do
at
the
end.
A
A
A
Most
sense,
I
think
I
I
mean
to
be
honest.
We
do
it
optimistically,
probably
I,
don't
know
Mark
is
done
because
sometimes
this
takes
quite
a
while
right,
but
you're
right
I
mean
we're
actually
marking
the
button
to
be
yes,
you're
right,
we're
actually
marking
you
know
the
button
to
be
loading,
so
nobody-
and
what's
also
funny,
is
because
the
counts
are
now
in
two
different
places.
Actually,
someone
rightfully
so
complained
about
it.
A
So
if
you're
I'm
looking
at
the
markets
done
and
clicking
the
button
and
I,
don't
even
see
the
update
on
the
left
hand
side,
while
in
the
old
nav,
they
are
right
next
to
each
other
right
so
like
it
was
like
I
I,
see
it
right,
I
can
I
cannot
in
a
new
nav.
I
cannot
focus
on
both
things
at
the
same
time.
So.
D
A
B
A
B
C
A
A
B
I
I
feel,
like
my
my
preference,
and
this
is
my
preference,
but
like
that's
in
a
state
it's
in,
because
it
is
clearly
tried
to
do
too
much
and
consistently
all
over
the
place
like.
Let's,
let's
do
solve
a
simple
problem
really
well
and
then
treat
each
problem
separately
of
keeping
the
deuce
to
sink
with
the
back
end
is
one
separate
problem,
then
updating
the
counts,
I'm.
Fine.
If
we
want
to
do
the
optimistic
change
like
that's
just
that
could
be
a
nice
to
have
but
yeah
the
the
maintainability
costs
you
unload.
B
A
Yeah,
so
the
right
change
here,
probably
in
either
case,
would
be
wait.
Is
this
Houston,
so
it's
actually
used
in
more
than
one
place
right,
so
the
the
right
change.
Even
if
we
do
the
optimistic
thingy,
the
right
change
would
be
to
actually
move
it
through
that
graphql
mutation
method,
right,
yeah,
and
and
do
the
optimistic
update
before
in
case
of
an
error,
you
know
undo
it
like
I
mean
even
this
error
would
probably
mean
to
undo.
It
is.
B
C
A
B
A
A
B
No,
that
makes
sense,
I
do
think.
What's
on
the
right
hand,
side
I
think
we
can
improve
the
abstraction
by
just
moving
it
to
a
function,
whether
or
not
we
want
to
encapsulate
Apollo
in
that
a
function
or
passed
to
us.
What
you're
going
to
use
to
actually
make
the
request
and
then
we'll
handle
transactionally
updating
the
the
accounts
makes
sense,
but
like
what
I
see
on
the
right
hand,
side
is
like
this
could
and
should
just
be
a
function.
A
B
A
A
A
D
A
B
B
A
A
The
problem
is
because
this
function
is
used
optimistically
beforehand,
we're
getting
the
wrong
count
right.
So
we
send
like
the
update
count
request
before
the
toggle
mutation
has
actually
gone
through
right
and
that
that's
the
problem.
So
we
cannot
just
do
that.
I
mean
we
could
do
it
with
a
timeout
or
whatever,
but
we've
seen
that
the
thing
takes
like
360
milliseconds
so
like
in
production.
B
A
This
is
the
other,
which
is
super
simple.
We
don't
really
need
to
talk
about
it,
because
it's
just
for
all
of
these
right
so
like
this
is
constrained.
We
can
have
a
look
later,
which
is
also
basically
just
optimistic
updating,
because
if
you
do
this,
you
don't
know
if,
in
the
back
end,
you
know
you
got
a
new
one
so
which
others.
B
So,
at
the
very
beginning
you
talked
about
you
had
some
like
view
observable
State,
yes,
managing
and
stuff,
and
it's
like
I
think
that
solves
one
of
the
Crux
of
one
of
the
key
problems
with
this
old
behavior
of
the
state
is
the
text
itself
in
the
Dom
and
yes,
it
could
be
so
much
more
powerful,
it'd
be
just
okay.
We
have
we've
fetched
the
to-do's.
They
go
into
this
bucket
and
we'll
just
update
that
bucket
and
every
time
that
bucket
updates.
B
A
You
say:
I,
I,
I,
I,
I,
don't
want
to
I,
don't
think
it's
worthwhile.
We
could
do
it
as
a
second
iteration,
but
to
be
honest,
given
the
state
of
the
new
nav
and
that
you
want
to
use
the
new
nav
and
we
want
to
push
for
a
new
knife
and
I.
Don't
know
when
it's
going
to
be
to
default
right,
but
like
Sam
could
speak
to
that
I.
Don't
think
it's
worthwhile
to
put
a
lot
of
energy
into
into
into
thinking
of
the
old
nav.
A
B
A
A
A
A
C
A
A
My
idea
was,
and
we
only
triggered
these
counts
in
a
reasonable
amount
of
places
right
like
three
or
four
right.
So
my
idea
was
that
you
can
see
that
the
event
has
event
detail
count,
and
this
is
a
number,
and
this
is
the
absolute
number
we
set
it
to
what
if
we
do
the
following.
We
support
both
use
cases
of
the
optimistic
update
here,
meaning
if
event
detail.
A
B
A
And
then
in
the
new
Naf,
instead
of
doing
this,
instead
of
setting
the
the
whole
count,
we
consider,
if
you
send
a
complete
count,
not
to
be
optimistic,
but
to
be
what's
the
what's
the
pessimistic?
Let's
call
it
pessimistic
right,
so
in
this
case
we
would
do
full
fetch
of
all
the
counts
in
the
new
Naf
right
while
in
the
while
in
the
old
one.
We
would.
A
A
What
do
you
think
of
this?
Basically,
so
now,
the
only
thing
that
we
would
need
to
do
is
we
would
so
right
now
we
have
not
broken
anything,
and
the
thing
should
behave
like
it
did
before
right,
but
we
would
have
added
support
for
optimistic,
diff,
stuff
and
excuse
me,
and
so
we,
for
example,
wouldn't
even
need
to
touch
this
one,
because
this
one
is
still
pessimistic.
A
B
A
A
A
C
A
D
D
C
C
A
A
B
I
would
just
I
would
suggest
just
simplifying
the
problem
as
much
as
possible,
and
it's
the
number
going
down
from
my
understanding
is
meant
to
give
the
user
feeling
that
what
you
did
was
successful.
You
just
did
something
that
yes
brought
your
total
to-do's
down,
but
getting
the
actual
number
is
a
separate
problem.
That's
like
this
is
this:
is
a
state
syncing
subscription-e
kind
of
problem
potentially
but
I
liked
your
idea
of,
like
hey,
we
can
handle
counts
and
diffs
for
an
event,
because
we
have
Legacy
code.
B
Yeah
to
something
consistent
so
that
that
could
be
helpful
yeah,
it's
not
an
easy
problem.
I
very
I,
really
like.
Let's
move
the
state
outside
of
the
Dom,
because
right
now
we
read
the
number
to
to
and
subtract
it
like.
That's
that
was
what
was
so
crazy
with
one
of
those
components
he
shared
was
I'm
about
to
trigger
the
event.
Let
me
give
it
the
Full
Count
by
looking
up
the
number
it's
going
to
update
parsing
that
and
then
subtracting
it
and
then
giving
that
to
the
event
for
it
to
handle.
A
A
I
think
the
the
all
the
sidebar
ones,
because,
honestly
this
is
just
sidebar
ones,
right,
like
all
the
sidebar
ones
and
all
the
ones
on
Mrs
and
whatnot
they'd,
always
just
increase
or
decrease
by
one
right
yeah,
while
I
think
the
one
on
the
to-do
list,
like
does
like
full
counts,
and
that
kind
of
makes
sense,
because
if
I
Mark
all
is
done
unmarked
right,
like
yep
yeah
and
even
then
it
could
potentially
be
a
diff.
But
it
is
easier
here
to
set
the
absolute
number
right.
A
B
D
That
problem
go
away.
If
and
when
we
move
to
subscriptions,
though,
because
the
chances
are
the
two
extra
to-do's
will
have
come
in
like
in
real
time
so
you'll
be
at
that
new
level.
By
the
time
you
go
to
decrease
yeah,
like
the
chances
of
you
decreasing
at
the
exact
time
that
two
more
come
in
really
reduced.
A
Yeah,
it's
I
mean
if
we
move
to
subscriptions.
Actually
it's
completely
decoupled
right
and
I
I
assume
that
if
we
remove
subscriptions,
we
would
just
remove
all
of
the
optimistic
updates
because,
as
I
was
calling
out
earlier
and
that's
the
question,
if
we
don't
want
to
do
that
with
the
new
enough
anyhow,
just
don't
care
about
the
optimistic
updates,
because
I
click
way
over
here
I,
don't
even
concede
the
count
right
like
and
then
I
look
again
and
it's
updated
and
whether
it's
updated
to
five
I
mean
for
the
to-do
list.
A
Specifically
it's
weird
if
this
would
be
higher
than
the
items
shown,
but
you
know
another
Edge
case
but
like
if
I'm
in
an
issue,
I
click
add
to
do
remove
to
do
now.
I,
don't
even
see
the
number
right,
yeah
I,
don't
see
the
number
updates
it's
impossible
for
me.
I
can't
sit
far
enough
to
sit
both
things.
At
the
same
time,.
B
You
know
that
there's
some
user
somewhere,
that's
like
going
from
one
edge
of
the
screen
and
like
measuring
okay,
the
numbers
added
up
good
but
yeah
one
subscriptions
is
an
interesting
thing.
If
we,
when
we
move
to
there
yeah,
we
could
hopefully
eliminate
all
of
this,
because
then
we
just
naturally
react
to
subscriptions.
So
what's.
A
A
C
The
background
I
agree,
yeah
subscription
is
probably
quite
expensive,
but
just
a
little
account
like
that's,
it
seems
a
bit.
Much
do
do
I,
there's
a
current
Rock
URL
API.
If
such
a
thing
even
exists
so
to
for
to
do
mutations,
what
I?
What
I
would
expect
from
that
API?
Is
you
give
it
like?
You
know,
Mark
these
to
Do's
as
done
or
add
these
to
do's,
and
it
returns
your
account
of
to-do's,
so
that
that
count
is
always
correct
at
the
time
of
the
request
and
then,
if.
C
B
Is
that
not
yeah
how
it
works?
I,
don't
know
if
the
it's
possibly
mutation
works
that
way,
but
I
would
also
be
surprised
if
it
doesn't,
because,
like
counting
things
in
the
database,
especially
things
you
just
changed
like
is
something
you
may
not
want
to
do
too
often,
because
we
have
in
some
parts
of
the
application.
We
have
counting
problems
and
I.
A
B
So
they're
like
heavily
cached
yeah,
so
maybe
yeah,
maybe
the
mutation
does
return
it,
and
but
my
biggest
concern
is
this
is
worth
talking
to
ux
about
is
I.
Think
users
are
going
to
want
to
see
the
number
as
an
indicator
that
my
current
action
was
successful.
I'm
not
going
to
want
to
see
it
as
I
see
the
latest
counts.
So
if
I
did
something
and
it
increased,
I
would
be
really
confused,
but
in
a
fight
and
I
did
something
and
it
decreased.
By
way,
more
I
would
be
really
confused.
B
So
to
me,
I
think
from
the
the
user
problem.
We're
trying
to
solve
is
just
let
it
in
trying
to
indicate
to
the
user.
What
you
did
was
successful
on
the
page
and
things
have
actually
changed,
which
is
a
little
counter-intuitive
with
you
know
the
idea
of
keeping
things
in
sync,
but
so,
even
if
the
mutation
returned
the
right
count,
I
don't
know
if
we'd
want
to
show
the
correct
count
at
this
time,
I
think
I
like
what
you
were
saying
earlier:
IPS
the
idea
of
I
just
refresh
the
page.
A
It
decreases
the
number
to
four,
but
it
gets
the
data
from
the
API.
So
if
you
assign
me
one,
it
will
show
the
correct
number,
rather
than
the
a
decreased
number
right,
like
I,
could
close
MMR
an
account
not
being
updated
right
like
conceptually
I
like
this
approach
and
I
mean
I,
don't
I,
don't
I
don't
care.
Currently,
we
have
basically
two
approaches.
We
have
optimistic
to-do
updates
that
have
nothing
to
do
with
reality
and
we
have
the
Mr
thing.
D
B
Well
subscriptions
you
mentioned,
you
said
something
that
we
don't
have
graphql
subscriptions.
We
did
that's
definitely
the
way
that
we
we
could
make
subscriptions,
but
I
think
the
cost
isn't
worth
it,
because
I
think
there
is
a
back-end
cost
to
this.
That
we'd
want
to
be
really
aware
of.
If
we're
doing
something
like
this
on
the
sidebar
on
every
page.
A
A
Mean
to
be
honest,
like
I,
that's
already
concerned,
because
the
foundations
team,
the
user
accounts,
API,
had
massive
performance
problems,
and
it
is
only
called
in
one
place.
You
know
if
you
open
them
or
closing
them
are
like
the
the
thing
that
updates
the
numbers.
Oh,
that's
thank
you.
Something
went
wrong
right
like
and
those
performance
problems
have
been
solved
by
smarter
querying
what
whatsoever,
but
even
if
we,
for
example,
would
start
fetching
the
API
every
time
you
change
it
to
do.
You
know.
A
Obviously
this
would
also
be
expensive,
but
again
the
underlying
data,
the
same
database.
Things
is
also
called
the
same
database.
Queries
are
called
when
you
just
open
a
new
new
tab
right,
and
so
sometimes
these
user
counts.
If
the
API
call
would
take
four
seconds
because
it's
slow
for
whatever
reason
the
next
page
load
would
also
be
deferred
by
four
seconds.
A
A
A
The
thing
that,
like
the
thing
that
we
do
for
storing
like
the
that,
where
is
it
right,
like
oh
geez,
the
thing
where
we,
where
we
store
like
just
56,
57.5,
K,
right,
I,
think
for
users,
if
you
would
cap
the
to-do's
or
if
we
had
an
API
that
would
you
allow-
or
if
we,
you
know.
Unfortunately,
it's
a
public
API,
so
changing
it
to
be
kept
would
be
a
breaking
change.
A
But
if
we
had
like
some
field,
that's
cheaper
on
the
database
side,
it
would
be
kept
at
200,
which
is
high
enough
that
you
know.
Okay,
if
I,
you
know,
click
Mark,
Mark
all
is
done
whatever
right,
like
I,
don't
know,
but
yeah.
It's
definitely
unnecessary.
Work,
that's
happening
for
people
that
have
thousands
of
to-do's
that
you
know
yeah
they
don't
care
about
it.
Yeah
does.
C
D
B
Here's
a
realistic,
there's,
a
realistic
possibility
and
then
I'll
then
I'll
have
to
hop
off.
We
get
a
community
contributor
that
wants
to
change
our
to-do's
from
instead
of
99
plus
it's
like
hey.
Why
don't
we
do
what
we
do
here,
where
we
can
show
I
have
1.6,
K
or
1.8k.
I
was
like
okay
cool,
that's
great.
It
gets
merged
in
but
elsewhere
in
the
code.
Where
we're
reading
from
it,
you
check
off
your
to-do.
It'll
go
from
1.8k
to
0.8k.