►
From YouTube: GraphQL js Working Group - 2022-03-08
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Okay,
great,
I
think
it's
necessary
that
people
that
are
not
you
and
me
join.
Otherwise,
it's
a
bit
pointless
if
we
just
agree
that
our
at
the
design
that.
C
Amazing,
I
guess
quickest
meeting
ever
no,
I'm
gonna,
I'm
gonna
stop
my
video
because
I'm
on
mobile
data,
we
got
a
power.
Okay,.
B
C
Power
outage
internet
outlet
stop
my
video
and
then
it
should
work.
B
A
A
A
Yeah,
so
let's
just
wait
a
few
more
minutes.
I
think
vicky
wants
to
join
yeah.
B
B
D
A
How's
it
going
hey
going
great,
just
getting
ready
here
yeah.
How
are
you
doing.
A
By
the
way,
I
wrote
brian
warner,
and
I
think
that
we
should
be
able
to
get
a
recording
of
this,
because
there
is
a
recording
in
progress.
We
just
need
to
ask
brian
how
we
yeah
how
we
can
get
this
recording,
but
I
will
just
assume
that
that
will
be
figured
out
yeah
yeah
good.
So
I
will
just
share
the
google
docs
here
julian
how's,
your
internet.
Doing,
do
you
think
we
can
enable
video,
or
should
we
rather
leave
it
out.
A
Okay,
okay,
so
then,
let's
I
will
just
share
my
screen
and
we
can
go
through
the
agenda
together.
First
agree
on
it
and
then
just
get
started
yeah,
it's
also
here
in
the
in
the
github
document.
So
I
just
added
that
here
in
the
google
doc.
A
So
this
is
what
I
propose
to
talk
about
today.
We
have
the
design
that
julian
created
and
now
we
got
a
bit
of
feedback
from
the
community,
including
ricky,
which
is
great.
So
let's
review
that
and
ratify
that
that
we
can
move
forward
and
then
agree
on
the
minimal
scope
that
we
want
to
start
with
and
then
how
we
actually
go
about
the
implementation
and
then
last
but
not
least,
how
we
then
communicate
that
plan
to
the
community.
D
Looks
looks
good,
yeah
yeah,
I
mean
for
the
one
thing
we'll
just
go
over
the
github
projects
for
the
toolkit.
A
Yep,
perfect,
perfect,
okay,
so
then,
let's
get
started
with
the
design
yeah.
We
had
the
discussion
here
in
the
and
the
github
discussion
that
we
already
had.
So
this
was
just
in
the
same
discussion
that
otter
posted
ricky
rightfully
mentioned
shouldn't.
We
put
this
into
a
separate
github
discussion,
so
we
can
have
a
better
thread
structure,
so
I
just
moved
it
over
here.
A
So
tldr
again,
we
have
worked
on
a
new
design
of
the
first
input
session
with
ricky
and
otter,
and
so
the
new
design
tries
to
incorporate
all
the
ideas,
all
the
plugins
and
everything
that
is
planned
for
graphical
tool
and
yeah.
I
can
give
a
quick
overview
again
of
the
design
and
then
the
optimal
outcome
would
be
that
we
here
get
consensus
on
the
design
and
say
yes,
this
is
what
we
want
to
move
forward
with,
so
we
can
start
with
the
actual
implementation.
A
C
B
C
Just
a
bit
of
delay:
yeah
internet
is
a
little
bit
flicky
now,
but
let's
see
okay,
yeah,
okay,
okay,
basic
idea
is
we
keep
the
interm
we'll
keep
the
interface
very
flexible.
We
basically,
as
you
can
see
in
the
in
the
structure,
view
that
tim
is
just
showing.
We
have
a
pane
on
the
left
for
the
docs
explorer.
C
That
can
be
all
different
kinds
of
things
as
well
in
the
center.
We
have
the
editor
on
the
right
side
with
the
result.
The
only
thing
that
is
in
this
design
really
kind
of
the
core
is
that
we
have
an
editor
and
the
result,
as
kind
of
like
two
two
elements
that
are
in
the
center
of
the
experience
and
everything
else
is
pretty
much
exchangeable
extendable
exactly.
A
Okay,
yeah
perfect,
and
I
think
we
had
a
bunch
of
questions
coming.
Did
you
incorporate
the
new
ideas
already
in
here?
Yes,
so,
for
example,
yeah.
So
this
is
how
the
high
fidelity
design
looks
like
yeah,
and
the
idea
is
again
the
idea
that
might
be
controversial,
but
so
far
I
think
we
didn't
hear
anyone
any
anyone
opposing
it
is
that
we
would
merge
the
docs
and
an
explorer
into
one
the
explorer
again
an
idea
that
one
graph
popularized.
A
Actually,
I
can
show
you
so
they
have
this.
They
call
it
graphical
explorer
where
you
can,
like
click
on,
like
kind
of
like
a
drop
down
menu.
What
kind
of
notes
you
want
to
add
to
your
query
and
the
idea
is
in
the
new
design
to
also
provide
that
that's
a
great
idea.
A
We
believe,
but
include
that
in
me,
like
with
the
with
the
docs,
and
we
can
show
a
bit
how
that
actually
looks.
D
D
D
Problem
is
users
need
deep
links
to
every
single
type
and
system.
We
really
are
gonna
need
like
tabs
for
that
sidebar,
so
that,
because
users
are
going
to
want
to
be
able
to
display
their
own
custom
components
there
as
well
very
soon,
so
that's
also
in
the
roadmap
for
2.0.
If
there's
issues
summarizing
all
of
this
and
stuff-
and
the
have
you
looked,
I
mean
never
mind
we'll
talk
about
it
later.
D
Okay,
yes,.
D
D
B
D
Entry
like
or
more
less
technical,
you
could
say,
user
experience
situation
here,
like
analysts,
one
graph
said
a
lot
of
their
customers
have
analysts
that
want
to
be
able
to
use
graphical,
but
they
don't
have
to
write
queries
for
everything,
so
they
want
to
just
have
the
explorer.
D
You
know
like
so
and
there's
other
views
where
people
have
other
modes
of
different
query
like
like
even
like
three-dimensional
tools
to
construct
queries,
and
it
should
be
just
as
easy
as
adding
a
you
know,
adding
a
custom
component
so
that
that's
kind
of
that
was
the
kind
of
vision
for
2.0
and
that's.
B
D
To
provide
that
level
of
flexibility
and
yeah
like
a
sidebar
where
you
can
switch
between
different
options,
the
idea
of
having
the
docs
is
like
a
first
like
almost
like
a
searching.
Docs
is
a
call
to
action,
is
great
and
I
think
yeah
users
will
like
that.
D
But
we'll
we'll
need
to
be
able
to
show
the
search
results
in
in
a
potentially
different
way,
because
if
they
click
on
something
will
it
add
the
field
or
will
it,
because
what
we
need
is
that
them,
like
users,
have
requested
the
ability
to
have
like
routes
that
point
to
each
individual
type
and
things
like
that
so
and
and
can
render
like
a
whole
field
and
it's
multi-paragraph
documentation
with
images
and
whatnot.
You
know
so
because
there's
like
people
want
to
use
this
for
api,
docs
and
stuff
as
well.
D
So
this
makes
a
lot
of
sense
for
something
that's
primarily
for
day-to-day
usage.
I
think
maybe,
but
even
then
the
doc
explores
kind
of
its
own.
It
would
just
need
to
be
different
from
that
behavior
there.
It
could
be
the
same
pain
that
they
you
switch
between
for
editing,
but
really
it
seems,
like
users
have
wanted
it.
D
I
mean
it
seems.
Various
like
people
want
editing
modes
for
grab
for
the
sidebar,
and
people
want
it
for
like
the
main
pane.
So
we
could
have
the
default
experience,
use
it
as
a
sidebar,
but
like
we
won't
be
able
to
be
too
prescriptive
with
graphical
anyways,
because
people,
you
know,
people
use
it
as
a
as
a
component
that
they
extend
a
lot
of
the
time.
D
The
vast
amount
of
the
time
it
seems
like
about
20
to
30
percent.
So
yeah,
I
think
we'll
we'll
just
find
people
will
will
want
to
have
the
idea
of
having
the
like.
We
want
to
be
able
to
show
these
custom
like
tabs
or
like
an
icon
menu
where
they
can
navigate
between,
like
apollo
apollo
studio
like
where
it
just
has
icon
menu
items
at
the
top
of
the
sidebar.
A
A
Okay,
you
know
so
here
and
then
I
can
switch
between
whatever
mode.
I
want
the
explorer
yeah.
D
A
Yeah
so
so
far
ricky.
Maybe
you
can
point
to
that,
but
I
didn't
see
anything
where
people
said
they
want
the
docs
and
the
explorer
to
be
separate.
Maybe
you
can
send
over
some
links
or
something,
but
there
was
a
couple.
D
A
A
D
There's
there's
several
feature:
requests
for
linking
to
specific
issues
they're
in
the
ish
in
the
issues
they're
labeled,
like
they're,
usually
labeled
with
a
plug-in
proposal.
Okay
or
enhanced.
D
D
D
So
this
one
goes
way
back
and
there's
a
ton
of
duplicates
for
this,
but
this
is
the
original
one.
B
D
D
B
C
Just
to
to
be
able
to
search
for
a
typo
click
on
a
type,
that's
definitely
yeah,
that's
this,
basically
and
and
it
like.
Ultimately,
this
works
exactly
like
the
current
docs,
docs
and
graphical.
You
know
you
can
click
on
the
type
you
can
you
can.
You
can
basically
go
as
deep
as
you
want
and
then
you
just.
A
B
D
Are
separate
interactions,
and
so
just
just
to
keep
in
mind,
we'll
need,
like
users,
have
asked
for
better
improvements
in
the
documentation
they
like
want
to
like
be
able
to
for
api
docs,
be
able
to
like
expand
the
docs
out
because
for
like
for
some
of
these
for
one
field
or
one
type,
that's
the
other
thing
is
I'm
not
sure
where
the
how
you'll
go
to
the
documentation
for
a
specific
type
or
interface
or
union.
C
C
D
C
C
D
And
also
the
type
itself
will
have
a
description,
so
it'll
need
to
push
down
yeah
as
well,
but
I
think
that's
and.
B
D
And
then
also
so,
they
also
want
to
be
able
to
just
because
they're
displaying
markdown
in
these
descriptions
and
they're.
Also,
it's
multiple
paragraphs
and
there's
code,
examples
and
stuff
like
that,
so
all
those
things
have
to
be
taken
into
account.
So
I
think
that
would
be
a
good
reason
to
have
like
a
collapsing
feature
where
you
could
collapse,
expand
or
collapse.
The
descriptions.
D
When
you
collapse
it,
it
would
just
inline
the
rest
of
the
description
and
whatever
space
was
left
for
a
single
line,
because
there's
also
you
know
at
my
company,
we
have,
you
know
thousands
of
types
and
fields
and
stuff,
so
search
result
might
take
a
while
to
to
get
to
where
you
need
to
be.
You
know,
so,
no.
C
Sure
yeah,
but
that's
that's
possible.
I
think
you
know,
especially
like
I
mean
absolutely
valid
point.
The
checkboxes
might
not
make
sense
here
we
can
like
you
know.
We
can
definitely
add
functionality
to
collapse
and
expand
descriptions
of.
D
C
D
The
other
thing
is
another
thing
to
keep
in
mind
with
this
component.
Is
users
are
often
requesting
to
render
it
standalone
in
their
own
editors
or
just
as
a
standalone
component
that
people
are
using?
So
that's
a
very
common
use
case
as
well,
so
people
are
exporting
it
now
to
use
throughout
different
places
so
just
having
it
render
in
a
way
where
the
the
automatic
insertion
of
fields
and
the
the
the
radio
buttons
maybe
are
optional
right.
We're
just
at
a
component.
Just
just
thinking
about
the
react.
Sdk,
the
the
graphical
react,
sdk
components.
C
D
B
D
It's
it's.
It's
very
widely
reused,
even
playground
reuses,
some
of
the
big
components
from
graphical,
so
yeah,
just
a
minor
few,
but
now
there's
others
use
it.
A
lot
and
people
are
often
asking
like,
even
though
they
obviously
can
people
often
open
issues,
saying
hey.
How
do
I
use
the
doc
explorer
on
its
own
and
you
know
the
components.
B
D
Yeah,
I
think
it
should
yeah.
I
think
we
could
have
it
maybe
even
render
and
like
have
the
the
this
remember
all
the
styles
are
themeable,
but
we
could
still
have
it
work
in
like
a
kind
of
responsive
way,
whereas
you
expand
on
old
school.
I
don't
know
if
that's
the
term
views
now,
but
like
mobile,
responsive.
You
know
where
it
like
expands
out
into
like
a
wider
view,
if
you're
in
a
larger
version
of
it
without
more
componentry
or
event
listeners.
D
Ideally,
but
I
guess
you
can
do
that
easily
now
with
react,
but
yeah,
but
I
haven't
done
mobile,
responsive
in
a
long
time,
but
this
is
one
case
where
it
would
be
easy.
So.
B
B
D
D
B
D
Like
one
thing
that
will
satisfy
a
lot
of
needs
just
for
graphical,
is
people
often
request
for
this
sidebar
to
expand
out
in
a
way
where
it
like?
Maybe
it
would
hide
the
results
or
something
like
that
or
the
query,
depending
on
the
bit.
D
B
D
But
I
mean
what
we
could
do
is
even
have
it
just
kind
of
like
push
the
results
closed
as
soon
as
you
expand
it
there's
something
simpler
because
you
don't
need
to
do.
The
full
fly
out
that
that
is
was
is
one
of
the
most
difficult
parts
of
playground
to
maintain
and
users
are
constantly
opening
bug
fixes
for
different
things
related
to
it.
C
D
I
think
it's
much
more
practical
to
think
about
what
if
there
was
just
a
mode
like
where
you
could
expand
the
sidebar
to
the
point
where
it
took
up
like
half
the
width
and
then
queries
and
variables
or
the
other
with
results
below
you
know,
or
something
like
that.
Just
like
a
kind
of
a
nice
like
rearrangement,
so
to
speak
that
handles
that
as
a
base
case.
Yeah.
C
B
D
D
B
C
D
D
But
but
I
don't
think
we
really
need
to
worry
about
that
too
much.
I
think,
there's
a
whole
different
if
you
like,
there's
a
previous
meeting
where
we
were
talking
about
like
a
simpler
graphical
sdk
react
components
that
would
be
more
for
simpler
cases,
and
that
would
be
something
where,
like
on
a
dock
site,
you
would
want
it
to
work,
but
we're
not
expecting
people
to
embed
this
in
their
dock
site.
It's
maybe
their
dock
explorer
that
they
want
to
customize,
but
their
branding
and
their
own
version
of
the
layout
and
whatnot.
D
B
A
This
is
one
example.
I
can
also
give
again
a
quick
overview
of
the
proposal.
A
So
yeah
we
have
the
direct
behavior
here
and
then,
let's
directly
jump
into
the
the
how
it
could
look
like
if
you
have
a
blog
post
or
docs.
So
it
would
just
be
this
minimal
approach.
Yeah,
okay,
I
wouldn't
yeah
the
fancy
like
sidebar
people
could
still
do
their
plugins
if
they
wanted
to
right-
and
here
these
icons
are
just
the
built-in
ones-
here's
the
prettier
one
and
the
history,
but
people
could
add
10
icons
that
all
have
different
plugins,
backed
okay.
D
D
A
A
Be
without
all
the
stuff
around
yes
great
yeah
and
then
also
dark
mode
little
thing
here,
nice.
A
C
A
Yeah
so
then,
with
the
tooltips,
by
the
way,
I
think
autumn
mentioned
that
with
the
monaco
sdk.
We
might
not
be
able
to
do
this,
so
we
have.
D
C
No,
I
just
wanted
to
say
that
something
I
guess
maybe
one
of
the
biggest
open
points.
I
need
to
know
a
little
bit
more
about
what
we
can
do
to
design
something
that
we
can
actually.
C
Implement
yeah,
I.
D
Could
speak
to
that
a
little
bit
so
what
we
can
do
so
the
way
the?
If
you
look
at
how
the
monaco
autocomplete
works.
Now,
when
you
hover
over
an
item,
if
it
has
a
description,
you
can
click
the
right
arrow
key
and
it
will
expand.
D
I
think
there's
also
a
short
another
shortcut,
but
it
will
expand
the
the
the
description
there
and
if
the
user
supplies
markdown,
we
can
have
it
right.
It
will
render
the
markdown.
D
So
that's
the
hover,
so
we
can
customize
hover.
If
you
see
I've
already.
B
D
Yeah,
so
that
would
be
a
great
starting
point
just
for
seeing
yeah
what
what
you
can
do
there
so.
D
Highlighted
with
that,
there
there's
only.
D
So
that's
that
effect.
I
did
there.
That's
markdown
that
I
add
in
the
in
the
lsp
and
get
autocomplete
sections
and
graphql
language.
D
B
D
It
just
it
just
renders
in
a
special
modality
where
it
can
show
that
I
could
also
even
print
the
whole
highlighted
type
there.
So
we
wouldn't
like
as
a
shortcut
until
we
have
definition
lookup,
so
I
could
even
print
the
whole
graphql
type
there.
I
found
with
the
github
example.
It
wasn't
great
because
it
also
prints
all
the
comments.
So
it's
really
hard
to
read
and
not
very
useful,
but.
D
C
Yeah
but
we
are
able
to
to
do
everything
in
the
in
the
realm
of
css,
with
the
markup
that
we
have.
D
So
what
I'm
explaining
right
here
is
this.
This
hover
is,
I
made
I
I
rendered
it
using
markdown,
so
that
coloration
is
all
they're
all
wrapped
in
span
tags
like
with
with
or
actually
I'm
sorry
that
that's
wrapped
in
a
graphql
like
triple
slash.
You
know,
like
markdown,
triple
slash
when
you
have
a
code
and
snippet.
So
all
I
did
was
I
just
wrapped
this
like.
I
have
a
function
that
prints
the
type
name
and
the
in
the
type
values.
D
So
if
you
just
just
it's
based
on
what
we
use
in
the
lsp
server,
and
then
it
prints
the
description
they
have,
but
beneath
it-
and
I
just
add
a
new
line,
so
it's
basic
whatever
markdown
support,
so
even
simple
header
elements
or
like
what
you
had
might
work
so.
C
My
question
is,
I
was
able
to
to
style
it
and
to
what
extent
can
we
style
it?
Do
we
have
the
full
range
of
css
and
style
options?
Are
we
limited
to
some
some
okay
got
it.
I.
D
D
Actually,
in
add
classes,
if
we
want
and
things
like
that,
we
could,
I
think
we
could
yeah
like
we
could.
We
could
use
classes,
we
can't
really
use,
we
can't
use
jss
or
css
and
js,
or
anything
like
that.
So
that's
a
consideration
for
our
theme
framework.
D
I'd
actually
like
our
theme
framework
to
use
css
variables
instead,
because
it
would
be
way
it
would
be
a
lot
simpler
to
configure
for,
like
probably
one
of
one
of
our
it's,
it's
amazing
what
people
do
with
it,
but
a
lot
of
people
just
consume
the
cdn
bundle
directly
in
an
html
file
and
then
customize
it
there
sometimes
to
hundreds
and
hundreds
of
lines,
but
they
they
would.
They
would
appreciate
being
able
to
override
like
something
like
that,
which
is
a
css
variable,
yeah,
just
sorry,
technical
notes.
D
I
don't
know
if
they're
welcome
or
necessary,
but
if
you
wanted
to,
let's
do
an
autocomplete
under
stargazer
account
for
fields,
oh
yeah
and.
D
Oh,
oh
right,
we
have
a
bug
for
this.
If
you
saw
the
monaco
graphql
working
group,
we
had
the
other
night.
We
were
talking
about
this.
So
at
some
point
monaco
stopped
run
adding
a
background
or
something,
but
as
you
can
see
there,
it's
already
displaying
the
description
to
the
right.
So
if
you
just
click
the
right,
I
think
it's
just
when
you're
hovering
over
an
item.
If
you
just
tap
the
right
button.
D
C
But
just
to
just
for
context,
this
is
not
too
far
away
from
the
designs
yeah.
The
only
thing
I
think
that
would
be
probably
would
be.
I
don't
know
actually
like
from
what
I
see
here.
It
looks
like
it
would
almost
be
possible
to
to
implement
the
designs
here.
I
think
the
only
thing
that
I
see
not
really
working
is
that
the
that
the
type
name
or
the
field,
the
field
type
is,
you
know,
part
of
the
list
and
not
part
of
the
description.
B
B
A
D
D
So
I
can't
override
that
header.
I
just
can
provide
that
description,
but
we
could
like
we
could
add
more
metadata
in
the
description
if
we
wanted
the
bottom,
where
it
like
links
to
that
item
in
the
documentation.
That's
what
users
request
all
the
time
is
they
want
to
be
able
to
when
they
hover
something.
That
already
is
how
it
works.
You
might
be
familiar
with
it
in
graphical
where,
when
you
hover
over
something
it
links
like
when
you
click
it,
it
links
to
the
documentation
for
that
field.
D
C
C
The
only
yeah
the
only
difference
is,
and
that
that's
the
question
for
you
now
is
like
the
intended
behavior
here
is
that
whatever
you
have
hovered
or
selected
on
the
left
side
in
the
list
also
shows
up
and
shows
up
in
the
description
on
the
right
side.
Right
away.
Is
that
something
that
we
can
influence
like
you
know
so
that
you
don't
have
to
you,
don't
have
to
have
an
arrow
that
you
click
and
then
the
description
opens,
but
that
it's
there
right
away.
D
I'm
not
sure
that's
something
I'll
take
note
of
to
look
at
I'm,
not
certain.
We
can,
but.
C
C
D
I've
I've
just
I'm
just
trying
to
think
of
like
the
the
monaco
interfaces
we
use
for
this,
and
I
I
don't
think
so.
I
can
look
into
it,
but
I
I
doubt
it:
it's
got
a
kind
of
a
universal
kind
of
behavior.
D
You
know
behavior
for
each
theme.
I
don't
think
they'll
need
that
if
we're
just
doing
things
like
font
size,
but
if
we're
doing
like
color,
we
have
you
know,
light
mode
and
dark
mode
and
different
types
with
different
background
colors.
You
know:
there's
multiple
dark
modes
and
multiple
light
modes
for
for
monaco
editor,
so
yeah.
C
Okay,
yeah
about
the
behavior.
I
would
assume
that
the
main
use
case
here
is
anyway
keyboard
navigation,
because
I'm
typing
so
I'll,
probably
just
stay
in
my
keyboard
and
we
do
have
the
description
showing
up
right
away.
When
I
you
know,
when
I
select
different
things,
I
think
that's
for
me
from
the
x
point
of
view.
That
would
be
sufficient
as
a
start
yeah.
D
D
What
keys,
you're,
pressing
and
just
kind
of
show
off
power
features
to
people
and
have
like
a
like
a
kind
of
a
helpful
key
map.
I
mean
we
can't
show
the
whole
monaco
editor
key
map,
but
hey
these.
These
are
some
shortcuts
that
might
be
useful
for
my
users
of
the
new
monaco
graphql
mode,
so
yeah
and
we
can
add
our
own
shortcuts
as
well.
So
keep
that
in
mind
it's
very
easy
to
do.
We
can
add
our
own
commands.
D
A
D
Yeah,
I
think
the
one
thing
to
add
to
there
is
some
way
like
a
rendering
like
we
do
with
the
oh,
the
overlay
or
with
the
the
oh.
What's
that
called
again
the
tool,
the
hover
so
like
we
do
with
the
hover
with
the
autocomplete.
We
should
render
that
at
the
bottom,
I'm
thinking
we
render
the
full
type
notation
and
have
each
part
of
it
linked
to
the
part
in
the
docs.
D
If
we
want-
and
we
don't
even
have
to
do
that
in
2.0
right
away,
I
could
we
can
add
that
later
because
it
would
be
an
enhancement
but
yeah.
It's
a
something
to
note
there
like
for
more
consistency,
because
yeah.
C
Anyways,
sorry,
no,
I
think
I
didn't.
I
didn't
fully
get
that
like
rendered
at
the
bottom
in,
in
terms
of
where
the
tooltip
shows
up.
D
D
D
B
C
Yeah
sure,
like
that's
like
that's,
that's,
maybe
also
one
thing
to
note,
like
the
the
the
docs
explorer
part
on
the
left
side
and
the
editor
they
they
should
be
interconnected.
So
if
I
click
on
anything
in
the
editor,
it
should
show
up
in
the
docs.
If
I,
if
I
add
a
new
field
in
the
editor,
it
should
also
be
checked
in
the
docs
and
the
other
way
around
yeah
yeah
so
like
in.
C
C
A
C
Okay
cool:
should
we
quickly
go
over
the
feature,
requests
in
the
or
like,
through
the
feedback
that
that
we
got
in
the
thread.
D
C
B
C
Previous
query,
you
get
the
prettify,
it
doesn't
really
change
the
mode
of
the
editor
that
could
be.
That
could
be
done
technically.
You
know
we
could
do
that.
It
might
not
be.
The
sidebar
might
not
be
the
best
tool
for
that.
I
think
if
we
would
want
to
have
different
different
states
here,
it
might
make
sense
to
do
something
similar
than
we
do
with
editor
tool.
One
two
and
three
down
here.
You
know
I
have
a
bit
of
a
a
bit
of
a
tap
one.
D
C
D
So
people
ask,
for
example,
to
do
like
schema
editors
and
things
like
that,
where
you
might
still
want
the
query.
So
I
think
that
would
be
a
case
where
you
do.
We
do
need
to
be
able
to
have
different
views
of
this
like
of
the
sidebar,
but
I
think
it's
a
great
start
to
combine
the
docs
and
search,
but
I
think
maybe
it
could
even
be
optional
where
by
default
it
doesn't
show.
But
then,
if
you
provide
custom
sidebar
components,
then
it
starts
showing
icons.
C
A
C
So,
oh.
C
That
so
that's
basically
you
know
that
that
would
that
would
be
the
visual
editor
here
on
the
right
side.
You
could
see
all
right.
You
know,
although,
like
one
comment
about
that,
I
like,
while
doing
that,
I
was
kind
of
I'm
figuring
out
what
exactly
the
use
cases
and,
in
the
end,
those
two
things
are
pretty
similar.
So
this
this.
D
D
And
then
also
people
want
to
render
and
also
just
custom
panes
that
people
want
to
render
in
the
sidebar
so
yeah.
There
would
be
a
lot
more
than
that
because,
like
being
able
to
configure
all
your
default
network
settings,
not
in
the
headers
editor,
I'm
talking
about
like
configure
multiple
endpoints,
it's
exploring
collections
of
queries,
yeah
sure
and
then
also
a
schema
editor
like
people
want
to
be
able
to
render
a
schema
editor
so
that
you
can
edit,
like
schema,
while
also
editing
values.
D
C
The
the
way
I
would
look
at
this
is
that
we
do
have
an
entry
point
for
settings
at
the
top
right.
It's
just
a
you
know
a
little
settings
icon,
that's
where
I
would
put
things
like
theme,
settings
for
example,
or
just
general
also
stuff,
like
network
settings,
could
be
up
there
different
views
on
the
docs.
You
know
like
a
schema
editor,
for
example.
C
That's
something
that
I
could
see
you
know
being
done
in
a
way
like
like
shown
in
the
like
shown
here
right
like
because
that's
something
that
that
really
just
influences
like
what
is
shown
in
this
left
pain.
C
D
People
need
more
advanced
layouts,
they
can
render
that's
the
other
thing
is
there
will
be
a
lot
of
cases
where
people
will
be
run
still
rendering
components
around
this,
because
because
yeah,
but
usually
people
want
to
be
able
to
override
almost
any
like
they'll
say
I
want
to
override
this
sidebar.
I
want
to
override
this
editor.
I
want
to
override
the
results
view
I
want
to
override
this
or
they
want
to
have
multiple
modes
and
like
there's
only
so
much
of
that
we
can
support,
but
we
can.
C
D
C
Yeah,
you
know
like
and
and
just
to
come
back
to
what
to
your
comment,
what
you
are
saying
about,
like
the
editor
itself,
having
maybe
two
or
three
modes.
That
is
something
that
definitely
could
be
done
by
using
the
same
approach
as
we
have
it
with
the
variables
and
headers
down
there
just
using
the
same
kind
of
tapa
approach.
C
C
B
D
C
It's
not
the
same
thing
like
the
query.
History
is
some
like,
so
the
the
way
that
we
thought
about
this
here
is
that
the
query
history
doesn't
have
anything
to
do
with
the
docs,
really
it
has
to
do
with
the
with
the
query
editor,
and
that
way,
it's
kind
of
it's
part
of
the
editor
tools
down
here
we
have.
D
D
Yeah
so
that
that
drop
down
yeah,
we'll
we'll
expand
more
into
that
further
in
2.0,
but
these
are
things
that
people
the
users
have
been
asking
for
for
years.
So
I
mean
it's
not
like
these
aren't
like
super
edge
cases.
These
are
very
established,
features
that
are
definitely
on
the
road
map,
so
yeah,
okay,.
D
C
It's
possible,
I
think
we
have
a
lot
of
tools
here
to
customize
and
extend
yeah:
okay,
cool,
okay,
okay,
second,.
A
What
else
do
we
want
to
do
before?
We
can
say
this
is
ready,
or
do
we
already
say?
Are
we
already
in
the
state
that
we
say
it's
ready
to
be
implemented
in
the
first
version.
A
C
Maybe
just
just
one
point
to
quickly
talk
about
like
we
had
this
comment
about,
the
selected
only
switch.
I
agree.
It's
not
the
most
amazing
position
up
there,
so
I
made
a
variation
where
it's
just
down
here,
which
I
think
makes
more
sense,
which
also
kind
of
like
makes
it.
B
C
To
put
responsive,
if
you
go
to
the
version
where
we
have
the
the
little
drop
down
here,
alternative
select
only
no
no.
A
D
C
D
C
B
C
You
might
want
to
have
more
screen
real
estate,
and
I
think
this
makes
it
makes
it
more
flexible.
I
would
say-
and
it
also
kind
of
groups
things
a
little
bit
better,
so
that
would
be
my
proposal
that
I
would,
if
you
all,
if
you
guys
all
agree,
then
I
would
just
change
that
and
all
the
all
the
other
designs
that
we
see
in
this
file
as
well.
D
C
To
add
tabs
for
the
editor
you
mean
yeah.
C
C
A
D
D
It
is,
and
it's
and
it's
laureen
from
who,
I
think
is
with
the
guild
now
who's
implementing
it.
So
it's
very
well
done.
I'm
about
to
yeah.
We
have
deployed
previews
now,
so
we're
going
to
be
able
to
show
it
off
to
people
and
get
feedback
so
yeah.
A
A
D
I
I
gotta
say
I
love
these
designs
and
I
really
appreciate
all
you're
doing
I'm
sorry.
I
had
a
lot
of
really
tough
questions.
I've
just
been
hearing
feature
requests
for
years,
so
it's
like.
C
No,
don't
worry,
don't
worry,
that's
great.
You
know
in
the
end,
in
the
end,
we
want
something
that
that
is
working
in
the
real
world
and
I
think
that
definitely
needs
the
hard
questions
to
be
asked
so
yeah
yeah.
I
appreciate
it.
D
D
C
D
I
think
it's
is
this
enough
to
go
forward
on
is
if
the
the
community
isn't
having
any
I'll
put
it
up
on
I'll
repost.
This
video
and
the
twitter
like
link
to
the
the
discussion.
If
I
kind
of
try
to
solicit
more
feedback,
maybe
see
if
I
can
get
some
a
few
other
companies
as
well
that
promote
it.
Like
hey
feedback,
you
know
and
then,
but
I
think
yeah
we
could
just
say
this
is
ready.
D
A
Yeah,
so
I
think
that's
totally
fair
good
great.
C
A
I
think
the
meeting
actually
is
two
hours,
but
we
are
just
saying
I'm
also
happy
to
close
out
now.
If
we
are
feeling
comfortable
with
that.
D
D
Yeah
yeah
I'll
be
giving
the
credentials
to
everyone,
I'm
talking
with
brian,
about
that
now
so,
okay,
we'll
use
like
one
password,
I
think,
to
share
credentials
like
that.
I
also
need
to
share
make
sure
everyone
has
access
to
the
vs
code
marketplace
credentials
the
vsx
like
the
the
the
ovsx
one
there's
like
so
many
credentials.
I
need
to
share
that's
a
that's
a
side,
maintainer
discussion,
but
so
yeah.
What
is
needed
missing
from
the
toolkit?
So
there's
some
issues
I
created
as
a
starting
point
in
the
roadmap.
D
Yeah,
so
I
just
created
a
few
just
for
someone
to
get
started,
but
I
could
create
more
about
the
like
documenting
different
utilities
that
we
want
to
move
there
in
fact,
and
these
are
specked
out
to
varying
degrees.
D
So
this
one
is
almost
for
laureen.
He
proposed
it
or
someone
that
I
can't
remember
who
I
think
doton
was
talking
about
too
on
a
previous
working
group
called.
D
Yeah
most
of
the
utilities
directory
can
move
to
tool
kit
and
then
there
should
be
more
detail
for
doing
the
others,
but
there's
other
things
too.
Like
async
storage
utility,
like
I'm,
probably
gonna,
build
a
simple
utility
for
index
db
that
we'll
need
for
monaco
graphql
like
we
can't.
I
don't
think
we
can.
I
want
to
use
dexi,
which
is
like
an
indexeddb
sdk
like
library,
that's
really
nice,
but
I
don't
know
if
we
can
use
it
because
of
the
license.
D
It's
apache
gpl2,
but
xc
yeah
like
that.
A
D
Yeah
for
indexeddb,
so
if
you
saw
the
last
call,
we
have
from
monaco
graphql
with
christine
from
airbnb
who
they've
been
doing
a
ton
with
monaco
graphql
building
their
own
in-house
ide.
D
They
are
having
issues
with
live,
schema
editing.
So
the
problem
is
is
when
the
schema
changes
for
graph
for
monaco
graphql,
it
reloads
the
web
worker
every
time.
So
when
you're
editing
a
schema,
it
means
you
rewrite.
The
worker
is
like
being
back
like
rapidly
destroyed
and
recreated.
D
It's
a
lot
of
memory
churn,
so
we're
going
to
instead
have
have
the
schema
synchronize
instead
of
at
the
webworker
creation
at
the
instead,
it
will
just
happen
transparently
through
indexeddb,
and
so
the
graphical
language
service
in
the
graphql
worker
web
worker
will
pick
up
the
new
schema
right
away
and
because
the
web
worker
and
main
process
can
share
indexeddb.
So
that's
going
to
be
fun,
so
I'm
going
to
implement
that,
but
then
that
that
wrapper
opens
up
lots
of
possibilities.
So
having
access
to
indexeddb
also
means
query
collection,
management
or
query.
D
History
can
be
much
longer
right.
Now,
it's
a
it's!
A
user
configurable
limit
people
requested
to
extend
the
query
history,
like
hundreds
in
a
search
and
things
like
that
I'll
bring
up
the
issues
for
that,
but
so
they
they
in
the
the
collection
management
of
course,
as
well
they're
like.
Basically,
we
wanted
to
work
like
postman.
I'm
like
I
don't.
I
don't
know
if
we
can
go
that
far,
but
we
can.
D
It
can
help
with
some
of
those
things,
but
with
that
all
those
things
are
great
for
indexeddb
and
then
also
with
the
ability.
I
can't
remember
the
exact
name
of
the
feature,
but
where
you
can
install
pwas,
then
that
actually,
the
advantage
of
that
is
that
it
actually
isolates
your
indexeddb
and
other
application
storage
from
the
rule
of
just
like
the
random
timeout
destruction
of
the
data
that
you
like
within
xdb.
It's
it's
less
there's
more
capacity,
but
eventually
you
can't
can't
really
control
when
it
will
destroy
that.
D
But
we
could
persist
that
with
indexeddb
and
a
pw,
the
pwa
install
even
better,
so
that
some
more
pwa
features
are
on
the
roadmap
for
graphical
too,
as
well
again,
they
don't
have
to
be
there
right
away,
but
we'll
be
introducing
them.
So,
let's
see,
can
we
it'd
be
cool
to
show
the
tabs
pr
in
the
working
group?
Oh.
B
Yes,
I
don't.
D
I
I
have
do
I
have
it,
I
don't
have
it
set
up,
let's
check
it
out.
Let's
see,
if
I
can,
the
new
this
the
vs
code
pull
request,
github
pull
request.
Extension
is
awesome.
Okay,
yarn
start
graphical,
so
the
deploy
previews
for
forked
branches
are
working
again
as
of
today,
but
not
with
this
pr
because
he
hasn't
made
a
new
commit
yet
well.
I
will
I
will
share
my
screen
in
a
few
seconds
here.
Okay,
let's
run.
A
B
C
A
D
D
Yeah,
basically
very
similar
to
playground.
You
know
extremely
simple
yeah.
C
Yeah,
but
that's
something
that
we
have.
I
think
that
we
even
planned
out
any
design
already
that
can
work.
Nice
amazing.
B
D
Why
I'm
like
you
know
it
looks
great
and
he's
even
doing
the
the
goofy
web,
1.0
or
2.0
3d
effect
to
keep
it.
C
D
D
And
we
can
do
3
and
4.0
as
other
major
changes.
Have
we
don't
have
to
bundle
everything
into
a
waterfall
2.0,
but
the
redesign
I'd
like
to
do
for
2.0
and
I'd
like
to
make
it
so
that
yeah,
it's
obviously
not
like
this,
but
but
we'll
well.
There
will
be
different
ways
to
toggle
between
themes
and
I
think
we
can
do
the
dark
theme.
The
dark
mode
as
a
separate
theme.
Right
as
like
the
example
of
how
a
user
can
implement
a
custom
theme.
Essentially
so
yeah.
D
It
really
just
depends
on
who
steps
up.
I
mean
the
guild
is
really
interested
in
other
company
twitter's,
also
interested
like
and
just
people.
Independent
contributors
are
all
very
interested
in
helping
it's
just
a
matter
of
really.
Someone
just
needs
to
act
as
like
a
community
manager
to
get
everyone
together
and
start
assigning
people
work.
D
To
do
I
mean
it
is
we
had
we
had
five
people
working
on
the
same
pr
and
it
actually
went
really
well
in
2020
in
january,
and
we
still
have
all
of
that
with
you
know
where
we
converted
most
of
the
dock
explorer
components
to
hooks
compo,
I
mean
actually
most
of
the
components,
soaks
components,
the
only
ones
that
were
class
components
still
were
the
main
dock
explorer
component
and
the
main
graphical
component.
But
even
then
we
had
moved
it
almost
all
out
into
contacts
and
hooks
modern.
D
D
Instead
of
trying
to
publish
from
two
branches
like
where
we
had
a
1x
branch
that
we
were
publishing
from
and
2x
that
we
were
developing
on
so
but
yeah,
it
was
very
prolific
and
I
think
we
can
get
back
to
that.
It
was
interrupted
literally
by
the
pandemic,
so
like
everything
it
just
shut
it
all
down.
That's
why
and
and
then.
C
D
Things
happened
like
I
I
at
gatsby.
I
was
that
I
wasn't
able
to
stay
full-time
on
graphical
anymore,
so
I
had
to
move
over
to
focusing
on
other
gatsby,
plugins
and
whatnot
so
yeah,
I
it's
that's.
Yeah
2020
was
really
kind
of
like
we
had
so
much
momentum
going,
but
either
way
yeah.
This
is
great
and
the
the
designs
are
a
whole
great
new
momentum
for
us
and
there's
a
lot
of
people
excited
and
doing
a
lot
of
great
work
so
yeah.
This
is.
A
I
think
we
will
mostly
talk
about
technical
stuff.
You
from
the
design
side.
I
think
all
good
you
can
leave
yeah
enjoy.
C
Literally
the
jungle
in
the
background
here
and
I'm
down
at
the
yoga
deck,
because
this
is
the
only
place
with
internet
right
now,
wow
crazy
yeah
thank
you
was
nice.
That
was
a
nice
chat,
nice
meeting
and
talk
to
you
soon,
hopefully,.
C
A
Yeah
ricky.
Regarding
implementation,
I
had
a
quick
chat
with
dota
from
the
guild,
and
so
I
think
we
can
just
coordinate
with
them
for
the
initial,
like.
A
Ground
foundation,
I
think
that
in
the
beginning,
it's
probably
better
if
just
a
few
people
are
involved
and
then
once
the
foundation
stands
it's
easier
to
like
yeah.
B
D
D
Internationalized
it
in
that
effort
and
we
implemented
a
custom
theming
system,
so
there's
a
great
points
of
reference
there
and
also
there's
a
lot
of
components
that
were
converted
to
hooks,
but
then
because
we
had
to
keep
working
off
the
one,
the
original
1x
branch,
because
we
didn't
have
enough
bandwidth
to
finish
and
also
we
were
trying
to
figure
out
state
management,
because
we
were
running
in
a
ton
of
re-rendering
issues
with
context.
D
But
I
have
different
ideas
for
that
now
and
actually
the
way
things
have
worked
out
with
monaco
graphql
and
the
way
variables
editing
is
handled.
We
don't
even
have
to
worry
about
that.
This,
like
handing
the
state
between
the
editors
like
graphical,
does
now
where,
if
you
notice
it
does
they
get
the
it
like?
D
It
does
all
this
stuff
in
the
actual
like
with
the
actual
component
state,
with
extracting
the
query
ast
and
transforming
it,
and
all
these
things
that
we'll
need
to
still
do
for
to
have
api
parity
for
the
different
event
handlers
but
like
we
actually
don't
need
to
handle
that
internally
in
graphical
anymore,
because
monaco
graphql
handles
it
is
at
a
sub
level.
So,
in
terms
of
you
know,
generating
variables
to
type
parameters
and
things
like
that,
so
either
way
yeah.
D
I
think
it's
that's
a
good
reference
point,
but
just
keep
in
mind.
There's
like
new,
for
example,
new
language
features
added
to
the
doc
explorer
since
the
doc
explorer
was
converted
to
hooks.
So
you
can
use
the
hooks
as
a
reference
point,
but
make
sure
you
you
cross
check
and
say:
oh
well,
now
we're
rendering
argument.
D
Deprecated
arguments
so
deprecated
arguments
is
something
that
was
added
recently
to
the
graphql
spec.
So
there's
there's
like
logic
now
for
that,
but
again
yeah
any
competent
react.
Developer
is
going
to
have
a
lot
of
fun
with
this.
So
and
most
are
I
just
probably
better
than
I
would
be
at
it
so
yeah.
A
A
D
Yeah
and
you
all
just
have
the
freedom
to
as
I'm
in,
like
as
I'm
gonna
go
under
surgery
and
be
in
the
hospital
and
whatnot
just
be
sure,
to
take
initiative
to
review
and
merge
each
other's
work
as
you
see
fit,
you
don't
need
my
final
say
on
anything.
D
D
To
give
their
their
opinion
on
things,
if
you
need
like
the
the
father
of
this
project,
the
the
parent
of
this
project,
please
leaves
your
person
so
he's
your
dude.
D
Oh
and
about
that,
I
haven't
had
time
to
open
the
request
with
the
technical
steering
committee
to
add
a
thing
to
our
readme
about
ukraine.
Yet
it
would
be
great
if
someone
did
we
already,
as
per
the
the
rules
that
are
that
are
dictated
in
the
graphql
working
group.
For
this,
the
existing
message
was
removed
at
least
requests
so
and
so
any
other
messages
can
be
proposed
to
the
technical
steering
committee,
so
just
putting
that
out
there
just
so
it's
on
the
record
for
the
working
group.
D
I
I
started
drafting
an
email
and
getting
chips
finished.
So,
okay,.
A
I
can
I
can
also
kingly
about
it.
Yeah
I
saw
that
I
saw
that
yeah
good
one
question:
you
had
this
session
with
the
moneco
about
the
moneco
plug-in.
What
is
the
best
way
to
get
informed
about
that
or
to
join
those
sessions
in
the
future.
D
That
was
like
kind
of
a
one-off
session
is
like
a
kind
of
breakout
like
committee,
so
to
speak
from
the
graphical
working
group,
we
could
set
up
a
regular
session
for
that
just
for
monaco
graphql
users,
but
it's
in,
I
think
I
accidentally
put
it
in
agendas
instead
of
minutes.
Folder
yeah,
but.
B
A
Just
to
know
how
to
join
such
a
session
because
it's
nice
to
be
able
to
ask
questions.
D
D
I'm
I'm
more
to
be
managed
I'll
make
a
great
contributor.
So,
okay.
A
Okay,
yeah
no,
but
that
is
great.
I
will
coordinate
with
the
guild
as
well
regarding
the
implementation,
because,
as
they
are
now
doing
more
graphical
one
work
that
would
just
make
sure
that
that
is
like
in
sync,
with
the
graphical
toolbox.
A
Dotan
actually
asked
when
I
was
writing
with
them.
If
we
want
to
even
adopt
the
new
design
for
graphical
one,
but
I
think
we
agree
here
that
we
would
rather
keep
it
separate,
because
it's
quite
significantly
different
right
and
a
quite
different
look.
So
I
think
keeping
that
as
a
clean
cut
is
a
it
makes
sense.
Yeah.
D
And
people
have
all
kinds
of
goofy
overrides
and
stuff
that
are.
B
D
Specific
and
I
want
designers
to
feel
like
they
don't
have
to
keep
class
names
intact,
they
don't
they
can
implement
a
whole
different
like
css
and
js
versus
you
know,
css4
variables
that
that's
an
open
question
for
people
to
decide
on
how
they
want
to
implement
that
in
a
custom
theming
system.
So
that's
that's
just
a
totally
open-ended
question
there,
but
I
definitely
want
it
to
be.
Like
yeah
like
like
you're,
saying
a
clean
cut
yeah,
we
can
use
any
approach
we
want,
but
it
will
be
a
different
design.
D
2.0
and
the
era
of
like
goofy
cs
overrides
should
be
over
like
they
should
either
feel
like
clean
css
overrides
or
clean
css
and
js
overrides
like
an
object.
Yeah
ala
theme,
ui
or
whatever
so
yeah
great.
A
Yeah
good,
I
mean
that's
great
and
I
think
the
people
who
will
work
on
it.
I
will
make
sure
that
we
schedule
resources
on
that.
They
can
then
just
see
what
they
prioritize.
On
the
toolkit
side,
we
can
also
just
what
what
is
the
best
channel
to
write
these
things?
Probably
the
graphical
channel
and
discord
yeah.
D
A
Yeah,
I
think
the
graphical
channel
is
good.
There
will
be
general
questions
that
are
a
bit
like
adding
noise
yeah,
but
should
be
fine.
Then
we
can
just
use
that
as
the
channel
to
coordinate
yeah,
perfect.
D
B
D
More
like,
I
think
we
say
something
in
the
readme
like
for
support,
go
to
the
discord
channel,
and
I
think
we
should
instead
say
for
support,
go
to
discussions
and
see
if
there's
like
a
discussion
that
that
does
this
or
that
solves
this
problem.
The
problem
with
that
is
there's
like
resolved
bugs
that
are
issues
and
not
discussions.
So
like
discussions
are
great
for
like
support
questions
bugs
are
great
for
issues.
D
B
D
For
it,
there's
legal
hangouts
but
orto
is
actually
has
the
idea
of
just
rewriting
the
client
in
general
anyways,
just
because
we
we
need
it
to
do
different
things
and
it
would.
It
could
use
a
rewrite
anyways
and
it's
only
like
12
files
of
escogreco
client,
but
when
we
merge
that
in
it
will
impact
like
the
user
experience
and
the
the
kind
of
waypoints,
we
want
to
give
users
and
bug
reporters
and
contributors
so
but
we'll
take
it
all
into
account.
It'll
work.
A
D
Another
major
change
just
lsp
wide
we're
merging
graphql
language
service
interface,
parser,
utils
and
types
into
one
graphical
language
service
package.
All
those
packages
will
be
retired,
they
will
be
deprecated
using
the
npm
deprecate
command
and
everyone
can
just
use
graphql
language
service
and
the
interfaces
are
going
to
to
change
to
the
the
parameters.
Will
change
just
to
make
it
easier
to
make
the
methods
more
customizable
and
extend
the
capability,
add
more
options
and
whatnot.
So
the
ordered
arguments
pattern
is
is
like
not
scaling.
D
Well
is
the
customization
needs
scale?
You
know
ordered
arguments
really
suck
for
that,
because
you're
like
this,
this
this?
No,
no!
No,
no,
then
this
important
thing
I
need
you
know,
and
you
know,
but
yeah.
So
those
are
some
major
there's,
there's
gonna
be
quite
a
some
big
nice
changes
to
the
the
underlying
language
service.
It'll,
make
things
nice
and
easy
and
simple,
though,.
D
D
Yeah
orta
has
been
like
co-maintaining
with
me
quite
a
bit
on
this
so
like.
If
people
are
interested
in
lsp,
they
can
post
in
the
graphql-lsp
channel.
This
is
whether
language
service
or
language
server
lsp
in
general,
so
language
service
is
universal.
It's
used
in
web
and
the
language
server
and
language
server
is
a
little
bit
more
specific,
but
we're
yeah.
D
We
want
to
bring
all
of
that
together
so
for
a
complete
end-to-end,
a
reference
implementation
where
graphicals
the
web
reference
implementation
and
vs
code
graph
go
is
the
main
ide
implementation
so
that
we
use
to
reference
and
make
sure
things,
work,
etc
and
ideally
evolves
with
the
language
features
of
graphical,
and
this
is
another
thing
to
keep
in
mind
developers
if
you
find
any
opportunity
in
your
architecture
to
introduce
envelop,
maybe
sooner
than
later,
with
like
the
language
server
than
with
graphical.
D
But
envelope
is
a
really
great
tool
that
I
think
is
like
the
future
of
adopting
new
graphql
language
features
will
be
with
a
tool
like
envelope
probably
envelope,
and
it's
great
and
people
we.
We
should
find
a
way
to
use
that
in
both
graphical
and
the
language
server,
just
just
adding
that
as
a
note
for
anyone
who's
listening
all
right
cool,
I'm
done.
D
D
It
shouldn't
like
the
the
highest,
the
lsp
changes,
we'll
get
to
will
be
monaco
graphql,
so
so
I'll
be
able
to
make
changes
there,
but
yeah
all
the
the
on
the
react.
Side.
They'll
just
need
to
they'll
just
be
consuming
the
updated
version
of
monaco
graphql.
It
shouldn't
break
anything
for
them.
Anyone
who's
working
on
graphical.
The
editor
can
just
focus
on
react.
D
D
Where
we're
like,
hey
like
for
graphical
utilities,
we
might
actually
end
up
using
graphical
utilities
in
vs
code
graphql,
because
there's
so
many
execution
related
utilities
that
we
need,
like
a
simple
utility
to
build
a
fragment
cache
so
and
like
a
simple
utility
to
add
the
specified
fragments
in
a
query,
string
or
ast
to
that
query.
Things
like
that
those
are
used
by
both
vs
code,
graphql
and
graphical
now.
So
those
are
great
candidates
for
the
graphical
toolkit,
yeah,
okay,.
A
So
that
means
the
changes
is
really
relevant
for
people
implementing
the
new
graphical
is
the
lsp
change.
I
guess
right
then,.
D
D
A
D
So
I
think
he'll
he,
like
anyone
who
wants
to
work
on
graphical
toolkit
will
want
to
talk
to
dhotan
and
folks
of
the
guild
who
have
like
they
already
have
like
a
vision
for
how
they
plan
on
kind
of
de-monolithic
graphical,
because
that's
that's
definitely
an
architectural
vision
is
reducing
complexity
of
more
modern
react
implementation
also
just
reducing
the
cognitive
overhead.
D
You
know,
because,
right
now,
if
people
want
to
open
up
feature
requests
for
graphical-
and
they
like
have
to
open
this-
like
2400
line
component
and
mess
around
with
the
state-
and
I
guess
that's-
that's
not
an
uncommon
pattern,
but
the
more
we
can
reduce
the
complexity
and,
like
business
logic,
built
deeply
within
this
complex
file,
the
better.
But
it's
it's
also
kind
of
a
common
pattern
with
react.
Libraries
that
are
you
know
shared.
D
You
know
reused
components,
they
end
up
with
this
kind
of
pattern
so,
but
I
think
we
got
with
the
graphical
2rc
we
got
it
down
to
about.
D
I
think
900
lines,
the
graphical
that
tsx
component,
so
yeah,
but
again
you
know,
focus
on.
What's
practical,
you
know,
that's
just
like
a
a
dream.
You
know
yeah
yeah
cool,
all
right
well,
have
at
it.
Yes,.
A
I
think
it's
pretty
much
it
for
my
side.
I
think
this
is
super
actionable
now,
thanks
for
providing
all
the
context
here
and
then
yeah,
I
will
just
coordinate
with
with
dotan
and
the
guild
here
as
next
steps
and
then
once
we,
I
can
also,
by
the
way,
create
a
bit
more
like
a
write-up
or
a
plan
or
for
the
graphical
path,
at
least
that
you
could
review
or
something
yeah.
There's.
D
A
road
map
issue,
okay,
that
I
originally
had
and
then
I
deleted
all
of
it
and
pointed
to
the
project,
but
you
could
add
more
to
that
roadmap
like
you
could
see
what
I
had
written
up
for
that
too,
even
because
there
was
a
lot
in
that
roadmap
issue
before
when
I
decided
to
switch
over
so
the
history
for
that
issue
actually
might
have
some
useful.
A
D
D
Yeah
got
me
excited
about
the
new
graphql
projects
and
I
think
I
or
the
new
github
projects
and.
B
D
Yeah,
hopefully
more
though,
and
but
yeah
like
a
summary,
like
a
starting
point
for
the
roadmap,
I
think
yeah,
like
you're
saying,
would
be
great
just
to
the
overall
vision.
What
we
want
to
do
letting
people
know
you
only
need
to
care
about
these
three
workspaces,
the
graphical
graphical
react
and
graphical
toolkit.
D
That's
all
you
need
to
worry
about
if
you
have
an
idea
to
create
a
new
separate
package
for
whatever
reason,
that's
graphical
related,
that's
it.
But
it's
all
react.
You
don't
have
to
worry
about
all
these
other
scary
projects
that
might
look
or
not
scary,
but
just
like
overwhelming
for
some
people,
so
yeah
just
important
to
know
that
yeah,
it's
definitely
scared
away
potential
graphical
contributors
before
they're.
Like
I'm
sorry,
I
can't
help
you
with
this
parser
and
I'm
like
you
know
me
too,
don't
leave
but
yeah
yeah,
so
cool
great.
A
It
from
my
site
and
thanks
a
lot.
A
Women's
day
women's
day
and
great
so
then
this
recording
goes.
I
will
chat
with
ryan
that
we
can
add
it
to
the
agenda
and
then
we
will
kick
this
off.
I'm
excited.
D
It's
totally
possible.
I've
also
told
the
playground
users,
just
as
a
side
note
that
they're
free
to
revive
this
project
if
they
want
and
doton's
linked
up
on
that
too
so
or
like
to
revive
playground
in
its
current
state
and
co-develop
still
so
that's
still
an
option.
I
I
don't
want
to
be
making
any
calls
for
the
community
on
that.
D
Okay,
but
also
I
like,
where
this
is
going
to
so
in
the
graphical
community,
graphical
users
will
like
it
there's
just
going
to
be
these
camps.
I
feel
like
until
eventually
I
don't
know
we'll
see,
so
I
think
once
there's
a
more
modern
graphical
interface
playground.
Users
are
going
to
be
less
like
focused
on
playground
once
there's
parody
and
this
nice
new
interface,
that's
designed
by
julian
yeah,
we'll
have
a
different
yeah.
Some
of
it.