►
Description
urql is a GraphQL client that exposes a set of helpers for several frameworks. It's built to be highly customizable and versatile so you can take it from getting started with your first GraphQL project all the way to building complex apps and experimenting with GraphQL clients.
While GraphQL is an elegant protocol and schema language, client libraries today typically come with large API footprints. We aim to create something more lightweight instead.
Join @bdougieYO and @kitten in learning the latest in consuming GraphQL.
https://github.com/FormidableLabs/urql
0:00 - Start
0:11 - What is urql
2:37 - Advantages for the urql client
10:36 - visual devtools demo
17:20 - Considering CORS
23:17 - Schema awareness
29:35 - RFCs
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
A
B
Yeah,
I'm
glad
you
actually
heard
about
it.
Was
we're
told
about
it.
I
guess
the
name
thing
is
a
bit
unfortunate,
but
the
name
has
started
a
bit
of
a
joke,
but
it's
a
graphql
client
and
I
see
it
as
kind
of
the
third
graphical
client
and
people
could
get
mad
at
me
for
saying
that
there
are
obviously
a
lot
more
attempts
at
creating
graphql
clients,
and
our
attempt
has
also
started
quite
humble.
B
So
initially
we
just
wanted
to
experiment
with
graphql
see.
You
know
what
was
the
bare
minimum
that
a
client
should
be
able
to
do
and
at
the
time
like
so
many
others,
we've
used
apollo's
client
and
we
had
some
frustration
and
snags
every
now
and
then
and
we
just
wanted
to
see
what
goes
into
making
a
client
and
we
started
from
a
very
small
base
and
then
grew
it
from
there,
which
also
means
that
we
had
a
very
different
approach
to
it
than
maybe
relaying
apollo.
B
B
There's
only
so
many
ways
to
write
these
query
hooks
I
mean
we're
passing
it
a
graphql
query.
We
kind
of
need
a
name
for
sending
a
query.
So
that's
going
to
be
use
query
and
then
we
get
a
result.
There
are
some
differences
in
like
the
api,
as
in
I
think
in
apollo
you
pass
the
query
string
or
the
document
as
the
first
argument,
you're
getting
the
result
back
as
one
object.
So
there
are
some
superficial
differences,
but
those
are
ultimately
just
small
choices.
B
A
Yeah
and
there's
a
question
in
the
chat
already
actually
a
couple
questions
to
chat,
but
I'll
grab
the
second
one,
because
I
think
it's
more
relevant
to
what
we're
talking
about
now,
which
what
do
you
see
the
biggest
advantage
advantages
comparing
said
to
apollo
in
relay
for
actually
the
advantages
over
apollo
for
everyday
react.
Users.
B
Right,
I
believe
the
interesting
thing
about
erko
is
that
when
you're
just
getting
started,
especially
when
you're
new
to
graphql
you're,
getting
a
graphql
client
with
urcall,
that
is
much
simpler
when
you're,
just
installing
it
and
one
of
the
things
that
is
different
than
is
patching
the
caching
approach,
because
by
default
you're
getting
a
very
similar
document,
cache
approach
and
that's
kind
of
more
like
how
a
browser
caches.
So
it
takes
your
query
takes
your
variables.
B
It
gives
you
a
result
and
this
result
is
cached
as
if
it
was
like
a
rest
api
response
by
your
browser
and
the
only
thing
that
we
then
add
on
top
is
when
you
send
a
mutation.
So
when
you
modify
some
data,
it
just
matches
the
type
name
and
invalidates
queries.
So
the
nice
thing
is
for
anyone,
that's
kind
of
new
to
this
in
graphql.
B
We
have
this
this
type
name
field,
and
whenever
we're
asking
for
a
set
of
data,
we
can
send
that
off
and
oracle
can
add
that
on
automatically
so
we
can
actually
inquire
the
api.
What
type
something
is
and
using
that
for
caching
validation
is
actually
already
so
intuitive
that
for
a
lot
of
simple
apps
like,
for
instance,
blogs
new
sites
like
sites
with
basically
mostly
static-ish
content.
That's.
A
B
Enough
so
then
you're
starting
off
from
a
very
simple
minimal
kind
of
starting
point,
and
that's
when
you
can
add
on
extensions,
you
know
those
are
called
exchanges
in
apollo.
Those
are
called
links
and
they're,
ultimately
pretty
similar,
which
is
why
I'm
comparing
them,
but
in
oracle
they
get
a
bit
more
power
because
even
caching
and
opal
is
actually
just
an
exchange.
B
So
the
only
abstraction
that
you
have
to
think
about
at
a
certain
point
is
what
exchanges
do
I
add,
so
the
advantage
you
get
is
that
you
have
a
lot
of
these
features
and
when
we
go
to
this
advanced
section,
all
of
these
are
basically
add-ons.
So
all
of
these
things
are
things
I
could
add
on
to
an
aqua
client.
B
You
can
add
those
step
by
step,
so
you
can
kind
of
customize
the
client
as
you're
going
and
as
you
need,
and
all
of
these
are
kind
of
layered.
On
top
of
what
you
already
get
when
you're
just
kind
of
browsing
around
building
a
simple
app
like
that
and
then
later
on,
you
could
even
drop
in
normalized
caching,
so
that's
very
different
from
relay
and
apollo,
because
we
believe
that
normalized
caching
doesn't
have
to
be.
You
know
in
there
from
the
start,
excellent.
A
B
B
So
these
are
actually
our
guiding
principles
and
the
reason
why
I'm
bringing
them
up
is
I've
kind
of
touched
on
that
very
briefly,
because,
when
you're
coming
to
oracle,
it
might
be
a
little
odd
to
hear.
Oh,
okay.
Caching
is
not
that
opinionated,
like
you,
don't
really
ship
with
opinions,
and
these
are
kind
of
the
things
we've
ended
up
on
the
middle.
One
here
says:
unopinionated
and
flexible.
B
So
what
we've
kind
of
settled
on
is
we
don't
really
want
to
force
any
opinions
on
people
that
use
our
core
so,
like
you
say,
it's
really
intuitive
to
get
started
with
something
that
has
that
swr
logic
where
you're
just
fetching
and
then
it
just
aggressively
invalidates.
So
basically,
just
you
know
folds
your
api.
B
Whenever
some
data
is
needs
to
be
updated,
simply
said
and
then
later
on,
for
like
more
complex
applications,
that's
when
you
need
to
use
something
like
normalized
caching,
maybe,
but
you
don't
want
to
be
forced
into
it
right
away,
because
you
might
not
even
get
the
benefits
of
it.
Instead,
you
would
be
forced
into
understanding
it
at
the
wrong
point
in
time
when
you're
not
even
interested-
and
that's
kind
of
the
third
point
here
intuitive
for
an
extended.
B
So
any
kind
of
exchanges
and
extensions
that
you
drop
in
the
idea
is
that
vocal
styles
are
as
unopinionated
as
possible,
but
as
soon
as
you
drop
these
things
in
that's
when
we
are
kind
of
buying
into
some
of
our
opinions
at
least
so.
What
I'd
like
to
think
is
our
normalized.
Caching.
Implementation,
for
instance,
is
actually
a
little
more
opinionated
than
apollos
and
that's
because
we
want
to
enable
a
couple
of
features
and
still
make
it
pretty
intuitive,
and
that
comes
with
a
bunch
of
opinions
which
I'm
going
to
be
honest.
B
Can
I
do
some
friction
if
you're
coming
from
apollo,
because
you
might
be
expecting
to
do
things
a
certain
way
and
then
yeah?
You
know
it
might
not
work
out
well,
but
that's
why
we
have
github
discussions.
So
we
see
a
couple
of
people,
basically
posting
apollo
code
and
asking
us
hey.
How
do
I
write
this
in
oracle?
B
But
if
I
quickly
scroll
through
this,
I
have
a
slide
somewhere
in
here
about
caching.
Here
comes
so
this
is
the
kind
of
short
summary
of
this.
If
I
make
this
below
that,
that
might
be
easier.
So
the
whole
idea
here
is-
and
this
is
the
short
explanation
document
caching
caches-
like
a
browser
to
fetching
documents
and
each
query
results.
So,
every
time
we're
sending
a
query.
B
B
So
that's
the
basically
smallest
amount
of
caching
and
invalidation
one
can
do
without
like
introducing
you
when
you're
just
playing
around
with
urkel
to
bugs
where
something
might
not
be
invalidated
and
you're
kind
of
stuck
with
a
sticky
cache,
so
that'll
be
annoying
and
normalized.
Caching,
on
the
other
hand,
is
the
complete
opposite.
B
A
normalized
cache
keeps
data
around
for
as
long
as
possible
and
it
caches
like
a
database.
So
it's
basically
an
in-memory
database.
It
builds
up
tables
of
these
objects
from
your
api
automatically,
so
everything's
split
by
the
type
that
is
already
set
up
on
your
graphql
api
and
then
any
changes
on
like
one
object,
so
one
entity
with
the
same
id
field,
maybe
is
shared
across
every
query,
so
you're
getting
a
lot
of
updates
as
soon
as
you're
fetching
different
stuff
from
the
api.
B
But
as
soon
as
you
use,
normalized
caching,
it
doesn't
invalidate
automatically
anymore.
Instead,
you're
encouraged
to
let
it
update,
but
sometimes
you
have
to
help
it
out
with
a
couple
of
updates
right,
we're
big
fans
of
github.
Obviously
I
don't
need
to
really
say
that,
but
I
was
working
hard
on
trying
to
get
early
access
to
github
discussions.
We
came
from
spectrum,
okay
and
now
that
this
is
kind
of
its
replacement,
it's
really
living
up
to
it
and
we
really
wanted
this
after
I
can.
B
A
B
So
just
having
this
one
hub,
where
all
the
questions
come
in
having
answered
marks
having
it
be
searchable,
has
helped
so
much
ever
since
we've
activated
it,
we
actually
have
gotten
less
questions.
I
assume,
because
it's
so
searchable
right.
This
is
pretty
early
days
yeah.
We
are
actually
working
on
new
examples
and
for
that
we're
building
a
new
demo
api.
This
whole
thing
here
try
graphql,
that's
just
all
temporary,
so
don't
worry
too
much
about
the
app
itself
and
the
ui.
B
B
B
This
is
kind
of
the
code
that
creates
the
client,
and
while
a
lot
is
in
here,
this
is
this
demo
shows
multiple
apis.
So
a
lot
of
this
is
actually
not
relevant.
We
can
go
and
delete
a
couple
of
things
now.
This
is
kind
of
how
we
can
create
a
client.
I
guess
I
can
make
it
even
simpler.
We
have
kind
of
like
just
this
this
setup,
so
let
me
make
it
a
bit
larger.
B
A
B
B
So
that's
not
very
interesting,
but
things
like
our
dev
tools
are
integrated
using
these
exchanges.
So
if
I
drop
in
the
dev
tools
exchange-
and
I
go
back
here-
and
we
give
this
a
little
refresh-
I
can
actually
open
this
dev
tools.
Tab.
All
that's
interesting
here
is:
this
is
all
an
extension.
You
can
install
the
oracle
extension
and
then,
if
I
start
fetching
things
we
can
start
seeing
some
kind
of
events
pop
up
in
here.
A
B
B
B
So
you
can
go
to
the
chrome
store,
the
firefox
extension
store.
You
just
search
ercor.
This
will
pop
up,
or
at
least
it
should.
I
mean
a
very
unique,
a
unique
combination
of
four
letters.
So
yes,
hopefully
that
works.
Then,
when
you
in
your
app
drop
in
the
dev
tools
exchange
that
will
enable
it
to
integrate
into
your
app
so
a
bunch
of
things.
I
have
more
apis
here,
using
which
we
can
demo
a
couple
of
things.
So,
for
instance,
this
is
a
colors
api.
B
This
colors
api
is
not
too
exciting,
but
I
can
tell
it
to
give
me
a
random
color
by
name
and
hex
code.
That's
not
very
useful
for
demoing,
but
as
you'll
quickly
see
this
api
misbehaves
a
bit
for
testing
purposes.
So
this
api
actually
has
a
66
chance
of
giving
me
a
very
unhelpful,
no
soup
error,
which
look-
I
mean
no
soup
for
you.
So
that
gives
me
the
opportunity
to
kind
of
show
a
bit
more
about
how
you
would
build
on
this.
B
I
can
actually
install
the
retry
exchange
and
it
can
add
retrying
to
urcle,
and
that
will
allow
me
to
basically
get
around
the
fact
that
this
api
is
sending
some
errors.
Now
this
api
is
very
contrived.
I
know
it
has
a
very
high
chance
of
giving
us
very
unhelpful
errors
yeah,
but
you
know
sometimes
you
need
to
actually
handle
errors
well,
or
at
least
avoid
getting
more
of
them.
I
think
it
has
some
default
stuff,
so
I
think
this
is
actually
all
I
need.
B
Let's
go
back
and
see,
I
think
I
need
to
tell
it
when
yeah,
okay,
fair
enough,
ignore
that
I
need
to
actually
tell
it
which
errors
to
react
to
by
default.
It
actually
only
reacts
to
network
errors,
which
is
because,
if
you're
getting
a
random
500
error
from
your
api,
because
something's
gone
wrong
with
some
routing,
then
you
could
just
drop
in
the
retry
exchange
and
everything
would
be
fine.
In
this
case,
I
actually
want
to
write
this
small
function,
I'm
just
going
to
trim
that
down.
B
In
this
case,
I
want
to
tell
it
to
specifically
watch
out
for
this
no
sub
error.
So
if
we
compare
this,
we
can
see
in
the
api
that
so
now,
if
we
go
to
the
network
tab,
we
can
actually
see
it
sent
a
bunch
more
requests
than
we
expected.
So
we
can
see
that
it
got
an
error
at
some
point,
but
it
retried
again
because
we've
added
the
retry
exchange,
so
this
kind
of
composability
is
what
we
want.
We
want
to
be
able
to
have.
These
changes
be
very
easy
to
add.
B
So
if
you
go
to
the
docs,
this
would
actually
be
under
advanced.
You
will
actually
find
out
under
retrying
operations,
so
the
idea
is
almost
each
of
these
sections
has
an
exchange.
That
is
useful
for
a
certain
case,
but
you
don't
need
to
worry
about
this
when
you're
starting
out,
but
instead
you
can
explore
this.
So
it's
not
unlikely
that
you
would
probably
at
some
point,
be
searching
for.
How
do
I
retry
failed
operations?
Now
you
could
go
here,
you
can
go
to
retro
operations
here
we
can
see.
B
A
Yeah
yeah,
that
sounds
that
that
seems,
approachable
and
intuitive
too,
as
well
like
there's
some
things
that
I've
I've
done
in
graphql
that
I've
had
to
do.
Some
like
weird
hacks
to
make
work
like
retrying
is
something
that
again,
I've
been
using
graphql
since
the
almost
the
beginning,
so
the
tooling,
the
advancing
and
tooling,
has
made
using
graphql
so
much
more
easier.
So
I'm
happy
to
to
hopefully
try
this
out
in
a
future
project.
There
was
a
question
actually
just
came
in.
B
B
B
A
Is
specifically
for
consuming
graphql
endpoints
into
your
your
front,
end
or
front
end
or
mobile
apps
and,
like
I
guess,
honestly
front
end
mobile
clients.
Any
sort
of
client
would
be
like
I'm
using
obs
right
now
to
stream
this,
so
that
would
technically
be
a
client
as
well.
That
does
not
not
very
friendly
to
graphql.
That's.
B
For
sure
yeah
it's
interesting,
but
I
guess
is
one
more
thing
we
can
do
is.
I
did
mention
the
cache
exchanges
here.
So
what
I
can
just
do
is
in
case
you
would
want
to
get
started
with
normalized.
Caching,
all
we'd
have
to
do
is
install
graph
cache.
So
that's
what
we
call
a
normalized
cache
sounds
a
bit
fancier
than
normalized
cache
and
shorter.
So
that's
important.
B
So
what
I
would
do
is
I
need
to
import
cache
exchange
from
that
package,
so
I'll
call
exchange
graph,
and
now
we
can
get
rid
of
the
other
cache
exchange.
We
don't
really
care
about
it
anymore,
and
this
here
changes
the
meaning
now,
instead
of
just
dropping
it
in
we're
actually
getting
a
bunch
of
options
on
the
cache
exchange
now
and
if
you're
just
getting
started
with
the
normalized
cache
to
kind
of
get
the
same
default
behavior,
they
would
expect
from
a
normalized
cache.
You
don't
need
to
pass
in
any
options.
B
So
once
we
drop
this
in,
we
could,
I
guess,
go
to
the
basic
pokedex
api.
That's
a
jolly
good
one
would
help
start
the
server
back
up.
Is
it
kind
of
yeah
right?
So
once
that's
set
up,
we
shouldn't
see
any
difference
initially,
so
it
should,
for
instance,
still
be
able
to
say
pokemon's
limit,
10
id
name.
B
So
once
we
do
that
we're
kind
of
just
fetching
pokemons
we're
getting
them.
That's
not
a
big
deal,
but
an
interesting
thing
happens.
For
instance,
if
I
leave
out
name,
we
can
see
it
executed
it,
but
no
new
network
request
came
in.
So
that's
the
big
advantage.
Now
that
we
have
a
normalized
cache,
it
can
start
executing
some
graphql
caching
locally.
It
already
knows
about
a
bunch
of
this
stuff,
a
bunch
of
this
data,
so
it
does
need
to
go
back
to
the
api,
and
this
kind
of
is
all
done
in
the
background
automatically.
B
But
there
is
a
caveat.
It
doesn't
know
about
any
kind
of
other
stuff,
any
kind
of
links
that
you
set
up
yourself.
So
while
we
know
about
pokemon
001-
and
we
know
we've
seen
it-
we
can
in
fact
still
see
it
on
the
right
here.
Graphics
doesn't
know
how
to
actually
get
to
it.
If
we
change
up
our
query
so
here
I'm
not
saying
I
want
a
single
pokemon
with
the
id01
and
if
I
execute
that,
but
it
had
to
go
back
to
the
api,
although
it
had
all
the
data
it
needed
interesting.
B
B
Isn't
too
hard,
it's
very
similar
to
how
you
set
up
a
graphql
server
api?
So
if
we
go
to
cache
exchange,
we
can
create
resolver,
configs
and
then
on
query.
I
can
actually
tell
it
what
to
do
when
it
gets
pokemon.
It
sounds
really
weird.
I
can
tell
it
what
to
do
when
it
gets
spoken.
Yeah
sure.
So
I
know
that
a
graphql
resolver
in
the
backend
in
graph
cache
is
parent
arguments
and
so
on.
But
it's
easy
to
forget.
I
don't
want
to
try
it
out
twice.
B
So,
let's
just
refresh
so
we're
going
to
do
the
same
thing
again,
I'm
going
to
get
some
pokemons
10.
In
fact
it's
always
a
good
amount.
Let's
also
get,
I
guess
the
types
here
so
we're
getting
the
types
of
pokemon,
so
that
has
worked.
We
sell
our
bulbasaur
on
number
one
and
what
we're
now
looking
out
for
is
it's
done
this
one
request
to
get
all
of
these
pokemon.
B
But
now,
if
I
do
id
001
there
we
go
now.
I
can
see
it's
gotten
that
one
pokemon
and
it
has
sent
no
network
request,
so
I
can
go
type
in
a
different
id.
I
can
get
a
different
pokemon,
so
that's
the
power
of
a
normalized
cache
as
long
as
you're,
basically
aware
of
what
you're
trying
to
do,
you
can
get
data
entirely
offline
well
without
going
to
the
api.
If
your
offline
cache
already
knows
about
it,
if
graph
cache
knows
about
it,
you
can
probably
get
it.
B
B
So
there
is
this
page
that
kind
of
explains
you
how
to
set
it
up,
but
this
diagram
is
mostly
what
it
is.
So
this
is
what
I've
just
described.
We
have
a
listing
page
we're
going
to
the
details
page.
The
idea
is
graphcat
should
be
able
to
give
you
part
of
that
page
until
it
has
fetched
the
rest
and
that
pairs
really
well
actually
with
the
suspense
concepts
in
react
and
view
three.
A
A
I
guess
because
I
have
basically
and
my
concept
is:
I
have
a
list
of
repositories
open
source.
Is
it's
a
project
to
encourage
open
source
contributions,
and
I
think
the
best
thing
for
me
to
do
is
just
I'll
switch
to
my
screen
share
for
a
second.
But
when
you
first
load
this,
I
have
a
list
of
repositories
that
I'm
sort
of
tracking
on
github
and
then,
when
I
click
through
pizza
ql.
A
A
But
with
this,
like
the
url
that
I
have
here
or
the
name,
I
I
have
to
add
it
to
the
I'm
actually
pulling
it
from
here,
because
I
didn't
have
a
way
to
properly
cache
this
and
possibly
there's
a
great
way
to
do
this
in
apollo
today,
because
I'm
using
apollo
here,
I
just
haven't-
had
the
time
to
go,
learn
it
to
then
fix
it
in
this
app.
So
that's
basically
where
I'm
at,
like.
I
probably
have
a
solution
for
this.
A
I
just
haven't
done
it
yet,
so
my
project's
open
source
definitely
check
it
out.
If
you
want
to
help
solve
problems
for
me,
but
going
back
to
urkel,
I
love
your
example
because
I
feel
like
I
could.
If
I
just
took
a
time
to
think
about
it,
I
can
leverage
that
example
to
help
teach
me
to
fix
that
problem.
B
Yeah,
it's
I
mean
it's
an
interesting
one.
I
think
this
diagram
is
an
interesting
one,
because
it
takes
a
bit
to
explain
the
whole
idea
of
oh,
give
me
powerful
data
and,
like
have
schema
awareness,
we
like
came
up
with,
like
short,
but
like
hand,
wavy
terms
for
it,
and
it
took
us
a
while
to
figure
out.
This
is
the
one
example
that
most
people
have
seen
that
most
people
understand
yeah
now.
B
The
reason
why
it's
called
schema
awareness
is,
I
have
left
out
a
small
but
important
bit
of
how
what
you
need
to
do
to
make
your
pizza
qr
example
work
yeah.
It's
called
schema
awareness
because
for
partial
data
to
work
we
need
to
actually
introspect.
Our
schema
sounds
pretty
scary,
but
it's
a
pretty
common
process.
B
In
fact,
in
this
demo,
all
of
this
info
down
here,
where,
like
lists,
what
this
graphql
schema,
can
do
for
pokemons
that's
introspection
and
that's
just
a
normal
graphql
query
where
we're
just
asking
the
graphql
schema:
hey
what
bunch
of
types
do
you
have
like?
What
do
you
know?
What
can
you
do
and
for
schema
awareness
to
work,
we're
kind
of
taking
advantage
of
that
data
as
well?
B
So
the
only
piece
of
data
that
a
normalized
cache
usually
needs
is
that
tight
name
field,
so
it
needs
to
know
hey.
This
object
is
a
pokemon,
or
this
object
is
an
evolution
of
a
pokemon.
I
think
we
do
have
that
in
there,
but,
as
you
kind
of
go
along,
there
are
two
types
of
information
that
you
add.
So,
first
of
all,
you
set
up
configuration
to
kind
of
set
up
resolvers,
so
you're
teaching
the
cache.
What
to
do
in
certain
circumstances.
B
And
these
are
all
very
brief
sections,
so
these
sections
down
here
are
all
the
ones
that
you
would
need
to
kind
of
understand
these
concepts,
so
we've
kind
of
already
seen
resolvers
great
half.
The
thing
is
done.
This
is
the
update
section,
so
it's
similar
to
resolvers,
if
you're,
for
instance,
adding
a
new
to-do
to
a
to-do
list.
A
normalized
cache
wouldn't
automatically
know
that
it
needs
to
add
that
to
a
different
query,
so
you
need
to
tell
it
hey.
B
This
is
the
query
where
you
need
to
add
it,
but
partial
data
is
an
interesting
one,
because
partial
data
is
a
pretty
useful
case.
Where
you
need
more
information
about
your
schema,
I
think
in
apollo
you
can
actually
force
it
force
the
cache
to
give
you
everything.
It
knows,
even
if
that
doesn't
fit
your
query
and
your
schema
and
that's
an
important
distinction,
because
do
you
actually
want
to
get
data
that
the
cache
doesn't
have
as
null?
B
So,
if
we're
thinking
about
what
a
graphql
api
does
when
an
error
occurs,
that
field
might
either
be
required
or
optional
when
it's
optional
and
that
field
errors,
the
server
can
just
set
it
to
now.
It
can
leave
it
out,
but
if
it's
required
it
actually
needs
to
cascade
out.
It
needs
to
check
that
parent
field
and
its
parent
fields.
Can
I
set
that
to
no.
B
So
there
is
a
small
process
involved
when
kind
of
dealing
with
partial
data
on
the
server
side
and
that's
why
partial
data
can
be
a
bit
dangerous
on
the
front
end
because
you
might
be
generating
types
for
your
schema,
so
typescript
may
be
telling
you
hey.
This
field
is
not
optional.
You
can
just
trust
that
that
will
always
be
set.
A
B
Which
isn't
the
case
when
you're
telling
the
cache
to
give
you
partial
data?
In
fact,
we
have
this
rfc
board
where
we're
tracking
everything
we're
doing
so.
While
I
can't
predict
what
good
new
ideas
might
come
from
people
browsing
the
repo,
I
can
only
encourage
people
to
create
rfcs,
because
when
you
create
a
new
issue,
you're
also
immediately
encouraged
to
create
an
rfc
and
remember
github
before
this
feature
was
wild.
So.
B
B
A
B
You
can
see
the
examples.
I've
talked
about,
that's
a
task,
that's
in
progress
and
that
started
as
an
rfc
sent
in
from
an
external
contributor.
It's
beautiful
someone
proposed
something
and
we
can
just
do
it.
Similarly,
there
are
a
lot
of
different
ones
that
we
created
as
well
a
lot
of
ones
that
come
in
externally,
but
there
is
actually
one
that
we
haven't
quite
started.
Yet
we
wanted
to
do
a
cross
tab
exchange,
so
we're
thinking.
If
two
tabs
are
open
and
with
an
oracle
client
they
could
send
each
other.
B
The
api
results
they've
gotten
from
the
api,
so
even
across
tabs
it
wouldn't
be
doing
work
twice.
We
haven't
really
started
this
yet,
but
the
rfc
is
down.
If
anyone
does
pick
it
up,
I
think
we
just
didn't
start
it,
because
there
were
other
things
that
we
wanted
to
do
first,
so
this
was
always
like
the
lowest
priority
one,
but
yeah.
There
is
an
open,
rfc
process.
It's
all
in
issues.
In
that
project
board
we
have
a
very
long
contributing
readme.
That
kind
of
tells
you
about
this.
B
A
Excellent
yeah
I
mean
that's
like
the
contributing
md
sounds
like
a
great
place
to
get
started
for
sure.
I'm
super
happy
to
see
y'all
leveraging
discussions
so
well,
and
then
our
rfcs
on
project
boards
really
really
easy
way
to
sort
of
grok
for
someone
who's
just
coming
in
for
the
first
time
and
just
learned
a
miracle
or
haven't
had
a
reason
to
try
it
out
until
today.
A
So
phil
thanks
so
much
for
the
conversation,
the
examples
I
would
say
where
could
people
find
you,
but
they
obviously
find
you
on
github
slash
kitten,
but
I
guess
the
the
other
question
is:
where
can
folks
find
more
conversations
like
this?
You
mentioned
you
had
a
talk
that
you
gave
with
the
slides
that
you
showed.
B
Right,
I
guess
there
are
two
things
I
can
shout
out,
which
is
if
you
want
to
find
out
more
about
how
the
normalized
cache
works-
and
you
know
I've
talked
a
lot
about
this,
but
the
normalized
cache
was
kind
of
the
main
thing
I've
talked
about.
Then
you
can
go
to
my
blog
kit
and
sh,
and
I
have
an
article
that
explains
more
about
how
it
works
other
than
that
go
to
the
docs.
Obviously,
if
you,
if
you
want
to
learn
more,
the
docs
are
a
good
place
to
start
formidable.com
open
source,
slash.
B
If
you
go
to
my
twitter
and
I'll,
add
this
in
more
place
later
on,
because
this
has
just
been
published,
you
can
actually
find
me
tweeting
out
the
talk
recording
soon.
I
haven't
tweeted
it
out
yet
because
it's
just
been
uploaded
yesterday.
Okay,
if
you're
really
ego
go
to
youtube,
find
prisma
and
big
big
thanks
to
prisma
for
being
awesome
in
terms
of
organizing
meetups
and
making
wrong
prism
and
making
an
awesome.
Orm
they've
just
launched
a
product
hunt
if
you're
on
product
hunt
give
them
an
upload
they're,
pretty
pretty
cool
people
there.