►
From YouTube: Create:Editor. Source-to-Content switch discussion
Description
Discussing the ultimate goal of introducing the WYSIWYG functionality in parallel with code editing for simple markdown files and Static Site Editor replacement
A
Hello:
everyone
we're
here
to
talk
about
source,
the
content,
editor
switch
discussion
and
a
couple
of
weeks
ago
we
had
a
wonderful
presentation
by
enrique
where
he.
A
Right
that
was
shared.
I
I
have
I'm
confusing
all
the
all
these
discussions
we
had,
I
know
so.
We
we
had
a
presentation
where
we
looked
into
two
possible
ways
of
implementing
the
source,
the
content
editors
switch
after
that
we
had
a
discussion
with
enrique
and
with
the
staff
engineers
and,
after
all,
we've
got
the
what
what
seems
to
be
to
me
like
the
solution
we
have
to
pursue,
namely
to
introduce
the
shared
data
data
layer
which
will
manage
requests
to
the
to
different
apis.
A
We
have
at
the
moment,
for
both
editors
source,
header
and
content
editor,
and
this
shared
data
layer
will
connect
us
to
to
to
directly
to
api
for
the
rails,
applications
to
graphql
and
to
uix
store.
So
that's
that's
the
plan
we
have
at
the
moment.
A
So
that's
that's
what
I
would
like
to
talk
about
today,
whether
we
have
any
any
ideas
how
we
will
we
are
gonna
build
this.
Do
we
have
any
examples
of
how
we
will
build
this
and
whether
we,
whether
there
is
anything
we
should
keep
in
mind
and
be
aware
of
before
we
do
that
or
maybe
maybe
somebody
gave
another
thought
to
this
problem,
and
maybe
we
have
to
pursue
some
other
path.
A
No
okay
seems
like
we
are
all
in
agreement,
and
that's
that's
how
we
are
gonna
gonna
get
to
this.
So
technically,
if
this
is
the
case,
I
I
I
think
we
might
approach
the
whole.
The
whole
thing
of
the
source
to
content
editor
switch
in
parallel,
namely
enrique,
has
started
the
work
of
preserving
the
unchanged
markdown
in
the
files,
and
this
is
this
is
the
main
blocker
for
us
technically,
but
this
effort
of
shared
data
layer
can
be.
A
We
can
work
in
parallel
and
again
considering
considering
the
workload
considering
the
wish
of
of
the
group.
So
is
there
any?
Let's
say
mvc
like
way
of
implementing
this
shared
data
layer?
Can
we
do
it
like
what
is
the
absolute
minimum?
We
have
to
do
in
order
to
get
this
shared
data
layer.
B
A
This
is
a
this
is
a
good
point.
So,
first
of
all,
yes,
I
do
agree
that
we
have
to
start
with
one
place,
because
then
we
would
need
to
sort
of
this
is
this
is
probably
the
the
lowest
friction
solution
where
we
will
need
to
connect
like
to
only
one
real
data
source
in
our
in
our
abstraction
layer?
A
If
we,
if
we
target
only
one
application,
because
all
three
applications
we
have
now
like
web
ids
single
file,
letters,
direct
api
and
snippets
is
graphql,
so
the
best
would
be
indeed
to
take
just
one
application
and
hence
start
writing
this
proxy
layer,
so
that
we
we
connect
to
just
one
data
real
data
data
storage.
Underneath
the
question
is
whether
it
should
be
single
source,
editor,
web
id
or
snippets.
When
I
mentioned
some
snippets
on
slack
last
time,
so
technically.
A
A
Without
any
data
layer,
without
any
shared
data
layer,
we
can
start
doing
this.
We
can
start
implementing
this
switch
and
snippets
right
away
because
we
we
have
content
editor
as
a
view
component.
We
have
source
editors
view
component
and
there
is
no
need
to
update
for
for
the
snippets
use
case.
There
is
no
need
to
update
the
view
component
for
source
editor
to
to
work
with
extensions
and
things
like
this.
So
technically
we
can
start
doing
this
without
any
shared
data
layer.
But
technically
what
this
means
is
just
we.
A
We
postpone
the
solution
to
this
problem
to
later
and
since
we
because
again
why
we
can
do
it
now,
because
in
snippets
we
do
not
care
about
preserving
the
unchanged
markdown.
It's
it.
We
don't
care
about
divs
in
in
the
snippets.
So
snippets
is
a
good
candidate
for
starting
this
and
we
can.
We
can
implement
it
and
we
can
start
gathering
some
statistical
data
if
we
are
interested
in
that.
A
But,
as
eric
mentioned
in
slack,
snippets
won't
really
give
us
any
sensible
statistical
data,
because
it's
not
very
much
used,
especially
for
the
markdown,
especially
for
wheezyweek
functionality
in
markdown
in
in
the
snippets.
Apparently.
So
this
technically
means
that
we
will
just
spend
time,
probably
for
nothing
like
we'll
gain
some
experience,
but
this
experience
will
inevitably
be
moved
away
and
we
will
have
to
get
back
to
to
proper
implementation.
So
I
think
we
have
to
start
in
this
case.
We
have
to
start
with
the
single
file
editor.
A
And
implement
our
shared.layer
to
connect
both
editors
to
the
real
api,
since
this
is
the
the
single
file
layer
is
the
rails
application?
A
My
my
idea
is
that
we
have
to
initialize
view
application
on
the
the
problem
is
that
in
order
to
do
this
in
the
single
file
editor,
we
have
to
update
the
view
component
for
for
source
editor,
because
source
editor
in
single
file,
editor
does
use
extensions
and
use
them.
Use
extension
uses
extensions
extensively.
Let's
put
it
this
way,
so
this
is
one
more
friction
point
not
a
big
one
like
we
I've
already.
I
think
david
correct
me
if
I'm
wrong,
I
think
I've
put
this
for
49
the
view
component
yeah.
A
So
technically.
This
means
that
it
won't
happen
this
milestone.
But
if
we
can
approach
that
in
the
beginning
of
14
9,
then
we
will
be
able
to
to
start
looking
into
the
shared
data
layer
in
14.9
as
well,
because
my
plan
would
be
to
to
to
do
it
correct
right
from
the
start,
so
we,
instead
of
just
using
the
sword
the
raw
source
editor
on
the
single
file
letter.
A
We
will
use
the
view
component
to
to
be
on
the
same
page
with
the
content
editor
and
but
for
that
we
will
sort
of
initialize
the
view
application
just
for
the
editor
part,
and
then
we
will
have
to
use
a
source
editor
view
component
with
full
support
for
extensions
and
other
features
that
are
not
supported.
Yet.
A
B
That
makes
sense,
I
know
that
that
will
probably
increase
the
cost
of
inverting
the
continuator,
the
single
pilot
or
because
apparently
there
is
a
view,
migration
or
not-
maybe
a
no,
no,
not
view
migration.
I
think
that
we
could
like
instantiate
a
view
application
and
just
and
like
put
in
there
the
view
version
of
the
source
editor
right
there,
the
source
editor
that
is
like
wrapped
in
the
you
know
your
component
yeah.
Is
that
what
you.
A
Mean
yes,
I
I
mean
like
we,
we
do
have
the
source
editor
view
component
at
the
moment
it
is
the
sort
of
the
abstraction
for
the
for
the
full
size
source
editor
and
technically
we
can.
It
will
be
us
who
decides
how
far
far
we
go
in
this
process,
because
even
if
you
are
using
the
source
header
view
component,
you
can
still
get
access
to
the
raw
source
editor
in
this
component
and
technically
and
that's,
I
think,
that's
what
we
do
for
the
I
don't
confuse.
A
If
for
for
the
pipeline
editor,
we
use
the
view
component.
However,
we
access
directly
td
to
the
editor
underneath
it
in
order
to
install
the
in
order
to
use
the
the
extension.
So
we
can
do
do
it
that
way
without
actually
updating
the
view
component,
but
we
will
still
have
to
set
up
a
proper
communication
between,
like
from
the
source,
editor
and
listen
to
the
things
getting
into
the
source
area
in
order
to
to
to
make
source
editor
and
quantitator
to
speak
to
each
other.
A
When
it
comes
to
the
view
migration,
I
think
we
can
we.
We
can
identify
the
bare
minimum
that
we
have
to
convert
in
the
view,
and
this
probably
would
be
just
this
editor
part.
That
is
that
that
contains
the
editor.
So
we
will
convert
this
into
the
view.
Application
with
the
template
containing
source
header
view
component
and
content,
editor
view
component
or
content
content
editor
component.
A
If
we
are
on
the
markdown
file,
and
that
will
be
the
point
that
will
add
complexity
to
here
to
this
model
is
that
we
will
still
have
to
listen
to
events
from
outside
of
the
video
application,
because
when
one
clicks
the
buttons
on
the
on
the
markdown
toolbar
when
editing
in
a
single
file
later,
those
the
toolbar
is
just
again
the
rails
application
and
all
the
listeners
to
the
button
clicks
go
through.
A
Another
approach
would
be
to
wrap
both
the
editor
and
the
toolbar
with
the
with
the
view
application.
So
do
this
sort
of
migration.
That
would
be
the
correct
path
to
do
this,
but
this
would
mean
that
we
will
also
have
to
refactor
the
the
toolbar.
The
toolbar
for
the
source.
Editor
is
in
the
nbc
state
at
the
moment
like
in
the
mvc
of
mvc.
Let's
put
it
this
way,
it's
not
even
pushed
yet.
So
that's,
that's!
That's
another
approach
and
himanshu
do.
Do
you
mind
describing
what
you're,
what
you're
writing.
C
It's
a
bit
noisy
here,
but
I
can
describe
it
a
bit
briefly
so
so
right
now,
continuity
does
not
really
support
rendering
of
dynamic
content
or
any
kind
of
content.
That
content
editor,
like
other
renderers
support,
potentially
like
outside
of
gta
fm
and
underneath,
would
actually
render
it
as
plain
text,
which
means
that
any
paragraph
like
content,
you
have
that
would.
A
Okay,
so
you
mean,
if
I
am
doing
that
so
if
I'm
dynamically,
adding
markdown
that
is
like
I'm,
I'm
not
sure.
I
I
understand
what
what
is
not
support
like
we
do,
support
the
gfm
or
or
we
don't.
C
I'm
talking
about,
let's
say,
for
example,
in
the
handbook,
you
have
a
lot
of
ruby
code
inside
of.
C
Yeah
yeah,
so
those
would
be
converted
to
plain
text
and
you
would
lose
lose
them
completely
need
support
for
those.
If
you
yeah
enrique
has
his
stand
up,
I
think
he
would
explain
it
better.
B
Okay,
those
those
files
are
not
markdown
files,
those
are
erb
files,
they
are
converted
to
md,
so
we
could
disallow
opening
those
files
in
the
content
editor
and
we
could
get
rid
of
that
problem.
Does
it
make
sense?
It's
like.
D
Use
the
last
most
extension
file
type.
C
Yeah
yeah
we
can,
we
can
do
that,
but
since
you
can
right
now
you
can
open
those
files
and
content
later
sorry
in
static
site
editor,
and
if
you
want
to
like
deprecate,
study,
excited
editor
and
provide
a
sort
of
one-to-one
replacement
for
it.
Then
you
need
to
be
able
to
open
those
erb
files.
Then
content
editor
as
well.
B
Yeah
we
can
just
like
display
the
source
either
instead
of
the
confirmatory
in
those.
C
Cases
no,
but
then
it's
not
a
replacement
like
it's
not
a
one
to
one
replacement
and
like.
If
we
want
to
open
source
later,
then
then,
why
are
we
even
having
this
discussion
at
die.
D
C
But
the
translation,
one
of
the
reasons
for
having
this
translation
is
in
place,
is
to
like
have
people
who
use
statistical
editor
have
some
sort
of
alternative
that
they
can
use.
So
that
is
one
of
the
main
reasons.
Otherwise
you
can.
You
can
see
the
preview
as
well.
A
This
is,
this
is
absolutely
correct
and
eric
was
explicit
in
saying
that
he,
since
we
duplicate
the
static
side
later,
he
wants
to
direct
people
to
something
that
they
can
use
as
the
replacement
for
static
site
editor
and
preferably
it's
either
static,
a
single
violator
or
web
ide
with
with
the
wysiwyg
functionality,
and
if
we
do
not
deliver
the
same
functionality
that
they
got
used
to
in
the
static
site,
editor
that
might
be
seen
as
an
as
an
issue.
Is
there
any
like.
A
Yeah,
but
we
cannot,
we
cannot
expect
people
who
were
visually
editing
the
the
pages
to
exp.
We
cannot
expect
them
to
start
all
of
a
sudden
start
editing
markdown
as
the
code
right
and
if
we
do
not
provide
them
with
full
functionality
they
got
used
to
instead
excited
they
won't
be
able
to
get
the
same
results.
D
C
Yeah,
I
think
I'm
quite
clear
on
that,
so
we
do
need
to
open
the
erb
files
in
like
web
id
or
any
of
the
other
editors,
and
we
we
need
to
render
that
in
content
later
otherwise.
Like
this
there's
no
point,
I
think
eric
can
confirm
that
as
well,
but
you
know.
D
D
A
D
A
I
think
I
think,
like
delegating
this,
to
decision
to
eric
would
be
would
be
smart
and
and
eric
will
watch
this
recording,
and
I
hope
he
will
provide
us
with
the
answer
as
soon
as
possible
so
that
we
know
what
sort
of
to
what
level
we
have
to
to
to
mimic
the
functional
the
existing
functionality
in
the
static
site,
the
editor.
A
D
D
That
is
not
used
very
much
light
snippets
and
not
even
try
to
implement
the
translation
layer
just
go
ahead
and
implement
both
of
the
view
components
in
the
way
that
we
want
and
see
what
similarities
there
are,
because
you
know
one
of
the
rules
of
of
architecture.
Is
you
know
you?
Don't
you
don't
dry
things
up
on
the
first
one
you
duplicate
it
once
hold
your
nose
duplicate.
It
twice
hold
your
nose.
D
Maybe
the
third
time
is
where
you
dry
it
up,
because
then
you
can
see
what
the
similarities
and
the
patterns
are
and
have
a
good
feel
for
what
the
abstraction
in
the
interface
needs
to
be,
whereas
if
you
try
to
prematurely
implement
that,
you
can
often
get
it
wrong
before
you.
Actually,
if
you
try
to
do
it
before,
you
actually
know
what
it
needs
to
do.
D
Well,
so
I'm
being
very
hand-wavy
of
this,
but
as
generally
how
I
envisioned
a
problem,
there's
a
source
editor
in
the
content
editor.
They
both
have
to
communicate
via
view
to
something
underneath
them
right.
Presumably
they
will
have
different
requirements
and
this
translation
layer
will
have
to
support
the
superset,
the
combination
of
both
those
requirements.
D
A
Yeah,
I
think
so,
but
just
just
to
make
100
sure
that
I
understand
this,
so
the
suggestion
is
to
implement
this
as
two
separate
view:
components
without
any
any
data
layer.
Abstraction
just
see
how
these
two
things
can
communicate
with
each
other
and
use
this
as
the
basic
sort
of
model
of
how
these
things
communicate.
D
Right
and
do
it
in
a
low
traffic,
low
risk,
low
requirements
area
starting
first
like
snippets
and
then
maybe
you
know
we'll
get
an
idea
there
and
then,
as
we
move
to
more
complex
areas,
maybe
more
requirements
but
we'll
have
a
better
idea
for
the
basis
that
we
need
to
build
and
iterate
on.
By
that
point,.
A
Yeah
like
since
snippets
is
the,
as
I
said
like
implementing
snippets,
is,
is
trivial
like
to
a
certain
extent,
of
course
like,
but
we
don't
need
any
abstraction
layer
for
snippets
at
the
moment,
because
source
editor
source
editor
doesn't
need
to
be
the
view
component
doesn't
need
to
be
updated.
We
don't
need
the
shared
shared
data
layer,
so
we
can
do
it
in
snippets
right
away.
A
The
problem
is,
though,
is
that
I
don't
understand
I
or
I
don't
know
how
this
would
give
us
any
sort
of
any
pattern
that
we
can,
that
we
could
identify
like
you're
you're,
saying
yourself
like
we
have
to
implement
it
two
three
times
in
order
to
see
the
pattern
and
that's
exactly
when
how
many
times
we're
gonna
implement
this
like
we're,
we
have
only
three
three
applications
to
implement
this
in
and
it's
clear
like
it.
Okay,
it's
not
100
clear,
but
we
do
have,
because
of
because
we
have
in
all
three
applications.
A
We
have
three
different
storages.
We
still
have
to
make
sure
that
we
connect
to
all
of
them
from
both
editors
source.
Editor
does
have
connections
to
all
of
those
three.
We
need.
We
have
to
make
sure
that
content
editor
is
being
is
able
to
connect
those
three,
so
we
can
technically
if
we
say
that
we
will
not.
A
First
of
all,
we
won't
support
multiple
content
editors
on
one
page.
Second,
we
won't
support
any
other
additional
editors
in
the
future.
Then
we
can
say
that
okay,
we
don't
really
need
the
shared
data
layer.
A
A
But
then,
if
we
go
to
the
snippets
example,
we
have,
we
can
have
up
to
10
snippets
on
the
same
page
like
when
you
edit
it.
How
does
contemplator
work
with
like
with
with
in
the
in
that
scenario?
I
I
honestly
don't
know
so
enrique
might
might
tell
us
about
that,
but
snippets
is
not
as
straightforward
as
it
might
sound
technically.
A
So
we
might
take
this.
We
might
take
snippets
as
an
example,
and
it
will
actually
why
I
like
this
example
is
because
it
will
clearly
show
the
scalability
of
our
solutions.
A
So
we
will
see
how,
like
all
of
a
sudden,
we
have
a
playground
where
we
can
have
up
to
10
instances
of
both
editors.
At
the
same
time,
considering
all
10
files
are
marked
down,
and
then
we
will
be
able
to
measure
performance,
we
will
may
be
able
to
check
the
technical
requirements.
We
will
be
able
to
measure
all
sorts
of
things
so
that
that's,
even
though
this
might
not
reach
the
goal
of
replacement
for
static
site
or
like
it
won't
reach
the
point
of
replacing
the
static
citator
it
will.
A
It
might
give
us
a
very
good
basis
for
for
for
the
further
analysis
and
understanding
how
how
to
tune
this
solution
for
single
file,
letter
and
web
id.
That
might
be.
That
might
be
a
good
idea
actually.
B
One
is
obviously
delete
that,
like
using
this
experiment
to
deliver
value
immediately
and
provide
this,
we
see
week
8
or
for
markdown
in
one
of
the
applications
that
we
were
discussing
and
the
other
one
is
the
the
learning
part
that
chad
was
talking
about
like.
How
can
we
learn?
What
are
the
architectural
requirements
to
implement
this
layer?
That
is,
gonna
should
be
shared
across
all
of
the
applications.
B
Perhaps
a
way
in
which
we
can
start
is
by
like,
following
this
iterative
architecture
approach
that
chad
was
talking
about.
We
just
like
create
this
experiment
in
the
same
way
that
we
could
that
we
were
creating
proof
of
concepts
for
comparing
approaches
last
week
and
we
say:
hey,
let's,
let's
see
what
synchronizing
both
ethers
looks
like
in
the
single
violator.
B
B
We
can
reduce
the
learning
process
to
just
implementing
that
experiment
in
one
of
them
and
then
we
decide
based
on
that
learning
we
refactor
and
we
create
that
that
data
layer-
and
it's
probably
going
to
be
a
very
similar
requirement
to
what
you
will
see
in
the
web.
Ide
and,
as
you
say,
snippets
is
very
complex.
A
snippet.
The
the
difference
with
snippets
is
that
we
have
multiple
files
open.
At
the
same
time,
I
don't
know
how
you
are
handling
that
in
the
source.
Editor,
probably
that's.
B
You
are
like
handling
all
of
the
editor
instances
through
some
mechanisms
that
that
you
created
in
the
associated
api
right.
So
that's
gonna,
be
that's.
That
may
be
a
problem
because,
like
we
want
that
mechanism
as
well
detach
and
decouple
from
the
source
editor
if
we're
gonna,
have
multiple
editors
for
every
file
available.
So
maybe
we
don't.
We
don't
want
to
deal
with
that
right
now.
We
want
to
focus,
really
focus
and
reduce
the
scope
of
this
work
to
the
data.
Major
that
is
gonna
be
reusable
in
snippets,
but
it's
not
just
like
we're.
B
So
from
that
point
of
view,
I
think
that
the
scene,
the
the
simplest
path
here,
considering
that
we
can
instantiate
every
application
in
the
single
violator
and
create
and
use
the
view
version
of
the
source
editor
and
the
container
we
can
just
like
focus
on
experimenting
on
how
we
can
make
them
talk.
In
that
context,
you
just
use
all
of
that
knowledge
to
be
the
data
layer
solve
that
problem
and
then
focus
on
the
snippets.
A
Okay,
I
think
I
think
we
have
to
to
summarize
what
we
have
discussed
so
far,
so
that
everybody
is
on
the
same
page
and
maybe
for
eric
who
who's
going
to
watch.
This
video
yeah
can.
D
I
respond
to
that
real
quick
so
like
if
the
single
file
editor.
The
reason
I
said
snippets
is
because
I
was
under
the
impression
there
was
maybe
of
equal
complexity,
a
single
file
editor,
but
also
because
it
was
less
used,
so
it
was
less
risk.
But
if
the
single
file
editor
is
much
simpler,
even
though
it's
more
used-
and
therefore
you
know-
maybe
less
risk
of
trying
to
do
too
much
at
once-
then
maybe
that's
a
better
choice
to
start
with.
A
Yeah,
that's.
I
have
a
feeling
that
there
is.
A
There
is
like
what
we
are
discussing
so
far
inevitably
should
involve
product
no
matter
what
like,
we
have
to
understand
why
we
have
to
build
this.
What
for
and
and
humanity
has
a
as
point
like?
What
is
the
problem
we
are
trying
to
solve
here?
If,
if
it's,
because
that's
that's
a
very
good
point-
that
if
we
are
trying
to
replace
the
static
site
editor,
this
is
this
is
one
set
of
requirements.
A
If
we
try
to
say
okay,
we
just
deliver,
we
say
we
can
pick
capabilities
for
people
working
with
markdown
so
that
they
could
pick
whether
they
edit
as
busy
week
or
code.
This
is
another
set
of
rules
or
a
set
of
requirements
and
without
having
a
clear
understanding.
What
is
the,
what
is
the
end
goal,
or
at
least
what
are
the
goals
on
the
path
of
our
ultimate
goal?
A
We
won't
be
able
to
to
deliver
proper,
proper
value
here
before
I
sum
up
the
things
that
we
have
discussed
about
different
solutions
now,
and
we
can
you
have
the
hand
faced.
B
Thank
you,
danish,
so
yeah
that
that's
that's
a
great
point.
What
is
what
problem
are
we
trying
to
solve
here?
I
think
that
all
of
this
effort
started
with
providing
a
replacement
for
the
static
site
editor.
B
So
in
some
ways
like
that,
that
point
has
weights
a
lot
in
this
decision
and
the
snippets
is
not
a
replacement
for
the
study.
Psychiatry.
A
Exactly
so,
and
that
that
is,
this
is
very
very
true,
so,
like.
A
A
D
I
just
want
to
verbalize
something
that
enrique
had
put
in
the
chat,
which
I
think
is
really
important
for
for
what
it's
worth
opening
these
types
of
dynamic
files
you
know,
embedded
erb
or
whatever
in
the
static
site.
Editor
is
currently
buggy
and
unreliable
so
like.
If
that
is
actually
going
to
be
a
requirement.
D
A
A
This
doesn't
mean
that
on
the
way
to
that
go
like
we
are
talking
really,
we
are
talking
about
source
to
content
switch
for
markdown
files,
and
if
we
can,
we
can
talk
about
supporting
dynamic
files
for
as
long
as
we
want,
but
if
we
fail
supporting
the
very
basic
operation
of
providing
users
who
are
working
with
simple
marginal
files,
if
we,
if
we
don't
support
that
case,
we
won't
reach
our
end
goal.
So
we
start
with
just
supporting
the
basic
markdown
editing
as
the
as
the
starting
point.
A
This
again
doing,
this
supporting
the
switch
between
code
and
content
for
simple
markdown
files
will
again
put
us
one
step
closer
to
our
end
goal,
so
we
we
can
approach
this
from.
Let's,
let's
say
we
have
two
ways
for
now.
We
have
static,
we
have
a
single
file
editor
and
we
have
snippets
so
with
snippets.
A
What
are
the
benefits
of
starting
with
niblets
snippets
do
not
require
any
any
shared
data
layer
right
now,
snippets
can
be
implemented
without
updates
to
the
source.
Editor
view
component.
A
And
I
think
snippets
this
is
one
more
interesting
one.
One
interesting
point
to
add
is
that
in
snippets
we
will
be
practicing
the
the
best
practices
technically,
because
snippets
are
on
graphql
and
ultimately
we
have
to
move
our
applications
to
graphql,
and
this
will
be
the
question
when
we
might,
when
we
refactor
a
single
file
editor,
we
will
inevitably
might
refactor
it
with
graphql
in
mind.
So
doing
this
in
snippets
will
give
us
this
experience
and
this
basis,
and
we
will
know
how
to
connect
things
to
to
graphql.
A
There
are
issues
with
with
snippets,
as
we
said,
we
do
not
know
how
it
will
scale
for
multi-file
snippets,
because
we
just
we
just
don't
know
we
we
haven't
tried
this.
This
is
first
point.
The
second
point
is
observability.
It
won't
be
observed
by
enough
users
to
give
us
any
sensible
feedback
or
even
provide
us
with
any
significant
statistical
data
for
us
to
make
this
decision.
Okay,
like
do
people
need
this
feature.
Do
people
use
this
feature
so
snippet?
A
I
would,
I
would
think
about,
starting
with
snippets
as
sort
of
a
sandbox
approach,
where
we,
where
the
cost
of
failure
is
not
that
high,
because,
because
of
the
feature
itself
being
not
widely
used,
another
solution
is
to
start
with
a
single
file.
Editor
single
file
editor.
What
are
the
pros
of
starting
there?
We
will
deliver
value,
and
I,
by
value
I
mean
anything,
we
do
to
provide
with
weak
capabilities
for
editing.
A
A
We
provide
this
in
the
in
the
application
that
is
highly
visible,
so
we
can
start
gathering
really
significant
statistical
data
and
now,
when
users
switch
to
whether
users
switch
to
wiziwik,
whether
they
switch
back
to
code,
what
they're
doing
technically,
whatever
we
want
to
to
to
measure
in
in
this
application,
so
static
single
file
later,
will
provide
us
with
much
better,
statistically
reliable
data.
However,
there
are
technical
issues
with
with
starting
with
static
with
single
file.
A
Later,
first
of
all,
we
have
to
migrate
the
not
not
migrate
but
update
the
view
component
for
source
editor.
Second,
we
most
probably
have
to
convert
the
toolbar
for
the
markdown
files
in
the
single
file
editor
to
be
the
view
component
as
well.
A
It
does
match
the
idea
of
the
toolbar
mvc
for
static
files
for
source
editor.
However,
we're
not
there
yet
it's
not.
We
cannot
just
take
and
migrate
the
toolbar
right
away.
Third
point
is:
we
have
to
actually
introduce
the
view
application
there?
This
is,
this
is
pretty
minor
if
we
all
have
all
the
view
components
in
place,
initializing
view
application
is
not
a
big
thing.
A
However,
the
biggest
thing
is
that
if
we
start
with
single
file
letter,
we
do
have
to
have
the
shared
data
layer,
because
in
this
case
it
doesn't
really
make
sense
to
to
just
well
okay,
I'm
I'm
pulling
this
one
back.
We
can
start
without
the
shared
data
layer.
We
just
connect
both
editors
straight
to
api,
and
that's
that's
how
we
can
roll
so
okay,
we
can
do
that.
A
We
will
have
to
introduce
the
shared
data
layer
on
the
second
step
when
we
implement
the
same
feature
for
any
other
application.
Should
it
be
snippets
should
it
be
web
id.
We
will
have
to
get
back
and
revisit
this
idea
of
shared
data
layer,
but
at
the
first
ration
we
don't
technically
need
that
we
can
go
straight
to
to
api
and
be
done
with
that.
A
So
I
don't
know
to
me
still
implementing
this
in
snippets,
even
though
it
won't
make
us
any
closer
to
the
ultimate
goal,
with
like
replacement
of
static
site
editor
that
fast.
A
I
still
like
the
idea
of
snippets,
because,
because
it's
just
in
single
file
later
there
are
too
many
unknowns
like
how
fast
will
be.
We
will
update
the
view
compound
and
how
fast
we
will
migrate,
the
markdown,
the
using
the
toolbar
for
yeah.
We
still
have
to
connect
this
toolbar
to
to
the
source
editor.
A
So
whatever
we
do
like,
we
can
reuse
any
any
any
view
component.
It
still
has
to
talk
to
source
editor
right.
So
and
that's
that's
the
that's
the
thing
so
at
the
moment,
source
editor
in
this
single
file
letter
is
connected
to
all
those
bars
on
the
toolbar
or
to
all
those
buttons
on
the
toolbar
through
just
a
simple
javascript.
A
If
we,
if
we
use
the
view
component,
we
will
have
to
connect
this
things
via
events.
So
that's
that's
the
thing
again.
I
don't
say
that
this
is
any
significant
work
or
something
like
this,
but
it
has
to
be
done.
A
So
considering
all
all
this,
I
would
still
think
that
starting
with
snippets
with
in
the
long
run
would
give
us
bigger
benefit
because
we
won't
be
sidetracked
by
by
people
filing
the
bugs
about
this
about
this
particular
feature.
A
So
I
would
still
consider
snippets
being
being
a
safer
bat
for
us.
Currently,
I
don't
know,
that's
that's
my
opinion.
What
do
you
guys
think.
D
So
I
just
had
another
thought,
so
I
think
one
of
the
reasons
I'm
confused
about
the
static
site,
editor
like
being
the
dynamic
files
needed
to
be
replaced,
is
because
eric
just
prioritized
the
issue
for
me
to
implement
the
redirects
from
the
static
site
editor
to
the
web.
Ide
he's
already
committed
the
changes
to
remove
it
from
the
docs
and
everything
so
like
that's
why?
D
A
D
I
think
he's
not
assuming
that
we're
going
to
fix
this
problem
of
dynamic.
You
know
content
display
and
erb
files.
I.
A
Don't
know
to
me
this
doesn't
doesn't
mean
anything
really
like
we
will
have
to
redirect
links
to
somewhere,
and
it
might
very
much
be
that
may
very
well
be
that
eric
just
assumes
that
we
will
have
this
support
eventually
for
for
these
dynamic
pages
in
web
id,
and
that's
that's,
that's
it
yeah.
C
A
A
Yes,
but
from
from
from
the
implementation
point
of
view,
what
do
you
think
about
what
solution
do
you
think
would
make
more
like?
Let's
assume
again,
the
ultimate
goal
is
replacement
for
the
static
site.
Editor,
that's
the
ultimate
goal.
We
will
get
there.
Eventually,
we
won't
support
the
dynamic
pages
right
now.
B
I
have
a
question
for
you
dennis,
so
is
your
concern
with
starting
with
the
single
file
editor
the
amount
of
work
that
it
requires
to
implement
it
in
in
comparison
with
the
snippets.
A
Both
like,
firstly,
the
amount
of
work,
the
that
is
kind
of
tricky
to
to
estimate,
and
second,
is
the
visibility
of
potential
regressions
for
bugs.
B
Okay,
well,
first,
we
definitely
need
to
talk
about
eric
about
this.
Like
degrading
the
user
experience,
I
don't
think
that
we're
going
to
provide
a
worse
experience
than
the
static
citator,
because
that's
really
really
bad,
but
besides
that
we
can.
B
The
using
the
continuator,
as
the
you
know,
as
the
editor
for
for
macdonald
files,
totally
opt-in.
I
think
that's
something
that
is
a
requirement
here.
We
couldn't
open,
we
shouldn't
open
markdown
files
by
default
in
the
content
editor
until
we
have
preserve
and
change
markdown
implemented.
B
B
I
I
think
that
we
are
running
a
spike
right
now
be
it
could
be
a
second
one,
but
maybe
we
have
we
have
some
time
until
the
end,
the
end
of
the
milestone
to
continue
investigating
how
complex
it
is
to
do
it
in
the
single
violator.
A
This
is
this,
is
both
points
are
very
good
ones
about.
I
will
start
with
the
second
one
about
the
estimations
first
of
all,
as
you
may,
as
you
have
mentioned,
we
are
in
the
middle
of
one
spike.
The
spike
comes
in
addition
to
the
deliverables
and
to
our
like
technical
assigned
work
asking
people
to
respite
in
yet
another
spike
in
this
milestone
is
a
bit
too
to
like
stretching
the
things
a
bit.
This
is
the
first
thing.
The
second
one
is.
A
How,
in
your
opinion,
a
new
spike
would
allow
us
to
estimate
the
things
I.
I
really
believe
that
spike
in
these
regards
would
mean
we
just
jump
straight
into
the
implementation,
and
we
will
know
how
we'll
know
the
estimations
when
we
are
done
with
the
work
so
like
retrospectively.
Estimating
the
work
isn't
is
not
really
the
way
to
estimate
the
things
here,
especially
considering
that
spikes
like
in
the
in
this
particular
case
spike
would
go
in
parallel
with
the
with
the
main
work.
A
So
this
is
something
for
david
to
decide
how
to
how
to
manage
this.
It's
not
me
who's,
who's,
gonna,
sort
of
say
what
is
right
or
what
is
wrong
here.
But
that's
that's
my
personal
opinion,
but
when
it
comes
to
the
quality
and
you've
mentioned
a
really
really
good
thing,
that
makes
me
even
more
worrisome
about
single
file
later
unless
we
have
solved
the
problem
of
preserved,
unchanged
markdown.
A
A
So
that's
that's
one
more
point
in
favor
of
snippets
and
against
implementing
this
in
single
file
later
for
now,
again,
don't
don't
don't
forget
that
we,
like,
even
that
thing
is,
is
the
spike
in
parallel
with
the
with
the
main
deliverables
right.
So
I
don't
want
us
to
stretch
to.
A
A
Technically,
unless
we
solve
the
and
we
and
not
only
solve
this
is
this
is
very
crucial
like
we
have
to
be
100
certain
that
preserving
marked
unchanged
markdown
works
as
expected
before
we
implement
this
in
either
single
file
later
or
web
id,
because
messing
up
with
people's
commit
commits
is
not
really
opt-in,
anymore,
like
if
they,
when
it
comes
to
the
ui,
they
can
open,
they
can
close
editors.
A
That's
that's
fine,
but
if
this
will
will
be
reflected
on
their
dips,
this
is
not
going
to
be
really
nice
and
we
will
get
bugged
a
lot
about
that.
Yes,.
B
In
the
hypothetical
case
that
we
don't
solve
the
unchanged
preserve
the
preserving
change
markdown
program,
what
would
be
the
what
would
be
a
decision
from
a
product
site
from
a
product
management
point
of
view?
We
don't
provide
that
replacement
at
all.
B
A
I
start
editing
this
I
switch
to
wizzyweek
editor
and
then
all
of
a
sudden
in
my
when
I,
when
I'm
done
with
edits,
I
check
the
change
log
nice
or,
like
the
diff
of
my
last
command.
I
see
all
sorts
of
edits
that
I
haven't
made,
so
it's
not
about
static
site
data
at
the
moment.
It's
just
about
regular
markdown
editing.
A
B
But
I
want
I,
I
think
that
it
is
important
to
talk
about
the
statistic
data
because
all
of
this
discussion
it
starts
there
and
it
starts
at
solving
that
problem,
which
is
providing
a
replacement
for
the
static
site
data.
B
D
D
C
D
You'll
get
the
preview,
that's
implemented
there.
It's
not
wizi.
I
mean
it's,
it's
not
editable,
but
that's
it.
So
I
mean
this
meeting
is
almost
to
an
end.
I
think
that
we
really
need
to
talk
to
eric
about
where
he
wants
to
go
to
get
the
requirements
for
this.
A
Yeah,
that's
that
again.
That
puts
us
back
that
we
have
to
clear
to
have
the
clear
answer
from
the
product,
and
this
just
highlights
like
to
to
to
mention
once
again
the
thing
that
yes,
the
ultimate
goal
might
might
or
is
to
replace
the
static
site
editor.
But
if,
on
the
way
there,
we
will
screw
up
the
basic
markdown
editing
with
with
the,
as
I
said,
with
the
example
that
I
that
I
talked
about
when
we,
when
people
just
edit
a
simple
markdown
file
and
they
get
unwanted
changes.
A
This
is
this
is
something
that
we
have
to.
I,
I
don't
think
this
sort
of
regression
will
be
acceptable,
so
we
will
have
to
solve
in
this.
In
this
case,
I
think
we
absolutely
must
solve
the
unchanged,
an
unchanged
markup
markdown
issue.
A
That's
that's
something
that
that
we
have
to
be
very,
very
careful
with
yeah
and
but
again
eric
should
tell
us
what
is
the
expectations
and
whether
we
have
committed
to
something
that
we
won't
be
able
to
deliver
anytime
soon,
like
with
by
by
saying
that
we
duplicate
the
static
site
data,
but
we,
as
the
group
are
just
not
ready
to
serve
the
the
needs
of
the
people
who
need
static
site
editor.
A
That
would
be.
That
would
be
weird
situation,
but
we
will
well
like
we
cannot
if
we,
if
we're,
not
technically
ready-
and
we
are
not
technically
ready
at
the
moment-
that's
we.
We
won't
rush
this
to
to
just
to
do
things
fast
and
buggy.
I
think
that
that
would
be
the
worst
we
can
do.
E
A
Great
thanks
david,
so
yeah,
so
we
I
will
post
the
the
update
the
from
the
technical
side
of
things
in
in
slack,
so
that
everybody
can
read
through
and
comment
on
that.
But
the
main
thing
we
we
have
to
know
is
where
what
is
the?
What
is
the
purpose
of
this
move
like
what
is
the
end
goal,
and
where
can
this
would
help
as
well?
Where
can
we
cut
the
corners
like
what
product
expects
us
to
deliver
100,
and
where
can
we
say?
A
A
Because,
like
saying
that,
we
have
to
provide
all
like
big
this
big
picture
of
the
license
for
the
static
citator.
That's
that's
not
gonna
happen
right
now.
So,
okay,
thank
you
very
much
for
for
this
meeting.
If,
if
we
have
nothing
to
to
add
here,
I
think
we
have
to
wrap
up
okay,
cool.
Thank
you
very
much
for
jumping
in
this
call.
That
was
super
productive.
I
think,
and
I'm
really
looking
forward
to
hear
what
eric
thinks
about
this.