►
From YouTube: Magento PWA Community Meeting August 16th, 2019
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
C
C
A
A
Looks
like
I
can
get
started.
I
think
James
will
join
us
here
in
just
a
few
minutes.
So
as
promised,
we've
got
an
action-packed
agenda,
so
Andrew
will
be
out
for
the
next
few
days,
he's
still
on
vacation
at
the
beach,
so
I'm,
covering
as
the
guest
MC
for
today,
and
so
we've
got
a
couple
updates.
So,
first
of
all,
andis
going
to
take
us
through
some
of
the
work
we've
done
on
github
projects,
which
sounds
like
a
small
thing,
but
it
is
a
big
thing,
as
we'd
love
to
give
your
contribution
in
the
project.
A
So
he's
gonna
walk
us
through
the
latest
organization,
the
board,
but
also
show
us
some
of
the
new
good
good
first
issues
and
other
things
that
the
community
can
help
with.
Next
we've
got
a
walkthrough
of
some
of
the
server-side
rendering
work
that
that's
been
posted
as
an
issue,
and
so
Jamie's
gonna
kind
of
walk
us
through
his
thinking
on
that.
But
really
you
know
in
the
spirit
of
the
these
being
grooming.
The
grooming
meetings
in
the
past
want
to
use
that
as
an
opportunity
to
bring
some
feedback
into
that
as
well.
A
Before
we
get
started
on
that
one
so
James
will
join
us
walk
us
through
that,
then
we're
going
to
have
a
discussion
on
vineya,
vineya,
UI,
so
I
know,
there's
been
some
questions
in
the
slack
channel
around
some
of
the
new
work
on
the
scaffolding
and
so
I
want
to
make
sure
those
are
addressed,
but
also
just
a
refresher
from
James
on
kind
of
what's
changed
and
kind
of
what
saw
what
can
be
done
on
that
based
on
some
of
the
organization.
That's
happened.
B
A
Then,
if
that's
not
a
demo,
so
Jimmy
Jimmy's
gonna
walk
us
through
some
of
the
yeah,
so
the
I
believe
the
the
left
drawer
work
that
he's
been
working
on
with
with
Peregrine,
probably
towards
the
end
there
and
at
the
very
end,
we'll
of
course,
we'll
have
QA
and
then
open,
not
open
items
as
people
people
would
like
to
wash
it.
So
how
does
that
sound
sounds.
A
E
A
F
So
here's
the
backlog,
there's
the
description
there
was
like
that
attracts
issues.
So
these
are
all
issues.
Here's
you
know
every
new
issue
that
gets
opened
up.
You
know
kind
of
falls
in
this
ready
for
grooming
and
then
we
go
through
these
and
decide
which
ones
are
valid
and
we'll
close
duplicates
and
all
that
kind
of
stuff.
So
that's
that's
your
traditional
kind
of
backlog,
ready
for
development.
These
are
in
priority
order,
so
we'll
be
pulling
from
the
top.
That
would
be
the
most
important
thing
to
work
on,
but
yeah.
F
So
then,
once
somebody
picks
up
one
of
these
is
it's
as
easy.
Well,
actually
we
have
a.
We
should
probably
talk
about
our
contributing
process
and
how
we
assign
things
to
people,
but
for
now,
if
you
get
assigned
to
an
issue,
you
know
it'll
pop
over
here
to
dev
in
progress,
and
that
means
that
you
know,
if
you're,
actively
working
on
it
and
then
once
you
throw
up
a
pull
request.
It'll
it'll
end
up
in
this
pull
request
in
progress
column
and
that's
where
the
other
board
comes
in
got
me.
F
It'll
pop
over
to
this
review
of
progress
column,
there's
a
couple
of
columns
for
like
the
state
of
the
PR.
So
if
there's
changes
requested
or
you
know,
something's
on
hold
or
it's
been
approved
once
it's
a
approve,
there's
kind
of
this
ready
for
QA,
like
reviewer,
approved
and
ready
for
QA,
economist
and
arm,
is
here
then
there's
another
column
for
when
QA
is
in
progress
on
it
and
then
the
PR
is
kind
of
considered
done.
F
So
if
we
pop
back
to
this
other
board
here,
so
that's
that
would
be
the
end
of
pull
requests
journey
and
then
so,
once
it's
done
it,
you
know.
The
issue
will
show
up
here,
ready
for
production
and
then
once
we
do
a
release,
we'll
kind
of
flush,
this
column
and
and
things
will
move
to
release
calm.
So
these
are
all
the
things
that
are
done
and
merged
into
develop,
but
not
but
haven't
been
part
of
it
again
so
fun
just
for
clothes
issues.
Yeah
we'll
have
to
fix
that.
F
C
Now
I
think
now
it's
almost
clear
just
to
first
go
my
walking
progress.
Currently,
it's
it
doesn't
work
this
request,
but
we
already
cannot
put
as
a
VIP
his
real
address
to
the
title
of
the
paw
request
and
this
question
left
immediately
mode
to
this
column.
So
it's
a
little
bit
another
pose
and
then
provide,
but
we
calculate
also
can
use
this
column
cool.
A
And
I
think
one
of
the
biggest
reasons,
barber
trend
and
do
this
is
to
be
consistent
with
the
community
engineering
projects
and
so
you've
got
blue
Tamir
on
the
team
from
from
access
organization.
You
know,
we've
got
quite
a
few
contribution
days
that
are
coming
up,
and
so
we
want
to
shore
up
our
work
so
that
people
can
start
to
contribute
and
especially,
if
they're,
already
familiar
with
one
project,
they'll
be
familiar
with
all
them.
A
C
A
E
E
The
the
Munich
contribution
day
that
I'm
going
to
be
personally
attending
is
nicely
centrally
located
in
the
middle
of
Europe,
so
it
might
be.
Nice
I'd,
be
nice
pickings
for
you
all
and
in
light
of
the
are
sort
of
busier
schedule
in
the
autumn
and
the
excitement
that
we
have
towards
a
few
new
feature
concepts
and
a
few
new
initiatives
in
PWA
studio,
we're
trying
to
open
and
tag
more
issues
that
are
ready
for
contribution
or
for
suggestion,
or
even
just
guidance,
an
argument
from
folks
in
the
community.
E
The
one
that
I'm
the
most
interested
in
right
now
is
one
that
I
opened
because
I
only
care
about
any
things
and
that's
a
ticket
to
add
static,
compiled
server-side,
rendering
to
venya
I
spoke
about
this
in
a
previous
community
sync,
and
that
was
kind
of
in
the
middle
of
showing
off
a
bunch
of
code.
I'd
like
this
to
be
a
simpler
and
quicker
message.
E
We
don't
need
to
do
complicated,
server-side,
rendering
or
almost
any
cases
with
pwace
to
do.
Venya
can
render
from
a
completely
static
pre-generated
HTML
document.
It
will
be
easier
to
understand
and
Eric's
Berman's
are
showing
other
people's
experiments
are
showing
that
it
will
probably
feel
faster.
So
this
doesn't
mean
we
get
rid
of
upward
SSR.
There
are
other
cases
where
it's
important,
and
so
you
need
to
have
an
SSR
concept.
You
need
to
have
a
server-side
rendering
capabilities
in
the
stacks
it
might
turn
out
to
be.
E
It
might
turn
out
to
be
insufficient
for
some
purpose.
We
need
in
the
future,
so
we're
prepared
to
accept
that
and
maybe
add
something
to
the
concept.
But
for
now
it's
looking
like
the
sort
of
very
simple
basic
server-side
render
that
upward
can
do
out
of
the
box
is
about
as
much
server-side
render
as
you
need
and
for
most
cases
before
your
phone
for
your
browser.
For
basically
anything.
That's
not
a
search
marketing
bot,
we're
gonna,
try
to
do
fully
static,
compiled
server-side
vendor,
and
there
are
a
number
of
different
ways
to
go
about
that.
E
In
our
custom
architecture,
we
could
try
to
simplify
upwards
to
make
that
happen.
There
are
also
some
off-the-shelf
solutions
for
web
pack
that
are
possible
rather
than
me
disappearing
for
two
weeks
and
making
something
and
then
demanding
that
everybody
understand
it.
I
wanted
to
invite
folks
from
our
community
to
contribute
to
this
or
to
make
arguments
for
or
against
it,
and
that's
why
we
opened
this
ticket.
E
The
things
that
I
have
just
explained
to
you
are
kind
of
laid
out
here.
Ssr
may
not
be
necessary
for
most
renders
and
I
wanted
to
briefly
show
off
the
most
popular
plugins
in
the
web
pack
ecosystem,
one
that
is
part
of
the
create
react,
app
workflow
most
web
pack
based
scaffolding
projects
and
has
probably
the
largest
plug-in
ecosystem
within
a
plug-in
that
exists
in
the
web
pack
world
and
that's
the
HTML
web
pack
plugin.
E
What
this
does
is
it
helps
you
to
create
an
HTML
file
as
one
of
your
generated
web
pack
assets
and
almost
always
that
means
that
you're
generating
a
file
to
be
used
as
an
application.
Shell
and
index
dot,
HTML
that
your
browser
receives
that
helps
it
to
load
the
JavaScript
app
the
HTML
web
pack
plug-in
has
just
countless
teachers,
you
shouldn't
use
all
of
them.
It
can
get
too
complicated
and
the
whole
point
of
this
is
to
make
it
simpler.
E
But
the
key
difference
is
that,
instead
of
waiting
for
a
request
to
come
in
too
lazily
create
an
HTML
document
waiting
for
graph
QL
to
come
back,
etc.
We
we
would
like
to
try
not
bothering
to
do
any
back-end
work
or
just
sending
out
an
HTML
document.
So
all
the
document
would
need
would
be
to
have
hard-coded
links
to
the
JavaScript
asset
files
that
are
necessary
so
with
the
asset
manifest
plug-in
that
we
have
and
with
the
other
parts
of
the
build
pack
and
web
pack
echo
system.
E
This
is
a
perfect
candidate
for
generating
the
type
of
HTML
file
that
we're
talking
about
lots
of
capabilities.
Lots
of
concepts
ends
really
extensive
documentation.
So
this
is
the
place
where
I
would
suggest
that
you
get
started
and
now
that
there
is
a
single
place
for
PWA
studios
library
code
to
include
changes
to
the
web
pack.
Configuration
I
feel
comfortable,
saying,
there's
a
place
where
you
can
contribute
work
that
would
be
used
by
many
many
other
folks.
E
It
used
to
be
that
everyone
out
there
who's
doing
a
project
has
copied
the
venía
directory
to
some
extent
and
they've
probably
made
some
changes
to
this
big
web
pack.
Config
file
that
we've
done
very
well.
That
file
is
small
now
and
where
you
would
implement
the
HTML
web
pack
plug-in
if
you're
doing
it
for
your
individual
project.
E
You
might
do
it
in
web
that
config,
but
if
you're
here
on
this
call-
and
you
want
to
contribute
to
the
core
codebase,
then
there
is
now
a
place
here
in
build
pack
in
our
configure
web
pack
function.
This
is
where
we
do
all
the
stuff
that
an
off-the-shelf
project
might
do
in
web
pack,
config
dot
j.
Yes,
here's
where
you
might
do
something
like
adding
the
HTML
web
pack
plug-in
to
the
recipe
that
we
have
set
up
here.
I
would
really
be
interested
in
folks
developing
experiments
towards
this.
E
So
that's
just
this
summary
I
intended
to
make
it
that
short
at
first,
but
it
is
a
large
topic
and
probably
something
that
I
could
answer
more
questions
on.
If
you
guys
need
clarification,
bottom
line
is
this
is
just
an
exploration
story,
a
research
spike
and
we'd
like
to
invite
folks
in
the
community
to
be
part
of
our
own
research
efforts.
E
E
No
all
right,
then,
okay,
the
other
thing
I
want
to
point
out
is
that
we
recently
merged
a
major
change
to
the
organization
of
the
codebase.
There
is
now
a
venía
UI
directory,
which
contains
almost
all
of
the
stuff
that
used
to
be
in
venía
concept.
So
the
vast
majority
of
the
code,
including
component
code,
redux
code,
this
all
lives
in
another
package,
called
Vinnie
a
UI.
E
That's
intentional,
because
the
NIA
UI
is
supposed
to
be
a
library
for
other
applications
to
include
and
many
a
concept
is
the
perfect
example
of
an
application
that
takes
the
UI
library
and
then
renders
it
into
a
web
page
and
then
builds
a
document.
So
it's
wind
pack
that
builds
that
document.
Venía
concept
is
the
place
that
connects
via
UI
to
build
pack
to
produce
a
finished
progressive
web
app.
E
If
you
are
working
on
a
code
project
right
now
that
you
branched
before
we
made
this
change,
you
might
worry
that
this
is
going
to
make
your
merge
impossible.
I
promise!
It's
not!
So
it's
not
going
to
be
that
hard.
There
may
be
some
difficulty.
You
may
want
to
make
sure
that
you
do
merges
carefully
and
we'll
try
to
help
you
with
that
when
we
can,
but
the
bottom
line.
Is
it's
not
going
to
be
that
bad?
E
It
understands
when
you
have
a
move
to
file
and
if
you
make
a
change
that
file
and
then
try
to
merge
in
a
move
of
that
file,
it
should
do
the
right
thing
fortune
and
I'm
loading
up
the
PR
so
that
you
can
see
this.
Fortunately,
you
might
see
that
get
is
aware
that
we
didn't
just
like
delete
a
directory
and
create
a
new
directory
that
we
actually
copied
files,
and
you
can
see
that
it
understands
that
and
github
does
too
so,
go
forward
with
confidence
and
continue
to
merge,
develop
into
your
open
work.
E
It
should
work
just
fine.
That's
the
only
other
piece
of
news
that
I
have
I'm
gonna.
Stop
sharing
questions
concerns
vehement
disagreements.
A
D
E
E
A
It
was
really
cool,
so
all
right,
well,
very
good.
Well,
thank
you.
Sarah
I
said:
let's
not
switch
gears
and
show
you
a
little
demo.
So
I've
got
to
give
me
a
mention
that
there's
some
leftover
progress
here
worth
that
kind
of
we're
sharing
working
pretty.
That
could
be
a
great
time
to
show
it
and
get
some
feedback
cool.
G
Drawer
seem
like
a
good
place,
because
it's
kind
of
a
deep
tree
right,
it's
sort
of
an
app
within
an
app
it's
a
routable.
You
know
it's.
It's
got
different
views
within
sort
of
a
modal
view
and
that
in
that
left
drawer.
So
what
I've
done
here
is
reworked
how
state
for
navigation
is
kept
and
then
reorganized
the
views
into
into
a
header.
The
category
tree,
authentication,
bar
and
authentication
modal
with
all
of
the
sub
flows
within
it
create
account,
forgot
password
my
account
and
sign
in
and
now
keeping
that
state
much
as
possible.
G
G
Then
there's
another
change
in
here,
which
is
where
this
branch
initially
began,
which
actually
is
going
to
alter
the
category
tree
here
to
expose
all
of
the
categories
for
the
first
time.
You
can
now
actually
look
at
more
than
just
a
few
top-level
categories.
You
can
actually
come
in
here
and
look
at
belts,
for
example.
G
We're
still
we're
still
waiting
on
one
more
on
one,
more
addition
to
graph
QL
that
will
allow
us
to
understand
the
child
count
before
we
click
in
to
a
category.
So
so
that's
why
you
see
a
slight
flash
there
as
it
performs
the
query
to
like
figure
out
whether
it
belts
has
any
child
categories,
but
once
we
once
we're
able
to
fetch
basically
children
of
children-
and
this
will
be
even
more
seamless
than
it
is,
but
for
right
now.
G
G
Is
that
the
app
state
that
is
available
from
redux,
and
that
is
still
held
in
redux
here
at
the
moment,
is
being
threaded
through
context?
So,
if
you've
been
paying
attention
to
the
project,
you've
probably
seen
quite
a
bit
that
we
are
using
react
contexts
pretty
extensively,
maybe
compared
to
other
apps.
That
you've
seen
context
is,
is
the
best
way
to
take
state
that
lives
up
high
and
pat
and
make
it
available
to
the
app
at
any
level
down
below
the
tree
without
having
to
thread
it
through
every
step
along
the
way.
G
This
is
going
to
be
particularly
powerful
for
extensions,
which
don't
have
control
necessarily
over
the
entire
tree
right.
So
if
you
wanted
to
change
something
at
the
bottom
of
the
left
drawer,
you
would
have
to
change
the
navigation
and
every
view
in
between
normally.
But
if
we
can
provide
appstate
via
context,
then
you
can
just
change
whatever
you
want
at
the
bottom
of
the
tree
and
tap
into
that
app
state
sort
of
like
connecting
and
redux,
but
without
the
performance
penalty.
G
We're
rendering
context
providers
with
that
state
and
API
state
and
api's
data
here,
and
this
proves
out
the
concept
without
quite
overhauling
everything
yet.
But
what
you
can
see
is
that
this
pattern
can
work
for
the
app
and
so
when
we're
ready,
we
can
do
this
context
providing
at
the
root,
and
we
can
provide
all
of
the
actions
that
are
associated
with
app
and
with
user
with
catalog,
and
so
the
components
underneath
here
that
the
navigation
and
everything
down
below
will
still
just
use
the
they'll
just
use
a
context.
G
D
H
G
That's
that's
still
a
call
we
can
make
it
doesn't.
It
doesn't
matter
too
much
for
the
current
implementation.
It's
just
just
a
question
of
whether
we
want
you
know
whether
we
want
to
avoid
the
churn
or
not.
You
know
whether
it's,
whether
it's
figured
better
to
go
for
the
bigger
change
now
to
avoid
churn
or
just
to
go
for
the
smaller
change
now
and
and
be
prepared
to
make
the
big
one
in
the
future
yeah.
G
G
A
A
All
right,
oh,
very
good.
Well,
thank
you.
So
much
for
everybody's
help
lots
of
great
progress.
You
know
for
those
are
following
the
history.
We've
done
some
great
work
thanks
to
folks
like
Nicholas
and
others
who
have
gotten
some
some
PRS
committed
in
this
week's
this
week's
progress.
We
also
upgraded
to
16.9
of
react,
which
is
pretty
exciting,
for
that.
So
definitely
take
a
look
at
that.
As
always,
if
there's
any
questions,
you
know
where
to
find
us,
but
again,
thank
you.
Thank
you.