►
From YouTube: PWA Grooming July 27, 2018
Description
Grooming of the PWA studio's next feature set
A
So
first
of
all,
I
want
to
come
back
to
the
to
the
homepage,
the
venue
homepage
or
on
CMS
I
know.
We've
made
a
lot
of
good
progress
last
week
on
it
with
aren't
much.
We
rushed
a
bit
and
so
I
want
to
make
sure
that
as
a
good
understanding
of
that,
and
so
if
it's
worth
a
quick
review
on
that
I'm
willing
to
spend
a
few
minutes
on
that.
A
If
you
guys
are
okay
with
that,
the
second
piece
is
checkout,
and
so,
as
as
we've
moved
into
the
scenario
based
approach
to
our
work,
which
I
can
share
with
you
here
in
just
a
second
checkout
is
paramount.
And
so
what
you're
going
to
see
on
Mondays
demo
at
the
at
the
usual
time,
is
as
a
full
completed.
Checkout.
You
guys
have
seen
the
basics
of
it.
A
It's
been
coming
together
in
a
very
iterative
fashion,
but
Jimmy
before
he
left,
I
checked
in
with
with
it,
was
gonna,
give
us
a
true
Magento
order,
and
so
we're
excited
to
share
with
you
that
on
Monday,
but
but
with
with
anything,
you
know
there
were
some
trade-offs
made
along
the
way
in
this
kind
of
minimal,
viable
approach.
The
the
cart
and
check-out
the
osya
that
you've
seen
on
the
right
came
in
as
a
drawer
and
the
the
order
completely
confirmation
came
in
as
a
drawer,
all
things
that
are
still
successful
to
get
things
done.
A
Think
that
has
a
lot
to
do
with
you
know
it
has
a
lot
to
do
with
the
attendees
we
have
today,
I
think
with
every
growing
our
attendees
shift
from
one
to
another.
Are
we
gonna
be
more
front
and
focused?
Are
we
gonna
be
more
PHP
focused,
and
so
we
can
cater
based
on
that
I
know.
Alex
you've
been
chomping
at
the
bit
and
been
working
with
the
the
Web
API
folks.
Actually
it
looks
like
you.
A
You
hosted
recently
a
community
session
which
is
pretty
exciting
as
well,
but
there's
aspects
of
that
that
we
can
cover.
We've
got
plenty
of
work
to
go
around
and
that,
and
so
with
that
and
of
course,
with
James's
direction,
we
can
go
a
little
bit
deeper
on
developer
experience
if
we
like
it,
look
at
a
couple
stories
there.
A
So
that
was
the
that's
the
intent
and
that's
the
that
was
the
plan
for
for
today's
berming
again,
based
on
the
feedback
we've
got
this
week,
based
on
kind
of
where
we
left
off
last
week,
which
is
the
which
is
around
the
homepage
and,
of
course,
leaving
room
for
anything
else.
So
with
that
mind,
are
there
any
any
questions
or
comments
before
we
get
started.
A
A
We
can
go
through
these
one
by
one
which,
which
would
be
one
way
of
going
about
it,
but
in
terms
of
kind
of
where
we
left
off
with
your
understanding
of
those
did,
you
feel
like
we
left
that
in
a
good
place
for
you
two
to
get
started,
did
you
think
any
of
anything
after
afterwards,
in
terms
of
how
we're
breaking
down
things
like
how
to
get
a
gallery
and
other
aspects
of
the
homepage?
For
you
for
you
to
get
going
or
or
simply
put
is
this?
Is
this
sufficient?
B
A
It
that's
it
good
and
I
was
gonna.
Ask
you
about
that,
and
so
we're
on
just
to
give
you
a
little
backstory
art
has
been
a
hero
lately
for
us
and
has
done
doesn't
done
a
recent
poll
request
this
week
on
the
homepage,
and
so
he's
got
the
basics
of
that
up
were
doing
some
merging
and
reviewing
now
and
so
hopeful
we're
hoping
cross
our
fingers
that
that
also
will
be
part
of
Monday's
demo
book.
A
Again,
as
we
look
at
components
like
the
product
gallery
and
like
like
these,
others
are
these
things
that
you
think
you
can
start
looking
at
next
week
in
terms
of
your
availability,
so
we're
thinking
a
little
bit
around
sprint
22,
which
starts
next
week.
Are
there
aspects
of
this?
Do
you
think
you
can
begin
begin
working
on
or
too
early
to
tell
based
on
your
availability,
no.
A
So
I'll
go
ahead
for
the
purposes
of
at
least
of
this,
since
we're
here
on
a
tag
tag
this
one
first
print
22
which
begins
on
Monday
and
and
then
we'll
we'll
shuffle
this,
and
if
we're
and
get
this
in,
for
the
beginnings
of
that
on
Monday.
So
that's
that's
super
helpful
cool,
all
right
so
on.
So
then
that's
not!
Let's
switch
gears
here.
Then,
what
check
out
again,
we've
got
I.
Think
we've
got
a
good
queue
here
for
good
queue
here.
A
For
for
what
we
want
to
do
on
the
homepage,
the
checkout
is
next
and
again
for
those
who
the
those
who
saw
the
demo
I
think
what
I'd
like
to
do
is
to
build
off
of
this
epic
here,
which
is
the
again
the
full
checkout
experience
for
venya
and
I.
Think
where
we've
all
done
nicely
here,
is
to
set
up
a
very
minimal
form,
things
that
are
traditionally
again
write
real
kind
of
sliding
components
very
minimal,
but
still
allow
you
to
create
a
completed
order
confirmation.
A
So
what
I'd
like
to
suggest
are
a
series
of
you
know
a
series
of
improvements
that
that
basically
make
the
static,
editable,
so
shipping
addresses
and
about
potentially
expansion
for
multiple
payments,
things
that
were
just
baked
in
assumptions
that
we'd
like
to
like
to
expand
down
a
little
bit
further,
some
of
which,
of
course
like
payments,
will
be
much
more,
will
be
much
more
involved
in
others.
But
it's
important
for
us
to
Kirk
start
carving
this
out.
A
A
A
So
this
is
the
phases
we're
looking
at
for
for
the
whole
shopping
experience,
and
so,
if
you
look
at
the
the
full
phases,
we've
done
the
basics
of
Phase
II
or
what
you
see
here
right
and
so,
when
we
talk
about
shipping,
address,
we're
talking
about
payment,
login
account
again
and
it's
very
highest
level.
We're
gonna
be
breaking
down
the
epic
in
these
very
various
ways:
sound
Mia's,
getting
done
a
nice
job.
For
my
account,
we're
probably
not
ready
yet
for
stories.
A
I
mean
we
kind
of
know
what
it
looks
like,
but
for
the
purposes
of
today's
grooming
will
likely
start
tackling
that
next
week.
But
we're
gonna
be
doing
the
we're
gonna,
be
doing
things
around
the
the
the
shipping
address
and
method
as
we
evolved
for
Phase
II
er
into
one
eventually
around
phase
two
which
we're
considering
our
MVP.
And
then
you
know
if
we
get
more
contribution
from
the
community,
we're
hoping
to
get
into
areas
like
like
wishlist
subscriptions
and
other
areas
that
are
important,
but
maybe
not
as
important
as
a
complete
checkout.
A
So
again,
this
may
be
a
repeat
for
some
folks,
but
I
do
want
to
kind
of
put
this
out
there
to
show
our
thinking
and
how
this
is
coming
together
in
a
in
an
iterative
format.
Any
questions
about
this
before
we
go
to
the
story
again,
I
just
thought
this
would
be
useful,
yep
cool
all
right.
So,
let's
switch
gears
then.
A
So,
let's
take
a
look
at
the
checkout
experience.
We're
gonna
again
build
this
off
of
the
the
epic
here.
That
is
the
the
checkout
experience.
As
you
guys
know,
the
first
one
takes
a
little
bit
of
work
and
then
we
get
into
kind
of
a
repeat
of
a
repeat
way
of
kind
of
copy,
paste
and
and
modify,
and
so
let's
take
a
look
at
the
epic
that
we
have
here
for
checkout
experience,
and
this
is
pretty
basic.
A
A
Edible
editable
shipping
address
or
check
out,
but
no
we've
looked
at
this
a
little
bit,
but
I
really
want
to
formalize
this
in
a
way
that
formalize
this
in
a
way
that
it
gets
I
gets
put
into
it
to
what's
being
done
and
there
Jimmy
had
started
off
with
that.
So
this
one
it
is
a
in
other,
because
it's
really
a
feature
description.
So
as
a
shopper
again,
I
want
to.
A
E
A
Alright,
we'll
try
that
again,
guys
are
being
so
polite,
I'm
sitting
there
typing
here
very
good,
so
so
we're
gonna
start
off
with
this
one
so
implement
implements
editable
shipping
address
for
our
checkout.
So
for
this
one
again
this
is
gonna
affect
the
venue
venue
theme
itself.
It
is
a
feature
so
we're
gonna
mark
that
as
other
and
then
as
a
shopper.
I
want
to
to
use
a
use,
an
actual
address
for
shipment
when
making
a
purchase.
A
A
A
That's
essentially
what
we
want
to
do
in
terms
of
tasks
themselves
and
I
think
this
is
where
I
want
to
get
a
little
bit
of
help
on
this
one
in
terms
of
tasks
themselves,
like
I
mean
we
can
talk
about
the
components
themselves,
we
can
talk
about
the
the
existence
and
the
in
the
modification
of
the
checkout,
but
what
else?
How
should
we
break
this?
How
should
we
break
this
up
in
terms
of
building
off
of
the
existing
experience.
C
Well,
first
of
all,
we
need
to
just
as
a
as
a
plain
old
acceptance
criterion:
yeah
yep.
We
need
to
say
that
it's
possible
to
fill
out
and
address
them
for
multiple
countries.
Some
of
the
people
who
are
working
on
this
will
not
know
how
to
formulate
the
United
States
zip
codes.
So
we
cannot
afford
to
be
completely
completely
national
centric
about
this.
So
acceptance
criteria
on
all
types
of
international
address
there
are
most
types
of
international
address
are
supported.
Yeah.
A
C
C
B
C
Everything
we
want
to
support
those
things
and
we
we
can
only
support
them
in
so
far
as
the
rest.
Api
supports
them.
So
if
there
is
no
way
to
access
the
list
of
countries
in
rest,
then
our
MVP
right
now
would
include
simply
our
coding
countries
based
on
prior
knowledge
and
then
perhaps
making
that
hard-coded
list
configurable
at
Build
time,
and
then
it
bill
time.
You
would
do
what's
necessary
to
integrate
with
Magento
and
find
out
what
the
country
list
is.
I
can.
B
Tell
here
that,
for
example,
we
working
on
graph
QL
and
a
configuration
feel
scattered
from
agenda
which
are
generally
those
countries
list
region
and
so
on
a
we
know.
We
need
that
config
API
ago.
So
in
that
short
path,
first
part
is
already
merged
and
second
one
is
extended
at
T
is
coming
so
I
would
say
that
we
can
use
those
calls
from
graph
career,
forgetting
the
config.
G
C
C
E
G
C
A
good
hack,
yeah
there
we
go
I
like
to
use
an
end
just
to
get
a
little
bit
of
extra
and
yeah
ok.
So
this
is
getting
big
yeah,
but
I
also
I
think
these
are
things
that
are
really
about
quality
and
definition
of
death.
Oh
yeah
I'm
angry,
it's
good
to
have
them
in
acceptance
criteria
for
the
initial
story.
So,
let's
happen,
yep.
A
C
No
I
think
you
need
it
on
VP
darkness,
but
the
companies
that
we're
talking
about
here,
like
when
Rowan,
says
autocomplete
attributes.
That's
literally
just
like
one
piece
of
text
that
you
had
to
every
component
operator.
Oh
really,
autocomplete
is
not
like
pulling
something
that
autocompletes
out
of
the
API
call.
If
so,
just
tell
the
browser
that
they're
allowed
to
fill
in
save
shipping
address
Oh
got
it,
so
it
sounds.
Yeah
browser
level
all
goes
yeah.
So
what's
really
not
that
bad,
but
I
think
that
we
should
say
it's
got
to
implement
some
aspect.
C
It's
got.
That
means
just
implement
some
of
the
vignette
visual
concept
I
mean
so
we're
gonna
attack
to
talk
to
this
yeah.
Unfortunately,
Sammy
is
out,
so
we
can't
pull
up
that
calm
and
identify
it
super
easily
unless
either
of
you
guys
have
like
the
envision
facilities
to
do
that.
I
mean
this
one
right
here.
Oh
did
we
already
look
at
it
and
I
missed
that
we.
C
All
right
now,
let's
blow
everyone's
minds
with
a
forum
on
the
web,
that
obviously
there
are
a
lot
of
questions
to
answer
here.
That's
why
it's
an
MVP
yeah,
so
I
mean
the
styling
cues
that
you
could
take
or
that
it's
a
drawer.
It
comes
from
below
and
mobile,
and
this
is
the
this
is
a
mobile
design
zone,
yeah
and
they're
now,
they're
all
other
designs
our
second
day
yeah.
C
This
is
a
drawer.
It
comes
from
below
you.
You
fully
justified
that
fields.
Obviously
there
must
be
some
way
to
select
country
so
that
the
rest
of
the
fields
adjust
in
their
labels
and
validation
states,
so
that
you
know
for
firoan.
You
would
get
like
a
historic
County
field
and
like
a
for
for
art,
where
art,
where
you
located.
C
Traffic
yeah,
so
so
you
know
we
would
get
like
I,
don't
know
fiefdom.
Europe
is
weird
so
yeah
we've.
Obviously
we
do
adjust
the
the
address
fields
based
on
what
is
there
so
yeah?
You
guys
already
are
familiar
with
how
the
data
population
functions
in
Magento
as
as
Alex
as
you've
observed.
So
this
to
me
seems
like
it's
doable
in
a
sprint,
probably
an
eight
pointer
to
be
very
safe,
but
we
don't
need,
for
instance,
to
address
all
possible
types
of
client-side
validation.
C
A
I
think
I
think
that
makes
sense,
yeah
cool,
let's,
let's
there's
just
one
out,
then
at
least
for
the
sake
of
this
exercise,
so
tagging
it
for
venya
assignee.
We
can.
We
can
worry
about
that
later,
unless
anybody's
feeling
ambitious
right
now
same
thing
with
milestone.
We
worry
about
that
during
sprint.
Planning
like
this,
a
proper
eight
pointer,
which
is
just
for
those
who
are
following
along
as
a
full
sprint
of
work,
and
then
the
epic
itself
is
part
of
checkout
and
then
crossing
our
fingers.
A
I'm
gonna
put
this
in
considers
for
release
three
of
this.
The
very
least
we
should
consider
that
next
again
for
those
who
are
following
along
release,
three
is
lined
up
two
quarter
three
and
so
we're
in
the
middle
of
that.
So
hopefully
we
can
get
this
done
within
the
current
release
and
I.
Think
that's
I
think
that's
similar
to
what
we
anticipated
so
cool,
good
stuff.
Anything
else.
Any
other
questions
or
comments
is
a
really
good
feedback
before
we
are
before
you
submit
this.
D
A
A
So
so,
let's
take
a
look
at
payment,
then
so
I
think
we
got
a
sneak
peek
of
what
payment
looks
like
from
Sammy
again,
some
of
those
some
of
the
earlier
work
that
she
did
I
think
we
again
even
being
payment
provider,
agnostic,
I
think
we
can
create
something
that
has
the
beginnings
of
what
payment
might
be
I
know,
though,
the
considerations
for
PayPal
and
other
considerations
for
Google
pay
all
those
things,
but
at
least
begin
with
what-
and
this
may
be
something
that
comes
later
but
begins
of
what
like
what
might
credit
card
be
if
we
once
when
we
come
back
around
to
that
and
less
so
worried
about
the
backend
aspects
of
it,
but
maybe
the
front
end
the
the
scenario
based
approach
of
like
when
we're
ready
for
this.
A
What
might
this
look
like,
and
so
this
one's
gonna
be
a
little
bit
more
a
little
bit
more
abstract,
but
I
think
it's
important
to
put
this
in
here
for
our
for
the
completion
of
our
checkout
scenarios
personally
for
the
larger
estimate
itself,
but
also
again,
to
show
us
what's
next
and
help
us
inform
the
rest.
So
that's
we're
gonna
do
next.
A
A
C
G
G
B
C
Another
possibility,
too,
is
because
I
think
that's
significant
metadata
on
the
quote:
object
that
you
could
consider
looking
at
the
quote:
object
in
graph
QL
writing
a
module
that
extends
the
schema
and
adds
that
information
to
quotes
because
it's
relevant
in
that
context.
It
also
it
may
be
different
depending
on
the
quote,
so
I
think
ultimately,
we'll
probably
want
it
to
be.
There.
G
No
so
I
think
my
point
here
would
be
that
you
can
absolutely
do
like
a
form
with
the
autocomplete
attributes.
You
can
very
easily
do
the
payment
request
API,
but
the
utility
of
those
is
kind
of
tied
on
having
that
at
upfront
as
to
what
those
valid
payment
methods
are
before
you
present
them
to
the
user.
Yes,.
C
G
C
C
We're
grabbing
them
from
rest.
What
I'm
concerned
about,
because
it's
the
client-side
that's
doing
that
is
I'm
concerned
about
the
security.
Is
that
an
admin
only
REST,
API
and
I?
Actually
don't
have
that
in
front
of
me,
because
I
have
swagger
in
front
of
me,
so
it
sounds
like
there
could
be
a
spike
on
it
and
that
that
would
have
time.
Yeah
I
mean
rest.