►
From YouTube: Editor Extensions mob programming session
Description
An experiment with running UI parts of the Source Editor extensions externally in the Vue compoenents.
B
So
with
that,
with
that
phrase
that
paul
failed,
we'll
begin
our
recording,
that's
a
nice
intro,
so
hi
everyone,
we
are
recording
a
very
nice
mob
session.
I
think
it's
it
qualifies
for
a
mob
session,
editor
extension
architecture.
It
will
be
a
bit
different
from
the
regular
sessions
we
have,
because
this
is
going
to
be
the
hands-on
experience.
I
hope-
and
that's
that's
how
it's
going
do
we
have
anything
to
discuss
before
we
get
into
the
things.
B
I
have
one
point,
but
I
will
we
don't
have
the
agenda
linked
to
the
let's:
let's
use
the
agenda
for
regular
editor
group.
B
C
B
So
it's
it's,
it's
called
as
simple
as
the
path
forward.
The
effort
we're
going
to
to
put
today
is
is
very
important
and
in
the
light
of
our
think
big
session,
this
becomes
even
more
important
to
to
come
up
with
the
lightweight
architecture
and
the
flexible
architecture.
If
we
are
talking
about
in-context,
editing,
capabilities
and
gradual
editing
experience
that
we
want
to
provide
to
the
users,
so
this
is
very
important.
However,
there
is
one
point
that
we
have
to
keep
in
mind.
We
are
not.
B
We
should
not
allow
this
effort
to
be
to
be
the
blocker
for
the
main
things
we're
working
with,
in
particular,
related
to
the
source
header,
so
there
have
to
be
two
processes
done
parallel.
One
is
gradually
going
forward
with
the
source,
editor
features
and
implementations
that
we
have
on
our
plate,
and
this
is
this
should
be
considered
as
an
experiment
as
enrique
phrased
it
during
the
last
session.
B
This
is
the
experiment
that
we
will
go
through
and
see
how
we
implement
the
ideas
we
generate
during
these
sessions
into
the
into
the
main
product.
B
So
with
that
in
mind,
I'm
I
think
that
it
would
be
great
to
have
some
some
some
understanding
of
the
expectations
that
we
want
to
get
from
this
session
so
that
we
would
not
like.
We
would
understand
whether
this
is
a
one-time
session
or
it's
a
repetitive
session.
How
often
do
we
meet?
What
is
the
the
ultimate
goal
because,
like
saying
that,
we
want
to
change
the
architecture
of
source
editor.
This
is
like
the
uber
go
right,
but
what
is
the
more
or
less.
B
B
So,
I
think,
wait.
I
think,
we'll
we'll
follow
the
same
bureaucracy.
D
D
As
we
said
last
time,
I
see
the
goal:
yeah
no
expectations
or
anything
in
the
in
the
product.
The
goal
of
this
is
to
reimplement
what
current
functionality
we
have
for,
like
the
markdown,
editor
extension
and
then
possibly
the
other
two
editor
extensions
in
the
way
that
we've
described
as
a
thinner
layer
that
is
just
focused
around
persistence
and
the
model,
the
rest
of
it
as
view
and
possibly
following
on,
to
implement
the
functionality
of
the
other
two,
a
couple
of
more
extensions
to
get
that
context
and
the
way
I'm
seeing
it.
D
F
So
I
think
that
that's
that's
useful
right.
It
makes
like
very
explicit
goals,
so
we
can
focus
on
that,
but
we're
going
to
focus
on
the
markdown
live
preview
feature
that
was
implemented.
Two
milestones
before.
F
Into
another
one,
if
we
don't
have
enough
time
but
the
goal,
the
goal
is
following
a
new
approach
where
we
only
use
the
where
we
separate
all
the
concerns.
The
concerns
that
we
implemented
in
the
markdown,
like
preview
extension
in
the
source
editor
right
now
we
have
data,
fetching
presentation,
done
manipulation
and
business
logic
inside
a
single
class.
We're
going
to
break
that
apart,
we're
going
to
use
view
to
implement
to
separate
all
of
those
concerns
into
independent
layers
and
we're
going
to
try
to
follow.
B
Sounds
good
it
does.
It
does,
and
the
only
thing
that
I
would
like
us
to
to
look
into
while
we're
in
in
our
effort.
We
didn't
have
a
chance
to,
during
the
last
session,
to
look
into
the
last
poc
of
the
current,
like
of
the
current
changes
in
the
source
editor
and
the
extensions
I've
linked
in
the
agenda.
B
But
we
didn't
have
time
to
have
time
and
the
overall
impression
I've
got
that
we
didn't
want
to
look
at
the
poc
back
then,
but
I
think
it
would
be
beneficial
to
take
a
look
now
because
in
particular
it
it
because
what
we
will
see
in
the
poc
is
technically
the
path
that
is
going
to
be,
as,
as
I
mentioned
in
the
beginning
of
the
session,
that's
going
to
be
the
path
that
the
main
product
takes
right
now
and
we
will
evaluate
and
iterate
on
top
of
that
with
with
whatever
we
come
up
with
during
this
session.
F
But
we
we
scheduled
this
session
specifically
for
the
mark
down
like
trivia
experiment.
Do
you
think
that
we
could
like
move
that
conversation
of
the
poc
for
next
monday?
That
would
happen.
B
But
it
doesn't
really
make
sense,
because
we
are
going
to
talk
about
the
extension
as
it
is
now
in
the
master,
but
it's
not
going
to
be
going
to
be
like
this
during
the
next
week.
I
issue
because
we
had
several
sessions
on
the
architecture
and
there
were
comments
and
concerns
raised
that
were
that
have
been
addressed
during
in
the
epoc
and
the.
The
thing
is
that
we,
I
don't.
B
I
don't
really
see
a
point
of
discarding
the
effort
put
into
it
in
like
what
what
will
be
our
starting
point.
Really,
what
will?
What
do
you
think
is
going
to
be
our
starting
point?
The
master,
the
current
master.
D
So
I
can
jump
in
like
the
the
behavior
of
the
markdown
preview,
the
user-facing
behavior,
that
is
the
goal
where
we
are
starting
from,
is
greenfield
nothing
to
do
with
the
current
extension
architecture
or
behavior.
That's
how
I'm
seeing
it
so
we
will
re-implement
from
scratch.
Just
from
monaco,
I
presume,
and
we
will
pair
tdd
whatever
makes
sense
to
re-implement
that
functionality
with
the
alternative
architectures,
we
discussed
thin
layer
for
model
persistence
and
view
for
the
rest
of
the
behavior.
B
B
That's
your
question,
then:
let's,
let's,
let's
make
it
like
super
clean
experiment,
and
we
start
wherever
we
want
with
this
experiment.
So
pocs
poc
is
going
to
be
the
main
products
line
for
now
and
then
we
will
incorporate
these
ideas
and
this
brainstorming
into
the
mainline
product.
Okay,.
D
H
D
F
F
Okay,
so
let
me
see
we
have
the
workspace
here.
So
let's
see
I'm
going
to
open
the
just
a
a
new
file
to
to
list
which
step
we
will
be
taking
here
to
see
if
we
have
some
consensus
about
it.
F
F
Component
and
then
we
have,
we
need
to
find
a
way
of
integrating
monaco
inside
the
live
preview
component
component
like
we
create.
We
create
an
instance
of
monaco.
A
All
right
so
are
we
are
we
doing
this
completely
separate
from
the
existing
editor
source
editor
component,
or
is
it.
F
A
F
F
F
F
And
then,
based
on
the
document,
changes.
B
The
when
it
comes
to
the
markdown
live
preview
functionality.
It's
essentially
that's
that's
how
it
works.
Now
the
car
like,
since
we
cover
only
the
live
for
you,
then
I
I
think
we
should
be
good.
The
current
markdown
extension
is
more
than
just
preview,
but
that's,
as
I
said,
that
has
to
be
split
into
separate,
separate
extension,
so
we're.
A
A
B
Yeah
so
technically,
ideally,
instead
of
like
setting
up
the
dome
element,
we
are
using
the
the
already
existing
stuff,
like
the
view,
components,
yeah,
yeah.
Okay,
that's.
F
Interesting,
okay,
so,
let's
start
I
just
set
up
a
new
directory
here
and
call
it
markdown
live
preview.
What
do
you
think.
A
F
Saw
it
in
the
extensions,
can
you
show
me
that
in
the
sidebar
cool,
let's
call
it
right
down
there,
but
wait
a
minute
like
if
we
do
it
in
the
extension
like
we
are
trying
to
to
integrate
the
source
later
within
this
picture,
not
the
this
picture
into
the
source
editor.
So
I
see
like
the
dependencies
relationship
is
not
like
very
clear
from
that
point
of
view.
That's.
J
F
A
Me
of
you
remind
you
of
your
three
yeah.
So
what
what
do
we
anticipate
being
the
input
and
output
of
this
component
from
the
props
perspective
and
the
slots
perspective
and
I'd
almost
be
really
interested
to
see?
How
do
we,
maybe
before
we
start
filling
this
out?
How
do
we
anticipate
using
this
component.
J
And
I
don't
know
this
is
this
is
a
tough
question
because.
B
And
that's
that's.
Why
that's
why
I'm
I'm
skeptical
about
putting
wrapping
this
into
one
view
component,
but
we
technically
have
two
places
where
we
use
the
live
preview.
It's
web
id
and
it's
the
single
violated
right.
So
this
approach
in
in
both
cases,
this
approach
will
will
be
tough
to
implement,
in
my
opinion,
because
technically
we
have
to
step
into
something
that
is
like
in
particular
web
ie.
It's
already
the
source
editor,
it's
already
just
one
editor.
B
So
how
are
we
going
to
implement
the
view
component
into
the
existing
web
id
source?
Editor?
That's
that's
a
bit
un
clear
to
me,
but
for
the
sake
of
experiment,
I
think
we
can.
We
can
come
up
with
with
something
I
don't
know.
Yeah.
That's.
F
A
that's
a
very
important
point.
So
could
you
then
show
me
how
how
do
we
integrate
the
markdown
light
preview
in
the
single
editor
right
now
in
the
single
byte
loader.
B
B
F
F
Loading,
a
synchronously,
the
eight
or
the
the
markdown
live
video
extension.
B
This
is
the
root
editor,
then
this
editor
is
actually
instance,
and
then
we
we
use
the
extension
okay.
So.
F
If
we
had
something
like,
let's
say
that
we
have
a
the
markdown
live
review
app,
we
say
it's
a
new
markdown
live
preview
and
we
attach
the
well
to
the
element
that
let's
say
that
we
create
a
div
or
an
element
next
to
the
the
domain
element
that
is,
that
contains
the
source.
Editor
say:
markdown
live
radio.
F
Then
we
could
say
that
we
have
some
data.
That
is,
that
is
the
document
like
the
actual
document.
F
F
Is
a
document
property
would
that
work
as
a
as
a
way
of
like
creating
that
internal
player
between
the
markdown
live,
3d
application
and
the
source
sector?
In
that
context,
I've
I
would
consider.
A
I
would
consider
maybe
thinking
about
how
this
would
fit
into
the
web
id,
which
is
already
using
vue,
okay
and
because
what
would
work
here
is.
We
are
creating
a
new
view,
application
and
stuff,
and
that
might
kind
of
work.
A
A
No,
I
was
so
I
don't
think,
there's
a
lot
preventing
us
from
and
the
single
file
editor
making
a
very
rudimentary
view
context
that
we're
already
a
part
of
like
we
can
even
use
some
of
these
same
classes
like,
but
I
would,
I
would
maybe
think
about
how
we
could
shimmy
this
into
the
web.
Ide.
A
And
seeing
what
interfaces
pop
up
pop
out
to
us
there
and
when
I
look
at
oh
go
ahead,
what
are
we
gonna
say
dennis
I'm.
B
I'm
I'm
I'm
still.
I
still
have
hard
times
like
I.
I
know
that
we
are
prototyping
and
we're
just
playing
and
we're
experimenting.
I
still
have
hard
times
understanding
why
we
should
go
this
way
of
wrapping
the
editor
in
a
component
rather
than
creating
creating
a
view
application
within
within
an
extension,
we
can
pass
the
state
to
the
component
as
a
parameter
if
we
are
concerned
with
with
the
state
in
the
in
the
extension.
B
The
the
main
point
is
that
the
markdown
live
preview
is
one
there's
only
one
extension
now
that
requires
the
view
component.
All
the
remaining
components
are
functional.
So
this,
if
we
pursue
this
approach,
this
means
that
we
will
have
two
different
ways
of
applying
an
extension
one
for
the
functional
components
and
one
for
the
view
components
yeah.
This
is
this
is
a
bit
a
bit
strange.
I
think.
A
Correct
me,
if
I'm
wrong
enrique
wants
you,
but
I
think
the
well
what's
happening
with
the
markdown
live
preview
is
indicative
of
how
we
may
want
to
implement
a
toolbar
extension.
A
The
toolbar
is
gonna,
be
a
much
more
complex
ui
and
something
that
might
need
to
be
reactive,
based
on
where
the
cursor
is
selected,
and
things
like
that
it'd
be
nice
to
have
those
presentation
logic.
Let's
use
our
view
framework,
that's
that
would
be
ideal.
So
I
think
the
goal
is
less
about
is
forward
thinking
beyond
just
markdown
extensions
or
yeah,
just
the
markdown
extension
and
trying
to
trying
to
find
for
more
complex
presentational
stuff.
F
Is
that
right,
enrique
yeah,
although,
like
thinking
from
from
denny's
point
of
view
like
we
could
follow
a
similar
approach,
this
within
the
the
source?
Editor
extension
right
like
I
could
like
create
a
news
as
a
preview
application
and
just
listen
to
it
or
to
editor
events
and
then
update
the
state
of
the
view
up
and
summarize,
the
toolbar
state.
B
But
think
about,
like
one
editor,
one
instance,
can
have
multiple
extensions.
So
do
you
think
that
we
have
to
create
one
view
app
per
extension
or
do
we?
How
do
we?
How
do
we
do
this
like
if
we
even
the
functional
components
if
they
get
turned
into
into
or
functional
extensions
if
they
get
turned
into
the
view
component?
B
A
A
The
main
concern
is
this
block,
and
could
we
do
this?
Is
there
a
usable
interface
where
we
could
separate
how
we're
presenting
things
with
the
functional
bit?
So
those
functional
extensions
wouldn't
necessarily
need
a
view
component
unless
I'm
mistaken,
and
when
I
look
at
this,
though
I
feel
like,
I
feel
like
that
there
is
something
there,
but
it
might
require
us,
anticipating,
anticipating
the
abstraction
ahead
of
time.
So
maybe
this
extension
says
something
like
I
need
to
add
a
panel
to
the
or.
K
B
It's
I
like
it
set.
It
puts
the
like
a
pants
preview
into
into
an
element
right,
so
there
is
nothing
nothing
that
would
prevent
us
from
creating
a
view
component
in
power
in,
in
our
view,
in
parallel
with
with
our
editor
and
then
in
the
editor,
in
an
extension,
for
example,
say
have
a
method
set
up
view
or
something
like
this.
B
That
would
take
the
parameter
as
an
as
an
element
to
on
which
to
set
this
up
or
even
the
view
component
as
the
as
the
component
reference,
maybe
with
the
with
the
with
the
element,
something
like
this
like
where,
when
we,
when
we
have
view,
do
its
job,
but
then
we
just
notify,
as
I
mentioned
during
our
previous
session,
we
just
built
this
bridge
between
the
extension,
that
is,
that
does
deal
with
the
business
logic,
and
then
we
just
delegate
the
view
functionality
to
the
external
component
to
the
external
element.
B
Should
it
be
view
components?
Should
it
be
just
plain:
html
doesn't
really
matter,
but
we
just
build
this
bridge
on
the
extension
level
instead
of
wrapping.
This
whole
thing
in
in
view
I'm
but
again
like
this
is
this
is
just
my
my
my
thoughts,
so
we
we
can
just
continue
going
on
with
this
experiment,
but
I
think
it
would
really
make
sense
to
to
take
paul's
suggestion
and
try
this
in
the
web
id
because
webby
is
the
like.
A
F
A
Yep
and
you
can
look
for
where
we
do
the
markdown
extension,
I
want
to
show
one
thing,
and
this
is
this-
is
one
of
the
this.
I
want
to
show
one
thing
that
would
need
to
be
confirmed,
or
if
this
is
a
legit
concern
or
not,
but
it's
definitely
not
clear
whether
it
is
or
not.
If
you
go
to,
if,
if
you
do
a
search
for
ref
editor.
A
Yeah
yeah
yeah,
so
this
is
the
div
that
we
actually
mount
monaco
to
and
if
you
go
back
to
the
source,
editor
markdown
extension,
the
module,
yeah
yeah
yeah.
J
A
So
here
we're
we're
inserting
a
new
element
into
something:
that's
already
quasi-managed
by
view-
and
I
mean
that's
what
monaco
is
already
doing
so
so
we
just
can't
get
rid
of
that
element.
A
But
if
you
go
to
where
we
do
set
up
dom
elements
where
we
call
it
right,
yeah
yeah,
so
we
actually
inject
this
into
the
parent
of
what
monaco
says.
A
The
dom
node
is-
and
I
don't
know
if
that's
that
ref
editor
or
if
that's
a
sibling
of
ref
editor
and
if
it's
a
sibling
of
rap
editor,
that's
really
concerning,
because
vue
could
decide
to
we're
going
to
re-render
that
part
of
the
template,
and
then
we
got
rid
of
this
and
so
keeping
things
within
the
vue
ecosystem
is
there's
a
lot
of
wind
there
and
because
there
there
might
not
be
a
problem
here.
There
could
be
a
problem.
A
F
Do
we
move
forward
here,
because
this
is
like
what
I
see
as
a
main
blocker
right
now,
like
I'm
gonna
prototype
here?
What
I
wish
that
we
could
just
like
implement
as
a
fit
as
the
market
like
preview
like.
I
think
that
this
is
like
the
idea
that
we
want
to
achieve
so
right
now
we
don't
have
a
a
way
of
listening
here
to
the
to
associate
or
events,
but
I
think
that
what
we
wanted
to
do
in
some
ways
was
like
saying:
hey,
markdown,
live
preview.
F
But
for
doing
that,
we
need.
We
first
need
to
find
a
way
of
like
listening
to
the
to
the
to
associate
their
events
for
this
for
this
data.
So
how
do
we
do
that.
C
F
B
The
content
viewer
is
a
bit
different
because
it's
it
does
it's
not
not
shown
in
parallel
with
the
really
code.
It's
like
it's
either
code
as
the
div
above
or
the
content
viewer.
It's
for
the
cases
where
we,
where
we
cannot
show
the
code
for
like
binaries
or
something
like
images
or
something
like
this.
I
yeah
yeah.
F
B
F
A
So
one
thing
to
add
to
the
complexity
here
is
markdown.
Live
preview
is
something
that
the
user
toggles
on.
So
it's
not
like.
A
We
necessarily
are
just
going
to
automatically
show
it
if
we're
in
markdown
land,
and
this
might
be
helpful
at
figuring
out
what
the
responsibilities
we'd
want
for
this
view
component
and
the
extension
to
be
it's
nice.
If
you
go
to
like
the
extension
it
like,
creates
the
command,
I
think,
and
when
the
command
happens
it
it
does
the
event
to
like
trigger
something,
but
rather
than
it
doing
the
presentational
logic
there
if
it
could
just
emit
some
sort
of
event.
A
I
don't
know
if
monaco
lets
us
admit
custom
events
that
we
could
listen
to
on
the
instance
or
something
that
I
think
is
what
we'd
want
to
hook
into
is.
B
A
So
I
think
we
would,
we
would
want
there
to
be
some
sort
of
state
managed
outside
of
it's.
Mainly
it's
not
vf
current
language.
I
think
it's
almost
like
via
show
markdown
live
preview
and
that's
going
to
be
set
by
the.
F
F
Okay,
so
I
think
that
this
could
be
the
interface
we
only
need
to
implement
now
there.
Well,
let's,
let's
start
by
by
by
making
sure
that
we
are
interacting
in
the
right
way
with
with
monaco.
Sorry
with
the
source
later,
let's
just
like
ensure
that
we
are
listening
to
that
event
that
we're
triggering
that
event
and
that
we
can.
F
F
So,
let's
just
like
go
to
data
here
and
declare
that
data
data
field-
oh
man,
it's
long.
F
Markdown
live
preview
extension
and
this
extension
should
have
two
responsibilities.
It
should
indicate
when
the
user
wants
to
display
the
like
preview,
and
I
think
that
we
already
have
some
events.
How
do
we
take
when,
when
the
language
changes,
but
we
just
need
like
to
move
the
logic
from
here
like
that's
what
this
extension
is
doing,
there
is
right,
like
this
is
detecting
the
language
change
and
then
doing
some
monitoring.
No.
B
No
extension
doesn't
do
any
language
detection.
This
is
done
by
source
editor
itself.
It's
not
extension's
responsibility
to
detect
the
language
changes.
What
extension
does
is
simply
listens
to
the
user
interactions,
whether
as
paul
mentioned
either
user
toggles,
the
preview
on
or
user
toggles,
the
preview
off
if
the
user
is
toggling
the
preview
on
we
also,
this
extension
also
listens
to
the
to
the
content
updates
in
the
editor.
In
order
to
generate
the
new
preview.
B
That's
all
it
does.
It
doesn't
listen
to
the
language
changes.
B
The
user
interaction
like
if
you
check,
let
me
just
fire
up
this
if
you
go
to
the
constructor
of
this
extension,.
C
B
This,
oh
right:
okay,
yeah,
okay!
This
is
all
right.
B
All
right,
because
I
wanted
to
clean
up
right.
Yes,
this
this
makes
sense.
Okay.
So
when
we
set
up
the
extension,
we
set
up
the
actions
for
user
interactions,
but
when
we
switch
away
from
this
extension,
so
when
this
extension
is
sort
of
is
not
needed,
we
clean
up
and
remove
that
action
right.
So,
yes,
that's
why
this
has
to
be.
This
had
to
be
moved
into
the
into
the
extension.
That's
correct!
Oh.
F
C
Yeah,
that's
a
good
question.
A
I
think
the
model
is
monaco's
like
content,
the
content
of
the.
D
A
D
B
B
Yeah
yeah
so
technically,
when
you
like,
it
does
change
every
time
you
you,
you
technically
interact
with
the
with
the
content.
B
A
It's
maybe
it's
possible
that
for
some
reason
the
cleanup
was
needed
like
on
every
change
like
if
the
preview
is
yes.
B
B
This
is
the
thing
so
the
first
one,
the
language
it
just
when
you,
when
you
change
the
language
of
the
model,
the
second
one
is
actually
needed
for
for
the
web
ide
because
in
the
web
ide
the
architecture
of
web
id
is
such
that
we
have
one
instance,
no
matter
how
many
files
we
open.
It
has
one
instance,
but
it
has
multiple
models.
This
is
this
is
getting
back
to
chad's
question,
so
every
tab
technically
represents
represents
a
new
model,
because
this
is
new
content.
B
However,
we
reuse
the
same
instance
and
in
in
web
id
this.
This
is
needed
for
the
web
id
when
we
close
a
tab
that
was
with
the
markdown
file.
We
have
to
clean
up,
even
though
it's
not
like
the
language
change,
and
we
just
discard
the
mo
that
model
that
we
have
closed
and
the
language
change.
Language
event
isn't
immediate.
In
case
the
modal
gets
discarded
or
gets
sort
of,
when
the
same
instance
gets
the
new
model
replacing
the
old
one.
B
B
A
Well,
what
no
that
I,
I
see,
that's
a
that's
an
interesting
and
a
good
point
of
yeah
on
the
web
id.
We
have
multiple
tabs
open.
We
will
change
the
model
as
we
change
tabs,
but
here's
an
interesting
point.
I
don't
know
then
what's
going
to
happen,
if
you
scroll
up
to
the
constructor,
what
happens
on
line
51
then
because
we're
only
adding
the
did
change
language
to
one
model
and
I
don't
know
what's
going
to
happen,
and
I
don't
know
if
maybe
changing
tabs
we're
also
happy
to
be
disposing.
Everything
and
recreating
it.
A
So
yeah
I'm
gonna,
I'm
gonna,
I'm
gonna
attempt
to
navigate
a
little
bit
and
regain
but
feel
free
to
tell
me
to
stop
backstage
driving.
A
A
So
we
do
this
asynchronously
based
on.
Are
we
actually
marked
on
file
or
not
and
that's
great,
and
we
we
get
it,
we
start
using
it.
I
would
imagine
once
I
use
it.
A
I
can
then
want
to
hook
on
to
the
event
of
have.
Are
we
have
we
shown
the
preview
thing
yet
I
like?
How
are
we
do?
I
need
to
show
this,
or
is
the
user
not
use
the
command
yet
so,
whether
we
have
our
own
markdown
extension
or
we're
using
the
the
well,
we
have
a
new
one,
we're
using
the
old
one
somewhere.
What
you're
saying
is
here
this
is
where
I
want
to
hook
into.
A
I
need
to
either
show
it
or
not,
and
I'm
not
sure
if
monaco
lets
us
just
submit
random
events
on
the
instance,
I'm
pretty
sure
it
would,
but
maybe
we
also
want
to
interface
with
the
extension
itself.
I
think
it'd
be
easier
to
use
monaco's
events.
F
Denis
said
that
we
could
just
like
listen
to
some
events
in
the
in
the
source,
editor
itself
right.
That
is
like
do
we
have
a
an
interface
to
to
attach
event
listeners
to
a
source.
B
Sort
of
we're
doing
that
we're
doing
it.
Events
not
like
we
have
clear
interface
there,
but
we
have
this
is
this.
Is.
B
You
can
check
the
source
editor
source
on
the
score
editor.js.
I
think.
B
B
So
we
have
added
a
red
event
and
that's
pretty
much
it.
This
is
some
like
the
only
event
we
we
display
chess
custom.
Otherwise,
we
just
proxy
the
monaco
events.
A
B
We
can
oh
yeah
that
it
used
to
be
this
way,
and
I
I
think
somebody
somebody
was
reviewing
this,
so
this
merge
request
and
they
they
suddenly
started.
Hating
me
for
that.
A
The
the
well
from
the
repo
editor
from
this
component,
we
may
not
want
from
the
reporter
component,
we
doing
a
hooking
onto
event
on
the
dom
we
would
have
to
clean
it
up.
It'd
be
nice
to
hook
it
on
to
something
that
will
clean
up
itself,
eventually
like
if
it
gets
disposed.
So
it
would
have
been
nice
to
hook
it
onto
the
editor
instance.
But
I'm
gonna,
just
I'm
gonna
say
let's
just
keep
plowing
forward,
and
maybe
we
can
just
use.
A
Gosh,
maybe
we
should
just
use
the
maybe
we'll
need
to
actually
add
this
event
listener
outside
of
us,
creating
the
instance,
because
if
we
do
need
to
clean
it
up,
so
that
we
have
just
one
of
these
events,
because
we
can't
just
keep
creating
events
every
time.
We
do
something
like
this
and
I
don't
want
to
manage.
A
So
maybe
we
should
create
an
event
listener
on
our
created
here
on
the
created
of
this
component.
F
Yeah,
so
we
would
do
something
like
we
have
the
these
dot
refs
dot,
eight
or
oops,
to
make
our
science
just
even
listener
right.
A
Well,
so
here's
the
thing
that
can
happen
well
if
we
did
that.
F
We
just
want
to
listen
like
here's,
here's.
What
what
I
was
thinking
like
our
goal
is
like
right.
Now
we
have
this
extension
that
is
doing
on
on
these
event,
listeners
like
some
setup
like
creating
the
the
preview
panel
and
doing
the
fetch
request.
I
want
to
change
all
of
this
to
just
emitting
an
event
that
indicates
that
the
preview
functionality
was
activated
or
this
activate
or
deactivate
it
yeah.
A
That's
it
look,
I'm
going
to
try
to
get
us
to
plow
forward
as
quickly
as
possible.
Can
we
go
to
the
repo
editor
dot
view.
A
A
Oh,
we
don't
have
one
so
so
we
can
add
or
mount
it
if
we
have
a
mounted
one
yeah
yeah
yeah.
So
here,
let's
add
I'm
fine.
If
it's
a
window
event,
let's
add
a
window
event
and
we
could
figure
out.
A
Oh
what
the
right
hub
for
this
is,
but
we
can
call
it.
I
don't
know
yep
yep,
whatever
we
want
to
call
it.
A
A
Well,
do
you?
I
didn't
understand
that
just
looking
at
line
229
like
we
can
just
create
a
new
method
for
this,
because
we're
going
to
have
to
dispose.
B
Some
point,
but
also,
why
not
to
listen
on
the
this
graph
editor
like
this.
This
element
this
refs
editor.
I
think
this.
B
A
Concern
is
like
because
that
ref
is
the
same
if
we
like
change
files
and
other
things
right,
I'm
concerned
about
creating
that
event
more
than
it's
needed
and
letting
it
do
its
thing
when,
when
it
shouldn't
be
okay,
and
but
I
but
I
I
really
don't
know,
I'm.
F
I
A
Okay,
we
are
there
okay,
so
this
is
then
you
know
somehow
we
are
going
to
get
the
event
back,
that
we
should
turn
it
on
and
that's
like
we're.
Just
gonna
update
our
data,
though,
which
is
really
sweet.
F
That's
right,
so
we
have
that
in
here
and
I'm
gonna,
just
like
add
a
a
console
log
here,
yep
and
let's
just
like
focus
on
on
making
sure
that
we're
doing
this
event
when
all
of
that
happens,
yep
I'm
gonna.
F
F
F
And
we
can
emit
an
event.
Does
someone
remember
where
is
the.
F
And
what
was
the
name
that
we
use
here
was
to
go
mark
down
like
previous.
F
A
A
B
Event
this,
I
think,
in
order
to
pass
the
data
you
need
to
create
the
custom
event,
not
the
new
event.
New
van
doesn't
accept
the
parameters.
I
think
okay.
A
B
K
A
The
thing
yes,
yes,
yes
yeah,
you
want
to
do
a
cuts.
Yeah,
that's
interesting
yep.
So
I
think
we
correct
me
if
I'm
wrong,
but
I
think
dispatch
event
takes
the
name
that
we're
gonna
it'll.
Take
the
toggle.
Markdown
live
preview.
F
F
A
Yeah
yep
yep,
that's
that's
how
we
would
do
it
and
I
guess
we
would
want
to
do
the
same
thing
on
line
20.
A
Or
18.,
so,
let's
just.
I
A
F
Okay,
oh
we
can
just
like.
Oh
that
doesn't
matter
so
I'm
gonna
do
this
again
here.
H
I
A
J
F
Okay,
so
we
have
this,
then
that's
included
in
repo
later
it
should
be
marked
down
next.
A
So,
let's
yeah
are
we
going
to
so
we're
going
to
replace
the
cool
yeah?
Let's
do
that
we
can
do
that.
I
F
A
K
A
Can
we
replace
this
with
like
a
pre
or
div
with
just
something
silly
in
it,
so
you
want
to
to
shake
like
this.
The
same.
K
A
I
A
It's
in
event.details
it'll
be
that
value
whatever
the
name
of
the
detail
was
markdown
preview,
active,
yeah
cool.
So
let's
see
how
what
happens.
A
Is
this?
Has
the
gdk
been
running
all
night
for
you?
A
D
A
Yep,
I
guess
the
gdk
channel
is
like
the
it
crowd.
Did
you
try
turning
it
off
and
on
again.
A
A
Oh
yeah,
well,
I
did
say
him:
aren't
you
yeah?
I
posted
a
comment
in
the
chat.
A
You
look
like
you're,
you
look
like
you're
progressing
pretty
nicely.
So,
let's
open
up
the
web
ide.
D
A
D
But
I
think
it's
configurable,
I
think
you
could
like
tell
it
to
rebuild
everything
all
at
once.
If
you
wanted
to
personally,
I
wouldn't
want
to.
I
waiting
is
not
one
of
my
funnest
things.
A
I
I
agree,
but
now
I'm
like
rather
than
batching
my
waiting
at
all
one
time
I
feel
like
got
another
black
screen
thing,
but
it's
just
me.
B
Right,
we
don't
have
markdown
extension
like
we.
We
have
to
use
the
the
actual
name
of
the
class
that
we
have
in
our
new
extension
now
right,
not
the
markdown
extension.
J
B
It
was
right
there
like
no,
where
we
import
the
markdown
extension.
I
keep
going
down
yeah
here
we
go
so
instead
of
markdown
extension
we
have
to
use
or
on
three
on
325.
B
J
A
B
Why
do
we
preview
mark
down
this
thing?
Because
we
don't
have
any
clear
view
clear,
a
way
of
showing
the
new
preview?
So
this
is
temporary
thing
unless
until
we
have
the
toolbar
with
the
dedicated
button,
we
have
to
sort
of
keep
this
so
that
people
do
not
freak
out
because
we
removed
functionality.
A
Still
didn't
work
right
because
it
let's,
let's
inspect
our
document,.
C
B
Again,
it's
okay,
so
you
can
pass
multiple
details,
but
you
still
have
to
name
it.
The
details
well.
C
A
And
the
constructor
it
actually
needs
to
be
detailed
as
well
yeah
and
and
that.
I
B
C
C
C
B
Let's
check
the
the
the
source,
the
elements
tab,
oh
yeah,.
F
B
B
Wait
a
second
this
we're
we're
actually
in
the
in.
I
F
F
F
No,
it
never
did
like
it
was
for
a
different
file,
so
I
just
like
hit
play
because
it
was
not
a
marginal
file,
so
it
seems
like
this
is
not
executing
when
you're
opening
a
new
file.
A
What
is
there's
a
console
error
so
something
happening
before?
Is
there
an
error
happening
before
we
can
get
that.
F
A
A
Is
it
false,
yeah
is
the?
Is
our
template
getting
updated?
It's
probably
just
pushed
to
the
bottom.
It's
the
element.
Oh
there.
B
A
F
Think,
that's
that's
a
bug.
Okay,
so
I
think
that
the
next
step
now
is
just
implementing
the
the
live
preview
panel
right,
the
actual
the.
A
J
A
D
A
D
A
I'm
gonna
need
to
hop
off
a
little
bit.
I'm
gonna
be
out
next
week
and
I
added
a
comment
about
this
on
the
agenda.
So
this
is,
if
you
don't
mind
me
just
bringing
up
food
for
thought
for
discussion
as
we
talk
about
how
to
move
forward
with
this
enrique.
Can
you
open
up
the
source?
Editor
markdown
x?
A
Yes,
the
other
one,
not
the
new
one.
So
one
of
the
one
of
the
concerns
that
we
were
approaching
with
this
session
was
exploring.
How
can
we
separate
responsibilities,
specifically
presentational
responsibilities
from
state
and
logic
management,
responsibilities
with
extensions,
and
I
think
that's
really
good
worth
thinking
and
talking
about
there's
a
there's,
a
separate
problem-
and
this
is
a
this-
is
a
significant
concern
for
me.
If
you
scroll
down
in
this
file-
and
you
go
to
the
cleanup
method.
A
Yeah,
so
if,
if
we
had
called
this
dispose,
it
would
cause
problems-
and
this
is
a
known
issue
of
right
now,
because
everything's
mixing
in
there's
naming
collision
with
the
methods
we
create
for
the
extensions,
and
that
can
be
a
little
scary,
and
so
I
really
like
some
of
the
ideas
that
we
brought
up
and
and
talked
about
it
and
the
more
I
think
about
it.
A
I
really
want
to
propose
us
to
explore
this
kind
of,
like
injecting
inject,
provide
paradigm
of
letting
extensions
declare
what
they're
going
to
provide-
and
I
like
how
we're
doing
that
with
this,
like
methods
callback,
but
then
the
flip
side
is
letting
extensions
declare
what
I
expect
to
inject
and
what
I
expect
to
and
letting
these
things
all
be
named.
Space,
I
think,
is
very
doable.
So
it's
like
the
effort
we
can
put
to
separate.
A
You
know
what
methods
am
I
just
going
to
call
internally
and
I
don't
want
to
expose
to
everybody
and
what
methods
do
I
want
to
expose
out
there
like
if
I'm
creating
some
sort
of
abstract
panel
extension,
that's,
I
think,
going
to
be
worth
a
whole
lot.
So
in
our
agenda
I
dropped
a
snippet
of
just
this
is
the
kind
of
api
I
think
would
solve
this
and
it's
worth
thinking
about
and
seeing
seeing
how
it
could
how
it
could
fit.
A
B
I,
like
the
the
provide
in
your
snippets.
B
K
A
I
can
anticipate
this
and
just
blow
it
up
if
some
extensions
that
were
dependent
on
each
other
aren't
are
created.
That's
one
interesting
side
effect
of
that
so
yeah,
I'm
gonna
be
out
next
week,
so
I'll
miss
the
meetings
thanks
so
much
enrique
for
driving
and
putting
this
together,
and
I
think
I
think
it's
this
specifically
is
an
interesting
problem
of
separating
responsibilities,
especially
as
we
get
more
complicated
things
like
toolbar,
because
on
the
content
editor,
the
toolbar
is
very
reactive,
and
so
it's
a
good
thing.
A
B
Up
thanks
paul
thanks,
I
just
wanted
to
since
since
paul
mentioned
the
the
toolbar.
I
just
want
to
want
us
to
keep
one
moment
in
mind
that
this
visual
components
like
just
just
for
a
second,
if
we
abstract,
go
away
from
the
live
preview
and
talk
about
the
toolbar
so
with
the
tool.
The
idea
of
the
toolbar
is
that
any
extension
should
be
able
to
tune
it
add
buttons,
remove
buttons,
add
actions
so
to
a
certain
extent.
B
So
that's
that's
that
toolbar
should
be
very
flexible
and
whatever
we
come
so,
for
example,
we
already
have
a
very
valid
use
case,
so
when
user
gets
to
to
edit
ascii
doc
document,
they
are
presented
with
a
markdown
toolbar,
so
they
try
to
to
to
do
those
like
bolding
or
something
like
this
and
the
markup
generated
is
actually
marked
down.
So
I
would
envision
this
with
with
the
new
toolbar
for
the
source
header
that
if
we
are
on
the
ascii
dock,
we
load
the
ascii
dock
extension.
B
It
sets
up
buttons
connected
to
the
ascii
dock
actions
so
generating
the
correct
market.
However,
if
you
rename
the
file
to
markdown,
we
replace
those
buttons
with
the
markdown
extensions
buttons
that
have
completely
different
action,
like
bold,
will
generate
completely
different
markup
for
the
for
the
markdown
files.
So
this
flexibility
should
be
should
should
we
keep
in
mind
as
well
when,
when
we
talk
about
the
the
the
graphical
extensions
and
the
way
we
connect
an
extension
to
these?
To
these
view,
components.
F
B
Well,
I
I
really
like
the
idea
of
of
delegating
of
what
I
see
as
abstracting
the
monaco
events
and
like
to
technically
offload
this.
What
whatever
you
want
to
do
with
like
cleanup,
or
something
like
this
to
offload
this
to
the
actual
user
of
an
extension,
rather
than
do
this
in
in
the
extension
itself
and
then
relying
on
the
source,
editor
events
like
the
custom
events,
instead
of
listening
directly
to
the
moniker
events
that
that
idea,
I
I
I
really
like.
B
However,
I
I
I
still
I'm
still
not
convinced
that
wrapping
like
wrapping
extension
into
the
view
component,
we're
like
we
are
not
doing
this
now
right.
So
we
technically
do
not
wrap
things
into
the
view
component.
We
have
the
view
component
separate
and
we
have
the
extension
as
the
as
as
like
a
bridge
right.
B
As
the
bridge,
so
this
this
part
I
like
this
part
I
like
and
again
like
I-
I
just
think
that
doing
it
this
way,
instead
of
like
wrapping
the
whole
editor
into
the
view
component,
will
be
much
simpler
to
implement
for
our
different
use
cases.
B
The
the
the
thing
that
we
should
keep
in
mind
is
how
this
whole
thing:
how
this
whole
system
will
be
working
in
the
context
of
non-view
applications,
but
so
far
I'm.
I
think
it's
it's
very
valuable
experience
we
have
now.
So,
let's,
let's
just
continue,
we
have
some.
We
have
an
hour
yeah
well,.
F
That's
that's
good
yeah!
That's
true!
We
haven't
solved
that
problem
of
how
we
can.
We
can
load
this
function
of
these
new
components
in
different
contexts.
I
think
that
we
can
explore
the
solutions
like
I
can
see
like
in
instantiating
the
markdown
this
mark,
that
live
preview
component,
that
we're
going
to
implement
now
inside
an
extension
and
then
just
like
listening
to
these
event,
listeners
and
and
turning
on
and
off
the
the
application
or
switching
the
state.
F
B
You
know
that's
right,
that's
what
we
have
everywhere
in
the
product
now
right,
so
we
have
nesting
of
the
view
applications
it's
like
it's.
I
think
we
have
plenty
of
places
where
we
nest
the
application
within
a
new
application
in
the
product
at
the
moment.
So
it's
it's
clearly
not
the
optimal
way,
but
since
since
we
are
still
like
the
code
base
is
still
not
homogeneous
like
we
are
not
100
percent
of
the
application.
B
Yet
that's
just
let's
as
from
time
to
time,
we
just
have
to
to
do
the
view
application
within
a
view,
application.
F
Well,
so
let's
go
to
the
next
step.
That
is
just
like
displaying
the
the
previous
channel.
Sorry,
the
preview
of
the
of
the
markdown.
F
I
think
that
it's
strange
that
we
still
don't
have
an
api
service
for
this
in
the
in
in
api.js,
but
ideally
we
would
put
this
in
a
different
module
and
just
import
it
from
the
components
for
now.
We
can
just
like
take
this
and
put
it
here.
F
And
then
right
now
we
are
invoking
the
preview
every
time.
The
document
changes
right.
B
Yes,
I'm
sorry,
I
was
muted.
I
think
I
think
so
you
mean
this
new
one
or
the
or
the
old
one
recurring
oil
in
production
and
the
introduction
the
one
in
production
we
invoke.
We
are
supposed
to
invoke
every
time
we
switch
to
the
markdown
file
or
switch
away
from
the
markdown
file.
B
We
no
no.
We
do.
We
do,
of
course,
like
when
user
types
we
have
this,
we
defer
the
fetch.
I
think
it's
300
milliseconds,
but
that's
that's
what
we
do.
Yes,
okay,.
F
So
we're
gonna
store
the
preview
here.
F
F
B
We
should
also
update
the
the
event
listener
right
to
to
get
the
content.
B
I
mean
the
the
the
event
listener
should
listen
that
we
have
in
the
repo
editor
it
has
to
get
the
content
and
then
set
the
content
to
the
assign
the
content
to
the
pro
to
the
data
here.
Right.
C
K
B
C
Same
name
for
consistency
for
constant
consistency's
sake:
oh
man,
friday,
is
stuff.
C
We
wait:
did
we
update
all
the
instances
of
this
of
this
property
in
the
component?
I
missed
that
when
you
renamed
the
the
property.
B
I
F
Yes
and
that's
what
that
that
was
pretty
much
the
main
point
of
my
life
proposing
experiment
like:
can
we
use
up
this
video
api
to
have
like
this
clean
separation
of
concerns
that
we
are
inheriting
from
from
from
the
framework
and
that
base?
You
know
like
distinguishing
all
of
the
concerns
like
listening
to
events
in
data
and
then
displaying
the
actual
preview,
like
it's
really
clear
where
something
wanna
start
on
the
other
ends
oops.
J
B
And
and
according
to
our
wait,
a
second
no,
I
know
what's
going
on,
I
just
have
to
switch,
we
didn't
yeah,
we
didn't
have
the
event
triggered
yet.
B
F
F
B
Was
that's,
that's
what
I
meant.
The
problem
is
like.
B
B
Monica
mode
will
get
value
so
on
the
model
on
change,
and
this
is
correct,
so
content
but
wait
a
second.
This
is
just
constant
con
content.
This
is
not
this
dot
content
right,
that's
right,
yeah!
This
is
show
quantum
viewer,
not
what
we
are
looking
for.
Ooh
fancy
right!
Okay,
content!
Is
the
property
right?
F
F
B
F
F
F
B
B
F
B
B
In
the
the
actual
extension
now,
but
for
for
the
sake
of
the
experience,
it
does
work,
it's
nice.
The
the
question,
though,
comes
like
or
like
not
the
question,
but
if
we
will,
if
we
would
brainstorm
on
on
the
versatility
of
this
of
this
solution,
so.
B
If
we
need
to
unuse
this
extension,
it's
just
a
matter
of
like
saying
hide
this
component
right,
so
so
that
the
v,
if
is
false,
and
that's
good,
that's
good.
B
Well,
technically,
it's
it's
really
nice
with
so
in
regards
to
the
to
the
toolbar
like
this,
this
is
this
is
clearly
an
interesting
path
to
follow
for
for
the
for
the
live
preview,
how
does
it?
How
is
it
supposed
to
work
in
this
single
file?
Editor?
Where
we
don't
have
view.
F
Well
there
I
see
there
are
still
many
nodes.
Like
that's
alone,
the
toolbar
is
a
very
difficult
problem
and
I
don't
really
know
like
that.
That
requirement
that
you
talk
about
about
like
an
organization
through
others
remove
enemies.
The
only
thing
that
I
see
clear
in
there
is
that
probably
we
need
two
layers
of
extensions
one.
There
are
ui
extensions
and
then
the
other
one
are
the
data
extensions.
I.
B
So,
just
so
that
I
understand
correctly,
so
the
part
that
is
related
to
setting
up
the
ui
extension
will
still
be.
The
ui
extent
will
be
part
of
the
ui
extension
right
like
to
to
give
an
example
like
if
we
get
back
to
this
live
preview
extension.
So
there
is
plenty
of
work
that
has
to
be
done
in
order
to
prepare
this,
this
toggling
of
the
the
of
the
preview
right
so,
as
I
said,
keystroke
and
action,
so
that
should
be
part
of
this
visual
extension
technically
right.
F
Oh,
that
makes
sense
so
that
what
what
is
the
part
of
the
of
the
web
id
that
is
catching
the
keybindings?
Is
this
as
well.
B
Yeah,
it's
it's
tactically,
the
extension,
the
markdown
preview
extension
or
like
markdown
extension
at
the
moment,.
F
Is
actually
extending
monocoque
bindings?
What
I
could
do
is
just
like
expose
the
same
event
that
I
just
like
triggering
from
the
source
editor
and
then
allowing
the
web
id
to
handle
the
events
so.
B
Technically
this
just
you
know
just
to
to
get
the
general
picture
of
the
approach
we
took
here
today.
So.
B
So
technically,
technically,
the
ui
part
is
not
the
part
of
it
of
an
extension
as
long
unless
we
somehow,
on
extension
level,
we
assume
some
file
pattern
and
like
path
where
we
fetch
the
ui
component
or
something,
but
it's
going
to
be
challenging.
B
So
technically
we
we
leave
the
ui
like
we.
We
leave
the
business
logic
to
the
extension
and
we
leave
the
presentation
to
the
cloud
to
the
end
user
to
the
client
right.
B
This
means
that
present
ui
presentation
of
more
or
less
the
same
functionality
can
differ
in
different
places
in
the
product
because
of
different
ui
presentations,
like
haml
application
view
application.
Is
this
correct.
F
That's
correct:
it's
like
we
have
a
completely
completely
separate
like
the
business
logic
that
is
related
with
the
with
the
itex
model,
the
the
link
that
I
faced.
We
separate
that
business
logic
from
what
is
you
know
implementing
like
these
mini
applications
like
the
markdown
live,
and
we
just
like
allow
those
mini
applications
to
interact
with
the
source
cycle
through
event
listeners.
That's
what
would
be
like
the
interface.
D
We
can
see
what
we
need
to
reuse
like
what
the
requirements
are
actually
driving
and
then
drive
the
abstractions
that
are
necessary,
whether
it's
a
view
component,
that
is
a
toolbar
or
a
subset
of
a
toolbar
that
are
all
based
on
gitlab
ui.
But
let
let
the
usage
drive
how
we're
going
to
abstract
the
ui
parts
rather
than
trying
to
predict
what
that
should
be.
B
Yeah,
there
is
just
one
catch
with
this
like
I'm,
not
I'm
not
sure
it's
going
to
be
major
again
getting
back
to
the
toolbar
so
implementing
the
toolbar
as
the
view
component
in
the
non-view
environment
of
the
rails
application
we
just,
we
will
have
to
create
the
view
application
anyway
right
for
this
component,
if
we
are
implementing
editor
in
the
haml
part
of
the
application,
so
we
implement
toolbar
as
a
new
application
and
then.
B
We
have
the
the
live
preview
as
the
complete
self-contained
view
application,
and
it
becomes
a
bit
different
use
case
comparing
to
what
we
have
now
we
were
operating
under
the
view
umbrella,
so
we
we
had
the
editor
in
view
already
right.
F
F
We
can
find
a
way
of
fixing
sharing
it
within
the
view
up
in
those
places.
Where
view
is
not,
you
know,
we
are
not
using
view
for
the
single
for
four
days
and
then,
like
you,
know,
create
a
bridge
between
that
view.
Application
on
the
source
or
the
other
option
is
just
like
add
view
to
that.
To
that
place
right,
you
know
why
why
why?
What
is
the
limitation
that
we
have
right
now
that
we
cannot
add
view
to
a
single
violator
other
than
time?
Well,
there
is
no.
B
Like
no
strict
limitation
there
and
no
concerns
the
problem
is
just
every
time
we
add
a
view
application
we
harm
performance
because
whatever
we
do
with
our
whatever
we
wrap
with
the
view
application
slows
down
performance
simply
because
any
bootstrapping
happens
only
after
we
loaded
the
view
loaded
the
components
and
went
through
the
javascript
bootstrapping
of
that
view
application.
So
it
hires
performance,
not
necessarily
hitting
it
hard,
but
it
does
harm
performance.
B
So
that's
that's
why
some
of
some
parts
of
the
application
are
pretty
resistant
to
to
reflect
to
be
reflected
to
to
to
view
because
they
want
to
be
fast.
I
don't
believe
this
is.
This
is
the
case
for
for
editing
a
blob,
though
adding
blobs
adding
the
single
file.
B
B
Like
egg
and
chicken
problem,
like
the
way
we
arch
that
source
editor
requires
us
to
refactor
to
view,
there
is
no
other
obvious
reason
for
us
to
do
that.
Rather
than
use
the
component
that
might
not
even
be
required
like
consider
the
scenario
for
a
project
where
users
just
go
and
edit
only
javascript
files,
they
won't
need
the
live
preview.
B
So
the
only
reason
why
we
would
drop
this
interview
is
because
we
assume
that
some
of
the
users
will
want
to
edit
markdown
files
and
we'll
want
to
have
the
live
preview.
So
that's
that's
sort
of
the
justification
we
have
so
far.
There
is
no
technical
reason
to
to
migrate
those
views
to
those
four
like
editing
interfaces
to
be.
Apart
from
that.
B
F
B
Yeah
pipeline
editor
is
viewed
like
they're
they're,
using
the
view
component
of
the
source
editor
the
the
implementation
that
security
team
has.
I'm
not
sure
I
don't
remember
the
snippets
are
view
absolutely
so
technically.
There
are
not
that
many,
but
again
getting
back
to
our
think
big
discussion.
We
were
talking
about
maybe
introducing
the
editor
to
even
more
places
where
things
might
be
editable
and.
B
Well,
we,
as
I
said,
we
still
can't
justify
this,
like
we
say,
okay,
this
this
is
this
should
be
like,
within
the
view,
application
right,
the
or
another
way
of
doing
this
is
to
not
use
view
components
for
the
functionality
right
for
for
the
live
preview
of
markdown.
Technically,
we
don't
even
need
this
to
be
marked
to
be
view
a
component
right.
B
There
are
no
ui
elements
requiring
gitlab
ui,
for
example,
so
whether
we
implemented
this
as
the
plain
html
or
view
component
for
the
end
user,
it
won't
make
any
difference
like
when
they
look
at
the
page.
So
it
doesn't
really
need
to
be
the
view.
The
view
component,
it's
just
for
our
own
convenience,
technically.
D
Yeah,
that's
the
point
I
want
to
make
like
having
a
standardized,
understandable
interface
to
this.
That
was
one
of
the
the
benefits
that
we
pointed
out
of
this
approach.
People
understand
vue.
They
understand
how
it
works,
so
I
think
that,
like
rather
than
assuming
that
it's
a
constraint
that
we
may
not
have
where
we're
embedding
that
rdb
view
we
should
go
from
the
perspective.
We
are
going
to
have
a
standard
interface
that
this
is
a
view
component.
D
If
we
need
to
include
this
in
other
parts
of
the
app,
then
they
need
to
at
least
have
that
layer
converted
to
view
if
there's
performance
issues
with
that,
then
that
is
a
whole
separate
question
like
get
lab
is
all
in
on
view.
If
there's
performance
considerations
with
view,
then
we
need
to
deal
with
them
in
the
context
of
you.
K
F
D
Like
there's
the
statistics,
you
can
slice
them.
However,
you
want
okay,
eighty
percent
of,
like
all
of
the
ruby
code,
that's
that
actually
still
sounds
like
a
lot.
Eighty
percent
of
all
of
the
lines
of
javascript,
okay,
that's
probably
a
bigger
number
or
the
number
of
files
of
view
versus
the
review
components
owned
versus
non.
D
You
know:
vanilla,
javascript,
that's
probably
a
much
larger
percentage
and,
like
enrique
said,
the
percentage
of
logic
or
files
that
we
have
around
editing,
that's
probably
mostly
view
and
then
whatever
is
left.
What
are
the
reasons
we
can't
convert
that
to
view
and
if
one
of
the
proposals
is
performance?
Okay,
let's
benchmark
that,
like
don't
make
assumptions
about
performance,
you
you
measure
it.
D
I
mean
the
the
way
that
I'm
thinking
of
it,
it
seems,
I
think
other
people
are
too
is
prioritizing
maintainability
and
a
clean
interface
loose
coupling
and
high
cohesion
for
this
context
and
the
that
will
drive
how
we
integrate
it
into
the
rest
of
the
app
and
all
of
the
editing
context.
And
if
that
has
to
change
to
meet
those
prioritized
goals,
then
we'll
do
that.
B
You
know
I,
as
I
said
like
it's,
it's
totally
like
if
we
have
to
say
that
okay,
this
is
this
has
to
be
to
live
within
context
of
view
application.
That's
that's
the
restriction,
the
the
constraint
that
we
just
have
to
communicate.
That's
it!
That's
there's!
No,
no
problem
with
that.
The
only
the
only
thing
that
I
I'm
I'm
concerned
is
that
we
will
sort
of.
We
will
push
for
a
view
that
is
again
not
necessarily
a
bad
thing
like
we
will
push
for
view.
B
Even
for
the,
for
the
cases
where
view
is
not
needed
and
editor
instance
doesn't
mean,
doesn't
use
any
ui
components
at
all.
That's
that's
the
only
thing
that
I
see
architecturally
a
bit
weird,
but
not
necessarily
bad
like
for
the
unification
and
for
maintainability.
It
might
make
sense
and.
D
I
think
that
needs
to
be
done
for
other
reasons
like
on
the
captcha
stuff.
It
was
a
big
problem
with
the
parts
that
weren't
converted
to
view
yet
because,
like
we
had
this
very
clean
framework,
basically,
you
had
needed
zero
code
on
the
front
end.
If
you
were
already
using
vue
it
just
magically
worked
through
the
axios
and
at
the
other
interceptor
for
the
areas
of
the
app
that
weren't
converted.
It's
like.
Okay,
we
we
have
to
maintain
a
completely
different
implementation,
is
based
on
hamel
and
a
bunch
of
janky
stuff
and
like
no.
B
That's
that's.
That's
totally
totally
totally
valid
point.
The
the
the
only
problem
with
that
with
this
approach
is
that
we
as
the
group
we
do
not
control
all
parts
of
the
application.
We
cannot
tell
people
in
other
groups.
You
have
to
refactor
to
view
it's
like
it's
a
bit
too
pushy
like
the
areas
we
are
responsible
for,
we
can
do
whatever
we
want
for
other
par
for
the
other
areas.
It's
it's
a
bit
like
people
might
like.
The
other
groups
might
have
different
priorities
and
different
expectations
from
from
the
things.
D
Well,
at
that
point,
it's
a
product
decision.
It's
like
okay.
We
have
this
really
nice
editor
interface,
that
there
would
be
a
lot
of
benefits
to
using
this
throughout
the
product
in
a
standardized
way,
and
if
another
group
says
no,
we
don't
want
to
rewrite
it
to
view.
Then
it's
it's
not
up
to
us,
we're
saying
here's,
here's
what
we
provide
and
it's
a
product
decision,
whether.
F
K
B
Yeah,
no
fair
enough,
fair
enough,
so,
okay,
so
to
to
sum
up
today's
session.
Thank
you
very
much
for
for
leading
it
weekend.
It
was.
It
was
really
a
really
good
indication,
so
we
opt
out
for
saying
source
editor
is
supposed
to
be
used
within
the
view
context,
whether
you
do
you
work
with
ui
components
or
not
that
doesn't
really
make
any
difference,
so
we
we
strive
for
implementing
it
within
the
new
compiler.
Within
the
view
context.
B
We
think
about
two
different
types
of
extensions:
the
functional
extensions
and
the
the
ui
extensions.
How
to.
B
But
this
is
this
is
something
for
later.
We
are
we're
past
time,
I'm
sorry,
but
in
general,
we
we
keep
this
this
approach
in
mind,
and
we
strive
for
this,
because
I
really
like
the
the
the
way
the
ui
part
is
so
clean
and
very
easy
to
understand,
and
it
indeed
it
helps
us
to
to
decouple
the
extension
for,
like
the
business
logic
from
the
from
the
presentation-
and
this
is
this
is
huge
plus.
B
This
is
especially
considering
again
our
think
big
session,
where
we
said
that
we
want
this
to
be
light
and
gradual
experience.
It's
just
in
the
long
run
it's
going
to
be
easier
and
faster
to
build
new
ui
experiences
on
view
rather
than
reinventing
will.
So
I
I
think
this
this
all
makes
sense.
So
ui
parts
of
the
extensions
will
be
built
with
vue
and
how
we
frame
whether
whether
we
will
have
two
different
types
of
extensions,
or
it
will
be
one
extension
extension
type-
is
still
to
be
defined.
B
But
another
important
point
is
that
we
are
going
to
do
our
best
to
communicate
with
the
advanced
mission
from
the
extensions
and
then
listen
to
those
events.
On
the
client's
side
to
update
those
ui
components,
rather
than
do
all
sorts
of
magic
internally
in
in
the
extensions,
is
this
correct
summary
enrique
chad,
I'm
not
sure.
F
I
think
it's
it
is
correct.
Also.
I
want
to
to
link
the
conversation
of
a
meeting
events
to
the
to
your
proof
of
concept
of
monday
on
monday.
So
now,
like
you,
are
working
on
redefining
the
the
interface,
the
api
that
on
how
we
define
source
editor
extensions.
I
think
that
meeting
events
is
a
big
part
of
it,
but
basically
that's
it.
D
And
I
I
think
maybe
the
next
session
should
be
focused
around
looking
at
the
provided
inject
paradigm
that
that
paul
mentioned
like
is
because
that's
related
to
how
we're
exposing
the
events
and
having
a
narrow
interface
exposed.
B
Right,
I
I
took
a
look
at
this
at
the
snippet
and
technically
this,
like
the
the
injection
mechanism,
is
what's
missing
in
the
c
in
the
proof
of
concept.
At
the
moment,
I
I
think
we
have
to
during
the
next
session.
We
have
to
think
about
this.
B
What
problem
this
solves
and
how
does
it
help
help
the
extensions,
but
that's
that's
totally
totally
possible.
So
far.
The
proof
of
concept
at
the
moment
follows
pretty
much
all
of
these
ideas,
except
for
for
the
injection
part.
Okay
and-
and
yes,
we
do
have
clear
a
clear
api
for
the
extensions
now
we,
the
current
proof
of
concept,
totally
employs
the
inversion
of
of
control
and
that's
technically
it.
It
counts
for
all
the
discussions
we
had
previously
during
the
sessions.
B
So
that's
that's
what
we
are
going
to
to
go
with
in
the
in
the
main
line
and
if
we
are,
if
we
will
come
up
with
with
proper
irrational
behind
the
injections,
that's
going
to
be
easy
to
implement
because
it's
technically
a
very
easy
iterative
step
on
on
top
of
what
is
already
in
the
proof
of
concept.
B
So
that's
that's!
That's
good
to
discuss
and
see
the
like
to
to
check
with
the
real
use
cases
where
and
how
we
we
use
this.
B
So
that's
that's
a
good
point
and
the
next
session
we
will
have
on
monday,
I'm
wondering
whether
we
want
to
have
it
on
monday,
considering
that
the
30,
the
last
commit
of
this
milestone
will
be
on
13th
and
we
still
need
to
work
on
the
deliverables.
D
Yeah,
I'm
good
with
moving
it
later
in
the
week
since
paula
and
I
are
out
monday
too.
Oh.
B
Okay,
okay,
then
we
skip
the
the
monday
one
at
least,
and
and
do
our
best
to
deliver
some.
Some
good
results,
like
it's
pretty
sure.
B
To
when
we
move
it
up,
yeah
yeah,
we
could
so
we
could
discuss
this
asynchronously
or
I
will
try
to
find
the
time.
That's
that,
according
to
the
calendars
that
suits
most
of
us,
I
won't
I
like
in
in
the
worst
case.
We
just
skip
next
monday
and
we
take
the
one
on
18th.
D
D
B
Yeah
right
right,
that's
that's
a
very
good
point
and
friday
is
technically
no
meetings
day.
I
don't
want
to.
I
don't
want
to
spoil
this
pattern.
So,
okay,
I
will
try
to
find
the
day
and
then
we'll
just
I
will.
I
don't
know
we'll
have
a
poll
or
something
like
this
on
on
slack
to
to
find
the
suitable
time.
Okay,
okay,
good!
Thank
you
very
much
for
this
session.
It
was
really
nice.
Thank
you
very
much
again
enrique
for
driving
this.