►
From YouTube: Source Editor extension’s architecture
Description
The group discussion about the current and future architecture for the extensions of Source Editor.
A
Computer,
hello,
everyone.
We
are
here
as
editor
group
to
discuss
the
extensions
for
the
editors
we're
working
with
at
the
moment.
We
have
two
main
editors
in
under
our
group's
umbrella,
that
is,
source
editor
and
content
editor,
and
we
are
like.
The
purpose
of
this
meeting
is
to
discuss
the
extensions
for
this
for
both
of
these
editors
and
to
figure
out
whether
we
can
somehow
make
the
universal
extensions
that
would
work
in
both
editors
by
any
chance.
A
A
A
I
hope
that
enrique
and
himanshu
will
make
a
deep
dive
for
about
for
the
combinator
pretty
soon
as
well,
but
the
the
main
sort
of
the
main
trigger
for
this
meeting
was
that
we
have
a
long,
belated
long-related
task,
slash
in
source
editor,
where
the
extensions
for
the
source
editor,
even
though
they
do
work,
they
work.
Fine.
A
The
architecture
of
the
whole
extensions
mechanism
is
not
very
optimal
and
I
can
just
give
an
intro
on
how
it
is
done
in
source
editor
now,
and
what
is
the
plan
for
that?
But,
after
that,
we
I.
I
would
really
like
to
to
hear
how
the
things
are
done
in
the
content
editor
and
to
know
how
the
tip
top
extensions
actually
cope
with
them
with
with
with
the
same
problems.
A
B
A
A
A
Got
it
so
right,
editor
extensions
architecture
is
the
is
the
title
sounds
wonderful,
so
yes,
I
should
have
done
that
prior
to
the
meeting,
but
okay,
let's
let
me
just
share
my
my
screen
for
a
second
and
just
give
a
very,
very
brief
intro
to
how
the
things
actually
work
in
source
editor.
At
the
moment.
A
A
A
So
there
are
several
paradigms
in
source
editor,
so
there
is
the
global
editor.
This
is
the
object
that
is
created
with
the
help
of
monaco
that
drives
different
instances
of
the
editor.
What
is
instance
instance
is
a
separate
entity
of
a
source
editor.
You
can
think
about
this
as
like,
for
example,
when
you
go
to
edit
a
multi-file
snippet,
you
will
see
potentially
up
to
10
different
ui
elements
representing
10
different
editors.
A
All
of
those
are
our
instances
so
10
instances,
however,
they
are
managed
by
one
global
editor
object.
Why
this
this
architecture?
Because
this
way
we
can
apply
some
properties
to
all
of
the
instances
on
the
page
right
away
through
the
global
editor
object,
so
global
editor,
several
instances
that
can
be
managed,
but
we
said
that
every
that
our
core
source
editor
is
very
slim.
So
every
instance
is
a
slim
wrapper
around
monaco
as
well.
The
full
potential
of
the
source
header
is
revealed
when
we
apply
extensions.
A
So
what
is
an
extension
extension
is
the
is
the
code.
It
can
be
a
function,
it
can
be
class,
it
can
be
just
inline
object
that
provides
additional
functionality
to
to
an
instance,
contrary
to
the
core
of
the
source.
Editor
that
is
managed
by
our
group.
Extensions
can
be
managed
by
anybody
owned
by
anybody
and
can
be
shared
between
different
instances
in
different
in
different
parts
of
the
project.
A
So
what
is
what
is
extension?
As
I
said
yeah
it
can
be
just
regular
class.
It
also
can
extend
other
extensions.
So,
for
example,
you
create
extension
based
on
another
extension.
If
you
need
some
to
tweak
something,
for
example,
or
to
to
to
tweak
a
lot,
it
can
be
function
and
it
can
be
any
inline
object,
providing
properties,
functions
and
so
on.
So
all
the
functionality
that
you
want
your
instance
to
be
extended
with.
A
Extension
can
be,
extension
can
be
applied,
or
extension
is
applied
on
per
instance
level,
but
you
can
also
apply
the
same
extension
to
all
the
instances
on
the
page
through
the
global
editor
object.
Should
that
should
there
be
a
need
for
that?
So
how
does
this
work?
The
current
architecture
of
extensions
is
using
the
mixing
pattern
and,
yes,
we
can
talk
about
bad
sides
of
this
of
this
approach
later,
but
at
the
moment
it
is
the
mixing
pattern.
A
So,
technically
what
when
we
say
this
instance
has
to
apply
this
extension,
what
it?
What
happens
is
that
extension
literally
extends
the
instance
by
getting
straight
into
the
instance.
So
it's
it
just
works
it.
It's
fine.
It
works
it's
real
to
implement
it's
easy
to
maintain.
However.
Obviously
there
are,
there
are
clear
side
effects
of
this
approach.
So,
first
of
all,
we
are
mutating
the
incidence
well,
of
course,
this.
A
This
is
not
really
nice
thing,
and
since
we
are
talking
about
having
instance,
as
the
slim
wrapper
around
monaco,
obviously
this
this
is
not
a
very
good
thing
and
also
the
one
of
the
main
problems
that
we're
trying
to
solve.
With
the
extensions
and
source
editor
now,
one
cannot
unuse
an
extension
since
we're
using
the
mixing
pattern.
A
A
A
So,
for
example,
when
one
requests
a
prop
or
a
method
on
the
instance,
the
proxy
taps
this
this
call,
but
in
this
particular
case
the
proxy
will
tap
the
get
method
and
we'll
check
if
the
requested
prop
or
function
can
be
found
on
the
extension
level,
the
prop
or
method
from
extension
is
returned.
If
the
prop
or
extension
isn't
found,
we
return
the
method
or
prop
from
the
original
instance,
pretty
pretty
simple,
pretty
working
pretty
good.
A
A
However,
there
are
issues
with
revocability
of
the
extension
still
so
proxies
allow
one
to
create
a
revocable
version
of
it
right.
So
technically
one
can
call
proxy
dot
revocable
and
then
we
get
both
proxy
and
revocable
reference
so
or
revocable
method
to
revoke
that
particular
proxy,
and
this
works.
This
works
wonderful
in
this
scenario,
where
we
have
only
one
extension
applied.
A
A
A
A
A
How
this
is
supposed
to
work?
Where
is
it
chromebook
tools?
Brave
browser?
Okay?
So
if
we
go
to
the
do
you
see
my
screen
now
cool?
So
if
we
go
to
this
proxy
pattern,
so
you
can
see
that
it's
just
pure
javascript
and
there
are
some
the
tasks
here.
I
didn't
use
any
just
or
anything
like
this.
I
just
wanted
the
very
fast
response
to
my
changes,
so
I
have
this
like
manually,
created
tests
with
visual
clues.
A
A
A
So
and
then
you
can
you
have
all
this
output
with
green
check
marks,
so
all
the
tasks
do
pass
here,
I'm
I'm
actually
using
this
run
gs
application.
That
is
super
handy
when
one
tries
to
things
like
this
and
like
just
very
quickly
test
things
with
pure
javascript
without
any
without
any
dependencies.
A
So
looking
at
this
snippet
technically,
this
is
this-
is
all
it
takes
to
implement
the
proxy
pattern
for
the
extensions,
however,
as
I
said,
the
problem
with
proxy
pattern
is
that
with
a
pure
proxy
pattern,
the
way
it
is
implemented
in
this
snippet
is
that
we
still
cannot
like.
There
is
one
task
about
revoking
the:
where
is
it
the
independent
extension
extents.
B
A
A
A
A
A
I'm
working
on
another
pattern
at
the
moment.
That
is
way
too
raw
to
to
demonstrate.
Unfortunately,
but
I
came
to
a
conclusion
that
we
still
have
to
have
some
sort
of
registry
for
extensions
and
for
methods
where
we
map
different
methods
and
extensions
to
be
able
to
know
what
particular
methods
we
have
to
disable.
It
will
still
be
based
on
the
proxy
pattern
but
proxy
not
on
when
we
apply
apply
extension
but
proxy
when
we
request
any
information
from
the
instance.
A
B
A
I'm
I'm
very
sorry
paul.
I
I
think
the
the
question
is
a
bit
a
bit
about
different,
like
I
might.
I
might
have
expressed
myself
wrong,
but
extensions
do
not
need
to
extend
monaco's
api.
No
extensions
will
have
access
to
monaco
api
should
they
need,
but
they
do
not.
They
are
not
coupled
with
the
moniker
api
by
any
means,
so
you
can
create-
and
we
have
a
couple
of
extensions
that
are
that
do
not
use
monica
api
at
all.
A
A
D
But
why
are
we
we
are
using
mixings,
so
we
are
augmenting
the
the
api
of
an
object
so
which
which
object
is
the
one
that
we
are
augmenting
and
we
are
using.
We
are
trying
to
use
another
way
of
decorating
an
object.
That
is
a
proxy
that
has
the
same
purpose.
So
what
what
I
mean?
My
question
is:
why
do
we
need
to
augment
the
api
of?
D
Why
don't
we
invert
that
dependencies
in
that
dependency
relationship
and
we
say:
hey,
let's
take
this
action
that
is
encapsulated
in
an
extension
that
it
says
like
I
was
exploring
the
source
code
of
the
of
the
markdown
extension
that
for
the
source
editor,
and
I
see
that
there
are
actions
like.
Let
me
see
like
get
selected
text,
so
why
don't
we
just
take
that
get
selected
text
method
and
we
just
accept
the
the
instance
like
the
the
monaco
instance
and
perform
an
action
on
it
like
that.
A
Can
we
definitely
can
pass
past
instance?
And
there
is
that's-
that's
the
problem
of
the
mixing
pattern
at
the
moment
that
actually,
when
we
start
when
we
start
using
an
extension,
we
do
pass
the
instance
and
if
you
check
check
the
constructor
of
the
of
the
extensions
there,
we
are
referencing
to
the
instance
as
the
instance,
because
it
is
passed
to
the
invocation
of
of
of
an
extension.
A
A
So
that's,
that's
the
only
difference
right,
but
the
this
doesn't
make
the
the
extension
any
any
more
universal,
because
if
I'm
calling
a
monaco
method
on
the
instance,
this
method
will
guarantee
not
to
exist
in
t
tab
right.
So
we
will
have
to
find
to
go
through
the
path
of
some
adapters
that
sort
of
adapt
our
extensions
to
either
to
either
tip
tap
or
to
monaco.
D
No
just
like,
following
up
on
on
the
on
the
proxy
pro
like
more
than
like
what
I
my
my
thoughts,
is
not
focused
on
like
having
some
in
interrupt
with
monaco.
Sorry
with
dick
with
the
contaminator,
it's
more
like
we
are
using
like
we
have
a
current
right
now
and
it's
like
we
cannot
dispose
the
extensions
from
monaco
instances.
So
I
I
like
to
find
a
way
of
solving
that
problem
like
why
we
are
using
process.
D
C
It
may
be
the
same,
but
if
you're
not
actually
mixing
it
in
to
the
implementation,
then
that
removes
that
coupling.
That
seemed
to
be
at
the
crux
of
the
both
of
the
mixin
and
the
the
proxy
pattern,
because
you,
you
seem
to
talk
about
not
being
able
to
unregister
them,
but
if
it
is
just
a
dependency
inversion
and
it's
receiving
an
instance,
you
can
just
destroy
that.
C
A
I'm
missing
something:
I'm
I'm
not
sure.
I
actually
understand
the
the
usage
then
of
of
an
extension.
So
if
we
pass
an
instance
to
an
extension
and
then
we
operate
within
instance,
objects
right
so
it
might
be,
might
be
monochrome
instance,
it
might
be
tip
tap.
Instance
doesn't
matter
right,
so
we
operate
on
the
instance
in
all
of
the
methods
of
an
extension.
A
However,
how
do
we
use
this
outside
of
the
extension,
so
I
have
a
code.
I
I
say:
okay
create
me
new
instance
of
in
this
particular
case
of
source
setting.
So
I
have
the
source,
editor
instance,
then
I
say:
okay,
I
want
this
extension,
so
I
by
using
something
at
the
moment
it's
instance
dot
use
method.
On
the
instance
I
say:
okay
use
this
extension.
A
B
You
had
mentioned
an
instance
being
a
very
light
wrapping
around
monaco,
and
so
that
way
we
can
conveniently
use
monaco's
api
whenever
we
need
to
and-
and
I
think
as
long
as
we're
thinking
about
this
from
the
convenience
perspective,
we're
gonna
we're
gonna
end
up
in
really
tricky
situations.
We
don't
want
the
client
of
our
extension,
or
instance
to
do
whatever
they
want,
because
that
increases
coupling
and
that's
gonna
increase
coupling
to
monaco's
api
and
we
want.
B
I,
I
would,
I
think,
with
extensions
currently
there's
a
couple
of
things
that
are
happening
and
one
which
proxy
solves
a
bit,
which
is
really
exciting,
is
that
right
now
instances
reference
extensions
and
extensions
reference,
the
instances
that
they
were
created.
There's
this
like
circular
dependency,
they
all
get
mixed
in
and
hopefully
nothing
collides.
But
then
two
is
later
on
in
the
code
that
that,
because
of
that
mix-in,
my
extension
actually
changed.
B
My
a
my
api
and
later
on
in
the
code,
I
could
be
coupled
to
something
that
conditionally
happened
beforehand
and
that's
a
really
scary
thing
to
do,
and
I
think
what
other
extension
frameworks
have
done
is
we
need
to
expose
a
finite
set
of
hooks
that
our
extension
can
hook
into
and
extend
behavior,
and
we
can
use
events
to
do
this.
But
limiting
the
client's
api
is
a
good
thing.
B
A
A
The
events
we
in
order
to
listen
to
the
events
we
either
have
to
dispatch
those
from
the
instance
of
the
source
editor
or
we
have
to
listen
to
the
monaco
events.
If
we
want
to
decouple
the
extensions
from
the
monaco,
we
cannot
hook
up
to
the
monaco
events
right.
So
we
we
have
to
listen
to
the
events
dispatched
by
the
source.
Seated
instance
means
we
have
to
extend
the
source
at
our
core.
A
This
is,
this
is
an
interesting
thing
to
like:
where
do
we
dispatch
the
events?
When
do
we
dispatch
events?
This?
I
just
I'm
just
afraid
that
we
will
technically
what
we
will
do
is
we
will
just
duplicate
the
the
advanced
scheme
of
monaco
itself,
because
that's
those
events
are
emitted
in
the
in
the
good
sort
of
time
spots
that
that
we
will
just
have
to
copy
like
not.
B
And
for
a
lot
of
the
ways
I've
seen
eric
the
source
editor
used,
I
don't
think
the
like.
When
I
think
about
snippets
web
id
pipeline
editor.
We
would
not
want
to
dispatch
events
on
those
clients.
I
think
they're
just
saying
here's
source
editor.
Here's
extensions,
give
me
the
values
and
I
think
a
really
good
api,
for
this
is
the
view
component
and
I
would
say,
let's
try
to
architect
something
so
that
the
only
like
the
web
id
and
snippets
just
have
to
instantiate
the
view
component.
B
C
C
In
order
to
decrease
that
coupling
and
reduce
the
chance
of
regressions,
you
want
a
very
narrow
interface
to
be
exposed,
like
you
want
to
say.
Okay,
here
are
only
the
things
I
use
right
like
this
one,
and
this
one
and
those
are
the
only
apis
that
I'm
going
to
expose
and
work
with
and
hide
all
of
the
rest
of
the
complexity,
and
that
also
gives
you
a
layer
to
like
you
said
if
you
mutate
that
or
write
adapter
patterns
or
whatever
to
massage
that
data
flowing
both
ways.
C
If
you
need
to
into
what
you
want,
and
that
gives
you
this
layer
to
really
reduce
that
coupling
to
whatever
is
underlying.
If
you
have
a
keep
that
interface
really
narrow
and
know
that
you
have
complete
control
over
it,
that's
supposed
to
like
the
existing
pattern
where
it's
like
at
the
beginning.
You
said
an
extension
can
be
anything
it
can,
and
it's
mixed
into
the
behavior.
It
could
be
a
function,
it
could
be
whatever
and
it
could
sort
of
do
whatever
it
wants.
It's
sort
of
the
opposite
of
that.
It's
like
no!
C
A
Very,
like
broad
support
in
the
types
of
extensions
like
class
function,
whatever
inline
objects
was
just
like
inline
objects
are
easy,
are
great
for
for
testing
and
the
I
I
didn't
want
to
die
to
to
to
get
into
the
object,
oriented
programming
versus
functional
programming
debate
because,
like
we
have,
we
have
some
really
hardcore
apps
of
both
styles
in
the
company,
and
I
just
I
just
wanted
to
since.
As
I
said,
the
main
thing
to
keep
in
mind
is
that
extensions
are
not
our
way
of
response.
A
A
C
B
And
I
think
that
there's
ways
to
do
the
abstraction
where
you
you
have
it
flexible.
You
have
access
to
the
root
monocle
instance
like
like,
but
it's
constraints
aren't
bad
and
it's
a
good
thing
and
it's
harder
to
work
with
something.
That's
unconstrained
and
it's
much
harder
to
work
with
something.
That's
like
monaco
is
a
beefy
library.
So
you
talk
about
source,
editor
being
light,
but
really
what
we've
done
is
we've
just
we've
spreaded
the
beefiness
of
monica
and
that's
that's
a
challenge,
I
think,
and
adding
a
healthy
level
constraints.
B
C
I
think
it's
easy
in
the
beginning
to
give
all
the
flexibility
you
want,
but
in
the
end
the
the
coupling
the
circular
dependencies,
like
the
maintainability
of
it,
is
what
kills
you
in
the
end
when
you
that
sort
of
like
why
ruby
is
awesome.
But
it's
also
why
you
need
like
20
000
tests
in
it,
because
you
can
do
whatever
you
want.
You
have
all
the
rope
to
hang
yourself.
A
That
is
not
required,
yet
it's
just.
You
know
like
something
for
the
future,
so
in
the
current
layout
in
the
current
setup,
there
is
nothing
biting
us
at
the
moment,
and
other
groups
are
capable
and
they
have
been
developing
new
extensions
and
they
have
had
successful
stories
with
those
the
the
this
this
is
sort
of.
This
is
the
the
main
thing
that
makes
me
sort
of
uneasy
about
restricting
the
things,
but
I
totally
get
that,
and
I
totally
agree
with
that.
A
When
something
happens
on
the
screen
like
when
the
editor
has
been
bootstrapped
when
the
instance
has
been
bootstrapped
when
like
when
the
content
has
been
put
into
the
editor,
so
those
things
are
a
bit
challenging
at
the
moment.
The
the
problem
is
that,
even
if
we
introduce
the
events
in
the
in
the
source
center,
we
we,
I
am
afraid
we
won't
solve
those
problems,
but
this
is
completely
different
story.
A
So
I
I
do
agree
that
we
we
have
to
revisit
the
architecture
and
making
things
more
decoupled
would
be
great.
I
just
I
just
probably
need
to
so.
So
do
you
understand
right
that
you,
chad
and
you
paul
technically
say
that
a
proxy
pattern
is
like
might
be
fine,
but
we,
by
the
end
of
the
day,
we
will
technically
be
talking
about
exactly
the
same
issues
at
the
moment.
At
the
end
of
the
day,.
B
I
think
that
there's
an
alternative
more
inspired
by
how
to
tap
does
extensions,
which
humanitarian
right
can
be
really
successful
with
with
and
even
community
contributors
may
be
able
to
pick
up,
because
it's
a
lot
more
constrained,
and
that
implies
it's
it's
simpler
to
understand
and
work
with
has
been
has
been
really
good,
because
we
already
have
some
extensions.
Those
concerns
about.
Well,
what
are
those
constraints
going
to
be?
We've
explored
it,
and
so
I
think
we
should
we.
B
C
E
Yeah,
that's
I
mean
yeah.
We
should
not
even
try
to
make
it
an
architecture
that,
like
you,
have
extensions
that
work
for
both
the
editors.
I
think
they
are
very
different
editors
and
we
should
not
not
really
not
even
try
to
create
an
architecture
where
you
can
share
the
extension
between
those
two
editors.
B
E
B
C
A
That's
that's
that's!
This
is
a
very,
very
good
point.
I'm
very
thankful
human
should
that
that
you've
raised
this,
because
I
was
afraid
that
this
is
going
to
be
the
case
like
the
the
monaco
and
tiptop
are
super
different
things
super
different
beasts
and
but
the
the
way
we
discussed
it
now
like
taking
like
creating
a
beefy
functionality
as
a
standalone
module
and
then
import
that
module
in
a
source,
editor
extension
or
tip
or
collider
extension.
That's
like
that's
the
common
sense.
A
That's
that's
good
architecture,
and
after
all,
that
beefy
code
should
get
some
some
input
data
and
it
should
spit
out
some
some
content
or
any
any
other
data
so
that
that
the
extension
can
can
use-
and
that's
that's
pretty
common
common
way
of
building
this
the
shared
code
right
so,
but
but
to
to
make
it
clear.
So
are
we
all
do
we
all
agree
that
it
doesn't
make
sense
to
create
extensions
that
are
shared,
like
literally
shared
between
the
two
editors
yeah.
A
Okay-
and
it
doesn't
even
make
sense
to
to
create
any
like
adapters
to
adapt
the
things,
because
technically
I
was
thinking
about
this
and
I
thought
well.
We
might
then
need
to
create
an
adapter
method
for
pretty
much
any
api
that
we
want
to
use
any
public
api
in
monaco,
for
example,
if
we
want
to
map
that
functionality
to
tip
tap
so
that
we
have
like
mapping
monaco
functionality
to
tip
tap
and
vice
versa,
so
it
might
be
just
tiring
and
not
very
maintainable
way.
So
we
just
say:
okay,
we
don't
pursue
this
path.
C
D
There
are
other
ideas
that
we're
not
exactly
trying
to
to
create
portable
extensions
for
the
contaminator
and
source
editor,
like
some
of
the
patterns
that
we
were
discussing
about
inverting
the
dependency
relationship
between
the
sourcetator
extensions
and
the
indoor
core.
So
I
was
wondering
like
what
concrete
step
can
we
do
to
explore
those
ideas
right
like
something
that
right
that
you
did,
then
it
was
like
creating
this
snippet
with
all
of
those
explorations
of
different
approaches.
So
what
do
you
think
like?
D
Could
we
do
that
like
something
like
that?
As
a
team
like
now,
we've
been
thinking
about
like
what,
like
the
idea
of
like
not
using
like
not
maintaining
the
the
instance
api.
You
know
using
the
extensions
like
how
what
could
we
do
like
to
explore
those
kind
of
ideas?
That's
the
next
step
like.
Could
we
do
something
like
that.
A
I
think
I
think
doing
this
as
as
a
team
would
be,
would
be
great,
I'm
just
not
sure
how
to
how
to
arrange
this
and
how
to
organize
this.
This
effort,
the
the
thing
to
to
keep
in
mind,
though,
is
that
now
we
are
talking
that
we
do
not,
we
did
not
pursue
the
path
of
of
shared
extensions
between
the
two
editors
so
technically.
A
This
means
that
the
topic
of
decoupling,
for
example,
extension
from
monaco
or
a
source
or
like
source
editor
from
won't
be
decoupled
from
from
monaco
by
any
mean,
but
the
coupling
extensions
from
monaco
isn't
that
that
important.
So
we
still
can't
provide
this
flexibility
technically,
technically
speaking,
the
access
to
full
monaco
api
in
the
extensions
or
we
should
forbid
that
we
and
we
should
be
very
strict
and
extend
the
core
of
the
source.
B
B
B
Give
me
give
me
values,
give
me
the
text
so
that
I
can
put
this
in
my
api
submission
and
I
think,
if
one
approach
to
doing
this
would
be
to
take
one
of
our
current
extensions
and
references
to
source
editor
and
see
what
we
can
do
to
improve
our
view
component
for
source
editor,
so
that
I
don't
need
a
reference
back
to
the
instance.
It's
just
a
v
model
and
I
say
here's
the
extensions,
here's
the
v
model
back
and
I
think
extensions-
can
still
have
a
reference
to
the
monolith.
B
Monocle
api,
it
won't
be
at
construction
time,
it'll
be
within
version
of
control.
It
will
be
a
parameter
to
some
other
function
and
you
won't
have
extensions
bumping
into
each
other,
but
I
would
I
would
so,
even
though
we're
not
looking
at
doing
multiple
editors
and
so
that
reusability
is
different,
there's
still
a
lot
of
need
to
decouple
what
we're
exposing
we
don't
want
to.
We
want
to
really
have
exposed
constraints
to
the
client
to
extensions
they
can
have.
B
No,
I
was
just
saying
that
I
was
saying
that,
even
though
there's
not
the
reusability
but
there's
still
a
lot
of
benefit
to
not
exposing
to
the
client
the
monaco
api,
I
think
extensions
will
still
end
up
having
some
reference
to
them,
but
not
at
constructive
time.
It'll
be
probably
at
a
different,
some
sort
of
lifestyle
hook,
method
where
I
can
add
events
or
something
to
the
instance
and
things
like
that.
But
at
the
client
side
I
don't
want
to
interface
with
extensions.
I
don't
want
to
interface
with
monoclonal
instance.
B
A
B
Instance,
yes,
and
so
the
client
would
have
access
to
the
array
of
extensions
that
I'm
passing
to
source
editor,
but
and
just
the
types
I'm
just
referencing,
here's
the
types
that
I
want
to
use
right
now,
but
I'm
not
going
to
be
interfacing
with
the
with
the
instance.
I'm
just
saying,
hey,
based
on
this
name.
I
want
these
extensions
build
source
editor.
It's
like.
Oh,
the
name
changed.
B
My
array
of
extensions
changed
go
editor
and
if
you're
dealing
with
life
cycle
hooks
those
things
nothing's,
those
things
can
be
ex
disposed
and
created
really
quickly
because
they're
not
they're,
not
they're,
not
mixing
into
the
beefy
monarch,
though
it's
it's
just
responding
to
the
life
cycle
of
the
of
the
instance.
The.
A
Is
there
are
no
instances
in
our
product
where
we
would
follow
anything
different
so
and
pretty
much?
All
of
the
all
of
the
instances
where
we
use
source
editor
are
initializing
the
source,
editor
applying
the
extensions
and
then
listening
to
the
events.
If
we
need
to
change
something,
that's
that's
the
way
it
works
now
and
that's
the
way
that
that
that
that
that
technically
has
been
has
been
like
this.
For
for,
for
all
the
time.
B
Right
and
so
I'm
saying
that
those
are
things
that's
the
scary
part
is,
is
that
we
are
we're
changing
this
type
at
runtime
and
the
client
still
has
access
to
it,
and
some
of
those
methods
are
based
only
exists
because
of
things
we've
done
previously,
that's
extractions.
We
want
to
fix.
We
want
to
hide
this
from
the
clients
and-
and
I
think
it's
very-
I
think
it's
really
doable
and
and
so
and
sometimes
like
for
the
web
id,
for
instance,
like
there's
some
really
gnarly
stuff,
that
going
on
the
web.
B
Ide
of
we
can
create
extensions
with
references
to
like
event
hubs,
and
things
like
that,
so
you
can
still
decouple
these
things
and
use
events
or
other
patterns
that
that
promote
this,
but
yeah
we
want
to
just
because
that's
what's
existing
right
now
doesn't
mean
that's
what
should
be
existing.
That's
that's
one
of
the
scariest
parts
so.
A
Web
ide
is
is,
is
the
sort
of
exception
case
where,
where
we
extensively
access
the
monaco
api
directly
from
the
repo
editor
component,
that's
definitely
not
how
it's
going
to
be
and
the
the
it
was
just.
I
didn't
really
clean
that
up,
because
we
just
needed
to
replace
the
to
to
convert
the
whole
thing
into
the
extension
and
but
I
didn't
clean
up
the
component,
but
just
to
make
sure
that
I
understand
right.
A
So
this
is
exactly
the
scenario
you
want
to
avoid
so
that
clients
get
access
to
the
to
the
directly
to
the
monaco
api,
for
example,
from
from
view
component
or
from
from
any
other
module,
so
that
everything
should
be
just
editor
and
that's
it.
No
monaco
direct
requests.
That's
that's
exactly
the
the
the
case
that
you
had
in
mind
when
you.
B
Were
talking
about
this
right,
yeah
and
and
that's
and
that's,
what's
beautiful
with
tip
tap,
is
you
just
say:
here's
tithe
editor,
here's
all
the
extensions
and
there's
a
lot
of
extensions
and
each
of
those
extensions
have
access
to
specific
type
apis.
But
the
client
is
just
saying
you
know,
give
me
tip
tap
and
tell
me
when
I
have
values
and
correct
me.
If
I'm
wrong,
I'm
probably
over
simplifying
it,
but.
E
Yeah
yeah,
that's
how
much
word
works,
but
then
again,
pro
rose.
Mirror
is
built
that
way
but
yeah.
I
guess
you
could
do
the
same
thing
with
the
with
monaco
as
well.
Moneco
has
the
view
and
the
model
separate,
and
we
could
sort
of
have
an
extension
architecture
that
makes
use
of
those
separately
but
yeah.
We
need
to
come
up
with
something
but
tip.
D
E
D
It
make
sense
to
like
I
I
feel
like
right
now.
We
are
like
exploring
this
problem
very
conceptually
and
it's
really
difficult
to
see
the
advantages
from
justice
causing.
So
I,
what
do
you
think
about
like
doing
some
sort
of
mob
session
like
programming,
where
we
can
just
like
play
with
the
code,
see
this
in
a
more
concrete
way
and
see
how
it
works
out.
A
B
B
B
B
Pairing
session
yeah
yeah,
we
could
do
it
on
on
fridays.
I
I
hesitate
to.
We
could
totally
use
it
for
that.
I
hesitate
too,
because
that's
I.
I
tried
to
open
it
up
for
all
the
front
end.
If
there's
anyone
else
in
front
end,
that
has
something
completely
random
to
work
on,
but
I
I
don't
know
do
you
want.
We
can
also.