►
Description
January 24th, 2022.
The links mentioned in the video:
- The Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/349635
- The PoC #1: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/78579
- The PoC #2: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/79013
A
Hello,
everyone
we
are
here
in
with
the
create
editor
group
to
talk
about
content,
editor
integration
into
the
editing
interfaces
of
the
product,
and
that's
going
to
be
a
very
short
introduction.
That's
that's
what
we
are
going
to
talk
about
today
in
the
agenda
linked
to
this
meeting.
There
are
links
in
the
in
the
in
the
agenda
for
this
meeting,
there's
a
link
to
the
issue
that
sparked
this
discussion,
and
there
are
two
links
to
two
pocs
and
just
to
make
it
clear.
A
These
pocs
do
not
compete
with
each
other.
It's
just
like
approaching
exactly
the
same
thing
from
different
angles,
so
that
we
could
have
a
fuller
picture
of
how
things
can
be
glued
together.
But
before
we
proceed,
I
would
like
probably
eric
to
sum
up:
what
is
what
is
the
end
goal?
What
what
are
we
supposed
to
implement
like,
and
I'm
asking
this
after
two
pocs
now
right?
So
what
and
why?
A
B
Just
go
on
yeah,
that's
a
good
question
for
the
recording
and
for
anybody
that
hasn't
heard
this
already
part
of
the
reason
for
the
specific
interest
right
now
in
doing
this
is
because
we
are
deprecating
and
removing
the
static
site
editor,
which,
for
a
small
number
of
people,
was
a
way
to
edit
our
handbook
or
similar
type
markdown
content
in
a
wysiwyg
manner.
B
Rewind
back
two
years
when
I
started
on
the
static
site
editor
and
a
lot
of
the
research,
there
was
around
non-developer
personas,
who
would
be
intimidated
by
the
repository
structure
intimidated
by
the
web
ide
itself
intimidated
by
markdown,
and
those
are
all
three
of
the
top
barriers
to
collaboration
and
contribution.
So,
with
the
winding
down
of
the
static
site
editor,
I
was
really
hoping
that
we
could
find
a
way
to
bring
people
into
the
web
ide
or
the
web
editor
or
somewhere
in
the
repository
view.
B
And
yes,
there
might
might
not
be
a
quite
as
seamless
and
abstracted
collaboration
flow,
but
if
they
can
find
the
file
they're
working
on
through
an
incoming
link
or
elsewhere,
you
know
elsewhere.
B
The
content
editor
already
does
most
of
it
and
some
of
it
it
does
even
better
than
the
static
cited
editor
ever
did,
and
the
big
concern
two
big
concerns:
one:
the
overall
user
experience
of
switching
between
the
two
views
source,
the
raw
source
of
markdown,
which
we
don't
want
to
get
rid
of,
and
the
visual
editing
keeping
those
in
sync
is
important
and
then
the
other
one
which
I
mentioned
in
the
issue,
which
we
know
as
a
problem,
is
the
ability
to
preserve
unchanged
markdown
or
other
types
of
content
in
the
document
that
may
not
be
interpreted
by
the
the
gfm
renderer
or
something
like
that,
so
those
those
being
the
two
major
like
experience,
concerns
and
the
the
reasoning
for
making
this
happen.
A
Okay,
cool.
Thank
you.
Thank
you.
Eric
hello,
david
we've
outlined
the
purpose
of
this
discussion
just
now
so,
okay
cool.
A
Do
we
have
any
no
okay,
enrique,
since
your
poc
you've
uploaded
the
poc?
Quite
quite
a
while?
Do
you
do
you
mind,
walking
us
through
it
and
explaining
what
what
is
the
rational
behind
this,
and
how
do
you
envision
this
implemented.
C
Poc
number
one,
so
this
poc
is
focused
on
pretty
much
integrating
the
the
continuator
into
the
web
ide.
The
idea
is
that
when
you-
oh
my
god,
I
don't
know-
I
don't
even
know
if
I
have
to
run
an
example.
No,
I'm
not
ready
for
that.
There's
a
youtube
video.
I
I
think
that
I
can
play
it.
Do
you
think
that
that
would
work
like?
So
you
can
see
how
the
poc
works.
C
I'm
gonna
just
play
it
here,
and
hopefully
I
can
play
a
youtube
video
and
continue
talking
with
you.
At
the
same
time,.
C
So
you
will
see
that
I
I
have
the
the
web
ide
open
here
with
a
text
file,
but
once
you
go
and
try
to
open
a
margin
file
instead
of
using
the
the
source
editor,
it's
gonna
use
the
the
configurator.
C
C
If
you
make
a
change,
if
you
add
something,
you
will
see
that
the
comment
button
is
is
enabled,
so
you
can
commit
changes
if
you
switch
to
a
to
a
different
to
a
different
app
like
the
code
review
mode,
the
review
changes
mode
or
the
com
mode,
it's
going
to
switch
to
the
source
either
again,
because
obviously
the
container
doesn't
have
a
diff
here.
B
By
the
way,
file
that
away
for
a
future
feature
request
a
diff
split
view
in
the
content.
Editor
would
be
pretty
cool.
C
E
C
That's
right,
so
the
contaminator
is
just
like
applying
its
formatting
preferences
for
markdown,
because
we
don't
have
a
good
mechanism
for
to
preserve.
They
don't
change
document
the
change,
don't
change
part
of
the
document.
So
why
did
I
create
this
proof
of
concept
so
denise
and
I
were
talking
about
what?
What
is
the
the
best
technical
direction
to
integrate
the
content
editor
in
the
web?
Ide?
C
I
think
that,
well,
you
dennis
made
a
point
that
integrating
the
continator
would
require
to
do
a
significant
refactoring
in
the
web
id
because
they
went
by
they
started
coupled
to
the
to
the
source
later,
so
I
decided
like
to
go
and
do
some
investigation
and
and
and
see
if,
if
we
actually
need
to
to
do
some
a
big
amount
of
work
to
change
that
assumption,
and
it
turns
out
that
it
didn't
you
know
like
I.
C
I
noticed
that
we
are
encapsulating
all
of
the
source
either
the
source,
either
logic
in
the
ripple
editor
component,
and
the
only
thing
that
I
have
to
do
was
to
say
hey,
you
know
if,
if,
if
the
user
has
a
preference,
it
has
to
use
a
container
to
hit
markdown,
I
just
need
to
switch
the
frequent
or
component
by
the
repo
continuator
component
and,
and
that
was
that,
like
the
the
only
requirement-
and
then
I
created
a
little
grappler
around
the
continent
or
for
the
web
id-
and
the
idea
basically
is
that
if
I
want
to
sync
the
changes
that
the
container
is
making
with
the
data
model
that
the
web
id
uses,
I
just
need
to
dispatch
some
ux
actions
to
achieve
that.
C
So
yeah,
that's
like
what.
Basically,
what
the
the
the
concept
illustrates,
like
the
simplicity
of
just
like
sticking
with
our
practices
of
using
view
and
using
the
tools
that
view
provides
to
integrate
the
container
in
the
web
ide.
C
I
know
there
are
things
that
we
have
to
improve.
For
example,
I
think
that
many
users
won't
prefer
using
the
the
continator
as
the
the
main
mark
donator
because
of
the
we
cannot
preserve
the
unchanged
document.
C
A
Cool,
thank
you
very
much.
Okay,
I've.
I've
put
a
couple
of
notes
in
the
agenda
so,
first
of
all
this
is
this
is
really
cool
demo
and
I'm
I'm
I
I
will
be
honest.
I
haven't.
I
haven't
expected
this
to
be
that
easy
to
implement
content
data
into
the
web
id
and
I'm
I'm
super
super
happy
to
see
that
it's.
It
is
actually
that
simple,
so
that
that
was
that
is
really
impressive
work
enrique.
Thank
you.
However,
I
have
a
question.
A
By
pulling
in
the
content
editor,
we
technically
create
two
sources
of
truth
or
like
two
things
that
manipulate
the
viewing
state.
It
can
be
a
source
code
source
editor.
It
can
be
content
editor.
Apparently
they
do
not
do
this
at
the
same
time.
A
But
is
this?
Is
this
really
like
this,
or
am
I
overlooking
something
like
we?
Are?
We
create
two
two
editors
that
change
the
same
state
technically.
C
Right
so
I
don't
see
the
the
source
of
truth,
like
I
don't
see
the
sources
through
being
located
in
the
editor.
I
only
see
the
editor
as
as
the
medium
that
the
user
uses
to
to
change
the
source
of
truth.
That
is
actually
the
model
that
is
ux,
so
we
have
like.
I
don't.
C
I
don't
have
a
lot
of
knowledge
of
how
the
web
id
works,
but
I
think
that
it
would
be
fair
to
say
that
we
have
like
a
a
file
model
that
that
tracks
that,
if
the
file
change,
which
is
the
the
active
file
and
it
stores
the
the
file
content,
so
that's
actually
the
the
source
is
true
what
they
editor
the
source
seater
and
the
container
those
it's
just
like
providing
a
a
user
interface.
C
So
so
the
user
can
change
the
file
and
then
that
triggers
some
sort
of
action
to
the
model
to
change
it
right.
So
it's
so!
It's
like.
C
E
I
I
just
to
piggyback
on
it
like
there
is.
We
do
want
to
make
sure
that
the
repo
editor,
if
we're
treating
vuex
as
a
single
source
of
truth,
we
need
to
make
sure
view
x,
is
the
single
source
of
truth,
and
something
would
be
off
if
the
repo
editor
is
doing
more
than
it
should.
So,
that's
something
to
look
at
if
there's
logic
happening
in
the
repo
editor
which
we
might
need
to
see
if
we
need
to
promote
up
in
the
view
x,
store
or
something
like
that,.
C
The
proof
of
concept
I
I
I
had
like
I-
I
could
rely
on
those
vox
actions
to
do
things
like
hey
this
dispatch,
this
action
to
to
change
the
the
the
file
state
and
then,
like
everything
else
around
in
the
web,
id
was
reacting
to
those
stage
changes.
So
I
think
that,
from
from
that
point
of
view,
the
the
separation
is,
it's
working.
It's
working
all
right.
E
E
Sorry,
the
point
that
I
was
saying
here
was:
if,
if
you
look
at
the
repo
editor,
like
you
see,
there's
a
whole
bunch
of
file
watchers
and
the
biggest
concern
would
be
if
one
of
those
file
watchers
is
actually
critical
to
like.
Based
on
this
state
change,
we
call
this
ux
action
and
none
of
it
really
has
to
do
with
repo
editor.
It's
really
should
probably
just
live
separately
in
its
own,
like
when
we
set
up
the
store
it's
worth
going
through
is.
If
we
want
this
to
be
separate
from
repo
editor
does.
E
Is
there
something
that
the
reaper
editor
is
doing
that
you
know
maybe
belongs
to
be
promoted
up
or
something
like
that.
I
I
agree
100,
that
yeah
the
components
we
should
be
able
to
you
know,
mix
and
match
components
as
needed,
because
ux
needs
to
be
that
single
source
of
truth,
but
unfortunately,
the
web
id
we've
done
a
number
of
cases
where
sometimes
components
are
doing
business
critical
logic
in
a
really
tightly
coupled
way-
and
I
don't
know-
if
that's
the
case
here
in
the
repo
editor
or
not.
F
Yeah,
so
I
just
wanted
to
add
that
that
we
already
have
a
couple
of
viewers
that
react
to
the
state
in
ux
right
now.
They
don't
really
edit
the
state
but
later
on.
If
you
wanted
to
make
them
edit.
The
state
like
if
you
wanted
to
edit
an
image,
let's
say
change
the
dimensions
of
an
image
or
something
like
that.
That
would
still
not
be
using
the
the
content
editor
or
the
associator.
F
It
would
use
its
own
image
editor,
so
yeah,
I'm
just
agreeing
to
the
fact
that
view
x
state
is
the
thing
is
a
single
source
of
truth
here.
A
Cool,
thank
you
paul,
the
your
ux.
No,
this.
E
Is
just
a
side
note
of
like
when
we
go
down
this
route?
I
know
just
as
a
developer.
E
If
I
click
on
a
markdown
file,
I
like
markdown
and
if
I
saw
a
wizzy
wig
I'd
freak
out
and
stop
abusing
the
editor.
G
A
Like
we,
I
think
we
can
all
agree
that
this
has
to
be
driven
by
user
preference,
where
user
decides
for
themselves
whether
they
want
to
to
use
to
edit
markdown
as
the
code
or
as
the
wizard.
The
only
thing
that
I'm
missing
is
the
switch
between
code
and
and
the
wizardweak.
That
would
be
super
cool.
That.
A
A
B
Anything
not
really
a
question,
but
just
to
reinforce
what
paul
said,
and
I
know
enrique
mentioned
that
would
be.
The
next
step
is
to
explore
ux
around
switching
between
these,
but
that's
absolutely
what
we
want.
We
want
to
be
able
to
in
the
same
session
you
shouldn't
have
to
decide
one
or
the
other
toggle
back
and
forth.
B
A
Exactly
exactly
my
thoughts
like
I,
I
really
like
writing
markdown
as
a
code,
but
when
it
comes
to
tables
man,
I've
tried
it
with
the
content
editor.
I
don't
want
to
go
back
to
code
like
the
tables,
adding
tables
in
the
content.
Editor
is
so
much
so
much
simpler.
That's
like
well,
I'm
switching
to
container
to
add
my
table
not.
B
To
mention
that
we
actually
make
it
easier
to
build
very
complex
tables
in
the
content,
editor
and
ones
that
you'd
have
to
just
write
in
straight
up
html,
if
you
really
wanted
to,
which
is
even
more
tedious.
Honestly.
A
Exactly
right,
yes,
so
this
is.
This
is
a
very
important
point
that
we
have
to
be
able
to
switch
between
the
editors,
not
only
from
the
preference
panel,
but
on
the
go
technically
okay,
I
have
finished
my
poc
only
today,
so
unfortunately
I
couldn't
provide
this
link
earlier.
I'm
I'm
very
sorry
for
that.
A
So
now
I
will
have
to
demonstrate
this
while,
while
we
are
on
the
call,
if
you
don't
mind-
and
I
will-
I
will
start
by
sharing
my
my
screen
now-
if
we
don't
have
any
comments
or
questions
about
the
first
poc.
A
The
second
poc,
where
is
it
like
here,
so
the
second
poc
is
based
as
we
as
as
one
could
could
expect
for
me
on
the
source,
editor
extension
that
wraps
around
the
content
editor.
My
rational
behind
this
was
that
I
do
want
to
preserve
the
same
editing.
A
Experience
like
we
have
a
lot
of
functionality
connected
to
the
way
source,
editor
communicates
or
like
not
source
editor,
but
some
some
bits
and
pieces
when
we
edit
the
files-
and
I
wanted
to
preserve
this
without
actually
mapping
the
apis
or
without
making,
without
updating
the
components
to
to
suit
both
use
cases.
A
Moreover,
I
was
I
was
by
design.
I
was
thinking
about
providing
exactly
the
same.
I
want
to
provide
the
same
editing
experience,
no
matter
where
we
are
editing
the
marginal
file,
be
it
web
id,
be
it
single
file
later
be
snippet,
be
anything
where
we
add
it
where
we
can
edit
a
margin
file,
and
I
will
be
honest-
I,
as
I
said,
I
wasn't
very
impressed
with
what
enrique
did
so.
My
poc
will
be
heavily
based
on
what
he
did.
I'm
sorry.
A
So
that's
because
there
were
some
some
really
neat
and
smart
ideas
in
that
in
that
poc
that
that
helped
me
to
shape
up
this
poc.
So
the
length
poc
is
in
the
in
the
agenda.
A
The
commits
are
split
like
you
will
find
the
content,
editor
extension
in
one
commit
and
then
integration
for
the
blobs
snippets
and
web
id
in
separate
commits,
so
that
we
could
go
through
those,
so
the
demo
time
I'll
start
with
the
let's,
let's
start
with
web
id,
since
we
were
at
the
web
id.
So
I'm
on
the
markdown
file
right
away.
A
What
this
extension
does
is
it
introduces
the
new
menu
as
long
as
we
don't
have
the
toolbar
yet
for
the
source
header.
Once
we
have
the
toolbar,
this
will
go
as
a
button
to
the
toolbar,
but
before
that
it
is
the
item
in
the
in
the
context
menu
or,
as
you
can
see,
shift
command
v
keystroke.
A
So
we
click
this
one.
And
here
we
go.
We
are
in
the
content,
editor
and
we
can
start
editing
things
right
away.
So.
A
And
like
do
some
emoji
or
something
like
this,
now,
keep
in
mind,
look
look
at
this.
First
of
all,
we
have
the
button
to
switch
back
to
the
code,
so
we
switch
back
to
the
code,
the
content
we
have
at
it
is
here
we
can
switch
back
to
the
wizardweak
and
again,
as
enrique
demonstrated,
the
the
changes
are
going
to
be
here.
A
They
are
in
sync
between
the
cloud
edit,
the
source
editor
and
the
content
editor,
and
that's
that's
how
technically
we
allow
in
this.
A
In
this
case,
things
are
no
different
from
from
the
first
poc,
except
for
this
ability
to
switch
between
the
editors
back
and
forth
technical
and
when
we
switched
like
this
panel
with
edit
and
preview
markdown
is
gone
when
we
switch
to
wiz
a
week,
because
there
is
nothing
to
preview,
we
are
looking
at
the
preview,
but
actually,
in
this
particular
case
we
can
combine
the
preview
for
those
who
are
working
with
with
markdown
files.
A
We
can
preview
if
we
want
and
then
like
technically
editing
in
wysiwyg
is
the
full
step
forward
for
for
the
visual
editing,
so
things
things
are
preserved,
things
get
get
saved
properly
and
in
this
particular
case,
we,
the
communication
between
the
content,
editor
and
the
source.
Editor
happens
with
with
the
properties
and
events
as
as
it
should
be.
A
The
content
editor
is
implemented
again,
as
the
view
component,
just
just
like
enrique
did
in
his
in
his
poc,
because
again
I
just
took
took
a
lot
of
ideas
from
his
from
his
poc.
A
The
only
thing
that
I
I
changed
was
I
wrapped
the
content,
the
original
content
editor
into
this
new
component,
that
is,
that
is
part
of
the
extension
in
order
to
be
able
to
set
up
the
slots
for
the
toolbar
of
the
condensator,
so
that
I
could
pass
in
the
button
to
switch
back
to
the
code,
and
I
have
significantly
comparing
to
the
first
poc
I
have
complete.
I
have
significantly
simplified
the
communication,
because
the
difference
here
is
that
I
do
not
communicate
changes
from
content
editor
to
the
source
header
on
every
change.
A
Technically,
once
we
make
one
change,
I
raise
the
flag.
Yes,
the
changes
are
there
and
then
that's
that's
pretty
much
it.
We
swap
the
con.
We
swap
the
content
when
we
switch
the
change
of
the
switch
the
editor
or
when
the
source
editor
explicitly
asks.
Content
editor
to
return
the
content,
it's
when,
for
example,
we
save
the
document
or
something
like
this.
A
A
At
any
point
in
time,
and
while
working
with
this,
it
helped
me
to
to
catch
a
couple
of
bugs
in
source
editor
and
shape
up
source
editor
as
well.
So
it
was
the
win-win
situation
here.
So
this
is
how
it
works
in
web
id
right.
So
it's
pretty
pretty
similar
to
how
it
works
in
in
the
fur,
in
the
first
poc.
But,
as
I
said,
implementing
this
as
the
as
an
extension
to
the
source,
header
allows
us
to
introduce
this
functionality
anywhere,
where
we
use
source
editor
and,
for
example,
the
single
source
editor.
A
A
Set
up
in
the
preferences
as
well,
if
I
want
always
open
my
markdown
files
with
the
wysiwyg
editor,
that
would
save
me
a
lot
of
clicks
sort
of
so
and
that
exactly
matches
the
the
scenario
where
we
talk
about
non-developer
users,
who
will
who
are
primarily
working
with
the
markdown
files,
but
okay,
we
in
this
case
it's
exactly
the
same
thing.
This
is
this
is
the
in
my
case.
In
my
my
opinion,
this
is
the
beauty
of
of
this
solution.
It's
exactly
this.
A
I
don't
know
something
again
like
emoji
and
we
can
switch
to
code
or
we
can
just
go
on
and
commit
the
changes
right
away
and
the
changes
will
be
saved
with
the
with
that
emoji
in
this
particular
case,
in
unicode
character.
So
that's
it
the
same
thing
for
the
snippet.
A
When
we
speak
about
the
snippets,
this
is
where,
where
I
think
the
beauty
of
of
this
particular
integration
comes
into
play
is,
if
I
have
we,
we
allow
up
to
10
snippets
in
the
multifile
snippet
scenario.
If
we
have
10
10
markdown
files,
it
will
cost
nothing
to
the
users
to
to
edit
the
to
to
lo,
to
start
this
page
with
the
10
source
editors
that
might
are
possible
to
switch
to
condenser.
A
I'm
not
sure
how
this
can
be.
This
is
going
to
be
implemented
with
the
content
data,
but
I
suspect
we
would
need
to
have
10
instances
of
the
content
editor
on
this
page.
I
don't
know
whether
it
will
affect
performance
or
not,
but
this
is
this
is
really
beyond
this.
This
particular
implementation
we
we
can
come
up
to
this
later,
but
in
the
snippets
exactly
the
same
thing,
just
exactly
the
same
functionality
in
all
the
instances
and
whenever,
wherever
we
can
use
source
editor
we
can
implement.
A
We
can
extend
the
experience
by
providing
this
with
weak
implementation
and
when
it
comes
to
the
particular
implementation.
So,
let's
just
take
a
look
at
how
how
simple
it
is
really
for,
for
example,
let's
take-
I
don't
know,
let's
take
web
id
to
compare
apples
to
apples,
so
all
it
takes
to
implement
this
in
web
id.
Is
this
so
and
most
like,
and
it's
most
of
it
is
just
moving
the
mechanism
of
setting
up
the
extensions
into
the
separate
async
function.
Otherwise
it's
really
exactly
the
same
web
id
yeah.
So
that's,
that's!
A
That's
it.
So
my
main
rational
behind
this
is
to
provide
exactly
the
same
editing
experience,
no
matter
what
part
of
the
project
you're
at
to
come
to
minimize,
if
not
eliminate
the
complexities
related
to
the
integration
part,
but
as
we
have
seen
in
the
first
poc,
it
doesn't
take
much
to
implement,
implement
this
in
web
id.
The
the
thing
is
that,
for
example,
single
file
editor.
It's
still
not
view
application,
it's
still
rails
plus
javascript
applications.
A
So
then
we
would
need
to
do
something
it's
a
bit
more
for
that,
but
not
too
much.
I
guess
for
the
first
poc.
So
really
it
boils
down
to
not
comparing
to
pocs
but
to
thinking
about
how
we
want
to
use
the
things
and
how
we
want
to
architect
the
things.
So
it's
really
to
me,
it
boils
down
to
the
architecture
decision
and
I'm
going
to
stop
sharing
my
screen
now
and
I'm
ready
for
for
the
questions.
E
I
I
left
a
comment,
but
I'm
diving
into
it
and
I
realized
my
comment
is
slightly
inaccurate
but
still
touches
on.
I
think
one
of
the
the
interesting
side
effects
of
doing
this
through
the
source,
editor
extension,
so
it
originally
looks
like
we're
going
to
be
mounting
a
view.
App
of
content
editor
inside
the
web
id
view
app,
but
I
see
that
we
actually
created
this
like
external
mounting
point
and
then
had
flags
to
that
like
through
css.
E
We
could
make
it
look
like
it
looked
like
it's
in
line
with
other
things,
I
guess,
or
I'm
not
sure
how
we're
making
it
when
it's
a
separate
view
app.
So.
A
This
is,
this
is
a
very
good
point.
The
the
view
bootstrapping
part
can
be.
The
reason
it
is
part
of
the
of
the
extension
at
the
moment
is
exactly
the
single
file
editor,
where
we
didn't.
A
Have
you
yet
and
to
be
honest
like
if
we
are
talking,
if
we're
talking
about
implementing
this
with
view
components,
probably
the
first
poc
will
be
simpler,
because
the
logic
of
the
current
extension
is
based
on
the
premises
that
everything
is
very
well
scoped,
and
I
want
to
be
to
make
sure
that
when
we
move
things
around,
they
will
keep
working
exactly
as
they
used
to.
So
I
don't
need
to
change
the
implementation,
don't
need
to
change
the
integration
part.
It's
it's
very
well,
scoped!
It's
in
my
opinion
having
having
it
well.
A
It's
very
easy
to
integrate,
as
as
we
have
seen,
it
doesn't
require
pretty
much
anything
just
using
one
more
extension
and
that's
that's
it,
and
when
it
comes
to
performance,
my
rational
is
that
markdown
not
first
of
all,
not
all
projects
use
markdown
files.
A
So
it's
kind
of
like
partial
usage
of
the
of
the
project
of
editing
the
files
and
also
the
visual
visually
editing
markdown
files
is
not,
as
we
have
seen,
is
not
like
default
option
for
everybody.
So
I
wanted
to
make
sure
that
this
is
really
the
experience.
A
Gradual
experience,
improvement
on
demand
when
users
request
this.
That's
where
we
serve
this
instead
of
just
doing
like
two
parallel
things.
That
was
my
rational.
C
So
I
think
that
at
the
end,
this
is
a
a
conversation
about
the
trade-off
that
we
get
from
the
portability
of
creating
a
single
source,
editor
extension
and
then
like.
We
can
just
like
use
this
infrastructure
that
they
consider
the
source
editor
provides
at
the
load
extension
everywhere
versus
following
a
developer
approach.
That
is
that
is
like
that.
That
is
that
we
are
more
familiar
by
using
the
the
view
framework.
C
This
is
a
conversation
that
we
had
like
months
ago
in
the
in
the
source
architecture
sessions
where
we
were
talking
about
like.
C
What
are
we,
what
what
we
would
be
sacrificing
like?
We
were
talking
like
when
we
implemented
the
a
demo
how
how
we
could
implement
the
the
markdown
live
preview.
So
we
tried
to
do
this
on
just
using
the
view
framework
and
it's
like.
Okay,
we
are
following
patterns
that
all
of
the
gitlab
developers
are
familiar
with
it's
easier
to
maintain
because,
like
vr3
provides
most
of
the
infrastructure
to
do
a
synchronous,
loading
of
components,
we
don't
have
to
handle
it
on
directly.
We
don't.
C
We
don't
have
to
deal
with
dumb
nodes.
We
don't
have
to
free
up
resources,
so
it's
pretty
much
the
the
same
conversation
and
I
think
that
it
both
it
boils
down
to
that
like
if,
from
an
architectural
point
of
view,
we
want
to
stick
with
the
the
are
the
the
big
and
the
well
the
wide
architectural
decisions
that
all
of
the
other
groups
in
github
are
following,
or
we
want
to
introduce
this
new
way
of,
like
you
know
like
integrating
ui
components
in
the
in
the
application.
A
These
are
very
good
points.
First
of
all
about
the
async
loading
components.
The
components
are
as
async
asynchronously
loaded
in
this
poc
as
they
are
in
the
first
one.
So
there
are,
there
is
no
change
in
that,
so
the
components
are,
as
I
think,
as
they
can
possibly
be.
Moreover,
the
the
editor
here
is
not
mounted
unless
we
user
explicitly
requests
this
this
component.
A
So
there
is
no
no
no
issue
with
synchronous
versus
asynchronous
here.
A
The
point
is
that
not
all
the
users
of
the
of
the
editors
that
might
want
this
to
be
implemented
in
their
parts
of
the
application
are
a
view
view
ready,
saying
that.
Well,
if
you
want
to
use
wiz
week
editor,
you
have
to
refactor
to
refactor
to
view
that's
that's
a
valid
point,
but
it's
it's
like
bringing
the
problem
from
our
table
to
their
table.
A
That's
that's
something
that
I,
I
think
is
still
valid.
It's
still
valid
to
communicate
that
we
expect
to
move
everything
the
whole
application
to
view,
but
it's
not
there
yet
right.
So
we
know
that
it's
still
mostly
rails
view.
Part
is
smaller
than
the
rails.
A
So,
that's
again,
that's
and
when
we
were
talking
about
the
this,
this
approach
at
the
architecture
session
we're
talking
about
exactly
the
small
ui
components,
in
my
opinion,
in
this
particular
case,
for
a
packaging
purpose
for
usability
purpose.
I
think
this
is
exactly
the
justified
case,
as
I
mentioned
in
the
comment
for
in
the
in
the
issue,
but
I
might
I
might
be
wrong
here
in
my
assumptions.
H
Yeah,
so
maybe
thinking
about
this
from
a
product
perspective
like
do
we
think
it's
reasonable
to
expect
that
every
place
that
there
is,
we
use
an
editor
that
we're
going
to
want
to
always
use
both
the
content,
editor
and
the
source
editor
to
support
editing
of
either.
I
don't
know
it
seems
like
a
reasonable
assumption
and
if
that's
the
case,
maybe
that's
something
that
leads
us
towards
yeah.
B
I
think
that's
the
most
compelling
part
about
that
approach
is
being
able
to
get
it
anywhere.
H
B
I
think
I
mean
to
to
get
right
to
it.
Yes,
I
think
there
probably
would
be
desire
in
any
instance
of
markdown
editing
to
switch
into
this.
At
least
I
like
to
think
there
would
be.
There
might
be
some
that
are
more
inclined,
like
maybe
in
snippets
they're,
probably
going
to
get
lower
usage.
That
would
be
fantastic
to
analyze,
but
I
can't
imagine
somebody
would
be
like
I
absolutely
do
not
want
to
have
wysiwyg
available
in
this
context
right
like
so.
B
Yes,
the
the
answer
is,
I
think
there
anywhere
markdown
is
written
in
git
lab,
for
example,
even
extending
this
to
issues
and
comments.
Although
I
know
that's
not
using
source
editor,
that's
another
place
where
you're
writing
markdown
that
I
would
imagine
we
would
want
to
have
it.
H
E
Well,
I,
for
one
want
zero
wizzywig
experiences
for
my
team,
because
it
just
makes
them
lazy,
I'm
joking!
No,
I
I
think
when
we
talk
about
reusing,
a
cohesive
thing
across
the
application,
I
think
vue
is
our
best
perspective
at
the
tool
set
of
doing
that,
and
so
it's
really
great.
We
have
a
content,
editor
component,
that
does
that
in
fact,
dennis's
poc
for
the
source,
editor
extension
reuses
that
same
component,
and
so
that's
that
is
really
great.
E
The
my
biggest
concern
with
the
source,
editor
poc
is
it's
a
it's
an
arc.
It's
a
view,
anti-pattern
and
red
flag
to
create
a
view
app
inside
of
a
view
app
so
right
now
we
have
sports
center
extensions
that
do
dom
manipulation
stuff,
but
it's
actually
creating
a
new
view.
App
inside
of
the
wider
web
id
view
app.
It
would
be
really
nice
if
the
source
editor
extensions
were
more
view.
Native
of
like
I
can
just
say
you
know,
hey.
I
want
to
here's.
E
My
service
editor
we're
doing
markdown
and
yes
sometimes
I
want
you.
I
want
you
to
use
the
content
editor
if
you
do
markdown
and
from
that
perspective,
even
though
not
everything
is
view
based,
you
know
we're
able.
We
do
have
patterns
of
pages.
That
aren't
completely
using
view.
Can
you
just
use
part
partly
view,
and
so
the
question
is:
does
that
part
just
use
the
content
editor
or
the
source
editor,
and
I
think
it'd
be
nice
to
have
just
one
component
for
the
entire
editing
experience,
but
it
has
to
be.
E
It
has
to
be
view
native
and
I
I
would
be
concerned
if
we
start
the
biggest
concern
is
if
we
spread
an
abstraction
that
is
leaky
and
flaky,
and
that's
why
I'm?
I
think
it's
help.
It's
helpful
that
we
have
content
editor
as
a
view
component.
It
feels
like
the
source.
Editor,
isn't
the
the
view
component.
It
doesn't
seem
to
play
nicely
with
the
ide,
and
I
think
that
would
be
a
prerequisite
for
doing
this.
A
Yep
thanks
for
a
comment
paul.
First
of
all,
there
are
a
bunch
of
places
where
we
do
have
view
up
in
the
view
app
in
our
product
just
to
begin
with.
A
So
it
is
the
red
flag
probably,
but
as
you
can
see
in
the
in
the
implementation,
this
view
application
bootstrapping
part
can
be
taken
out
of
the
of
the
extension
and
there
are.
There
are
technically
two
possibilities.
First,
is
we
create
two
different
extensions,
one
for
the
view
components
for
working?
In
the
view
environment
we
are
working
with
the
existing
view
of
view,
components
and
the
second
one
is
for
like
for
the
single
file
editor
where
we
we
write
it
so
that
you
application
is
bootstrapped
by
the
by
the
extension.
E
For
the
single
file
editor
like
like
why
why,
if
we
had,
why
don't
we
just
bootstrap
source
editor
if
the
source
editor
is
doing
content
editor,
like
I,
I
hear
what
you're
saying,
but
I
also
feel
like
you
know,
for
if
we're
using
view,
then
we
use
it
anywhere
up
the
component
tree.
We
don't
have
to
just
load
the
content
editor.
We
can
load
the
source
editor
as
the
view
component
if
the
source
center
vehicle.
A
The
the
view
component,
the
view
component
for
source
header
is,
is
more
limited
than
the
raw
source
header
and
that's.
E
My
and
that's
my
biggest
concern
and
that's
why
I
feel
like
if
we
want
to
be
able
to
switch
nicely
between
views,
I
feel
like
we
gotta.
The
source
editor
component
has
to
be
as
usable
and
be
able
to
do
as
robustly
the
same
amount
for
us
to
to
be
able
to
switch
components
and
stuff.
I
think
that's
a
that
would
be
really
nice,
and
so
my
concern
is
that
it
seems
like
the
source.
A
Okay,
so
switching
source
editor
to
to
be
just
view.
That's
like
that's
limiting
ourselves
in
my
opinion,
because
when
we
switch
to
view
three,
we
will
have
different
different
architecture
and
it's
like
it's
limiting
ourselves
in
the
long
perspective.
A
This
is
my
my
personal
opinion,
but
again
we
can
bootstrap
view
application
outside
of
the
extension.
Should
we
need
this,
we
can
tune
the
extension
so
that
it
works
with
the
existing
component
on
the
page.
The
problem
that
I
have
with
doing
the
hybrid
things
is
that
the
view
components
will
talk
to
each
other
using
view,
and
then
this
component,
with
the
with
the
source,
editor
extension,
will
will
be
speaking
different
language
kind
of
like
with
events
and
properties
right.
A
So
that's
that
that
sets
us
back
to
the
discussion
of
switching
source
header
to
be
a
view,
view
native
to
be
only
view,
but
that's
sort
of
that's
that's
another
thing.
I
guess
if
we,
if
we
really
want
this
whole
this
implementation,
to
be
view
only
done.
Probably
we
should
just
take
a
look
at
the
at
having
things
in
parallel
right.
A
I'm
source
editor
and
content
editor,
but
I
would
like
to
make
two
two
comments.
The
first
one
was
we
mentioned.
The
child
once
mentioned
wiki
and
fundamentally
editing
markdown
files
in
the
repository
and
in
wiki
are
two
different
things
like
wiki
is
100.
Markdown
repositories
are
not
repositories
are
actually
majority
of
the
files
in
the
repository
is
not
like,
depending
on
the
repository,
obviously,
but
a
majority
of
the
files
are
not
markdown
files.
A
So
that's
why
it's
important
to
to
actually
preserve
this
switch
between
source,
editor
and
content
and
content
editor
and
have
source
editor
still
to
be
to
be
able
to
to
to
orchestrate
this
process
and
what
I
like
about
this
second
approach.
The
second
poc
is
that
eric
mentioned
this.
We
don't
know
how
how
often
people
do
use.
We
would
use
wizardweak
in
the
repository
who
will
use
it
and
actually
with
this
approach.
A
It
would
allow
us
to
to
measure
this,
because
we
will
see
how
often
people
switch
to
to
content
editor.
How
often
people
store
content
editor
as
their
default
editor
for
markdown
files?
How
many?
How
often
people
open
the
files
without
switching
to
content
data?
So
it
this
this
poc
already
has
all
these
bases
for,
for
the
measurement,
I'm
pretty
sure
we
can.
A
We
can
make
the
first
poc
sort
of
statistics
aware
as
well,
so
this
this
should
not
be
sort
of
a
differentiating
factor,
but
I
do
I
I
do
like
how
how
it
is
easy.
It
is
with
the
with
the
second
approach:
it's
just
there,
like
all
the
measurement
things
will
be
there.
B
We're
almost
at
time
I
I
wanted
to
make
one
or
throw
one
more
point
out
there.
While
we
consider
the
direction-
and
I
think
this
plays
into
enrique-
maybe
something
that
is
related
to
what
you
just
posted
in
chat.
But
we
have
another
conversation
later
this
week,
paul's
going
to
be
presenting
a
potential
future
where
the
web
ide
is
no
longer
using
the
source,
editor
and
therefore
might
not
be
the
best
first
target
for
this
workflow.
So
what
changes
about
our
architectural
approach?
B
What
changes
if
we
target
the
web
editor
the
single
file
editor
first
or
exclusively,
does
that
enable
us
to
take
a
different
approach
or
focus
on
different
architectural
decisions?
If
we
know
that
the
web
ide
will
not
have
the
same
architecture
so
putting
that
out
there
enrique?
I
don't
know
if
that's
even
related
to
what
you
were
saying,
but
it
sounded
like
maybe
somewhat
related,
and
I
want
you
to
get
that
point
across
before
we
wrap
so
I'll
toss
it
to
you.
C
I
also
think
like
we,
the
the
single
violator
is
the
only
product
category
that
is
not
implemented
in
the
eu
right
now.
So
from
that
point
of
view,
a
source
later
extension.
B
So
well,
are
you
hearing
me
yeah
now
we
can
hear
you
sorry.
I.
A
B
Try
and
try
and
be
this
remote
work
nomad
life
you
gotta
well
anyway,
we're
at
word
time
anyway.
I
think
we
should
continue
that
async
there's
an
if
there's
not
an
issue
I'll
make
one,
but
I
think
we
can
use
the
issue
you
linked
in
this
to
yeah.
B
Summary
of
the
two
pocs
and
the
pros
and
cons
keep
this
going.
This
isn't
a
pressing
like
get
this
done.
This
milestone
kind
of
implementation
right,
so
I
want
to
make
the
right
decisions.
I
listed
a
few
things
that
I
think
are
prerequisites
and
the
one
I'll
throw
in
there
now
just
based
on
that
last
point
is
we
need
to
confu
convert
the
single
file
editor
to
view.
B
And
what
would
that
take
so
thoughts
about
that?
We
can.
We
can
keep
the
discussion
going,
but
this
has
been
helpful
for
me
to
understand
some
of
the
pros
and
cons.
B
It's
it's
I'm
optimistic
because
we've
already
gotten
so
far,
I
was
somewhat
afraid
it
was
just
going
to
be
like
there's
really
like
major
barriers
and
talking
between
the
two
and
or
you
know,
maybe
a
performance
bottleneck
or
something
like
that,
but
it
seems
like
these
are
very
good
architectural
discussions
that
I
that
I
know
you
will
all
resolve
and
come
to
the
best
decision.
But
it
looks
like
a
very
achievable
end
goal
in
the
near
future
and
yeah.
I'm
excited.
A
Cool,
so
we
have,
we
have
the
notes
in
the
in
the
agenda
probably
will
take
them
at
some
at
one
of
the
group
meetings
at
some
point
and
see
what
to
do
with
those.
A
But
thank
you
very
much
for
for
participating
in
this
call
and
expressing
the
opinions
and
the
concerns
so
the
again
to
wrap
it
up.
The
issue
and
both
pc
pocs
are
linked
in
the
agenda
so
for
anybody
who's
watching
the
recording.
Please
do
go
and
check
those
out
if
you
are
interested
thanks
dennis.