►
Description
This is the first weekly catch up for the Rich Text Editor scaffolding and Wiki Vue migration efforts. In this meeting, we provide status updates of the progress made so far. We also discuss the following topics:
- Asynchronously loading Rich Text Editor dependencies
- The feasibility of using the markdown field Vue component as part of the Wiki page Vue migration.
- We talk about a strategy for generating test fixtures for the Rich Text Editor
A
Hi
everyone:
we
are
the
creator
team.
This
is
our
weekly
catch
up
on
the
development
of
the
escape
holding
different
factoring
of
the
wiki
page
today.
So
the
goal
of
this
of
today's
meeting
is
just
providing
some
status
updates
and
catching
up
on
what
progress
we've
made.
So
far,
probably
I
should
share
my
share
the
agenda.
A
So
yeah,
let's
start,
let's
start
with
the
rich
technique
or
scaffolding.
I
am
the
person
who
is
doing
the
the
meaning.
Fourth
here
and
last
week,
I
I
focus
on
on
creating
the
the
the
shade,
like
the
main
structure,
where
the
components
will
be
implemented.
This
is
their
link
to
the
nurse
request
and
right
now,
what
I'm
doing
is
figuring
out.
What
is
the
best
way
of
distributing
the
editor?
A
So
I
received
some
feedback
from
from
it
and
he
told
me
that
having
a
separate
bundle
for
the
rich
taxation
was
not
necessary
because
gidlab
ui
supports
three
shading,
so
that
means
that
webpack
is
going
to
have
removed
the
rich
text
editor
component
and
its
dependencies
when
the
ether
is
not
imported
like
specifically
or
it's
not
specified
in
the
in
the
import
statement,
and
I
thought
like
well-
okay,
that's
great,
then
I
I
think
that
I
shouldn't
be
adding
like
creating
a
separate
bottle.
There.
A
B
A
A
Other
the
other
layer
of
information
that
he
mentioned
is
providing
is
that,
since
we
support
different
formats
in
the
weekly
other
than
martial,
we
probably
want
to
load
the
aether
synchronously,
because
you
may
start
with
a
different
format.
And
then,
once
you
decide
to
use
a
marginal
format,
then
you
can
load
the
eighth
russian
groups.
That's
what
you
mean
pretty
much
right.
A
We
are
gonna,
be
releasing
less
of
things
of
later,
because
we
don't
have
like
more
features,
but
you
know
the.
On
the
other
hand,
if
we
put
it
in
the
same
bowl
as
all
of
the
other
digital
appear
components,
we
are
going
to
be
updating
that
bundle
every
time
that
anything
of
this
is
sorry,
I
didn't
love
you
all
right.
B
Yes,
but
as
long
as
people
are
not
importing
rich
text,
editor
webpack
should
automatically
do
its
do
its
magic
and
separate.
This
text
editor
based
on
who
I
mean
how
common
is
it
to
import
this
thing,
but
yes,
to
be
on
on
a
safer
side
like
that,
it
does
make
sense
to
have
a
separate
bundle,
especially
if
it
doesn't
really
require
much.
A
Effort,
well,
I'm
gonna,
I'm
gonna.
Let's
see
what
what
also
ip
says
about
about
this,
but
thanks
for
thanks
for
these
thoughts,
so
yeah
then
next,
like
my
next
step,
would
be
to
what
the
dependencies
and
set
up
the
test
environment.
Since
we
talked
last
week
about
about
having
a
pairing
session
or
scaling
periodization.
Today
I
was
wondering
if
you
know
if
we
could
like
set
up
one,
perhaps
tomorrow
or
later
this
week,
to
work
on
this.
A
B
C
A
A
B
B
So
so
yeah,
this
is
the
the
edit
page,
and
this
is
the
edit
form
that
we
have
this
particular
part,
including
the
buttons.
So
this
is
what
we
need
to
convert
to
view,
so
I
have
had
a
little
bit
of
success
in
like
like.
I
did
some
work
last
week
and
today
on
this,
and
I
was
able
to
convert
these
three
inputs
to
view,
and
I
just
need
to
like
port
some
logic
of
wikis.js
to
do
it
so
yeah.
We
now
initialize
a
new
wiki
form
app,
which
has
a.
B
Which
has
the
three
inputs
right
now
so
I'll
soon
be
adding
the
fourth
content
input
as
well,
so
that
should
actually
make
it
work.
So
there
are
two
different
states
that
this
form
is
in
you
either
open
a
new
page
or
you
either
edit
a
page.
So
that's
quite
simple
enough.
I
just
this
is
the
the
hamlet
file
and
I
just
pass
whatever
content
was
used
in
the
haml
file
to
to
the
form
from
vue.js
files,
as
as
data
elements.
A
So,
are
you
gonna
in
the
in
the
in
the
case
of
the
content
field?
Are
you
like
just
creating
a
text
area
and
then
using
the
same,
the
same
javascript
field?
Like
the
same
you
know
component.
I
think
it's
like
a
jquery
component,
that
that
is
using
the
in
the
hammer
version,
or
are
you
like
migrating
to
something
like
to
add
to
a
marketing
field
that
is
implemented
on
view.
B
B
A
B
B
B
A
A
A
B
I
think
we
can
do
it
even
with
our
view.
It's
just
a
good
to
have
thing
that
we
are
putting
this
particular
form
entirely
to
view
it
I
mean
we
cannot
really.
We
use
all
the
good
things
yet,
even
after
you
convert
it
to
vue,
you
would
still
have
to
convert
it
to
use
gl
components
because
gl
components
use
a
different
kind
of
style
and
wiki
is
still
in
old
style.
B
B
My
point
is
that
we
could
wrap
the
risk
text
editor
in
a
component
of
itself
and
then
just
initialize
the
component
through
haml,
and
we
can
do
that
selectively
based
on
whether
markdown
is
selected
selected
or
not,
and
you
know
we
can
do
that
little
bit
of
code
in
in
traditional
javascript
as
well,
but
yeah.
It's
it's
good
to
have
good
to
convert
it
to
view
first.
A
Hey
what
I
meant
was
like
right
now.
I
don't
know
how
to
describe
fully
describe
it,
but
dave.
The
wiki
is
using
for
mark
down
18
this
component
that
well
this
component,
that
that
is
using
that
that
that
has
support
like
for
auto
for
autocomplete
and
in
markdown
right,
but
it
also
has.
It
also
has
support
for
the
other
formats
like
ascii.com
and
things
like
that.
A
B
B
C
Confused
it
seemed
to
me,
like
you,
were
saying
different
things
you
enrique
were
saying,
convert
it
to
view,
but
don't
try
to
reuse
the
like
the
editor
components
from
the
issuable
and
other
places
just
make
it
like
a
plate.
Have
the
exact
same
behavior
that
the
hamel
form
did,
which
is
the
plain
text
area
or
whatever
right
so
but
himanshu.
You
were
saying
you're
talking
about
not
even
converting
it
to
view
at
all,
but
I
don't
think
that's
what
you
weren't
saying
enrique
you're
saying.
B
B
B
I
mean
not
not
really
everything
not
fully,
but
but
I
think
that
makes
things
easier
for
us.
So
if
we
already
have
a
markdown
renderer
component
in
view,
you
can
just
reuse
it
directly
since
the
wiki
markdown
hammel
code
also
like
points
to
the
markdown
renderer,
only
we
don't
really
have
separate
renderers
for
other
components.
A
Yes,
I
think
that
we're
in
the
same
page.
I
think
that
what
you,
what
you're
saying
is
like,
let's
take
the
form
like
the
entire
form
and
let's
migrate,
to
view,
so
then
this
mark
that
this
content
field,
that
is
like
the
place
where
you
put
either
mark
down
or
rush
or
ascii
dog.
Let's
keep
it
with
the
same
component
that
is
being
used
right
now,
because
the
market
field
doesn't
support
those
type
of
content
right.
A
Yeah,
I
completely
agree
with
that.
I
think
that
this
is
not
going
to
be
a
blocker
and
the
only
the
the
only
three
blockers
that
we
have
is
like
not
have
not
having
the
the
form
implemented
in
view,
but
other
than
that
like
migraine,
that
that
feel
that
content
feel
to
the
to
the
component
that
is
using
the
usables
is
not
required
at.
A
A
B
A
B
A
B
A
B
C
A
B
B
B
A
A
So
the
idea
is
that
we
have
features
that
are
generated
by
the
markdown
api
inputs
and
we
use
those
features
to
test
the
the
transmitter.
The
titan
slash
cross,
mirror
extensions,
so
the
the
goal
of
the
firing
session
would
be
to
make
progress
on
doing
that
like
setting
up
a
ci
environment
that
yeah
sorry
setting
up
a
ci
job
that
generates
those
features
by
making
the
customer
today
to
the
api,
and
then
you
know
setting
up
the
the
yes
specs
to
make
use
of
those
features.
C
C
C
There's
gonna
be
the
part
that
runs
as
a
scheduled
job
that
is
going
to
generate
and
probably
commit
to
the
repo
like
some
characterization
golden
master
type
things
that
would
probably
be
like
just
an
html
file
like
here's,
some
markdown,
you
know
just
a
bold
tag,
here's
the
result
resulting
html,
and
that
would
be
one
html
file
committed
and
then
the
javascript
tests
would
then
use
that
html
file
as
the
fixture
to
assert
against
what
the
output
of
tip
top
and
post
mirror
was
right.
That's.
C
C
Think
that
you
don't
need
to
worry
about
that,
like
you
can
just
assume
like
we're
not
going
to
turn
on
the
javascript
tests
until
the
html
files
exist
right,
so
the
schedule
files
will
run,
they
will
check
them
in
and
then
in
some
future
commit
like
we
won't
ever
implement
a
javascript
test
until
the
corresponding
html
file
already
exists.
So
you
don't
have
to
worry
about
that
sort
of
dependency
of
like
trying
to
introduce
the
file
and
commit
it
and
use
it
in
the
same
pipeline,
because
that
really
doesn't
work.
C
A
B
A
C
I
don't
know
I
was
two
reasons
to
when
you
make
the
apa
calls
are
inherently
going
to
be
flaky.
I
know
this
from
the
dub
dub
dub
ones.
The
api
calls
they
just
fail.
You
get
500
sometimes
so
you
have
to
have
retry
logic
around
it
and
therefore,
if
you
want
to
run
them
locally,
you
don't
want
that
slowness
and
flakiness.
When
you
run
them
locally,
you
just
want
it
to
run
against
a
committed
file.
It
works
every
single
time
and
it's
fast,
it's
just
pure
javascript.
C
C
C
A
A
C
Another
reason
to
commit
them
is,
then:
you
have
the
you
have
get
source
control
and
the
history
to
show
you
where
the
api
has
changed,
and
that
has
on
a
previous
project
on
on
pivotal
tracker.
We
did
that
same
sort
of
thing
like
for
the
documentation
of
the
api,
but
we
had
it
driven
by
some
files
that
were
committed
in
like
for
the
request
and
the
response.
So
then
it
was
really
easy
to
see
when
the
shape
of
your
api
changed.
Sometimes
it
was
intentional.