►
From YouTube: Magento PWA Demo, 13 August 2018
Description
Sprint 22 demo for Magento PWA and PWA Studio.
A
In
addition
to
that,
we're
going
to
cover
some
development
documentation
as
well
as
so
Sambi
is
sitting
in
for
us
and
we're
going
to
continue
to
show
some
progress
on
the
the
venya
global
styles
project,
which
is
which
is
helping.
You
know,
helping
everyone
kind
of
learn
the
components
of
the
pages
that
we
continue
to
share
and
build
out
with
the
community
with
folks
like
that,
we
like
our
demand
and
others.
So
that's
really
the
lineup.
A
For
today
it
should
be
a
short
one
again
based
on
the
capacity
from
this
last
sprint,
but
we
want
to
keep
the
keep
with
what
we've
got
and
and
then
share
with
what
we've
got
as
well.
So
but
without
further
ado,
looks
like
let's
start
off
with
that.
Jimmy
here
is
going
to
show
us
some
work
on
checkouts,
as
well
as
some
of
the
some
of
the
extensibility
work.
B
Ordinarily,
when
you're
going
to
checkout,
you
enter
the
page.
You
need
to
do
some
kind
of
initial
requests
to
get
a
guest,
cart
or
load
it
from
local
storage.
If
one
already
exists
on
your
browser,
we
need
to
make
sure
the
checkout
is
in
the
right
state
since
you've
your
set,
and
then
we
need
to
get
the
details
of
that
cart,
and
so
you
see
that
whenever
you
refresh
the
page
you're
going
to
see
these
requests
that
go
off,
one
is
to
guest
kurtz
there's
totals
this
is
how
it
works
on
master
today.
B
B
Okay,
so
now
we
have
notice
that
all
of
the
Redux
actions
which
are
being
spit
out
here
in
the
console
as
we
go
through
this.
This
is
what
we're
paying
attention
to
down
here.
These
are
now
prefixed
by
their
area
or
domain
within
redux,
so
toggle
drawer
is
an
app
action
will
be
prefixed
as
app
cart
actions
we
prefixed
with
cart,
etc.
B
A
B
So
this
is
kind
of
a
pattern
that
we'll
see
after
this
refactor
right,
where
we
have
a
submit,
the
request
goes
off
and
then,
if
it
comes
back,
we'll
get
the
accept
version
of
that
action
and
if,
if
it
for
hundreds
or
five
hundreds
will
get
a
reject
for
that
and
then
once
we've
once
we
sent
that
off.
Since
the
response
that
we
get
from
the
server
is
not
particularly
useful.
We
update
the
cart
again,
and
so
now,
if
we
were
to
dive
back
in
here,
we'll
have
the
correct
information.
B
And
we're
good
so
to
walk
through
real
quick.
What
we're
looking
at
here!
Here's
the
address
form!
This
is
what
it
looks
right
now,
because
we
have
not
written
abstractions
for
this.
So
it's
it's
just
plain
old
containers,
labels
text
fields.
There
are
other
inputs
available.
The
inputs
here
are
coming
from
the
successor
to
react,
form
which
is
called
informed.
But
if
inputs
here
text
text
area,
radio
check
box,
select
a
multi-select
and
forms
are
a
higher-order
component
passed,
children
is
prompts
to
there's
lots
of
options.
Lots
of
documentation.
B
B
Check
out
flow
remains
largely
the
same.
There's
flow
component
renders
a
form
if
we're
in
the
checkout
form
section
and
then,
if
we're
editing,
the
address
that'll
run
to
the
address,
so
we'll
follow
the
same
pattern.
When
we
get
to
billing
information
and
shipping
method,
etcetera,
then,
to
take
a
look
real,
quick
at
the
way,
the.
B
Actions
and
reducers
manufactured
let's
dive
into
checkout
or
cart
so
inside
the
cart
where
we're
defining
actions.
This
is
effectively
events
right,
so
here's
the
here's,
the
namespace
for
them,
and
now
we
just
have
a
big
list
of
all
the
plain
sort
of
events
or
actions
associated
with
the
cart.
We
use
this
create
actions
function
here
to
make
functions
for
all
of
them.
It
will
automatically
create
action
payloads
you
give
it
type
and
that's
the
default
export
coming
out
of
a
of
an
actions
file,
and
then
we
have
a
bunch
of
async
action
creators.
B
These
are
the
orchestrators
things
that
like
to
make
API
requests
or
call
sequences
of
actions,
and
so
for
each
of
these
things
we
have
a
general
pattern
of
taking
in
a
payload
from
the
call
site,
maybe
doing
some
work,
and
then
we
return
the
thunk
same
as
before,
which
can
do
the
orchestration
here.
We
make
our
request,
weight
it
and
then
dispatch
its
results
or
if
there
was
an
error
during
the
request,
catch
the
error
and
dispatch
the
same
action
with
the
error.
B
What
we
can
do,
because
of
the
way
we've
created
these
actions,
is,
we
can
say,
dispatch
action
saw
add
item
this
one
is
coming
automatically
from
here.
So
when
we
create
these
actions,
it
generates
functions
that
we
can
automatically
call,
and
those
things
are
named
so
that
when
we
come
over
to
the
reducer.
B
We
really
just
import
them
up
here,
board
actions,
and
then
we
can
define
our
map
of
reducers
and
put
those
functions
in
as
the
action
type
that
we
want
to
handle,
and
so
now
this
reducer
file
is
totally
isolated
from
whatever
those
actions
might
be
exactly
named,
and
these
will
be
much
easier
to
refactor
in
the
future.
It'll
be
much
clearer
to
document
in
the
future.
They
all
follow
the
same
pattern.
B
B
D
A
Absolutely
thank
you
so
much
to
me,
yeah
I'm,
taking
a
look
at
the
board
right
now.
I
think
this
really
closes
what
we've
got
on
the
MVP.
So
I
think
that
was
the
last
remaining
portion
of
that
on
the
editable
shipping
I
think
shipping,
obviously
I
think,
is
in
good
shape,
and
then
you
showed
a
little
bit
there
on
extensibility,
so
I
think
really
really
good
sprint
for
you.
So
I'll
go
ahead
and
close
those
out
for
that.
So
thank
you.
So
much
thanks,
sir
excellent.
A
D
So
I'm
going
to
see
I
work,
we
have
request
that
I
made
to
kind
of
improve
internal
processes
that
were
part
of
a
epically
opens
and
that
we
sort
of
opportunistic
we
put
stuff
in
MATLAB
for
so
kind
of
a
commando
on
that,
and
then
there's
also
sort
of
the
beginnings
of
a
specification
for
military
or
architecture
which
I'd
like
to
share
ready
to.
Do
that
sound
me?
Would
you
like
to
go,
or
would
you
like
said?
Oh
wait.
A
C
All
right,
so
I
am
standing
it
in
for
mr.
jimothy
aka
James
Kalka
been
on
Docs.
So
what
we've
tried
to
do
is
to
provide
some
vailable
guidelines
for
component
work,
that
community
developers
or
whoever
it
is
that's
building
out,
venire
components
or
just
components
can
follow.
This
is
very
specific,
and
so
how
we
try
to
organize.
C
We've
tried
to
provide
links
to
the
open
source
sort
of
resources.
We
are
using
in
benya,
wherever
applicable,
whether
that's
phones
or
icons,
and
then
also
the
fallback
for,
if
you
are
not
using
the
one
in
venya,
you
know,
needs
to
happen.
Relative
text
type
of
typographic
size
specifications
a
sample
to
show
you
know
how
many
weight
variations
we
recommend
using
and
which
ones
how
to
deal
with
animations
and
easing,
and
then
the
icon
library
that
we're
currently
using
that's
it.
C
So
next
steps
on
this
is
we
currently
have
some
external
developers
as
part
of
Magento.
You
in
this
office
I'm
working
with
Calcavecchia,
to
define
some
tasks
from
a
usability
standpoint
that
we
can
test
with,
and
then
you
know,
stop
getting
feedback,
more
focused
feedback
on
the
dark
side
and
these
individual
pieces,
and
we
will
continue
to
refine
this
any
questions.
I.
D
B
D
A
D
D
You
might
see
that
in
the
slack
channels
and
the
tweets
and
in
some
of
the
github
issues,
some
of
the
most
common
problems
that
people
encounter
are
the
gwa
dev
server
part
of
build
pack
which
just
comes
right
out
of
the
box,
totally
pre-configured
with
venía
and
is
also
a
part
of
the
instruction
set
that
we
put
out
for
build
pack.
It
tried
to
do
a
couple
of
things
which
it
it's
not
super
great
at
on
everybody's
platforms.
D
It
tries
to
provision
them
as
a
cell
certificate
in
assumes
that
open
ssl
exists
in
a
certain
way,
and
it
tries
to
welcome
at
your
host
file,
which
is
the
most
cross-platform
way
of
providing
a
unique
domain.
And
writing
you
need
to
main
is
identity
in
order
for
people
to
work
on
multiple
PWA
simultaneously
without
overwriting
their
own
service
workers,
which
is
a
use
case
that,
as
it
turns
out,
was
probably
not
the
best
thing
to
focus
on
for
MVP.
It's
an
important
use
case
and
it's
it's.
D
The
the
code
is
still
useful
important,
but
making
it
optional
is
the
right
way,
and
so
that's
that's
sort
of
the
course
correction
we've
done
and
in
this
and
this
pull
request
not
only
didn't
make
those
things
optional
and
turned
off
by
default,
but
we
also
have
a
much
more
insistence.
You
don't
see
it
for
there's
two
leave
me
stuff.
You
know
much
more
consistent
documentation
regarding
it
and
I'm,
not
sure.
If
that's
going
to
be.
D
Yeah
we
have
a
much
better
configuration
documentation
for
it
and
it
works
a
lot
better.
It
does
a
very
simple
thing
where
it
will
create
a
unique
domain
if
you
wanted
to
based
on
file
system
path
of
your
GWA
studio
directory
and
that
if
it's
the
sort
of
work
style
of
people
that
we've
seen
work
and
is
a
lot
less
ambitious
than
what
we're
trying
to
do
for
analyze
a
lot
less
on
the
local
database.
Again,
it's
already
be
documented.
D
It
doesn't
show
up
perfectly
in
this
readme,
because
when
it's
published
in
dev
Docs,
it
looks
a
lot
better,
but
until
this
is
merged,
it
won't
be
published,
Deb
doc.
So
there
you
have
it
we're
a
little
in
the
way
of
demo.
For
this,
mostly
because
it's
meant
to
resolve
bugs
gonna
occur
on
other
people's
machines,
but
I
think
it's
important
to
point
out
that
we
have
a.
D
Iterative
process
of
moving
away
from
early
mistakes
or
early-
you
know
it's
just
soy
sin
that
we're
going
to
continue
to
do
that
so
as
an
important
thing
and
I
think
that
was
the
right
time
to
transition
to
a
specification.
I've
written,
unified,
PWA
definitions
of
graphs,
which
is
declared
sighs.
Oh
so
what
it
is
is
its
unified
PWA
definitions
of
grasses.
It's
going
to
be
distracting
because
it's
also
could
be
called
upward.
I
have
a
branch
where
it's
wise,
distractingly
named
and
I
totally
thought
he.
C
D
It's
about,
anyway,
what
this
repository
will
ultimately
be
is
a
test
suite,
which
is
something
that
other
specifications
like
mustache
and
a
QL
argument.
That
way.
Basically
it's
something
that
you
can
run
against
a
server
that
you
make
to
make
sure
that
it
hears
to
a
specification.
Let's
talk
about
that
specification
and
the
rationale
for
it.
An
upward
file
is
a
gamma
file,
maybe
later
when
the
law
and
XML
capability
to
it,
for
the
people
who
are
the
most
familiar
with
it.
D
But
it
is
a
completely
declarative
description
of
how
an
application
shells
server
should
function
an
app
shell
is
very
minimal,
and
this
is
an
ID
which
has
been
done
before
declarative
service.
Orchestration
is
something
that's
there's
hundreds
of
papers
on
in
computer
science,
I,
actually
reference
them
and
I
think
in
this,
but
with
progressive
web
apps.
There
is
a
subset
of
all
the
things
that
HTTP
can
do
that
we
want
to
do
and
that
we
want
to
be
responsible
for
and
because
of
that,
strict
subset.
D
It
gets
small
enough
and
the
set
of
behaviors
that
we
want
to
enable
gets
strict
enough
that
a
specification
language
becomes
a
real
possibility
with
that
sort
of
descending
into
rewriting
a
programming
language
in
XML.
There's
a
single
branch
structure
in
this-
that
is,
pattern
matching,
which
is
a
proven
technique
that
is
very
maintainable
and
also
variable,
and
the
rest
of
it
is
all
just
sort
of
processes
describes.
That's
assemble
an
application
shell
from
a
backhand
of
data.
D
D
There
is
a
request,
object
which
begins
the
cycle
and
is
always
present,
and
because
this
doesn't
do
anything
but
add
a
status
value
to
the
context
and
some
headers
and
a
body,
it's
not
going
to
add
anything
else
or
receive
anything
else
from
the
context
beside
was
built
in,
and
so
there
is
a
mustache
template
that
renders
what's
available
in
that
request,
object,
which
is,
of
course,
evil
things.
Http
version.
D
It
reads
over
header
entries
to
get
to
all
the
headers
that
came
back
or
the
call
post,
testing
or
captain
I
have
an
implementation
of
this.
That
is
running
fairly
well
and
passing
tests
with
a
few
snapshots
here
that
are
present
to
demonstrate
the
configuration
file
is
supposed
to
be
the
only
thing
that
a
server
means,
and
it
may
refer
to
other
local
files.
So
it
would
make
groups
have
folder
with
some
vacuole
queries
in
it,
and
then
those
queries
would
be
referenced
in
a
more
complex
example.
D
Here
we
see
the
branch
logic
there's
a
particular
type
of
action
or
response
later
called
a
win,
and
the
win
has
a
magic
laws
which
specifies
a
match
for
the
context
object.
So
if
there's
a
status,
it
will
do
a
regular
expression
against
that
status.
These
are
cross-platform
regular
expressions
that
should
be
influenced
in
the
ex
reg
X,
which
is
available
at
all
languages
and
upon
matching.
There
is
a
respond
clause,
which
is
another
node
which
implements
the
response
plan.
D
One
of
these
servers
is
supposed
to
detect
topological
dependencies.
So
since
this
thing
checks
on
the
status,
then
it
has
to
wait
to
execute
until
the
status
is
available.
So
rather
than
having
to
do
a
lot
of
after
in
the
floor
specification
or
make
sure
that
your
parallelizing
things
it
paralyzes
everything
by
default,
collects
these
rules
is
going
to
run.
E
D
As
much
concurrency
as
platform
will
permits
that's
up
to
the
implementation,
and
if
you
need
to
do
something
in
series,
it's
going
to
emerge
naturally,
because
the
dependencies
that
you
write,
you
can
see
a
more
complex
example
of
that,
and
actually
how
you
put
together
on
the
gentle
application
show
weight
thing
about
yanil
is
that
it
has
anchors
marshaling
xml
refs,
so
this
is
completely
unread
by
the
system.
All
that
it
cares
about
is
the
group
property,
and
it
just
is
a
useable
block
of
your
starter.
D
So
there
specifies
that
when
the
URL
matches
anything
about
HTML
that
it's
likely
to
be
an
SEO
friendly
URL,
so
in
order
to
resolve
it,
we
have
to
do
these
things.
First
of
all,
we
have
to
give
the
general
store
data.
This
is
a
graph,
you
well
query,
and
it
can
be
cash
and
the
caching
is
not
the
responsibility
of
the
server
that
happens
in
parallel
and
simultaneously,
a
request.
Goes
the
URL
resolver,
a
notice
that
we're
passing
something
to
the
request.
Is
this
something
that's
part
of
our
context?
D
The
URL
is
just
part
of
the
context,
object
that
were
assembling,
so
we
pass
it
in
as
a
variable
and
then
specify
an
actor
manually
in
this
example,
because
this
example
is
written
prior,
the
topological
sorting,
but
it's
after
the
URL
resolver
is
completes.
Then
we
can
go
through
a
conditional
match
on
what
the
URL
resolver
type
returned.
D
So
I
tried
to
go
to
the
trouble
of
explaining
why
this
is
necessary
based
on
12
factor
principles
and
starting
from
there.
A
progressive
web
app
is
a
strange
thing,
because
a
web
app
historically
cannot
function
without
backing
services.
So
it's
really
only
part
of
an
apple.
It
has
to
be
on
the
network
and
progressive
web.
That
has
this
new
thing
called
offline
mode.
We
it
has
to
run
as
much
as
possible,
but
without
any
backing
services
of
any
kind.
D
So
there's
this
coupling
that
exists,
even
it's
all,
even
at
a
12
factor
app,
and
this
diagram
is
actually
taken
from
12
factor
dad
where
the
production
deploying
has
orchestrated
URLs
to
services
and
that's
a
nice
bit
of
decoupling,
but
it
still
requires
that
these
four
services
with
these
roles,
be
there.
The
great
thing
about
a
total
factor
is
that
if
you
want
to
swap
out
the
my
sequel
implementation
with
another
server,
you
can.
But
this
is
still
something
that
kind
of
ad
hoc
depends
on
this
broad
graph
of
services.
D
D
Network
operation
that
you
need
to
do,
and
once
you've
done
that,
then
you
actually
have
a
specification
that
you
can
package
with
the
progressive
web
app
so
that
the
PWA
can
declare
what
kind
of
application
could
shell
it
needs,
independent
of
the
service
architecture.
For
some
reason,
this
thing
isn't
resolving,
but
the
idea
of
service
orchestration
is
common,
but
this
is
really
more
of
a
service
choreography
concept
which
is
sort
of
a
new
idea,
but
in
service
orchestration
there
is
a
notion
of
an
orchestra.
Where
is
an
object?
D
There
are
a
whole
lot
of
connectors
that
come
the
box
that
allow
you
to
configure
how
you
passed
that
authentication
law
much
in
the
way
that
varnish
and
the
edge
side
includes
passed
your
session
along
to
the
other
URLs
that
it
calls.
This
would
do
the
same
thing
so
as
a
individual
loading
of
aggressive
web
app.
My
session
would
be
passed
to
these
various
services.
It's
not
up
to
the
implementer
of
the
under
language
of
the
graph
QL
to
make
everything
graph.
You
know
before
this
comes
out.
D
D
That's
what
I
got
again,
it's
it's
a
specification
in
progress,
and
what's
the
appearance
of
this
specification
should
motivate
is
an
implementation
of
PHP
which
I
wanted
to
try.
I
think
that
it
was
out
of
scope,
but
I
wanted
to
kind
of
demonstrate
that
it
was
pretty
easy
to
do
the
things
that
are
necessary
and
supported,
which
are
just
adding
calling
and
doing
branch
logic.
Those
are
all
things
that
I
found
PHP
libraries
to
do.
D
A
I
think
it's
great
I,
I,
think
I
know
we're
do
working
on
some
discovery.
Work
for
middle
tier
I
think
this
is
a
big
big
first
step
of
this
and
love.
It
continue
getting
some
feedback
from
the
community,
especially
as
we
post
this
out,
but
I
think
this
solves
a
lot
of
those.
You
know,
there's
modularity,
extensibility
questions
that
we
have
especially
with
this
this
approach.
So
thank
you.
This
is
great.
D
Great,
thank
you
very
much.
I
guess.
That
concludes
my
part
of
the
demo.
Although
I
think
it's,
it
would
be
cool
to
observe
that
we
started
reporting
our
tests
as
j-unit
XML
into
LCI,
which
we
weren't
doing
before.
We
were
running
our
tests
inside
the
danger
file
and
that's
a
sort
of
that.
So
that's
an
implementation
detail.
D
What
it
means
is
that
there
was
only
one
system
that
understood
how
well
we
were
passing
our
tests
and
it
wasn't
reporting
by
angle
over
time,
but
circle
CI
now
understands
our
test
output
and
can
give
us,
as
we
get
more
and
more
successful,
builds
and
master.
Some
really
great
insight
into
how
much
working
code
coverage
and
quality
and
then
brass
that
you
can
show
that's.
A
D
A
A
Okay,
very
good,
so
just
start
cleaning
up
the
other
sprint
that
we
have
here.
I.
Think
we've
I,
think
we've
done
quite
a
bit
here
as
you've
seen
in
inspir,
22
I
mean
I,
would
I
would
consider
everything
that
we've
got
here.
Essentially
close
I
was
closing
this
throughout
from
this,
and
so
thank
you
again
for
everybody's
attendance
everybody's
work
at
though
it's
again
it
was
a
bit
of
a
difficult
week
in
terms
of
availability,
but
I
think
we
got
a
lot
done
and
that
and
what
relatively
short
amount
of
time.