►
Description
In this pairing session we work through some strange behavior that appeared when writing tests for a Vue component using a custom resolver.
Related issue: https://gitlab.com/gitlab-org/gitlab/-/issues/282440
Related docs: https://www.apollographql.com/docs/react/local-state/local-resolvers/
Related upstream issue: https://github.com/vuejs/vue-apollo/issues/636
B
B
A
little
bit
of
background.
Currently
local
resolvers
are
what
we
use
to
kind
of,
or
what
you
would
use
to
kind
of
resolve
a
local
value
instead
of
creating
a
graphql
fetch.
So
an
example
of
that
would
be.
If
you
have
to
read
from
a
cookie
or
local
storage,
that's
a
pretty
good
application
for
it.
I
should
say
that
a
disclaimer
a
little
star
that
they
are
being
deprecated
in
the
prescribed
way
yeah
well
hold
on
hold
your
horses.
B
A
D
Just
a
note
is
that
don't
worry
too
much
about
it
being
deprecated,
because
we
would
have
to
upgrade
to
a
much
newer
version
of
apollo
graphql
for
it
to
start
affecting
us,
and
my
understanding
from
talking
to
natalya,
because
when
I
was
working
on
local
reserve
was
resolvers.
I
essentially
went
through
this,
so
I
like
looked
it
up,
saw
it
was
deprecated
was
like
natalia.
Am
I
doing
the
right
thing
here
and
she
was
like?
Yes,
don't
worry?
It's
probably
gonna
be
a
little
while
before
we
update,
so
don't
worry
too
much.
D
We
also
use
them
in
we've,
been
using
them
in
ci
to
help
front
end
work
ahead
of
back
end,
so
that,
if
you
have
a
rest,
end
point,
but
you
it's
particularly
in
ci,
because
we
have
so
much
legacy
code
that
uses
like
old
homegrown
store
solutions
like
from
before
vuex
or
whatever
we've
just
like
gone
turbo
and
gone
straight
to
apollo.
Instead
of
doing
the
middle
ground.
B
E
D
B
A
B
Yes,
definitely,
I
know
I
use
small
font,
so
thank
you
for
calling
that
out
cool.
So
all
I'm
doing
here
really
is
just
a
regular
axios
get.
I
could
use
the
api
stuff,
but
I
want
to
do
stuff
with
headers,
and
so
I'm
just
making
the
integration
myself.
This
is
actually
paginated
and
it
actually
works.
B
I
have
an
example
where
it
fetches
all
the
groups
on
on
the
root
level,
so
so
this
is
generally
what
it
looks
like
we're
using
the
per
page
and
passing
that
on
and
the
search
parameter.
But
essentially
this
is
a
local
resolver
for
and
it's
in
is
particularly
in
the
devops
report.
Page,
it's
not
being
used
yet,
but
we
are
about
to
use
it.
A
B
B
B
Awesome
awesome,
yeah,
and
so
what
I
did
was
I
created
a
spec
for
it,
so
I
should
actually
also
just
show
you
how
I'm
using
it
so
in
here.
This
is
our
application
where
we
want
to
use
it,
and
here
is
the
integration
we're
saying:
let's
get
a
hold
of
that
groups
query.
This
is
the
query
that
we
want
to
look
at
and
that's
a
reference
to
the
graphql
query.
I
showed
you
before
and
the
results.
We
don't
really
care.
B
B
Where
data
is
present,
and
in
this
case
we
want
to
use
the
mock
adapter
because
for
the
local
resolver
we
want
to,
we
want
to
take
or
listen
to
that
route,
and
then
we
want
to
respond
with
the
data
and
make
sure
that
the
resolver
does
its
work
and
provides
the
data
as
we
expect
it
to
be
for
the
component
itself
and
down
here.
I'm
just
listening,
I'm
not
implementing
mocking
it
or
anything.
B
I'm
just
listing
spying
on
it,
the
fetch
more
to
see
that
it
actually
gets
called
again,
because
that's
kind
of
the
ability
that
we
want
to
test
here
is
that
when
there
is
a
next
page,
we
want
to
make
sure
that
it
tries
to
fetch
the
next
one.
So
that's
pretty
much
what
I'm
looking
to
zoom
in
on
and
if
I
do
run
this
and
I
actually
already
have
it
running,
but
I'm
going
to
run
it
again.
So
you
can
see
the
command
here
just
focusing
in
on
that
particular
test.
A
B
It
that's
it
all
right,
cool
we're
done.
Thank
you
guys
or
peeps.
Thank
you
for
checking
in
no,
unfortunately,
so
there's
an
environment
environment
violation
here
that
the
observer
will
query,
does
not
know
this
id
and,
as
far
as
I
could
read,
I
do
believe
it
has
something
to
do
with
us
starting
to
use
variables
here,
whereas,
as
you
see,
we
don't
do
that
in
the
original
query
a
little
bit,
because
so
this
is
referring
to
a
particular
thread.
A
A
C
C
A
D
I
don't
think
they
do.
I
think
they
only
need
the
type
name
in
them
if
you're
using
the
startup
js
to
prefetch
the
query,
because
the
type
I
don't
know
why
I'm
talking,
because
there's
people
on
this
call
to
know
way
more
about
fql
than
I
do.
But
I
think
it's
because
it's
using
the
type
name
to
like
match
it
in
the
cache.
B
B
A
So
I'd
act,
I
have
a
absolutely
crazy
thought
and
feel
free
to
be
like
paul.
You
don't
know
anything
so
be
quiet.
Is
it
possible
that
we're
triggering
fetch
more
and
then
we
add
the
spy,
because
I
noticed
that,
like
we're
not
doing
any
action
after
we
create
the
component
and
then
we're
checking
on
line
121
to
see
if
that
spy
was
called
like?
Is
it
possible
that
when
we
did
that
right
query
technically,
it
was
being
called
like
twice
or
something
or
does
that
make
sense
like
well.
B
A
B
Definitely
I
I
should
also
say
that,
like
we,
so
what
I
was
trying
to
get
at
with
the
resolvers
is
that
we're
both
writing
to
query
and
we're
like
asking
mock
adapter
to
return
something
for
us.
As
soon
as
I
write
to
the
query
I
don't
hit,
I
don't
hit
this.
This
request
ever
like
this
doesn't
get
activated.
A
B
I
A
Stuff
here,
you're
right,
it's
getting
called
multiple
times.
What
I
found
to
be
helpful
is
to
emit
an
event.
That's
like
a
like
a
test
like
a
youth
like
we're
not
going
to
actually
register
it
in
our
code,
but
like
just
using
this
event
and
our
test.
Knowing
hey.
What's
wait
for
this
specific
event
or
whatever.
A
A
D
A
I
D
H
So
I
recently
tested
the
local
resolver
pretty
much
the
exact
same
use
case.
You
did,
and
I
wonder
if
we're
doing
I
I
didn't
instantiate
cash,
but
I'm
wondering
if
we're
doing
too
much
like
actually
mocking
the
default
client
like
in
the
component
like
so
the
way
I
did,
it
is
just
mock
apollo
in
create
component
not
like
actually
create
a
default
client
and
I
didn't
have
to
use
mock
adapter.
H
C
H
H
C
A
What's
what's
tough
here
is,
like
you
know,
it's
it's
nice
doing
that
very
uni-test-focused
approach
when
the
things
you're
mocking
you're,
just
passing,
maybe
static
values
to
them,
and
I
can
just
assert
hey,
there's
these
lists
of
arguments,
but
there's
a
lot
of
callbacks
here
and
I
could
see
we
start
to
really
lose
the
benefit
of
our
test
when,
when
we're
not
able
to
actually
cert
did
I
do
update
query
as
apollo's
expecting
correctly
and
we're
actually
seeing
the
behavior
of
the
component.
I
really
like
the
way
that
that
your
test
was
looking
michael.
A
Like
it
looked,
hey
we're
setting
up
we've
we've
mocked
out,
you
know
our
collaborators
and
and
we're
gonna
assert
what
it
looks
like
on
the
component.
I
really
like
that
approach,
but
man,
I
know
that
that
apollo
is
really
tough
to
to
work
at
with
in
this
level,
and
so
that
is
an
approach
if
this
ends
up
taking
up
too
much
time.
A
Yeah,
I
think
what
peyton
is
saying
is
is
a
good
approach
and
maybe
adding
a
test
at
the
feature
spec
level
just
for
this,
for
that
full
coverage
and
then
doing
something
that
might
be
a
little
mocky
unity
over
here.
The
feature
spec
level
it
just
if
this
ends
up
being
like.
We
can't
get
this
to
work
the
way
we
want
doing
a
test
at
the
feature,
spec
level,
where
we're
just
asserting
you
know,
we
load
the
page,
and
we
assert
that
the
thing
showed
up
and
buttons
when.
I
B
I
guess
I
guess
that
we're
getting
the
same
like
flavor
by
just
like
keeping
the
the
mock,
client
and
writing
to
the
cache,
because
I'm
essentially
I'm
telling
the
component
like
this
is
what's
in
the
the
apollo
cache
for
this
particular
query
and
then
what
I'm
doing
further
down.
Is
that
I'm
asserting
that
that's
the
case?
So
if
I
were
to
go
and
look
like
this
is
the
test,
as
I
ended
up,
writing
them.
B
I
I
can
even
do
the
the
loading
state
where
I'm
just
I'm
not
setting
any
data
and
that
actually
displays
the
loading
date.
So
that's
that's
fairly
obvious
and
it's
it's
readable
and
for
the
so,
the
only
thing
I
had
to
like
work
a
little
bit
around
was
that
in
order
to
simulate
an
error
that
was
the
the
hardest
part
for
me
to
do.
I
ended
up
needing
to
spy
on
the
fetch
more
and
then
like
mock
a
return
value.
B
D
B
Sure,
sorry,
to
jump
in
for
sure
I
hear
what
you're
saying
and
I
I
totally
get
it,
and
this
is
minimal,
but
there
is
some
sense
to
jumping
in
looking
at
a
component
looking
at
the
different
states
and
just
see
coverage
for
all
the
different
states
and
when
there's
not
coverage
for
a
particular
state.
The
first
thing
that
my
mind
goes
is
like.
Oh,
why
not
like,
and
then,
if
I
were
to
like
jump
in
as
a
new
developer,
look
at
this
component
maybe
make
some
changes
to
it.
B
I
kind
of
want
to
go
there
and
like
well.
This
is
not
covered
by
tests,
so
I
might
as
well
just
also
cover
it
with
tests,
while
I'm
writing
test
for
it
anyways
and
then
perhaps
spend
end
up,
spend
a
lot
of
time
getting
to
the
same
conclusion
that
we're
getting
to
in
this
meeting
that
maybe
it's
not
worth
it
all
the
time.
But
it's
not
apparent
to
me
like
it's,
not
it's
not
easy
for
me
as
a
developer,
to
take
a
look
at
that
that
test
suite
and
see.
B
It
will
take
time
too
much
time,
perhaps
to
test
this
compared
to
what
we
get
out
of
it.
So
what
I'm
looking
for
is
a
nice
way
for
developers
to
look
at
how
to
test
our
components
in
the
different
states
that
we
wanted
to,
or,
if
not
like,
some
way,
that
it's
communicated
that
that's
not
necessary,
and
this
is
the
reason
why.
A
B
A
So
if
we
can
solve
these
problems
like
then
it's
gonna,
it's
gonna
propagate
across
other
component
tests
and
and
that's
a
win
for
this
specific
example
like
looking
at
the
error
state,
I
can
see
like
on
line
62.
You
could
replace
that
with
this
dot
handle
bogus
and
if
we
didn't
weren't
testing
the
error
state,
we
wouldn't
have
any
tests
fail
for
that
typo
and
to
me,
that's
just
a
little
warning
flag
like
something
needs.
Something
needs
to
happen.
It
would
be
nice.
C
For
something
to
happen,
in
addition
to
this,
as
somebody
that
recently
did
this,
I
shipped
out
a
code
with
the
typo
and
the
page
was
erroring
and
the
error
message
was
empty
and
there
was
nothing
more
frustrating
for
the
user.
Oh
man
and
my
test
wasn't
hard
enough
to
catch
this
because
they
were
tested
in
insulation
right.
So
yeah
I've
been.
I
I
E
A
C
B
B
A
A
B
H
B
H
H
B
B
I
expect
that
the
view
apollo
integration
to
work
and-
and
so
in
this
case
we
have
covered
all
the
bases.
I
would
say
I
just
I
guess
I
wish
there
was
a
more
elegant
way
to
to
do
this
in
instead
of
like
completely
overwriting
the
implementation,
since
we
do
have
nice
handlers
like
the
mock
adapter
for
the
local
resolver,
but
I
I
think
maybe
what
I'm
getting
at
is
that
whole
system
with
having
the
local
resolvers
and
the
local
directive
and
all
that
stuff.
B
H
B
Short,
a
lifetime:
that's
going
to
die
at
some
point
because
they're
getting
deprecated
or
we
implement
this
in
graphql
and
boom.
All
this
goes
out
the
window.
So
so
that's
that's
a
great
point
and
also
maybe
a
point
to
not
spend
too
much
time
on
this,
though
it
is
alerting
to
like
some
of
the
how
the
inner
working
is
of
gracule
and
and
the
our
ability
to
test
it
and
set
up
local.
C
C
B
C
B
B
A
A
A
B
A
C
C
Important,
that's
true!
That's
why
we
we,
I
think
the
recommended
approach
is
to
have
a
create
component
with
apollo,
which
is
a
wrapper
around
create
component.
You
initialize
apollo
there
and
then
get
a
component
underneath
okay,
but
this
is
me
just
how
I'm
I'm
used
to,
because
I'm
following
what
we
wrote
down.
B
A
C
B
A
B
No,
it's
just
you
see
it's
kept
in
this
loading
state
because
I
haven't
written
to
the
cache.
Yet
somehow,
because
it's
a
local
resolver,
it's
not
activated,
I
don't
yeah.
That's
those
two
are
kind
of
conflicting
things.
You
can't
have
a
local
resolver,
I've
learned
or
activated
in
component
without
having
like
you,
you
need
kind
of
to
write
the
cache
before
it
gets
activated.
B
B
E
A
D
A
A
And
yeah
we
could
wait
for
next
tick.
We
could
sometimes
wait
for
promises,
but
what
I
found
to
be
a
very
more
reliable
weight
is
actually
emitting
an
event
from
the
component.
That
says,
I
did
the
thing
and
then
we
can
do
that
in
our
test
and
that
has
little
to
no
production
cost.
I
feel
like
so,
and
it
could
be
help
make
tests
reliable
gotcha,
but.
B
B
A
C
D
A
E
H
E
C
One
of
the
thing
that
I
was
looking
at
is
that
when
we
use
the
our
helper
and
not
directly
mock
apollo
client,
we
are
actually
calling
how's.
It
called
set
request
handler
on
the
mock
client,
specifying
query
and
handler,
and
I
think
that's
the
bridge
that
tells
fetch
more
where
to
find
which
query
to
go
and
look
at.
Can
you
be
that?
But
maybe
there
is
people
that
know
better
than
me
about
this.
C
If
you
look
at
moccapolo
albert
the
activity
that
we
normally
use
for
this
right,
what
you
do
inside
it's
you
take
the
client
and
you
run
set
request
handler
query
resolver
on
it:
okay,
so
you're
telling
you're
telling,
which
is
the
request
android
for
every
query.
Maybe
that's
the
beat
that
you're
missing
to
buy
it
for
fetch
more.
C
B
Oh,
but
that's
that's
for
that's!
So
in
our
case
we
have
a
local
handler
and
it
actually
specifies
in
the
implementation
that
it
will
ignore
this,
because
it's
a
local
resolver,
a
client
or
local,
only
resolver,
so
yeah.
So
this
works
perfectly
when,
when
it's
it's
a
normal
graphql
request,
but
when
it's
a
local
resolver,
that's
kind
of
where
everything
goes
awry
a
little
bit.
A
A
D
A
A
A
A
F
B
A
E
B
I'm
not
actually
asserting
the
next
level,
because
that's
where
I
wanted
to
go
is
that
that
the
fetch
more
result
gets
returned.
And
now
my
component
is
reflected
reflecting
that
new
state,
where
I'm
seeing
all
like
the
not
only
the
first
request,
but
the
second
request-
and
so
I
didn't
get
to
go
to
that
point,
because
I
was
never
able
to
get
this
far.
A
A
A
A
Okay
and
I
wanna
see
like
what
is
going
on
and
a
lot
of
it
is
because
I
don't
really
know
how
apollo
works
and
natalya
or
someone
else.
That
knows
apollo
way
more
than
me
feel
free
to
stop
us
from
going
down
here.
If
this
is
a
dead
end,
but
I
feel
like
maybe
we
can
get
some
more
visibility
on.
What's
actually
throwing
this
error
by
logging,
the
node
module.
I
B
Oh
one
thing
that
that
I
I
noticed
while
I
was
debugging
this
just
as
a
fun
fyi,
I
tried
to
actually
use
the
actual
implementation
the
instead
of
using
the
mock
client,
and
I
learned
that
when
I'm
using
the
mock
client
in
the
in
tests,
it's
using
the
umd
module.
So
when
we're
running
tests,
we're
using
vmd
modules
where
we're
running
in
the
live
environment
or
like
this
environment,
it's
the
esm
modules.
Don't.
A
Is
not
sleeping
for
a
week
I've
I've
I'm
already
used
to
this,
like
our
jess
tests,
don't
run
with
the
webpack
builds
and
stuff
like
we
have
a
totally
separate
build
for
a
chess
test,
so
it's
like,
if
I'm
really
paranoid
and
90
of
me
is
like
I
get.
I
get
nervous
about
those
things.
So
I'm
sorry
to
bring
this
to
you
attention
these
days.
I've
been
really
enjoying
feature
specs,
but
I
actually
just
got
someone
ping
me
on
an
issue.
A
A
A
A
B
E
C
B
A
B
A
A
A
I
think
the
approach
I
was
thinking
of
is
a
little
different
and
it
might
be
even
simpler.
Oh
sorry,
okay,
no
you're
good!
I
would
try
this
out.
Let's
create
a
helper
function,
I'll
move
it
up
anywhere.
That's
fine!
We'll
call
it
like
a
create
mocked
sequence,
something
like
that
and
then
it
takes
in
a
sequence.
A
A
A
Yeah,
so
sorry
and
in
the
body
we
are
going
to
increment
current
index
if
we're
not
at
the
end.
So
you
know
what
I'm
saying
if
we're
like,
if
sequence
dot,
if
current
index
is
greater
than
or
equal
to
sequence,
to
add
length
minus
one,
I
guess
something
like
that:
there's
probably
a
prettier
way
to
do
that.
B
B
A
So
I
guess
what
I
really
want
to
do
here
is:
if
current
index
is
less
than
sequence,
that
length
minus
one,
then
we're
gonna
we're
going
to
increase
it,
but
that's
only
after
we
get
the
result,
which
is
so
right
above
the.
If
we're
going
to
get
the
result,
which
is
the
sequence
at
the
current
index
or
whatever.
A
A
C
B
C
B
Yeah
perhaps,
but
I
think
this
is
more
elegant
for
sure,
because
here
you're
like
sure
that
you're
getting
that
variable,
even
if
it's
just
declared
just
outside
that
function
and
not
dependent
on
this,
like
connectedness
yeah.
Now,
that's
that's
awesome
and
like,
and
furthermore
we
should
probably
put
in
like
if
the
page
is
the
same
as
the
next
one
like
you
should
probably
like
put
in
a
halt
and
not
continue
into
infinity.
A
This
is
a
good
point
and
probably
even
like,
if
there's,
if
you
have
done
10
pages
like
I
don't
you
probably
should
be
done,
even
if
there
is
more
like
we
probably
something's
problematic.
If
we
just
keep
fetching
pages
till
forever,
maybe
we
we
do
need
to
do
some
sort
of
forever
scroll
or
something
so
that's
a
good
point
as
well
we're
at
we're
at
time
you're
almost
out
of
battery.
I
know
so
thanks.
Everybody.