►
From YouTube: POC for Service Workers in Web IDE Live Preview
Description
Problem to solve: https://gitlab.com/gitlab-org/gitlab/-/issues/197206
Investigation issue: https://gitlab.com/gitlab-org/gitlab/-/issues/218438
POC: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36619
A
We're
gonna
walk
through
a
POC.
We
put
together
testing
out
fixing
this
problem
of
relative
URLs,
not
working
in
our
live
preview
feature
using
service
workers.
So
here's
the
problem
that
we
observed
was
for
static
sites,
relative
URLs
that
would
load
CSS
files
or
image
files
which
show
up
as
broken
images
or
not
load
those
because
our
live
preview
is
hosted
in
an
iframe
and
those
assets
are
certainly
not
an
iframe
and
is
trying
to
find
them.
A
So
one
solution
that
was
presented
to
us
was
to
use
service
workers
as
a
bridge
between
the
iframe
and
the
parent,
the
parent
window.
So
we
can
use
service
workers
to
communicate
to
the
IDE
components,
to
fetch
content
for
these
files,
which
is
really
exciting.
So
we
have
it
working
and
let's
show
what
that
looks
like
so
here,
I
have
an
HTML
file.
That
is
loading
an
image
here
for
ki
great
I
hit
live
preview
and
it
loads
and
I
can
even
upload
a
brand-new
file
here.
A
So
let's
upload,
cuphead
and
I
will
add
a
new
image
boom.
Oh
man,
you
see
the
light
preview
already
previewing
amazing
cool,
so
this
is
working.
It's
a
POC,
so
it
proves
that
this
architecture
is
gonna,
help
fix
our
problem.
There's
some
caveats
to
it
and
that's
what
we're
gonna
talk
about
now.
So,
first,
let's
talk
about
how
it
works
so
to
get
it
to
work,
oh
and
before
we
jump
into
that
in
this
issue,
there's
a
link
to
the
related
marriage
request
and
here's
the
POC
merge
request
that
can
all
the
code
for
it.
A
And
what
does
that
look
like
so
here?
I
have
a
little
bash
script
for
looking
for
the
smush
pack,
assets,
which
is
of
just
a
standalone
bundle
of
code.
Sandbox
does
its
bundling
it
fetches
it
and
extracts
it
and
moves
it
to
this
WWE,
and
that
contains
things
like
index.html,
which
gets
loaded
in
the
iframe
and
all
sorts
of
script
files,
and
we
can
take
a
look
at
it
real
fast
well
over
here
yeah.
A
It
contains
a
whole
bunch
of
stuff
yeah,
so
it
has
lots
of
different
app
chunks
and
just
everything
that
code
sandbox
needs
to
run,
but
it
also
has
this
index.html,
where
we
load
our
own
entry
point
now,
so
we've
had
to
kind
of
patch
on
top
of
that,
our
own
entry
point,
which
registers
our
own
serviceworker
for
doing
this
bit,
but
we
discovered
that
code
sandbox
already
has
some
service
workers
looking
at
their
source
code.
It
looks
like
these
are
just
service
workers
for
doing
some
sort
of
pre
caching.
A
So
it's
not
required
for
it
doesn't
seem
like
it's
a
hard
requirement
for
any
of
the
critical
quote:
sandbox
features
so
we're
kind
of
okay
with
removing
it,
but
you'll
notice.
Here
in
my
console,
it
does
spit
out
some
well
I,
don't
know!
What's
going
on
there?
Okay,
here
we
go.
It
does
spit
out
some
console
errors
because
it's
trying
to
find
the
serviceworker
which
we've
removed
but
anyways
yeah.
It
builds
all
that
and
it
runs
make
which
basically
copies
file
copies
these
files
into
the
root
WWD.
A
And
then
for
my
serviceworker,
we
have
two
things
that
we're
doing
from
it.
This
entry
point
listens
to
messages.
It
gets
from
the
serviceworker
of
hey,
we're
trying
to
request
this
resource
and
so
then
opposed
to
the
parent,
saying,
hey,
we're
look,
we're
gonna,
create
an
IDE
message
and
here's
our
payload
and
then
from
the
from
our
window,
the
iframe
window.
A
We
we
are
going
to
be
receiving
messages
from
the
parent
window,
which
are
view,
control
controls
and
that's
going
to
take
in
hay
or
we're
looking
for
messages
that
have
a
good
live,
IDE
response,
and
so
then
we
just
send
that
to
the
service
worker.
So
this
is
definitely
like
some
middleware
connecting
the
service
worker,
which
is
capturing
the
network
requests
to
the
parent
window,
IDE,
which
is
going
to
be
able
to
handle
those
requests
so
diving
into
our
service
worker.
A
We
do
some
install,
we
don't
really
do
anything
on
install
and
I'm
pretty
new
to
work
with
service
workers.
So
when
we
activate
it,
we
are
just
trying
to
get
it
to
be
active
as
soon
as
possible.
So
if
there's
no
disruption
and
features-
and
then
this
is
the
the
main
thing
that
the
service
worker
is
doing
is
any
time
we
fetch
and
what
happens
here
is
right.
Now
we
have
just
hard-coded
we're
just
looking
for
PNG
files
and
we'll
talk
about
that
and
a
little
bit.
A
But
if
it's
a
PNG
file,
then
we
want
the
ID
to
handle
it
and
the
way
we
do
that
is,
we
are
going
to
pull
the
path
that
we're
requesting
from
the
URL
generate
a
request.
Id,
which
is
kind
of
helping
us,
make
a
mock,
request
response
system
and
then
to
the
client,
and
that
is
the
iframe.
That's
run
the
iframe.
That's
currently
talking
to
this
instance.
A
This
part,
which
is
gonna,
then
hit
the
parent
window,
and
so
all
of
that
comes
back
to
here,
where
we've
added
a
listener
in
our
client-side
component,
and
this
probably
shouldn't
be
handled
here,
but
this
uses
a
POC
showing
that
this
works
and
then
I
get
my
hey,
here's
the
type
of
requests
and
here's
the
payload
that
were
requesting.
If
this
is
the
path
and
the
request
ID,
so
we're
gonna
capture
our
content
as
the
IDE
season
of
that
file
and
then
pace
it
back
to
the
iframe,
which
then
sends
it
to
the
serviceworker.
A
To
then
respond
to
that
request.
That's
waiting
for
it!
So
that's
kind
of
how
it's
happening.
It's
fairly,
straightforward,
there's,
there's
some
hack
eNOS,
though,
to
it,
and
one
of
the
things
that
stands
out
of
some
of
these
issues
is
that
we're
tightly
coupled
to
implementation
behavior
of
code
sandbox,
because
we
do
have
the
monkey
patch
on
top
of
it.
So
ideally,
this
kind
of
these
files,
which
is
this
main
entry
point,
setting
up
the
serviceworker
doing
this
thing.
A
Ideally,
these
would
be
baked
into
code
sandbox
and
we
would
have
a
consistent
API
that
we'd
be
able
to
rely
on,
but
having
to
paste
these
files
into.
There
is
a
little
concerning
having
to
override
our
then
index.html
is
obviously
concerning
and
removing
the
previous
service
workers
there.
There's
a
mother,
interesting
coupling
to
where
I
had
to
write
this
little
adapter
to
getting
the
actual
underlying
iframe
that
gets
built,
because
for
some
reason
the
iframe
would
be
created,
but
the
content
window
wasn't
available
when
I
was
trying
to
respond
to
a
request.
A
So
this
is
just
hey.
We're
just
gonna
keep
polling
this
until
the
iframes
content
window
is
available,
and
part
of
this
is
just
a
symptom
that
well
the
code.
Sandbox
is
really
the
one
creating
this
iframe.
They
really
control
the
life
cycle
of
when
it's
available
not
just
created,
but
also
that
everything's
loaded,
meaning
that
this
content
window
is
available.
Since
we
don't
control
that
we're
kind
of
coupled
to
two
polling
for
it,
which
is
a
little,
which
is
a
little
code
smelly
for
sure.
A
But
hopefully
this
this
kind
of
message
passing
could
be
encapsulated
inside
of
code
sandbox.
That
would
be
neat
yeah.
Looking
through
my
notes
here,
yeah
and
one
concern
two
about
service
workers.
How
a
host
can
only
ever
have
one
service
worker
so
over
here
when
we,
when
we
build
the
assets
that
are
San
pack
host
is
gonna
is
going
to
serve.
We
remove
the
previous
service
workers
and
some
questions
are
as
hey.
Are
we
ok
with
that?
A
But
then
another
question
is
well:
do
we
think
that
there's
ever
gonna
be
a
service
worker
that
code
sandbox
is
dependent
on
that's
different
than
this
kind
of
setup
of
a
service
worker,
and
so
since
a
host
can
only
ever
have
one
service
worker,
it's
a
it's
kind
of
a
big
deal
that
they
make
sure
we
find
a
solution
that
works
for
the
long,
the
long,
haul,
yeah
and
so
another.
Another
issue,
too,
is
because
going
back
to
here.
A
So
it's
an
interesting
some
interesting
things
happen
when,
rather
than
having
a
completely
containerized
environment
for
this
iframe,
we
have
a
host
that
hosts
all
the
scripts
to
run
the
bundlers
and
stuff.
But
then
we're
also
gonna
make
these.
You
know,
requests
that
don't
exist
on
that
host
on
top
of
it.
How
do
we
know
what
requests
to
intercept
our
are
part
of
this
actual
use
case
and
not
part
of
the
part
of
a
bundler?
A
If
I
was
gonna
request
something
from
here.
How
would
I
distinguish
hey
we're
trying
to
make
a
request,
not
for
code
sandbox
to
do
its
thing,
we're
trying
to
make
a
request
as
part
of
this
content
and
that's
kind
of
an
issue
that
happens
when
these
iframes
are
sharing
the
code
running
it,
and
we
want
to
kind
of
simulate
the
code
that
it
would
look
like
in
a
real
environment.
A
So
one
idea
would
be
maybe
if
there
was
an
event
that
we
could,
that
gets
triggered
that
we
need
to
watch
for
meaning.
Okay,
now
we
can
need
to
start
capturing
requests
going
to
the
ID,
but
is
that
event
gonna
be
retry
gerd
like
if
I
refresh
or
if
I
do
an
update.
Those
are
kind
of
things
that
we're
not
clear
about
so
yeah.