►
From YouTube: Source Editor: ITERATIVE multi file support
Description
The PoC, mentioned in the video: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/110001
A
Hello
during
our
very
short
discussion
about
the
multi-file
support
in
Source
editor
and
in
particular,
Bond
implementation
of
source
header
being
single
file
editor
earlier
this
week.
I
was
thinking
a
lot
about
how
we
can
pursue
this
approach,
pursue
this
idea,
but
still
not
overdo
it
right
from
the
start,
so
that
all
the
involved
parties
do
not
feel
obliged
to
contribute
right
away
and
I
think
that
we
could
take
a
very
iterative
approach
here
as
well.
A
Take
a
very
iterative
approach
here
as
well
and
now
I
would
like
to
demonstrate
what
I
mean
by
that.
So
let
me
just
switch
to
my
desktop,
so
we're
in
the
upholstery.
I
have
a
branch
that
I
made
POC
with
to
demonstrate
what
I
mean
by
by
the
iterative
approach
here.
So,
let's
try
to
create
a
new
file.
A
The
we
are
still
in
the
single
file
editor
we're
still
in
one
file,
editing
mode.
This
is
Source
editor.
The
toolbar
I
have
the
feature
flag
enabled
locally
for
myself.
The
toolbar
is
here,
and
there
is
this
button
to
toggle
file
tree
when
we
click
it.
We
get
instant
access
to
all
the
files
of
the
repository
files
and
folders.
A
A
The
the
things
to
note
here
is
are
that
when
you
hover
over
a
file
it
says
edit
and
then,
when
you
hover
over
a
folder,
it
says
open,
because
we
do
not
edit
the
folder.
We
just
drill
down
the
while
we
are
here
or
actually
we'll
get
back
to
this.
The
interesting
thing
is
that
this
approach
is
still
single
file
mode,
aware
and
single
file
first
approach.
So
if
you,
for
example,
find
what
you
want
it
and
focus
back
to
the
to
the
editor,
the
tree
is
gone.
It's
not
here
permanently.
It's
not!
A
This
is
done
on
purpose
to
not
project
this
as
anything
real
important.
It
is
here
just
to
help
when
users
need
this
once
users
are
done,
we're
back
to
editing
this
file.
However,
what
I
mean
by
the
iterative
approach
here
is
that
if
you,
for
example,
click
the
edit
adopters
link,
it's
not
going
to
do
anything
with
the
single
file
editor
here.
A
It
will
open
a
new
top
and
switch
straight
to
the
editing
mode
of
the
doctors
markdown
file,
so
that
you
can
open
any
number
of
the
files
to
edit.
They
will
still
create
multiple
commands
if
you
edit
them
and
save,
but
it
allows
users
to
still
have
context
of
where
they
are
in
the
repository
when
working
with
the
repository
and
if
you,
if
in
this
new
file,
if
we
click
this
tree,
you
will
have
the
highlighting
in
the
file
tree
telling
you
where
you
are
actually
in
the
tree.
A
Let's
make
it
a
bit
more
complex,
let's
go
to
the
test
pack
and
open
instance
spec,
for
example,
let's,
let's
edit
this
file
and
if
you
click
the
file
tree,
we'll
dive
straight
into
the
tests
pack
and
the
instance
pack
will
be
highlighted,
so
it
kind
of
tells
probably
this
should
not
be
clickable
anymore.
We
are
on
already
on
this
file,
but
again
this
is
POC
and
nothing
more
than
that.
So
if
we
are
happy
with
what
is
going
on
in
the
tree,
we
continue
editing
our
file
change
it
commit
and
things
go
this
way.
A
The
things
to
note
here
is
the
Stop
Bar.
So
whenever
you
drill
to
any
folder
the
first
step
into
folder
into
the
sub
into
the
folder
of
repository,
you
will
get
this
back
button
right.
Go
to
parent
folder,
but
if
you
dive
two
steps
down
from
the
root
of
the
repository,
you
will
also
get
this
home
button,
so
this
one
will
bring
you
back
to
the
test
level
but
oops.
A
But
if
you
click,
if
you're
in
test
spec
and
click
this
house
icon
home
icon,
you
will
get
to
the
root
of
the
repository.
So
this
way
users
can
easily
navigate
the
treat,
get
the
feel
at
least
to
get
the
feeling
and
understanding
of
where
they
are
and
if
they
need
to
edit
one
any
other
file,
they
can
easily
do
this.
A
They
still
will
be
in
the
context
of
the
single
file,
editing
experience,
but
they
will
get
this
additional
layer
of
awareness
of
their
where
they
are
of
their
context,
which
is
quite
quite
interesting
in
my
opinion.
So
what
is
what
can
it
give
us?
What
does
this
very
pretty
simple
extension?
Give
us,
oh,
actually
take
a
look
at
this
once
you
dive
into
the
into
the
folder.
The
content
of
this
folder
gets
cached,
so
we
use
Apollo
here,
graphql
and
Apollo.
A
So
all
the
requests
we
make
to
get
the
sub
items.
Some
items
are
of
the
folders,
so
subfolders
and
items
in
that
folder
are
not
fetched
right
away.
They
are
fetched
when
you,
when
we
get
there
first
time
after
that
they
get
cached
and
they
are
presented
instantly
to
to
the
user
without
any
additional
server
side
requests.
So
performance
wise.
This
is
a
very,
very
lightweight
solution
and
is
very,
very
performant.
So
what
can
this
solution
give
us?
First
of
all,
as
I
said,
this
is
an
iterative
approach
towards
the
ultimate
end.
A
End
goal
of
multi-file
support
in
Source
editor.
However,
this
particular
step
Don't
doesn't
require
back
end,
doesn't
require
any
infrastructure.
It
doesn't
require
any
cross-team
collaborations.
It
doesn't
even
require
that
much
from
the
U
UI
from
designers,
because
it's
it's
pretty
simple.
It
follows
the
same
ideas
we
have
in
the
tree
of
the
repository
that
is
already
there,
so
there
might
be
some
some
twitches
and
some
tweaks
and
improvements,
but
again
those
can't
be
taken
iteratively.
So
this
is
a
very
lightweight,
very
low
hanging
fruit
towards
these
ultimate
goal.
A
So,
what
to
think
about.
After
this
implementation,
let's
say
we.
We
agreed
that
this
implementation
is,
is
fine
and
we
can
go
so
file
operations
like
add
new
file
and
delete
the
file
from
the
from
the
tree.
These
are
not
here
and
they're
not
supposed
to
be
here,
because
that's
that's
already
getting
into
the
committing
and
the
different
all
sorts
of
back
end
involved,
involving
operations,
so
file
operations,
actual
editing
of
the
multiple
files.
This
is
the
most
tricky
part
as
we
discussed.
How
do
we
want
to
present
this?
A
A
The
main
question
is
what
it
does
it.
What
does
it
take
to
get
this
in
production
implemented?
So,
first
of
all,
we
have
to
finish
the
migration
of
all
the
buttons
to
from
from
the
a
conventional
toolbar
from
from
this
Toolbar
to
the
markdown
to
the
source,
editor
toolbar.
So,
for
example,
the
only
button
that
is
left
there
is
the
no
wrap
previously
I
couldn't
migrate.
A
A
Let's
say
here
than
the
all
of
the
buttons
are
here:
they
just
need
to
be
placed
differently
according
to
the
designs
from
Julia,
and
then
they
know,
wrap
is
the
only
one
button
that
is
left
to
migrate
here.
After
that,
we
can
might
add
this
button
to
the
toolbar
as
well
through
the
file
tree
extension.
A
The
thing
that
prevents
this
from
being
active
in
the
production,
of
course
not
only
the
buttons
but
the
feature
flag.
The
feature
flag
now
in
production
is
rolled
out
only
to
the
members
of
the
editor
group,
so
there's
buttons
on
the
source
editor
the
whole
Source.
Editor
toolbar
is
not
available
to
the
to
anybody
outside
of
the
editor
group,
so
we
might
consider
once
all
the
buttons
are
migrated.
A
Where
is
the
POC
I
well
link
the
poc
in
the
in
the
issue,
I
think
and
we'll
link
it
in
the
description
of
this
video,
but
in
general
that's
just
the
technical
detail
right.
So
the
main
things
to
have
it
in
production
is
to
finish
the
migration
of
the
buttons
and
roll
out
the
feature
flag.
After
that
we
can
start
Gathering
statistical
data
and
take
this
first,
very
subtle,
very
gentle,
step
towards
the
multi-file
support
and
Source
editor
without
dramatic
changes
in
dramatic
involvement
from
anybody.
Technically
I
hope
you
enjoyed
this.