►
From YouTube: Rich text editor / Wiki edit page Vue weekly catch up
Description
In this call, Himanshu, Chad, and Enrique discuss reverting the decision of implementing the Rich Text Editor in GitLab UI and putting the component in GitLab instead.
A
So
yeah,
let's
start,
I
have
the
first
point
on
the
which
text
editor.
Scaffolding
updates
and
I
have
well.
This
is
a
a
big
point
and
it's
about
analysis
that
that
I've
been
making
about
our
initial
decision
of
putting
the
frigid
x8
door
on
on
gitlab
ui.
So
I'm
gonna
verbalize
this.
So
we
have
a
a
a
summary
of
of
my
points
and
then
we
can
start
the
discussion
and
and
talk
about
it.
A
A
So
these
are
the
consequences
that
I
that
I
thought
about
until
now.
The
first
one
and
the
the
one
that
I
that
I'm
very
worried
about
is
the
support
for
internationalization.
So
usually
in
gitlab,
you
give
up
ui
components.
We
don't
put
labels
inside
the
components
because
they
are
abstract
enough
that
each
use
case
of
the
component
in
gitlab
will
have
a
different
like
their
own
specific
labels.
A
Well,
perhaps
we
can
well,
no
I'm
gonna
go
through
all
of
the
points
and
we
can
discuss.
I
was
thinking
like
perhaps
discussing
each
point
individually,
so
the
other
point
is
about
the
the
golden
master
tests.
I
think
that
we
should
do
like
we
should
pay
like
attention
and
I
think
the
implementing
those
tests
are.
Those
tests
is
very
important
and
we
are.
A
We
already
have
a
system
for
this
that
we
could
easily
reuse,
and
we
will
other
engineers
are
familiar
with
with
that.
So
I
think
that
we
could
take
a
lot
of
advantage
of
of
that.
Like
you
know,
it
will
be
more
maintainable
if
every
everyone
knows
how
to
listen
to
how
to
easily
generate
those
pictures.
A
And
finally,
I
think
that
you
know
moving
the
re.
I
I
feel
like
saying
repeatedly
that
I,
what
I
want
to
do
is
like
eventually
move
the
eight
or
to
to
get
lab
ui
once
we
have
history
books
set
in
place,
but
I
think
that
that
idea
doesn't
make
sense
like
you
might
imagine
that
we
decide
to
move
the
fridge
taxator
to
give
live
to
gtlab
in
three
months.
A
I
think
that
that
will
like
make
us
like
create
a
large
merchant
place
with
thousands
of
like
lines
of
code
that
probably
maintainers
won't
be
familiarized
with
and
and
that
we
like,
that.
That
is
not
consistent
with
our
development
process,
so
I
think
that
we
should
like
to
date
or
in
the
project
where
we
actually
want
to
you
know
to
we
want
that
component
to
live
from
there
from
the
beginning.
A
A
B
If
you
compare
it
with
the
markdown
editor
or,
let's
say
editor
light,
both
of
those
components
also
exist
in
both
of
those
components
also
exist
in
gitlab,
whereas
they
could
also
have
been
like,
like
by
the
logic
we
are
going.
They
could
also
have
been
in
gitlab
ui,
but
they
do
not
exist
in
gitlab
ui
for,
for
that
same
reason,.
B
So,
yes,
I
think
the
problem
that
we
have
right
now,
which
favors
gitlab
ui,
is
that
we
wouldn't
have.
We
wouldn't
really
have
the
documentation
in
one
place,
because
we
really
want
to
have
a
storybook
sort
of
thing.
But
then
again,
I
have
two
points
regarding
this.
The
first
point
I
already
discussed
that.
B
A
Yeah,
the
the
point
is
like
there
is
an
an
open
rfc
about
creating
in
including
history
book
in
gtlab
as
well,
so
we
can
take
components
like
the
like.
I
could
save
in
either
light
and
create
an
interactive
system
where
we
can
see
the
uses
of
a
component
that
cannot
exist
in
in
gitlab
ui,
and
we
are
you
know
we
are.
We
are
working
towards
that
like
there
is
an
open
mesh
request
with
reference
implementation,
but
there
are
many
technical
challenges
that
we
have
to
to
others.
First.
B
A
C
So
before
you
started
the
recording,
I
was
arguing
the
other
side
to
to
leave
it
there,
but
I
think
I
got
convinced
that
it's
better
to
have
it
in
gitlab
they.
I
definitely
think
we
should
try
to
work
on
the
storybook
implementation
and
maybe
like
raise
the
visibility
of
that
or
ask
the
rest
of
the
editor
team
to
help
with
it,
because
that
will
make
make
all
this
easier
to
see
what's
going
on,
and
the
other
thing
that
I
thought
of
is
and
I'll
put.
C
That
in
here
is
the
the
frameworks
we
have
this,
because
I
worked
on
this
last
week
too.
The
frameworks
we're
going
to
use
for
experimentation
and
future
flagging
and
for
metrics
it
will
be
much
easier
to
use
all
of
those
at
a
granular
granular
level
within
the
rich
text.
Editor
to
say
you
know
we're
working
on
this
particular
feature
within
the
rich
text.
C
A
That's
right
like,
rather
than
rather
than
like,
trying
to
skip
or
or
maneuver
around
rca
problems.
Perhaps
we
can.
We
should
face
those
problems
and
contribute
to
to
make
the
situation
better.
Another
point
that
I
didn't
put
in
there
in
the
document
that
I
also
think
that
is
important
is
that
eric
has
made
a
lot
of
emphasis
in
instruments
instruments
in
instrumentation.
A
And
he
wants
like
to
measure
the
usage
in
a
very
granular
level
of
all
of
the
actions
that
are
happening
in
in
the
editor
like
when
the
user
is
clicking
a
toolbar
button
or
the
user
is
executing
a
comment
again.
It's
like
the
common
pattern
here.
The
common
theme
is
that
the
library
provides
some
like
tools
for
for
handling
those
kind
of
use.
Cases
like
we
already
have
a
a
good
metric
system
that
we
can
use
to
implement
those
use
cases.
A
B
To
build
a
different
kind
of
static
site
editor,
I
mean
what
is
other
than
what
we
have
right
now,
so
we
might
need
some
additional
functionality
in
gitlab
and
we
might
in
order
to
do
that,
we
might
need
some
additional
functionality
in
both
gitlab
and
gitlab
ui,
and
it
would
be
very
cumbersome
to
work
in
on
both
repositories.
At
the
same
time,.
A
That's
right,
it's
like.
I
think
that
that
point
relates
to
the
golden
master,
with
our
golden
master
test
situation
like
we
have
to
implement.
If
we
want
like
to
commit
the
features
in
the
g
lab
repository,
we
have
to
create
a
custom
ci
job
in
in
gitlab
to
make
that
happen
and
then
combine
that
with
gilap
ui
by
implementing
something
else.
So
it
seems,
like
data
depends
on
gitlab
to
implement
several
things
and
we
have
to
work
on
two
repositories.
At
the
same
time,.
A
B
B
Yeah
gitlab
ui
components,
so
I'm
not
using
gitlab
ui
components
here,
for
example,
instead
of
using
gl
input,
I'm
actually
using
a
real
input
and
instead
of
using
gl,
select
I'm
using
a
regular
select
so
yeah.
I
I
don't
think
that
matters
much
right
now,
because,
as
long
as
the
it
looks
like
what
it
looked
like
earlier
and
the
functionality
remains
the
same,
we
can
do
it
in
the
next
step.
B
B
I
mean
it
works
correctly
for
existing
pages,
which
are
already
saved,
but
it
does
not
work
for
new
pages
need
to
figure
out
how
the
whole
thing
works
just
need
to
spend
a
little
more
time
on
it
and
and
yeah.
There
are
few
remaining
things
that
I
need
to
do
like,
like
the
javascript
written
earlier
in
old,
old
style
needs
to
be
converted
to
view,
and
we
need
to.
A
A
B
B
A
B
B
B
C
B
A
First
I'm
moving
what
I've
done
so
far
from
g
lab
ui
to
github,
which
which
isn't
a
lot
to
be
fair.
I
I
only
created,
like
the
theater
escafall
and
I
have
an
open,
merch
request
that
you've
been
reviewing
about
linking
the
dependencies.
It's
up
to
the
to
the
streets
text.
Editor,
I'm
going
to
close
out
merch
request.
A
A
I
was
going
to
well.
I
I've
been
thinking
about
that,
because
this
is
that
that's
different
from
the
from
the
golden
master
test,
because
you
are
not
complete
committing
the
fixtures.
So
what
we
can
do
is
like
look
what
the
front
end.
Fixtures,
though
those
is
that
it
generates
those
feature
pictures
every
time
that
the
ci
job
fronts.
So
they
are
not.
They
are
not
persistent.
They
are
transient
what
we
should
do
to
make
them.
A
A
golden
master
test
is
to
commit
jesus
snapshots
snapshot
tests,
so
we
generate
a
snapshot
that
com
that
is
committed
to
the
repository
outcome
and
contain
that
snapshot
will
be
compared
against
the
features.
That
is
the
feature
that
is
generated
in
the
ci,
and
I
think
that
achieves
the
same,
the
same
kind
of
test
that
I
you
know
that
I
call
the
master
characterization
test
is.
A
C
C
B
B
B
C
Right,
but
that
has
other
downsides,
it's
slow
it
and
it's
flaky.
It
has
the
potential
of
failing
the
api
fails
and
then
you
have
to
determine
which
version
of
the
api
you
run
it
against
like.
If
you
looked
at
the
comments
I
made
on
the
other
golden
master,
like
by
definition,
you
you
have
to
decide
what
version
you
of
the
live
running
api
you
have
to.
B
A
C
A
That's
where
that's
where
the
guess
snapshots
can
help
us,
because
when
let's
say
that
different,
let's
say
that
we
generate,
I
just
a
snapshot
that
it
could
be
like
the
first
one
that
will
be
that
will
be
generated
based
on
the
foreign
fixtures
that
we
are
generating
with
our
specs
right
and
we
commit
those
snapshots.
Those
snapshots
to
a
repository.
A
C
Okay,
that
makes
sense,
so
you
re
what
this
workflow
implies
is
when
the
back
end.
If
someone
changes
the
get
lap
flavored
marked
down
on
the
back
end
in
an
mr
that
forces
them
to
regenerate
the
snapshot
from
the
rich
text
editor
before
the
entire
build
can
pass
or
and
or
so,
if
it's
unintentional,
they
have
to
fix
the
regression.
If
it's
an
intentional
change,
they
either
have
to
at
the
same
time
implement
that
change
in
the
text
editor
or
pin
that
test
and
not
have
coverage
before
they
can
merge
it
exactly.
B
Yeah,
I
just
wanted
to
add
one
more
thing
here
that
I
don't
think
it
would
be
necessary
to
actually
commit
the
snapshots
like
we
have
in
in
the
integration
test.
We
have
the
ability
to
mock
a
particular
api
so
and
it
actually
sends
a
request
to
the
real
like
it
basically
sends
a
request
to
a
fixture,
so
you
would
just
generate
a
fixture
for
all
the
different
markdown
contents
we
have,
and
then
we
just
write
an
integration
test
to
compare
it.