►
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
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
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
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
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.
F
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
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
D
H
D
F
F
F
F
F
A
F
F
F
F
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
F
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.
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
F
B
B
F
B
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
F
A
A
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
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
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.
J
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
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
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.
B
A
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
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
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
D
A
D
B
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
A
A
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
F
B
B
A
B
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.
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
A
A
A
A
B
B
F
I
A
F
F
F
A
B
A
B
K
A
F
F
I
A
H
I
A
J
A
I
F
A
K
A
K
A
I
A
A
D
A
A
D
A
D
B
J
B
B
J
A
B
C
B
C
I
B
C
C
C
F
B
I
F
F
A
F
A
A
B
A
F
J
A
D
A
D
A
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
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.
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
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.
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.
F
F
B
B
F
F
B
C
K
B
C
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
F
F
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
B
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
F
B
B
B
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.
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
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
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
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.
B
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
B
B
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.