►
Description
Before joining Meltano, Douwe Maan worked for a period of time on implementing a WYSIWYG editor in GitLab using TipTap and ProseMirror as a side project. We talked about his experience and the challenges he found along the way.
A
Cool
so
hello,
everyone,
I
I'm
enrique
of
the
service
educator
team
and
I'm
meeting
here
with
with
dogman
who
works
in
merton
montana
and
he's
been
hit
before
jumping
into
this
into
that
project.
He
spent
some
time
working
on
implementing
a
reciprocator
in
the
g
lab
product
using
the
the
technologies
that
we
are,
that
the
site
author
team
decided
to
use
to
implement
the
receiving
for
that
product.
I'm
talking
about
tita
trust
me
for
a
markdown
as
a
marketing
parser.
B
Yeah,
so
I
mean
I'll
start
by
setting
a
little
bit
of
context
for
why
I
ended
up
working
on
this.
What
you
see
is
that
you
get
markdown
stuff
anyway,
because
at
the
time
I
was
an
engineering
manager
for
the
backend
create
source
code
team,
which
has
nothing
to
do
obviously
with
front
end
or
with
markdown
or
whatever,
but
from
the
beginning
of
getting
to
gitlab.
B
A
B
So
one
of
the
very
first
things
I
added
to
gitlab
because
I
wanted
it-
and
I
just
did
it
on
in
my
free
time-
was
this
copy
as
markdown
feature
where,
if
you
copy
a
comment-
or
you
know
an
issue
post
or
even
a
markdown
file
and
a
repo,
that's
rendered
you
copy
it
to
your
clipboard
in
your
browser
and
then,
if
you
later
go
to
a
markdown
text
area
and
paste
it
again,
the
actual
pasted
text
would
be
the
same
markdown.
That
would
have
generated
that
that
visual
html
you
copied
yourself.
B
So
this
was
built
on
this
idea
of
okay.
You
know,
markdown
takes
this
markdown
syntax
and
it
translates
it
into
a
html
document,
object
model
so
like
basically
in
a
syntax
tree
or
whatever
tree
of
html
elements.
So
then,
if
we
know
for
each
html
element,
what
its
smart
time
representation
is,
we
should
also
be
able
to
take
the
copied
html
document
fragment
iterate
over
all
of
the
elements
in
a
nested
fashion
and
then
replace
each
leaf
element
with
the
actual
markdown
string.
B
B
If
you
come
across
an
h1
tag,
you
need
to
you
know
edit
one
pound
sign
at
the
front,
etc
and
then
later
on,
when
I
had
realized
okay
on
the
back
end
of
gitlab,
we
have
this
markdown
2,
html
conversion,
where
I
think
we
I
don't
know.
If
you
know
what
larry
we
use
right
now,
but
whatever
it
is,
we
have
one
and
it
has
a
ton
of
custom
gitlab
stuff
on
top
of
it,
and
then
we
have
this
javascript.
That
basically
does
the
translation
back
and
by
having
those
two
components.
B
I
thought
it
would
be
pretty
cool
if
we
could
have
the
markdown
text
areas
that
people
are
working
in
not
just
allow
you
to
paste
the
copy,
html
and
paste
in
this
markdown,
and
only
edit
this
markdown.
But
I
thought
it
should
be
possible
to
also
switch
between
markdown
and
html
modes
because
we
do
have
both
of
those
conversion
directions
implemented
in
gitlab
already.
So
then,
when
I
started
looking
for
the
options
that
existed
with
regards
to,
what
you
see
is
what
you
get
editors.
B
That
would
be
more
useful
for
specifically
having
markdown
as
kind
of
a
serialization
format,
a
lot
of
the
wikiwick
editors.
That,
of
course
exist
just
expect
that
it
generates
html
and
people
store
html.
In
the
background,
so
I
started
looking
for
something
that
would
allow
us
to
really
define
the
the
language.
I
guess
of
the
specific
elements
we
support
and
give
us
the
ability
to
both
render
them
to
html
for
the
actual,
which
is,
which
is
what
you
get
aspect
of
it.
B
But
then,
in
the
background
store
it
as
markdown,
so
that
on
the
back
end
of
gitlab,
it
can
still
just
store
markdown,
with
the
front-end
being
responsible
for
taking
notice,
easy
to
get
editor
and
generating
markdown
from
it,
because
of
course
we
don't
want
to
be
storing
actual
html
snippets
in
the
lab
itself.
So
I
thought
okay,
since
this
is
basically
the
same
step
of
taking
an
html
document
fragment
or
tree
and
turning
it
into
markdown.
B
The
moment
that
I
had
less
time
for
it
in
a
moment
I
left
gitlab
for
montano,
and
there
was
no
one
else
in
the
gitlab
from
an
organization
want
to
pick
it
up.
I
basically
just
left
it
there
and
never
touched
it
again,
which
meant
that
I
have
kind
of
gotten
stuck
in
the
middle
of
all
of
this
refactoring.
B
That
should
be
interpreted.
This
element,
as
well
as
the
rules
for
how
should
this
test
then
be
translated
into
markdown,
and
what
we
basically
ended
up
with
is
that
the
back-end
ruby
codes
would
be
responsible
for
translating
markdown
to
html,
because
it
needs
access
to
like
the
database
of
issues,
and
it
needs
to
have
access
to
all
of
these
back-end
systems.
For,
like
add,
username
references
and
the
like,
but
then
on
the
front
end,
we
could
do
the
reverse
step,
because
that
doesn't
require
any
any
help
from
the
back
end.
B
B
It
was
as
much
a
way
for
me
to
try
and
play
around
with
ujs
and
frozmir
and
to
as
it
was
a
way
of
actually
building
this
received
feature
which
I
thought
would
be
useful
for
me,
and
I
still
think
that
if
you
look
at,
for
example,
the
wysiwyg
markdown
editor
that
slack
has
now,
where
you
have
this
box,
where,
if
you
copy
a
line
and
hit
dict
face,
you
can
accidentally
mess
up
your
whole
message
and
then
yeah
whatever
I'm
pretty
sure.
What
I
we
were
working
on
would
have
been
better.
B
A
Well,
first,
thanks
for
for
that
story,
that's
that's
amazing
and
I
think
that's
a
that's
exactly.
Those
benefits
that
you
described
about
rosemeter
are
exactly
what
we
but
we
found
like
very
attractive,
and
we
that's
the
reason
that
we
chose
the
platform
like
we
can
take
every
element
defined
like
a
schema
for
that
element
where
we
say:
hey,
you're,
going
to
have
to
to
take
this
domain.
Convert
it
in
this
way,
but
at
the
same
time
we
can
do
the
same
with
markdown
right.
A
We
can
say,
like
this
markdown
note
in
the
abstract
syntax
tree,
translate
to
this
prosmitter
note
and
that's
a
big
awesome
part.
So,
okay,
so
try
to
recap.
The
only
reason
that
this
break
didn't
move
forward
is
because
this
was
basically
a
pet
project
of
yours,
something
that
was
not
practically
part
of
a
product
roadmap
and
and
basically
that.
B
Exactly
and
right,
and
in
the
beginning
of
the
project
I
had
like
a
couple
of
weeks
to
to
work
on
translating
all
of
the
gitlab
markdown
into
this
post
mirror
schema,
and
then
there
were,
of
course,
like
frequent,
like
rewards
when
I
actually
was
able
to
replace
the
copies
gfm
code
with
this
pros
mirror
setup.
But
then
I
got
into
this
place
where
I
was
just
working
kind
of
fighting
with
the
markdown
field.
B
A
Yeah,
that's
amazing.
You
know
I
I
was
looking
through
the
code
and
I
think
that
the
progress
was
amazing
for
the
short
time
that
you
dedicated
to
that.
Thank
you.
I
have.
I
have
a
question
about
the
markdown
to
html
conversion.
You
pointed
out
that
that,
should
you
decided
that
that
should
happen
in
the
back
end,
because
it
needs
references
to
some
deep
lab
entities
like
issues,
mercy
quest
and
all
of
that.
B
B
That
is
actually
inserted
into
the
into
the
dom.
When
we
render
a
comment.
So
what
we
would
do
is
that
if
we
had
on
the
wiziwig
editor
two
tabs,
markdown
and
rich,
if
you
make
changes
on
the
mark
on
the
when
it's
initialized
initially,
both
the
markdown
and
rich
tabs
have
used
the
right,
the
actual
html
we
got
from
the
backend
and
then
the
actual
markdown
we
got
from
the
back
end.
So
we
know
it's
it's
exactly
what
the
user
wrote
or
what
the
backhand
now
renders.
B
B
If
you
switch
from
the
wizard
to
the
the
markdown
tab,
we
can
of
course
use
frozmir
to
convert
the
html
or,
like
the
scheme,
prospero
schema
into
the
correct
markdown,
and
then
you
can
make
your
further
edits
in
the
markdown
tab.
But
then,
if
you
go
from
the
markdown
tab
to
the
wysiwyg
tab
again,
if
changes
have
been
made
on
the
markdown
tab,
we
need
to
do
another
round
trip
on
the
back
end,
because
only
the
end
knows
exactly
what
the
markdown
to
html
conversion
looks
like.
B
If
you
hit
the
save
button,
we
do
actually
again
take
that
pros,
mirror
schema,
convert
it
to
markdown
and
then
send
the
markdown
to
the
back
end
to
save,
and
then
the
backend
immediately
comes
back
with
both
the
markdown
in,
like
the
note
field
and
the
rendered
markdown
html
in
a
node
underscore
html
field,
and
then
again
we
would
use
that
to
update
both
the
editor
and
the
the
html
itself,
wherever
the
issue
or
the
comment
is
rendered
yeah.
So
we
did
have
an
extra
round
trip
there.
B
A
B
B
B
Again
because
markdown
hits
or
post
mirror
or
whatever
wouldn't
have
a
concept
of
all
of
these
github
favorite
markdown
things
like
the
user,
references
and
the
issue,
reference,
etc.
So
it's
something
I
never
looked
into,
because
it
was
so
obvious
that
we
needed
support
user
reference
etc
because
they're
so
common
in
comments
so
yeah.
No,
I
never
looked
into
re-implementing
that
on
the
front
end.
A
Yeah
in
in,
in
our
case,
what
we're
thinking
is
that
right,
one
of
the
of
the
problems
of
the
challenges
that
we
haven't
been
able
to
solve
in
the
statistic
is
that
we
have.
We
have
exactly
that
problem.
We
have
to
take
some
customers
and
syntax
and
we
have
to
parse
it
and
compare
it
to
another
converted
to
another
syntax
tree.
So
we
want
to
add
actually
that
component
as
well.
We
want
to
take
the
markdown
parser
and
extended
it.
A
B
B
Which
has
the
advantage,
of
course,
of
not
getting
out
of
sync
with
the
mapping
of
markdown
its
own
ast
to
pros
mirror
schema
and
the
mapping
of
html
to
pros
from
your
schema
and
then
upping
off
market
on
its
ast
to
html,
but
but
I'm
sure
at
this
point
you've
already
done
more
research
into
this
particular
issue
than
I
ever
needed
to
do.
So
I
don't
know
how
useful
my
my
insights
are
here.
A
It
is,
and
I
think
it
is
very
useful.
It
is
exactly
like
I
feel,
like
I'm
walking,
that
the
same
path
that
you
walk
through
like
while
implementing
that
yeah.
You
know
talking
about
what
you
were
saying
about
the
that
prosecutor
won't
help
a
lot,
because
actually
the
document
schema
that
they
provide
does
not
support
gitlab,
flavor
markdown
in
the
first
place.
B
Yeah
yeah.
We
also
found
that
there
are
some
slight
differences
between
the
markdown
schema
that
throws
mirror
comes
with
which
I
guess
is
based
on
mark
down
yet
and
the
actual
markdown
that
that
we
were
using
in
the
back
end
like
there
were
some
slight
differences
between
escaping
rules
and
and
whatever,
although
that
might
have
been
resolved
since
gitlab
moved
to
common
mark,
because
I
think
I
started
working
on
this
when
gitlab
was
still
on
a
red
carpet
or
whatever
it
was
at
the
time
on
the
ruby
side
of
things.
B
So
yeah
you'll
you'll
want
to
end
up
you'll
end
up
building
your
own
schema
anyway,
with
your
own
custom
elements
and
with
potential
changes
from
the
default
one
rosemary
ships
with.
If
you
wanted
to
have
a
one-to-one
kind
of
consistent
mapping
between
markdown
it
and
the
reverse
using
pros
mirror,
but
it
seems
like
for
the
static
site
editor.
Since
you
just
have
a
couple
of
custom
elements
on
top
of
markdown
itself,
you
should
be
able
to
get
started
with
just
the
standard.
B
B
A
A
B
So,
your
first
step
will
be
to
build
that
pro
smear
schema
for
cram
down
and,
of
course,
that
is
something
that
you
could
separately
open
source
and
have
the
community
kind
of
work
on,
because
that's
something
that
we
are
probably
not,
that
gitlab,
the
only
ones
who
benefit
from
it
and
there
might
be
other
kind
of
like
pros,
mirror
markdown
cam
down
utils.
You
can
also
write
and
share
with
the
rest
of
the
community,
but
but
yeah.
A
That's
right,
there
are
some
some
elements
in
well
when
I,
this
is
a
question
about
tifta
when
you
started
using
tiptop,
how
rich
was
dipped
up
in
utilities
provided
because,
right
now
they
have
like
this
document
schema.
They
created
their
own.
Prospectual
document
schema
with
a
lot
of
elements,
and
this
could
be
like
this
could
be.
You
know
a
way
of
speeding
up
the
process
of
mapping
g-lock
flavor
mark
down
to
to
prosmitter,
because
we
have
an
existing
schema
and
we
just
need
to
map
both
notes.
B
I
I
think
when
I
found
tiptop
it
was
super
new
and
I
had
only
recently
read
about
it
in
you
know
online
product
hunt
or
whatever,
and
actually
I
remember
that
at
the
time
tiptap
was
also
heavily
changing
still.
So
I
I
needed
to
update
the
version
every
couple
of
weeks
and
I
needed
to
make
changes
to
how
we'll
be
using
it,
so
it
wasn't
wrapped
at
early
stages
development.
So
I
can
definitely
imagine
that
now
a
year.
A
B
Half
down
the
line,
it's
become
a
lot
more
mature,
but
fortunate
or
like
it
has
a
broader.
You
know
range
of
stuff
supported
out
of
the
box,
but
close
mirror
itself,
of
course,
was
already
more
mature
than
tip-top
at
the
time.
So
I
felt
pretty
confident
going
with
this
new
tool,
because
pros
mirror
was
kind
of
doing
the
bulk
of
the
work
and
then
dipped
that
was
just
kind
of
this
wizzy
wig
layer
on
top
of
it
and
we
and
pros
mirror
or
tip
tap,
was
relatively
easy
to
understand.
B
A
Awesome
yeah,
thank
you.
I
I
think
it
has
evolved
a
lot
now
we
have.
There
is
a
2.0
version
coming
up,
but
it's
definitely
well
much
more
stable
and
I
completely
agree
that
you
know
the
the
core
of
the
work
is
on
pros
meter
and
that's
the
actual,
the
actually
stable
tool
that
we
are
going
to
be
relying
on.