►
Description
In this session we talk about controlling the number of Apollo Clients rendered per page, and we write a Vue component test.
0:00 - Discussion about Apollo Clients
13:30 - Chatting
18:30 - Pairing on a Vue component test
A
B
So,
let's
start
with
I
think
we
have
too
many
follow
client
instances
in
GitHub,
even
across
one
page.
We
just
normally
have
as
many
Apollo
client
instances
as
we
have
view
applications,
because
every
New
View
app
brings
a
new
Apollo
client
instance,
and
it
leads
to
some
undesired
effects
that
we
are
fetching
the
same
data
twice
or
even
more
and
we're
caching
them
separately
in
a
separate
Apollo
client
instances,
because
every
instance
has
its
own
cache.
B
B
We
should
have
one
instance
per
page
implementation.
There
is
a
boring
way,
the
boring
way
you
just
merge
all
the
instances,
all
the
resolvers,
all
the
type
policies
put
them
in
the
graphql.js
in
lib
and
linked
against
everything
else.
You
want
to
Apollo
client
instance:
you
import
it
from
the
lead.
That's
it
a
way.
B
More
user
friendly
or
developer
friendly
approach
would
be
to
try
to
memorize
a
polo
client
instance
and
whenever
a
developer
tries
to
create
a
new
instance,
we
just
return
the
existing
instance
and
put
in
your
resolvers
and
type
policies
and
cash
conflict.
On
top
of
that,
there
are
methods
for
them.
For
these
there
are
methods
that
are
undocumented,
I,
don't
know
why
Apollo
doesn't
document
its
own
methods,
but
I
found
them
in
the
source
code.
So
there
are
methods
for
ad
type
policy
and
end
resolvers.
Oh.
B
We
cannot
read
resolvers,
Because,
add
resolver
and
anti-policy
are
public,
but
Gap
State
policy
and
get
resolvers
are
private
again,
I,
don't
know.
What's
the
logic
in
this,
but
potentially
we
can
end
up
in
the
situation
where
we
overriding
some
kind
of
resolver.
You
want
to
add
a
new
resolver
and
has
the
same
mutation
name
or
something
that
we
already
have
so
I'm,
not
sure.
If
it's
a
good
approach,
it
would
be
a
very
developer
friendly
because
we're
not
changing
the
code
base.
B
Let's
think
about
it,
so
in
memory
integration
is
mergeable
but
I'm
not
sure
about
the
context,
because
sometimes
we
do
provide
the
context
part,
which
is
like
a
single
request
or
something
I'm,
not
sure
as
well,
about
batch
packs
that
when
we
batch
queries
that
we
provide
I
know
that
type
policies
are
mergeable
and
resolvers
are
mergeable
and
possible
types
which
we
do
provide
on
a
global
level.
But
again
they
will
require
some
experimentation.
B
I
think,
even
if
we
do,
we
will
go
with
multiple
clients
per
application
and
you
can
do
it
in
Apollo
provider.
You
can
provide
a
few
clients
there,
but
I
don't
see
the
situation
give
up.
From
my
experience.
We
always
use
one
Apollo
client
per
application.
There
was
some
case
in
pipeline.
Some
a
bit
said
that
we
don't
have
anyone
from
verify
paop,
but
I
still
think
we
need
to
check
if
there
are
multiple
clients
actually
in
the
one
application,
but
normally
it
should
be
one
client
to
roll
them
all.
C
A
Of
having
not
the
memoise
option,
I
like
that,
but
from
the
runtime
Simplicity
like
I,
can
just
follow
and
know
what's
going
to
happen
without
I
like
we've
declared
the
whole
interface
for
the
thing,
but
it
does
run
into
you
how
well
when
at
runtime
you
only
need
a
slice
of
it.
What
do
you
do
and
I
kind
of
wonder
if
we
could
use?
A
I,
don't
know
if
that'll
run
into
performance
issues,
if
we're
I,
don't
know
or
so
like
if
I
was
creating
a
whole
bunch
of
resolvers
I
would
have
the
definition
for
all
my
resolvers
that's
Global
and
standard,
so
we
don't
run
into
name
collisions
all
of
that,
but
the
body
of
the
resolver
would
be
async
imported
or
something
like
that's
just
an
idea.
I
don't
know
if
okay
I
think
they're.
Both
great
options,
though,
but
the
memoizing
and
like
you
could
memorizing
with
merging,
is
really
interesting.
That's
cool.
B
It
makes
me
nervous
too,
because
I'm
afraid
that
we
will
be
overriding
some
policies
just
missing
something
in
the
end.
Client-
and
you
know,
Apollo
client
is
complicated
as
a
concept
in
general,
so
I'm
really
torn
between
you.
That's
why
I
brought
it
to
per
programming,
because
I
have
no
opinion
on
this
I'm
just
trying
to
find
some
decision.
That
is
nice
and
I
know
that
we
have
many
good
developers.
So
maybe
someone
comes
with
some
bright
idea
because
I'm
not
capable
of
here's.
A
A
I,
don't
have
to
worry
about
merging
into
some
shared
Globe
shared
globalish,
namespace
of
resolver
type
names
or
whatever,
but
if
everything
could
be
namespace
of
like
and
somehow
we
could
either
lent
or
even
enforce
that
we
could
get
really
sophisticated.
Maybe
even
like
every
time
you
create
an
Apollo
client,
it
automatically
creates
a
namespace
for
you
like
that,
would
be
really
wild,
but
name
spacing
I
think
would
be
an
interesting
way
to
simplify
merging
and
make
it
way
more
predictable.
B
Okay,
and
this
is
what
makes
me
a
bit
nervous
on
it,
because
we
already
have
a
situation
it's
on
board,
by
the
way
where
group
list
has
two
different
interactions.
So,
if
you
use
boards,
you
can
move
the
issue
to
the
list
right,
that's
the
first
one
and
the
second
one
is
you
can
scroll
down
and
there
will
be
more
issues.
Loading
and
these
two
have
different
type
policies.
It
took
us
a
lot
of
time
to
figure
out
how
to
separate
these
two
with
arguments
again
undocumented
the
policy
and
documented
Apollo
magic
here.
B
Potentially,
with
the
police,
we
would
have
no
other
options
because
we're
kind
of
forced
into
policies
I'm
not
loving
it,
but
we
are
and
from
to
measure
the
merge
results.
We
need
to
use
their
policies.
So
what
is
good
in
manual
emerging
things
into
one
large
Global
Tech
policies,
but
everything
that
it
will
make
developers
think
and
try
to
separate
the
situations,
because
our
requests,
they
accept
arguments,
we
can
access
arguments
in
type
policy,
and
with
this
we
can
write
conditions
like
if
this
is
some
kind
of
the
page.
B
A
Think
I
think
I've
enjoyed
Thai
policies
compared
to
right.
Query
like
I
think
that's
when
my
experience
with
it
so
I'm
not
eager
to
say:
oh,
let's
just
get
away
with
type
policies,
I'm
wondering!
Is
there
a
trade-off
but
I
think
no
you
you
highlight.
No,
there
just
needs
to
be
a
single
owner
to
this
type
policy
and
that's
a
big
deal,
but
I
love
that
man
I
think
it's
going
to
make
it.
So
that's
gonna
enhance
the
reusability
and
simplicity
of
the
application.
A
So
much
if
we
can
have,
rather
than
every
single
page,
creates
its
own
client,
its
own
type
policies,
everything
they
need
if
we
have
single
owner
for
of
this,
if
I
get
some
of
that
out
of
the
box
like
that,
that
would
be
really
cool.
I,
yeah
I
know
that's
interesting,
but
I.
Think
then,
the
the
need
for
the
single
owner
just
begs
the
question
of
how
what
would
the
memoys
look
like?
A
B
Resolvers
definitely
can
especially
if
we
enforce
name
facing
in
this
particular
case.
Resolvers
will
be
unique
and
we're
not
afraid
of
all
writing
and
we
have
a
method
to
add
resolvers
to
the
existing
resolvers
and
we
just
basically
concatenate
all
new
resolvers.
So
at
least
this
part
can
be
moved
to
Dynamic
ones,
and
we
can
move
type
policies
to
Global
like
like
we're
doing
right
now
with
possible
types.
So
possible
types
are
basically
generated
by
backend
from
the
schema
now
and
we
just
put
them
in
the
global
instance
all
the
time
and
you
like.
B
No,
you
don't
need
to
worry
about
possible
types
anymore.
You
probably
remember
that
before
Apollo
client
3,
you
will
need
to
write
this
awful
Json
with
possible
types
of
interfaces
and
unions
and
import
it
from
there
put
it
into
all
clients
or
not
anymore.
Maybe
that
policies
is
a
good
idea
to
put
in
This
Global
namespace
too
yeah.
B
D
A
A
A
Right,
I'm
gonna,
do
it
so
I
have
a
test
to
write,
and
maybe
that's
the
first
thing
to
do,
which
would
be
great.
I
also
have
some
Mrs
to
review
either
of
those
sound
interesting,
reviewing
Mrs
or
testing,
which
one
none
of
them
sound.
Interesting
best
thing
we
just
did
reviewing
okay
yeah,
we
did
just
see
a
review.
So
let's,
let's
do
a
testing.
A
D
D
D
C
E
D
I
I
love
having
two
screens.
It
means
you
can
be
doing
like
so
the
zooms
on
one
screen,
and
but
it
does
mean
that
the
camera
is
in
an
awkward
position
and
like
yeah,
so
I
I
still
haven't
decided,
I
and
I.
Don't
really
want
to
spend
the
money
to
test
the
other
I've
done
so
well
with
two
monitors
for
so
many
years,
but
I'm
starting
to
get
to
a
point
where
I
think.
Well,
if
I
had
one
big
one
camera
be
in
the
middle
and
I
wouldn't
be,
quite
so,
I
don't
know.
C
C
I
think,
like
two
comes
in
handy,
if
you
are
using
like
default,
Mac
window
management
things
where
they
just
kind
of
float
around
and
don't.
But
if
you
use
something
like
like
when
I
when
I
started
here
and
I
got
the
the
Mac,
it
was
really
frustrating
because
they
don't
you
can't
just
like
Snap
Windows
all
around.
But
if
you
download,
something
like
I
think
spectacle
is,
is
the.
D
E
E
A
It's
on
Windows.
It
was
like
some
sort
of
like
OS
face,
but
it
was
like
a
game.
It
was
like.
You
walked
around
a
room.
You
could
see
like
your
icons
or
whatever
did
you
ever
check
this
this
kind
of
thing
out,
so
it
wasn't
VR
because
you're,
obviously,
in
first
person,
shooter
controls
land,
but
it
was
like
oh
I'm
gonna.
Oh,
it
was
basically
what
VR
is
trying
to
do
without
the
whole
VR
thing
or
whatever
I.
A
A
A
Instead
of
this
alert
thing
which
looks
wonky,
he
liked
the
idea
of
adding
this
sidebar
that
opens
with
that
will
automatically
open
on
the
right
hand,
side
hey
we're
going
to
switch
editors
switch
to
the
new
web
ID,
you
can
close
the
sidebar
and
that's
all
there.
So
it's
great
so
I
have
my
part
3mr
here,
which
has
the
latest
changes
except
I.
A
Have
one
test
to
write,
which
is
a
lot
of
these
are
straightforward,
but
this
one,
which
is
that
whole
empty
State
View
with
the
button
which
makes
the
calls
this
one
I
haven't
written
a
test
for
yet
I
have
the
test
which
was
doing
for
the
component,
which
is
doing
something
very
similarly
in
the
other
Mr.
So
I
was
gonna.
I
think
what
I
was
gonna
do
was
take
that
test
the
make
it
work
here
and
then
fill
in
the
gaps.
So
that
was
my
strategy.
A
A
A
So
this
is
the
previous
Mr
and
I'm
going
to
compare
it
to
master,
which
gives
me
these
files
changed
and
I'm
going
to
steal
the
one
that
had
so
this
one
had.
This
is
the
function.
I
was
not
really
wanting
to
recreate
the
test
for
it's
not
like
it
was
hard.
I
just
get
lazy,
so
this
is
the
spec
for
it.
So
what
I'm
gonna
actually
do
is
apply.
The
changes
here.
A
C
A
Yeah,
you
all
are
like
really
picking
up
so
much
space.
Here
we
go
all
right,
so
I'm
on
my
new
branch
and
the
component.
We're
trying
to
test
is
called
switch
editors
view.
So
let
me
start
by
renaming
this
test
and
putting
it
to
where
it
should
live.
This
lives
in
components.
Switch
editors,
switch
editors
view,
so
it's
not
switch
web
ID
alert.
It's
called
switch
editors.
A
A
A
A
Yes,
it
does
I,
just
I
think
it'll
go
away
if
I,
if
I
tell
it
to
you
yeah,
but
I,
don't
think
I
want
to
go
I'll
find
you
go
all
the
way
away.
Right,
I,
don't
know
for
some
reason
it
gave
me
some
sense
of
security
like
I'm,
realizing
I
was
holding
on
to
it.
Chad.
Thank
you
for
encouraging
me
to
let
go
all
right.
A
One
of
the
wins
to
it
was
I
separated
the
logic
from
the
presentation,
so
this
layout
component,
which
you'll
see
references
to
in
the
old
test.
This
is
all
the
presentation
logic
here
just
for
Simplicity
I,
kept
it
all
in
one
component,
because
it
what
wasn't
that
separation
wasn't
needed
as
much
based
on
this
approach.
A
All
right,
all
right
so
I
want
to
get
rid
of
I
want
to
make
this
thing
yeah,
so
this
is
actually
triggering
the
switch
preferences,
so
this
will
be
instead
of
emitting
something
from
the
layout.
I
can
just
find
the
button.
So,
let's
find
the
button.
Let's
replace
this
with
find
okay,
I'm
just
going
to
call
it
find
button.
Oh
yeah
I'm,
not
gonna,
think
too
hard
I'm
trying
not
to
think
too
hard
at
this.
A
A
A
Let
me
let
me
just
leave
that
aside,
but
the
web
IDE
has
it
on
before
unload.
If
and
so,
if
I've
made
any
changes,
I
don't
want
to
have
the
user
go
through
two
clicks
of
yes,
I
really
want
to
do
this,
so
this
tells
the
IDE
skip
before
you're
on
unload
a
little
hacky,
but
it
works.
So
that
explains
these
lines
in
the
test
where
we're
just
setting
them
up
these
before
unload
things
they've
been
triggered.
E
E
A
B
A
A
E
I
mean
I'm,
so
this
is
like
as
a
legitimate,
a
meta
criticism,
slash
climate
for
people
following
along
like
seeing
the
entire
code
context
is
important
and
right
now,
you're
like
doing
a
scroll
back
and
forth
thing
it
your
eyes,
follow
it,
because
you
know
what
you're
doing,
but
it's
harder
for
other
people
to
follow
it.
When
you
can't
see
the
whole
width
of
the
code
and
when
it's
jumping
around
horizontally
thanks.
A
A
A
D
A
A
B
A
B
A
A
No
I
love
it.
Yes,
that
is
the
thing
it
needs.
Thank
you.
Thank
you.
I
get
so
hyper.
Focused
I
was
like
buttons
there
how's
this
not
showing
up.
That
was.
That
was
exactly
what
it
needs
so
right
now,
I
have
not
added
use
view
X,
because
I'm
questioning,
if
I
need
to
do
that,
looks
like
I.
Don't
need
to
do
that
so
great
cool,
let's
see
if
we
can
run
more
of
the
tests.
I
was
just
running
one
test.
Let's
run
all
the
tests.
A
A
A
A
A
A
A
You
want
to
really
consider
do
we
need
to
ignore
while
pending,
because
this
means,
while
One
Promise
is
pending,
let's
not
re-trigger,
multiple
Ones
based
on,
and
so
this
fixed
a
lot
of
double
confirmation
issues
with
gitlab,
but
I
have
tests
for
this,
not
which
is
nice
that
I'm,
not
what
I'm
doing
like
hey.
We
call
again
for
sure
we're
only
showing
one
confirmed
action
so
like
that
kind
of
thing,
so
that's
great,
but
I
am
noticing
I.
Don't
have
this
loading
state
I'm,
not
testing
this
loading
State
on
the
button.
C
A
A
C
A
A
B
A
It
wouldn't
so
that's
why
it's
like
yeah
I
want
to
make
sure
we
pass
in
the
values
we're
creating
a
saying
with
the
values
that
we
said
it
would
create
it.
It's
like
the
difference
between
being
to
have
been
called
with
versus
just
to
have
been
called
I
want
to
try
to
be
generally
explicit,
but
if
it's
challenging
then
I
I'm
also
eager
to
to
change
it
up
so
I'm
going
to
export
this
const,
where
they're
not
all
exported,
maybe.
C
D
A
A
B
A
A
Yeah
we
view
taxi
sales,
has
a
really
cool
enable
auto
destroy
so
all
of
the
wrappers,
even
if
I
create
multi.
This
is
a
big
deal
for
me
like.
Even
if
we
created
multiple
wrappers
accidentally,
we
would
be
able
to
destroy
them
all,
which
is
that's
such
a
huge
win.
Do
you
know,
do
you
know
who
originally
pushed
this
forward?
A
A
I'm
really
glad
that
we
have
that
now,
thanks
thanks
for
the
call
up,
okay,
cool,
so
we're
rendering
the
empty
State
that's
great
and
then
I
guess
I
want
to
just
you
know.
We
render
the
link
like
how
what
do
you
guys
like
to
do
here?
I
mean
I'm
I,
clearly
like
to
be
really
I'm
a
completionist
I.
Take
my
time
and
I
like
to
get
that
100
percent
feeling.
A
C
A
A
A
A
B
A
A
A
D
A
E
E
A
Yes,
I
I
thought
I
had
an
issue
with
my
test
setup.
The
reason
why
this
link
wasn't
being
passed
there
but
I
realize
now
it's
actually
an
attributes
and
set
of
props,
which
is
the
situation
but
yeah
I
agree.
This
is
why
I
also
rely
on
a
timer
a
lot,
so
I
don't
waste
so
much
time
trying
to
yeah
boom
like.
E
B
B
A
I
have
a
tendency
to
like
if
I
for
me,
the
litmus
test
is
yes,
I'm,
not
testing.
That
did
view
render
it
I'm
testing.
What
I
told
you
to
render
so,
if
I
removed
this,
and
it
didn't
cause
a
test
to
fail
that
gives,
even
though
this
is
trivial
that
makes
me
like.
Okay,
we're
just
choosing
not
to
test
this
and
that's
fine,
but
things
get
more
interesting
when
it's
like
for
props.
That's
a
more
significant
of
a
deal
for
me
than.
B
A
B
A
Gonna
try
to
but
there's
a
whole
lot.
We
don't
test
here
like
we
don't
test
all
the
classes,
and
that
makes
sense
the
the
fact
that
we
translate
these
strings
starts
to
like.
How
often
do
we
do
this.
You
know
and
I
think
we've
started.
I
don't
know
if
we
still
don't
lend
for
that,
but
sometimes
there's
been
situations
like
I
wish.
We
just
had
a
test
to
just
that.
We
didn't
that
we
didn't
include
the
namespace
in
the
string
like
there's
those
situations
but
yeah
when
things
are
just
raw
text.
A
C
E
C
A
C
E
And
I
I
wanted
to
try
to
be
snarky
and
say
you
know:
Ruby
mine,
I
can
click
and
say
run
with
coverage
for
jest
and
it
does
it.
But
I
tried
it
like
a
simple
one
worked,
but
a
test
of
a
view
component
like
blew
up
and
some
you
can't
do
an
import,
that's
not
a
module,
so
it
failed.
It's
sort
of
halfway
worked
and
gave
me
the
first,
a
simple
non-view
component
coverage.
A
B
B
Saying
yeah
no
problem
I
was
just
saying
that
to
improve
our
tests,
we
don't
need
to
increase
the
coverage.
We
need
to
improve
the
quality
of
upper
tests
and
it's
it's
like
every
single
time:
I
dive
into
code,
business,
three
years
old
and
older
purely
depressing,
because
I'm
writing
a
bunch
of
unit
tests.
I
just
need
to
fix
a
component,
but
test
doesn't
test.
A
E
Because
when
you
don't,
when
you
don't
write
tests
at
the
same
time,
and
ideally
tdd
Nothing
Stops
you
from
having
that
excessive
coupling
and
lack
of
cohesion,
so
then,
when
you
try
to
add
tests,
you're,
like
oh
man
like
it's
all,
mocks
I'm
mocking
this
I'm
mocking.
That
is
because
you
didn't
have
that
tdd
to
enforce
you
to
have
loose
coupling
in
high
cohesion
and
not
do
bad
things
in
the
first
place.
That's
my
yeah.
A
No
but
I
think
that
tdd
is
a
really
good
litmus
test
so
like
here,
clearly
we're
doing
test
hardening
and
so
for
me,
it's
easy
to
get
very
obsessive
about
the
completion
of
it.
Tdd
really
highlights
what
were
the
most
valuable
tests
for
this
and
the
tests
that
used
to
build
the
thing
and
that's
a
great
litmus
test
for
the
tests
that
are
actually
important
and
yeah.
That's
a
practice.
That's
interesting!
A.
E
Lot
of
people
on
the
TV
they'll
like
tdd
and
then
they'll
delete
those
tests.
We're
like
all
right
these
like
to
Natalia's
point.
It's
like
it's
just
really
ever
gonna
break
no
delete
the
test.
It's
just
it's
extra
overhead
and
cognitive
load
and
I
get
it
I'm
like
no
I'm
a
hoarder.
It's
a
beautiful
test.
Why
would
I
want
to
kill
it
but
kill
it?
That's.
A
True,
that's
true:
I
can't
wait,
so
you
know
you
so
you
know
we
get
measured
by
Mr
rates.
I'm
gonna
try
to
push
that
we
get
measured
by
line
count
so
I'm,
just
gonna
write,
crazy
amount
of
snapshot,
tests
and
I'm
joking
I
know
all
right,
I
catch
you
all
later,
thanks
for
helping
out
helping
me
bye
have
a
good
one.
See
you
later
bye.