►
From YouTube: GraphiQL Working Group - 2022-04-12
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
B
A
Have
you
been
the
one
in
discord?
No,
no.
B
B
A
C
A
Unfortunately,
it
looks
like
ricky
can't
come:
okay,
okay,
so
ricky
got
corvette
ricky
the
car
like
maintainer.
So
far,
I
would
say,
with
the
most
knowledge
isn't
here,
which
doesn't
mean
that
this
meeting
can't
happen.
Ricky
and
I
talked
quite
a
bit
in
the
last
days
where
things
can
go
and
yeah
it's
a
sub-optimal,
but
we
will
make
it
work.
B
Are
there
usually,
is
there
usually
more
attendance?
Where
is
there
usually
just
like
three
people.
A
The
attendance
is
very,
let's
say,
yeah
variable
we
have
usually
just
ricky
and
me
actually,
and
maybe
one
or
two
more
people-
it's
not
like
the
main
graphql
working
group
where
we
have
20
people
coming.
Although
I
promoted
this
on
twitter
last
week
and
then
the
graphical
discord
channel,
I
don't
know
we
might
have
to
promote
it
even
more
so
yeah.
B
C
C
A
A
So
I
try
to
like
get
this
inspired
by
the
main
graphql
working
groups-
we're
not
there
yet
we
last
year
we
didn't
have
any
graphical
working
group
meetings
and
I
joined
this
process
here.
I
think
three
months
ago,
something
like
that.
So
since
then,
we're
still
in
the
process
of
defining
things
and
and
making
having
a
proper
process
so
bear
with
us
for
our
chaos.
A
A
A
Just
quickly
creating
the
sections.
A
And
is
your
name,
is
it
mofi
or
how
do
I
I
guess
from
your
side?
It
would
be
important
to
talk
about
like
a
plug-in
system
and
how
that
could
tie
into
your
internal,
tooling,
meta
right.
A
Okay,
you
yeah,
you
also
have
this
like
compiler
ast
viewer
tool
right.
I
think
jordan
even
implemented
that
yeah.
He
showed
me
that
link
yeah,
but
so
then
I
will
just
start
with
the
quick
design
update
and
then
we
so
we
all
have
like
the
same
context,
and
I
suggest
we
talk
about
the
plugins
design.
Update
should
just
take
like
five
minutes-
probably
let's
say
10
plugins.
I
will
just
put
20
minutes
now.
B
How
many
people
are
working
on
graphical?
Where
are
y'all
contributors
of
graphical
as
well.
A
Yeah,
I
think
that
the
core
contributors,
probably
currently
like
three
or
something
yeah
yeah,
so
exactly
yeah,
I'm
also
contributing
thomas-
will
work
on
it
full
time
for
quite
a
bit.
We
will
sponsor
that
work
at
cry.
Ask
roxy,
dn
ricky
is
also
working
on
it
and
I
think
there
are
a
few
people
in
the
community
who
are
interested
in
joining
yeah.
A
Okay,
then,
let's
get
started.
Do
you
have
access
to
the
document?
Yes,
good.
This
beautiful
markdown
to
links
feel
free
to
clean
it
up,
but
I
will
I
will
clean
it
up
later.
I
don't
want
to
waste
our
time
with
this.
So
thanks
everyone
for
coming,
let's
do
a
quick
introduction
of
everyone.
I
I
think
it's
clear
with
the
the
the
guidelines
we
all
agree
to
them.
Let's
do
a
quick,
intro
yeah
just
say
our
name
where
we
are
from.
A
Okay,
so
yeah,
I
would
like
to
give
you
a
quick
overview
where
we're
at
with
the
design
the
design.
Just
to
give
you
some
context
here,
I
think
it
was
in
january.
A
I
I
think
I
joined
the
first
working
group
meeting
with
ricky
and
we
said
that
for
so
graphical
that
v1
is
out
for
a
long
time
and
that
we
have
planned
the
v2
and
there
have
been
a
bunch
of
design
proposals,
ideas
out
there,
and
so
we
signed
up
for
creating
the
design
for
the
v2,
because
I
believe,
as
it's
a
ui
that
we're
building
it's,
it
makes
sense
to
do
this
design
driven,
and
so
we
iterated
on
the
design
a
few
times
now
and
the
last
I
think,
was
last
week,
wednesday
or
thursday.
A
A
Okay,
so
let's
share
my
screen
here
we
go:
okay,
yeah,
okay!
Yes,
this
is
me
with
plugin
title.
I
changed
the
font
here
because
I
didn't
have
a
font.
Sorry,
that's
not!
That's,
not
the
the
plan
design.
So
the
idea
is
that
we
have
a
versatile
design
that
supports
all
the
needs
of
the
community.
C
A
C
A
However,
you
probably
still
want
to
influence
the
whole
view,
or
at
least
the
result
pane
for
that.
So
we
now
have
the
first
draft,
the
opinionation
and
the
opinion
here
that
you're
not
able
to
control
the
whole
view
or
replace
it,
but
rather
only
the
whole
wizard
view.
So
far,
the
use
cases
we
saw
it
would
be
sufficient
for
these
use
cases.
For
example,
if
you
have
an
asd
explorer
and
morphe
you
can.
C
A
A
Maybe
I'm
not
finding
it
currently
yeah,
no,
not
seeing
it,
but
I
mean
yeah.
You
can
imagine
if
you
click
on
graphql
editor
here
you
can
choose
between
as
a
drop
down.
Has
a
few
options
in
there
to,
for
example,
see
an
asd
explorer
by
default.
I
don't
necessarily
see
a
shipping
graph
here
and
an
sd
explorer,
but
it's
something
that
people
should
be
able
to
extend.
A
So
that's
that
on
that
level,
then
here
we
have
space
for
icons.
This
will
be
the
prettier
icon.
We
even
talked
about
it
already
that
this
might.
Even
so,
there
has
been
desire
in
the
community
to
move
more
towards
variables,
graphical
variables,
and
this
prettier
here
function
could
even
automatically
turn
inline
arcs
into
variables.
A
That
could
be
part
of
it
could
be
an
opinionated
version
we
put
in
here
variables
and
headers.
We
thought
a
lot
about
it
back
and
forth
how
we
could
change
them,
for
example,
hiding
variables
by
default
and
putting
headers
somewhere
else,
but
after
all,
they
need
to
be
accessible.
People
need
to
see
them,
and
so,
for
now
our
proposal
is
just
to
keep
it
as
it
is
in
the
current
graphical
as
a
button
like
tap
on
yeah
as
a
part
of
the
tab.
A
Here,
that's
mostly
that,
so
again
we
have
options
to
add
icons
here,
which
will
then
perform
potential
actions
on
the
editor
level
instead
of
just
variables
and
headers.
We
can
also
have
more
editor,
tooling
that
we
attach
here
on
the
bottom
and
also
for
the
result.
Tooling.
We
could
have
more
here
that
we
could
have
like
tabs.
A
A
An
advantage
of
having
this
fixed
height
is,
I
mean
you
have
really
big
schemas
at
meta
and
we
could
imagine,
for
example,
a
virtualized
implementation
there,
where
we
don't
need
to
render
everything
that
is
like.
If
you
have
thousands
of
types
and
fields,
we
could
just
show
the
ones
that
are
in
the
view
or
just
whenever
the
ones
in
the
view,
in
order
to
do
a
virtualized
implementation.
Usually
you
need
deterministic
heights
of
the
elements
and
if
we
would
render
arbitrary
markdown
here,
that's
very
hard
to
calculate
it's
possible
but
very
hard.
A
It's
a
nice
side
effect
of
this
design
that
we
could
do
virtualization,
not
saying
we
need
to
do
that
on
day,
one
quite
relevant
also
for
the
big
schemas,
I'm
not
sure
if
we
have
yeah
by
the
way.
This
is,
if
you
want
to
add.
C
A
So
that's
why
we
would
put
the
plus
here
in
the
beginning
and
then
once
you
need
tabs,
you
can
just
go
in
here
and
then
you
just
say
add
tab,
and
then
it
turns
into
this
kind
of
tab
view
here
where
you
have
multiple
tabs
but
as
we
all
know,
graphical
didn't
have
tabs
until
just
I
don't
know
two
weeks
ago
or
something
and
we
all
survived
without
them.
So
we
wanna
make
that
to
that
use
case
of
first
class
citizen.
A
I
excuse
my
quick
jumping
around,
but
I'm
not
finding
what
I'm
looking
for
one
thing
that
we
also
want
to
provide.
We
just
don't
have
it
here
in
the
designs.
A
A
So
again
the
schema
can
have
thousands
of
types
and
fields,
but
maybe
I'm
just
I
just
need
a
little
subset
of
that,
and
that
will
also
help
a
lot
again,
for
example,
for
meta.
If
you
have
these
huge
schemas
and
if
you're
sharing
a
graphical
link
where
there
is
again
thousands
of
types,
but
you
only
have
a
small
query:
by
default,
we
could
have
only.
We
could
only
show
the
selected
fields
and
types
on
the
left
side
to
make.
It
render
much
quicker.
A
Yeah,
that's
mostly
it
and
the
other
thing
just
to
modify.
I'm
not
sure
how
familiar
you
were
with
those
concepts
that
we
came
up
with
here.
You
go
reload
schema
and
show
selected.
Only
there
we
go
reload
schema.
We
didn't
find
a
natural
nice
spot
for
it.
So
we
said
we
would
rather
put
it
on
a
shortcut
and
in
general,
encourage
shortcuts
as
much
as
possible.
A
A
A
They
built
this
graphical
explorer,
okay,
you're
familiar
with
it,
where
they
have
this,
where
you
can
build
up
your
query
here
on
the
site
yeah.
A
So
we
like
that-
and
I
mean
it's
it's
a
tree
structure,
basically
right
and
if
you
want
the
the
docs
could
also
be
a
tree
structure,
and
so
we
looked
at
the
similarity
and
said
how
about
we
merge
them
into
one
mixing
the
two
concerns,
but
as
we
we
want
to
save
space,
and
so,
if
we
already
need
to
show
three
structures,
why
not
show
them
all
in
one
so
yeah?
The
idea
is
that
again
sorry
that
I
messed
up
the
difference
here.
The
idea
is
that
we
have
those
mixed.
A
It's
a
quite
ambitious
goal.
We
will
need
to
just
build
it
and
see
how
much
it
scales
in
particular.
If
you
have
deep
queries,
how
much
does
it
scale
here
on
a
horizontal
level?
That's
really
something
to
to
figure
out
to
be
fair.
This
scale
is
quite
well
for
the
graphical
explorer
from
one
graph,
so
I'm
also
confident
that
we
can
make
it
work,
but
it's
just
something
to
be
aware
of
that.
A
I
I
will
fix
that
sorry
about
that
tool,
tips
and
so
on
nothing,
nothing
special
here,
yeah,
okay,
so
that
was
the
review
all
in
all.
People
are
excited
about.
It
just
need
to
make
sure
that
it
scales,
which
is
exciting
to
have
you
here,
mufi
mufei,
because
we
can
talk
about
these
big
schemas
now
yeah,
okay,
so
that's
that.
A
So
then,
let's
talk
about
the
the
needs
for
for
the
plugins.
Could
you
just
walk
us
through
what
you
have?
What
kind
of
needs
you
have
internally
and
matter
what
tooling
you
build
and
yeah?
What's
the
current
state
for
you.
B
I
can
primarily
only
speak
for
the
relay
team.
I
know
that
meta
has
its
own
team
of
engineers.
B
B
So,
ideally,
we
should
be
able
to
get
plug-in
support
on
the
query.
Editor
query
fragment
editor
side,
so
is
that
something
that
you
can
envision
like
being
able
to
support.
A
Yeah,
so
just
to
understand
is:
does
would
that
look
like
similar
to
the
compiler
explorer
that
you
have
it's
basically.
Do
I
understand
correctly
it's
about
I'm
just
sharing
here
being
able
to
build.
Basically,
this
compiler
explorer,
but
just
with
the
with
the
graphical.
B
It's
more
in
the
document.
We
want
to
be
able
to
write,
relay
syntax
and
transform
that
into
graphic
graphql
syntax.
So
in
the
ideal
case,
we
would
be
able
to
write
graphql
incompatible
syntax
so
that
we
can
experiment
with
things
like
like
named
fragment
spreads,
for
example,
is
an
india
we've
been
trying
to
explore.
B
Alternatively,
if
it
totally
makes
sense
if
you're
not
able
to
support
graphql
incompatible
syntax,
because
I'm
sure
you
have
your
own
parser
and
ast
representation
as
well,
so
if
you're
not
able
to
support
graphql
incompatible,
syntax
and
we'd,
at
least
like
to
get
from
the
plugin
side,
we
like
to
get
a
string
of
what
the
document
is
before
sending
it
to
the
server
so
that
we
can
transform
the
relay
graphql.
A
B
A
B
B
B
B
Oh
so,
for
example,
here
best
friend
is
a
linked
field
of
user.
B
A
I
see
kind
of
stitching
that
together
in
a
way
in
the
relay
case,
wouldn't
that
be
covered
by
a
custom
schema
that
potentially
for
relay.
You
could
have
a
schema
builder
that
takes
the
summer
server
schema
and
then
adds
some
custom
fields.
On
top.
C
B
A
Okay,
okay,
so
you
basically,
yes,
you
said
you
have
client
specific
things
that
you
want
to
pass
out.
Okay,
I'm
just
wondering
I
agree
that
it
would
be
quite
easy
for
us
to
add
a
hook
before
things
are
sent
to
the
server.
I
know
that
the
I
think
existing
graphical
has
a
fetch
override
that
could
solve
it,
not
sure
where
we
have
it.
But
if
you
use
the
react
component
yourself,
then
you
can
override
that
right.
A
That
would
all
really
at
least
solve
that
case
right,
but
we
also
want
you
to
not
have
everything
with
with
the
squiggly
lines
here
that
it's
like
incorrect
right,
so
you
would
need
to
be
able
to,
but
even
that
should
be
covered
because
you
can
provide
your
own
graphical
schema
at
least.
B
Yes,
we'd
also
like
to
be
able
to
on
some
like
that
debounced.
You
know,
edit
of
the
document
we'd
like
to
be
able
to
run
the
relay
compiler
so
that
we
can
give
compiler
diagnostics.
B
So
not
only
during
the
operation
execution
during
documentary
as
well.
A
Okay,
so
that
means
if
we
would
now
look
again
into
the
design
that
could
mean
that,
on
the
response
tab,
we
might
have
different
options
here
that
here
you
could
choose
kind
of
the
rendered
relay
query
or
something,
and
if
I'm
editing
here
on
a
d-bounce,
you
just
want
to
have
a
hook.
So
you
can
rerun
that
so
you
can
rebuild
that
result.
A
Okay,
just
to
understand
the
syntax
that
you
are
you
are
you
want
kind
of
custom
syntax.
Basically,
that
is
not
like
quote
unquote
valid
graphql
part
of
the
query
here.
B
A
Because
what
we
need
to
look
into
is
that
the
moneco
graphql
plugin
has
is
like
a
web
worker
that
is
separate
which
runs
based
on
the
normal
graphql,
and
it
will
be
a
bit
tricky
to
build
a
plug-in
system
that
also
enables
adjusting
that
a
web
worker
it's
possible.
We.
We
would
need
to
think
about
that.
It's
it's
an
interesting
use
case,
but
I
mean
we
just
need
to
find
a
way
to
override
it,
somehow
not
yet
sure
how
we
would
do
that.
I
I
need
to
look
a
bit
into.
A
We
need
to
look
into
the
moneco
graphql
api,
yeah,
okay,
interesting.
B
A
A
So
the
the
the
part
where
we
changed
the
query
before
it's
sent
to
the
server
and
where
you
adjust
the
result
before
it's
shown
in
the
ui.
A
A
B
A
Graphical,
so
that
means
we,
it's
only
about
only
about
giving
you
the
right
hooks
where
you
could
potentially
tell
the
graphical
language
that
was
used
in
relay
and
and
graphical
use.
This
as
the
pass
function
use
this
as
whatever
okay,
it's
quite
an
advanced
use
case,
but,
to
be
honest,
makes
total
sense,
and
I
mean
we
also
wanna.
This
will
always
exist
that
there
are
people
who
wanna
push
the
boundaries
of
graphql,
which
is
important
anyway,
and
we
also
need
to
kind
of
keep
that
in
mind.
A
Like
graphql
is
never
in
this
and
finished
state.
There
will
always
be
a
new
stuff
that
we're
working
on.
So
I
think,
that's
still
quite
important,
okay
and
should
just
to
understand
at
mata.
Do
you
use
the
ordinary
graphical
inside
that
is
like
published
on
npm,
or
is
it
a
fork
or
how
is
that.
A
Okay,
okay,
okay,
makes
sense
good
yeah,
so,
to
summarize,
most
important
part
is
really
being
able
to
manipulate
the
request
and
the
response
basically
and
then
optimally,
even
your
own
validation
and
passing
that
would
even
be
integrated
into
graphical
so
that
the
inline
hints
tooltips.
All
of
that
would
work.
I
can
tell
you
that
sounds
a
bit
ambitious.
Let's
see
at
least
that
we
it's
not
a
big
error
and
it's
like
succeeding
and
passing.
That
would
be
good,
yeah,
okay,.
B
The
easiest
case
would
be
for
us
to
just
get
a
string
of
like
the
the
document
string,
but
if
you
give
us
an
ast,
we
can
parse
that
back
to
a
string
and
run.
A
Yeah,
we
will
probably
have
both
and
in
this
fetch
api
we
will
give
it
to
you,
because
we
will
need
to
pass
this
anyway,
the
ast.
Here
again,
I
need
to
see
how
that
ties
into
the
monaco
plugin,
but
I
know
that
in
the
current
graphical
we're
doing
exactly
what
you
talked
about
earlier,
having
a
d-bounce
and
then
we're
just
rebuilding
the
the
asd
in
the
background,
for
example,
also
for
our
tap
name
extraction
here,
where
is
it
anyway?
B
B
That
we
have
to
stitch
together,
I
think,
on
the
scale
of
tens
of
documents,
because
our
files
actually
can't
can't
get
that
large.
B
A
Nice
awesome
well
yeah.
This
is
this
is
awesome,
so
yeah,
then
I'm
happy
that
we
have
this
use
case
captured
here
and
we
will
make
sure
to
support
it
as
well
as
we
can.
B
A
We
don't
have
that
defined
yet,
but
I
would
basically
just
naively
say
that
you
have
a
bunch
of
props
for
the
main
graphical
component,
where
you
can
provide
your
definitions
of
the
the
icon.
You
basically
just
pass
in
a
certain
interface
right
that
we
define
a
render,
render
function
for
the
plug-in,
pane
and
icon
and
so
on.
A
It
really
depends
on
our
state
management
in
the
new
implementation.
I
I
used
to
implement
the
the
graphql
playground
and
there
we
used
redux
with
reselector.
What
was
the
name
and
there
we
only
re-rendered
if
data
dependencies
changed.
B
We
don't
have
strong
requirements,
we'd
like
to
show
an
ast
explorer,
for
example,
in
the
plug-in,
and
that
would
need
to
reflect
the
state
of
the
editor
on
a
d-bounce.
So
really
the
results
of
our
compilation.
A
Okay,
I
mean
you
are
controlling
the
plugin,
the
the
rendering.
So
if
you
change
something,
your
component
should
just
normally
be
rendered
right
with
hooks,
if
you
have
any
hooks
in
there
whatever.
I
think
that
should
be
fine.
B
A
I
think
that
yes,
and
so
the
thing
is
that
we
it's
not
the
first
thing
we
would
build
for
the
let's
say:
if
our
first
release,
I
don't
think
we
would
build
that.
The
first
goal
is
to
have
basically
feature
parity
plus
the
base
design
that
we
came
up
with
here,
including
like
the
ambitious
explorer
here,
but
I
can
definitely
see
that
step
by
step,
adding
more
functionality
there
do
you
have
a
use
case
for
that.
C
C
B
A
I
also
think
that
the
long-term
goal
would
be
to
have
a
plug-in
system
that
allows
community
plug-ins
that
are
awesome
and
can
be
shared.
I
mean
one
day
using
like
a
marketplace
and
be
becoming
the
vs
code
of
graphql,
but
step
by
step,
getting
there
so
yeah
that
would
you
could
build
something
like
that.
Yeah.
C
A
Okay
yeah,
so
we
will
actually
plan
the
implementation.
Now
you
can
stick
around
more
fair,
but
it's
also
fine.
If
you
want
to
leave
yeah
okay,
so.
A
There
are
many
parts
to
implement
this
and
I
will
just
share
with
the
the
discussions
we
had
so
far
and
then
we
can
just
discuss
what
makes
sense
to
us.
After
all,
I
think,
thomas,
you
will
actually
do
a
majority
of
the
work,
so
you
can
decide
in
like
the
actual
order.
I
don't
care
too
much
about
so
there
are
a
few.
There
are
a
bunch
of
things
here.
A
First
of
all,
this
is
quite
a
different
design
and
different
tool
than
what
we
had
so
far,
and
I
could
imagine
this
would
be
a
full-time
job
for
a
few
weeks,
depending
on
how
crazy
you
go,
and
we
also
don't
want
to
block
this
like
too
long
and
then
have
this
big
bang
really
so
both
ricky
and
lee
encouraged
us
strongly
to
do
a
step-and-step
approach,
and
I
agree
with
that.
A
To
give
some
context,
there
has
been
work
on
the
graphical
hooks
based
implementation
already
a
while
ago.
They
called
it.
I
will
quickly
show
you
in
my
screen.
They
had
a
graphical
two
rfc
context,
so
they
were
using
a
context-based
approach
for
for
state,
and
so
they
were
also
switching
to
theme.
Ui.
A
There
are
a
bunch
of
things
that
we
need
to
take
into
account.
One
is
obviously
long
term
want
to
go
to
monaco.
We
want
to
have
a
theming
support
here
that
that
works
for
for
our
users,
mostly
because
what
we
like,
which,
which
css
library
we
use-
I'm
not
that
concerned
it's
really.
How
can
people
customize
this?
A
I
talked
about
it
with
ricky
and
ricky,
recommends
us
to
do
as
much
with
css
variables
as
possible,
just
because
they're
the
most
the
least
opinionated
tool
out
there.
However,
we
want
to
support
them.
I
think
css
variables
doesn't
really
dictate
the
concrete
framework
we
would
use.
A
We
talked
about
something
like
a
radix
ui
ricky
looked
into
that,
but
also
potentially
stitches
for
yeah
beautiful
for
the
for
the
actual
implementation.
A
What
matters
is
that
it's
easy
to
extend
from
outside
and
so
from
this
code
base
here
in
this
folder
ricky
does
not
recommend
us
to
just
release
this
code
here,
but
just
to
use
it
as
a
reference
in
our
main
implementation
of
graphical.
A
What
we
can
do,
we
can
step
by
step,
move
components
over
and
modernize
them
and,
as
you
see,
they're
still
using
the
old
react
api
and
just
moving
them
over
to
hook.
Step
by
step
is
already
a
great
approach
yeah.
So
I
suggest
the
following,
and
I
would
would
like
to
hear
your
opinions
around
that,
especially
thomas,
that
we
are
moving.
A
The
current
code
mirror
based
implementation
as
much
as
possible
to
the
new
design
first
and
release
that
so
with
that
we
are
already
able
to
provide
the
community
value,
even
though
it's
on
v1,
maybe
not
everyone,
will
switch
to
v2
and
it's
a
good
step
forward
towards
our
the
like
the
end
state.
What
we
saw,
what
we
see
in
figma
is
like
the
end
stage.
Then
getting
there
will
take
a
bit
of
work.
A
I
still
need
to
talk
to
you,
julian
our
designer
how
we
can
take
the
current
docs
explorer
in
graphical
and
still
modernize
it
without
completely
rethinking
everything,
and
there
can
be
an
intermediate
step.
So
first
get
the
current
design
and
v1
release
it.
Next
step
would
be
already
replaced
monecco
and
the
monecaro
code.
Monaco
replacement
is
a
justification
for
v2.
A
The
new
design
itself
is
not
necessarily
because
it
can
still
be
fully
compatible,
but
the
moneco
replacement
is
definitely
v2
worthy
because
it
would
be
a
breaking
change.
People
might
need
introduce
a
web
worker
and
so
on
for
that
to
work
properly,
and
then
that
could
still
be
a
the
old
stock
explorer.
Already
all
new
design
moneco
release
that
one.
A
A
Okay,
thomas
gets
a
call,
I
will
just
give
thomas
a
minute
or
more
faye.
Does
that
make
sense
to
you,
even
though
you're
not
necessarily
implementing
it,
unless
you
have
time
by
the
way,
if
you
have
time
we're
always
welcoming
some
contributions,.
C
C
B
C
B
Curious,
I
guess,
since
thomas
is
not
here,
I'm
mostly
a
friend
and
new,
what's
the,
why
are
we
switching
to
monaco?
What
are
problems
with
code
mirror
we're
experiencing.
A
Yeah,
so
the
interesting
thing
with
monaco
is
first
of
all,
there
is
a
big
like
the
most
advanced
experience
is
currently
we
haven't
vs
called
and
and
a
lot
of
efforts
that
go
into
a
monaco
graphql
effort.
They
will
just
benefit
both
vs
code
and
and
the
front
end
part
here,
plus
the
so
called
mirror
is
way
more,
let's
say
primitive,
so
in
code
mirror
you
get
a
hook
where
you
can
say.
A
Okay,
someone
did
made
you
control
space
to
open
the
tooltip,
but
you
need
to
render
the
tooltip
you
need
to
calculate
it.
You
need
to
put
in
your
own
language
server
monaco
as
a
whole
system
runs.
It
does
that,
for
you,
that's
the
advantage
of
monaco,
it's
more
heavyweight
as
well,
but
you
just
you,
have
a
lot
of
editor-specific
things
that
you
would
need
to
re-implement
in
code
mero
that
are
already
present
in
monaco.
A
For
example,
you
have
these
collapse
that
you
can
like
press
the
carrot
symbol,
and
if
you
have
a
block
that
you
can
collapse
that
all
that
stuff
is
there
in
monaco,
we
don't
need
to
build
it
anymore.
So,
that's
why
the
monaco
is
probably
a
good
idea
to
move
there.
A
C
A
I
miss
yeah
morphe
was
just
asking
about
difference
or
why
we
are
interested
in
using
monaco
over
cod
mirror,
and
I
just
gave
a
quick
overview
there.
So
I
will
quickly
repeat
thomas
just
that
you
are
getting
back
into
the
zone.
Sorry,
the
we
have
the
I.
A
I
see
my
proposal
moving
as
much
as
possible
of
the
current
graphical
over
the
to
the
new
design,
like
kind
of
an
in-between
state
release
that
then
move
over
to
monaco
and
modernize
components,
but
with
still
the
old
docker
explorer
release
that
and
then
do
the
newer
dark
explorer
as
the
last
step,
basically
so
yeah.
What?
What
are
your
thoughts
around?
That.
C
I
like
it
in
general.
I
think
it
makes
sense
to
try
to
like
do
as
much
as
possible
without
or
like
and
and
see
where
are
the
actual
braking
changes
gonna
be
once
we
switch
or
once
we
wanna
do
a
version
two.
C
So
something
like
modernizing
the
react
code
and
implementing
the
new
design
at
least
the
parts
of
it.
The
general
theme
stuff
like
that
should
definitely
be
possible
within
the
bounds
of
the
current
v1.
C
I
think
the
docs
explorer
is
not
really
super
sophisticated
in
the
current
version,
so
yeah
just
putting
this
in
some
new
fonts,
some
new
colors
probably
wouldn't
be
like
too
much
overhead
like
because
it's
that
that's
the
only
thing
that
you're
gonna
throw
away
afterwards
when
you
build
a
new
dog
sister,
but
I
think
the
overhead
is
it's
not
too
much
yeah.
A
Okay,
awesome
again,
this
was
also
highly
the
recommendation
of
the
byron
that
we
don't
do
the
big
bang
and
I
mean
what
happened
in
the
last
time
we
had
this
branch
was
this
react.
16
branch
never
actually
saw
the
light
of
the
world.
A
A
But
maybe
the
easiest
is
really
just
that
people
do
css
variables
and
we
just
document
that
well
yeah
on
the
new
styling.
I
know
that
ricky
played
around
in
the
last
days
with
radix
and
and
stitches,
and
in
my
understanding
you
would
be
able
to
do
stitches
with
css
variables,
but
that
is
something
to
to
figure
out.
C
Yeah
so
at
least
from
the
so
I
keep
it
as
simple
as
possible
would
be
my
preferred
option.
So
I
actually
see
first
of
all,
css
variables
for
theming
makes
a
lot
of
sense.
I
guess
it's.
A
C
Supported
in
all
major
browsers,
so
probably
the
simplest
way
to
just
use
the
built-in
method
for
theming
yeah,
that's
built
into
the
browser,
then
I'm
not
sure
how
sophisticated
we
should
get
in
terms
of
using
styling
libraries.
I
also
don't
know
how
or
if
something
like
radix
ui.
I
never
had
a
closer
look
at
it,
but
I'm
not
sure
if
we
really
need
it
in
terms
of
the
the
components
that
we
that
we
use-
okay,
maybe
yeah,
we
do
have
some
drop
downs
and
stuff
like.
A
C
Like
that
in
there
that
would
be
nice
to
have
it
also
like
accessible
and
to
not
care,
and
we
need
to
re-implement
or
reinvent
the
wheel
there,
so
it
could
be,
it
could
be
yeah
and,
as
I
I
know,
I
looked
into
relation
in
particular,
so
can't
have
a
great
opinion
on
that
yeah.
C
Apart
from
that,
I
don't
know
if
we
need
to
go
for
something
like
stitches
or
if
playing
css
or
maybe
css
modules
wouldn't
be
enough,
because
I
think
that's
like
the
most
simple
thing
and
also
for
thinking
about
future
contributors,
it's
probably
easier
to
yeah,
if
it's
just
plain
css,
without
so
basically
being
able
to
contribute
without
having
to
learn
a
qcss
framework.
A
Yes,
so
I'm
just
taking
notes
here
in
my
understanding,
you
wouldn't
even
need
stitches
to
do
the
the
css
variables
right.
We
would
just
change
our
css
file.
It's
a
native
css
feature
right,
okay,
so
then
I
think
it's
totally
fine
to
keep
the
css
modules
that
we
have.
Currently
that's
like
this
exact
same
distribution
of
module
of
of
css.
A
Everyone
uses
that
already
as
soon
as
we
go
with
something
like
stitches,
we
need
to
see
okay,
what's
the
build
stab
and
what's
the
output,
how
do
people
include
the
css
and
so
on?
Yeah?
I
think
I'm
totally
fine
with
that.
It's
also
very
accessible,
because
people
can
just
see
one
file.
They
can
just
go
in
there
for
their
own
customization
on
top
of
css
variables.
A
So
that
means
the
first
step
could
really
be
implement
a
new
design
where
we
have
an
intermediate
dock
explorer
design.
I
will
talk
to
julian
about
that.
Just
keep
the
existing
existing
css
solution
and
just
introduce
css
variables
for
the
theming,
so
that
we
are
and
then
basically
implement
the
dark
and
light
theme
for
that,
and
that's
it
for
dark
and
light
theme.
We
might
need
to
introduce
a
theme
switch
so
that.
A
C
A
Nice,
so
okay,
so
that
means
just
when
the
decisions
made.
We
have
the
following
steps:
implement
new
design
with
existing
codeplace,
introduce
css
variables
for
dimming,
keep
existing
css
approach,
so
that's
kind
of
step.
One
then
maybe.
C
Could
go
through
component
by
component
and
like
step
by
step
until
we
modernized,
we
went
through
all
components,
have
a
new
design
for
all
of
them
and
also
have
a
modern
react
version
for
it.
A
A
A
A
A
And
also
for
the
ayah
for
the
weed
example,
yeah
yeah
I
mean
we
can
keep
that
structure
for
now
and
then
step
by
step,
it's
something
to
align
on
with
ricky.
We
can
talk
with
ricky
about
this
okay,
so
we
have
that
step-by-step
component
by
component
good.
So
then
that's
the
first
release.
A
A
And
what
we
can
also
do
for
the
v2
release
introduce
plug-in
hooks.
They
don't
necessarily
need
to
directly
be
there,
for
the
v1
we
can
see
could
also
be
an
in-between
step
doesn't
need
to
be
coupled.
A
I
will
just
say,
potentially
in
between
into
these
plug-in
hooks
yeah,
that
we
just
talked
about
at
least
the
hooks
for
the
fetch,
which
already
covers
most
of
the
needs
of
the
relay
team
and
yeah.
A
To
be
fair,
it's
maybe
good
to
come
to
do
that
during
the
monecco,
because
with
monaco
things
will
change
quite
significantly
and
I
don't
want
to
first
give
people
hooks
and
plug-ins,
and
then
we
do
a
week
later
we
want
echo
and
like
oops,
we
need
to
remove
them
or
something
that
is
at
least
something
the
monaco
should
be
part
of
the
context
and
that
we
need
to
make
a
good
decision
there.
C
Something
I
just
remembered,
I
think
there
is
like
this.
How
is
it
called
a
compound
component
pattern
currently,
where
you
can,
if
you
use
the
react
version,
if
you
run
the
the
graphical
component,
then
you
can
render
some
of
its
parts
as
child
components,
which
I
remember
slightly
some
comment
of.
We
want
to
defecate.
C
This,
I
can't
remember,
would
be
good
if
ricky
was
here,
but
maybe
in
general,
something
for
the
first
release,
also
to
spot
some
deprecations
and
at
warnings
that
this
will
no
longer
work
for
v2,
basically
giving
all
users
a
chance
to
have
a
version
that
warns
them
about
everything
that
will
break
before
they
actually
upgrade
to
ub2.
A
I
think
this
is
a
great
plan,
so
I
can
write
this
up
in
a
github
issue.
A
The
plan
that
we
have
here
we'll
send
that
over
to
ricky
as
well
and
share
that
with
the
rest
and
the
graphical
discord,
and
then
we
can
get
started
on
this.
Probably
this
week
I
would
say,
can
just
be
part
of
our
sprint
already
depressing.
The
end
sprint
big
thing
all
right
and
the
other
task
obviously
is
mapping
the
issues
here
and
doing
issue
triaging.
A
We
don't
need
to
do
that
in
this
call
here,
but
it's
probably
good
to
do
that
together
either
the
two
of
us,
or
together
with
ricky,
which
is
triaging
like
cleaning
up
the
existing
issues
and
also
making
sure
that
these
steps
that
we
have
here
are
documented
in
issues
and
then
we
can
just
post
this
plan
here
and
get
feedback
from
the
community.
I'm
sure
we
missed
something
and
we
there
for
sure
more
steps
than
just
this
around
like
documentation,
for
example,.