►
From YouTube: Magento PWA Backlog Grooming, 14 September 2018
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).
A
Now
we
have
just
a
couple
of
items
that
have
surfaced
in
priority
over
the
last
week,
which,
which
means
that
they're
late-breaking
sudden
changes
in
priority,
but
fortunately
they're
not
I,
think
very
heavy
they're,
not
very
hard,
so
we
felt
that
it
wasn't
too
big
of
a
surprise
to
try
to
move
in
this
direction
for
Magento
like
Europe
Eric.
Do
you
want
to
go
on.
B
B
There
we
go
very
good.
So
what's
our
goal
for
this
afternoon,
so
by
the
way,
hi
everybody,
and
so
so
we're
gonna
get
that
get
started
here.
So
we're
going
to
cover.
We
had
three
major
stories.
The
first
one
is
a
bit
of
a
bit
of
a
minor
edit
from
last
week,
but
I
do
want
to
make
sure
everybody's
aware
of
that.
B
But
then
the
other
two
get
us
into
some
some
interesting
areas
around
configurable
products
and
the
pagination
component,
which
at
which
I
think
will
be
the
interesting
one
to
tackle
on
the
category
page.
And
so,
if
we
take
a
look
at
the
first
one
here,
James
you
don't
mind.
Let's
take
a
look
at
the
implement
order,
confirmation
or
the
very
first
one.
This
should
be
sorted
there.
It.
A
B
Where
we
left
off
late
on
Friday
and
so
Ansem
had
some
really
great
feedback
on
really
how
to
make
this
simple
and
and
really
to
make.
This
simple
is
about
creating
just
an
email
that
gives
you
the
password
and
in
that
plan
during
during
that
moment,
with
the
current
API
is
the
account
can
be
made,
and
so,
of
course,
we're
going
to
have
a
more
robust,
create
account
experience,
you'll
click
this
and
that
will
link
up
to
some
of
the
existing
work,
which
is
great,
but
to
really
make
this
independent
from
others.
B
I
think
is
a
great
was
a
great
idea.
The
idea
and
the
clarification
that
we
may
hear
both
in
the
assumptions
and
the
tasks
were
to
create
that
account
and
then
quickly
be
able
to
be
sent
an
email
about
what
that
about
what
you
know,
basically
confirming
that
that's
been
done
and
and
then
you
can
verify
in
that,
an
m2
that
they
count
as
and
create
it.
So
that's
really
all
there
was
and
and
so
James.
B
The
actual
API
itself,
I
guess,
there's,
there's
an
aspect
here
of
the
other
management
interface
that
needs
to
be
exposed,
but
then,
from
that
point
you
could
be
able
to
send
the
mail,
although
I
do
think
you
probably
need
to
be
a
little
bit
of
work
on
how
to
get
the
the
mail
services
spun
up
so
I
added
that
also
at
the
task
and
then
just
verifying
it
make
sure
that
they
counts
created
and
that's
it.
So
we
had.
You
know
we
made
this
a
fairly
sizeable
story.
Upfront,
but
I.
B
Think
we've
now
simplify
this
into
something
that
still
gets
that
account
created,
but
doesn't
necessarily
have
to
string
together.
Some
of
the
things
that
we
can.
We
can
cover
in
later
stories,
so
yeah,
just
an
update
on
that
based
on
kind
of
the
post
grooming
activities,
but
I
wanted
to
open
this
up
to
the
floor
and
see
if
there's
any
questions
first
and
then,
and
then
just
confirm
the
estimate.
Second,
to
make
sure
that
we've
got
a
good
understanding
for
this.
A
Aleks
ought
to
be
familiar
with
the
practice
of
taking
an
API
interface
and
exposing
it
in
the
REST
API.
There's
a
pattern
to
it,
so
it's
actually
really
straightforward
to
do
and
if
you
need
any
assistance
with
it,
whoever
takes
the
story.
There
are
a
lot
of
experts,
including
some
of
our
core
architects,
who
can
show
you
how
most
of
the
boilerplate
and
the
plumbing
is
already
set
up.
Alex
I
know
you
know
how
to
do
it
because
you've
done
this
before,
for
it.
B
B
One
click
here:
we've
got
the
additional
screens
that
we
broke
out
under
a
separate
story.
You
know
we
actually
had
some
really
good
progress
from
the
bar
green,
so
simplifying
the
basics
of
that
there's
good
for
that,
so
just
join
into
that,
but
again
in
the
interest
of
making
this
independent.
This
is
just
the
creation
of
that.
We'll
probably
want
to
do
a
follow-up
story
next
week
that
actually
does
to
join
but
again
in
the
interest
of
making
this
brutally.
D
B
A
So
that
means
that
we
have
one
invocation
of
an
API
method
to
send
an
email,
one
invocation
of
an
API
method
to
populate
the
screen,
with
with
with
order
information
and
combined
customer
information,
and
then
the
UI
implementation
itself.
I
would
suggest
that
we
augment
these
tasks,
maybe
with
that
I'll
just
start
by
doing
that,
and
then
I
would
say.
C
E
C
Yes,
you
need,
we
want
to
display
information
about
the
order
that
was
placed
right.
You
know,
I
would
say
we
have
to
store
this
data
I
wanna
step
on
a
checkout.
We
already
don't
have
all
data
we
need.
First
of
all,
then
we
don't
need
an
extra
API
call
there,
because
that
data
is
already
there
because
he
submitted
it.
So
we
already
have
all
other
information
we.
A
Do
but
upon
submitting
an
order,
you
receive
confirmation
that
the
order
was
accepted
and
then
other
parts
of
the
resource
are
updated.
Perhaps
an
ID
is
created.
Perhaps
status
is
changed,
so
it
may
be
the
same
object
and
there's
parts
of
it
that
can
be
reused
but
for
the
sake
of
simplicity,
I
think
we
should
view
this
as
an
entirely
different
call.
I
know
it's
a
TWA,
so
that
seems
inefficient,
but
from
the
UI
developers
perspective
I,
don't
want
them
to
have
to
reuse.
C
A
So
there
are
a
couple
of
directions
to
go.
First
of
all,
my
favorite
baby,
the
upward
back-end
application
could
be
used
to
describe
an
integration
that
makes
an
administrative
rest
call
and
then
passes
a
subset
of
the
data.
However,
that's
maybe
a
stretch.
What
we
can
do,
instead
is
say,
identify
as
to
do's
identify
so
discovery
for
REST,
API,
graph,
QL
coverage
and
then
another
task
for
identify
admin.
Only
data.
C
A
A
The
configuration
here
uses
a
Magento
rest
administration
token,
as
one
of
the
standard
headers,
an
authorization
header
that
it
sends
with
all
of
the
requests
that
it
sends
to
the
Magento
REST
API.
So
in
this
case,
where
there's
an
idea
of
stitching
queries
together
with
graph
QL,
you
can
ignore
that.
But
here
you
can
see
that
we
have.
We
can
obtain
Magento
rest
admin,
token
and
upward.
A
That,
then,
is
lazily
required
by
the
headers,
which
are
then
lazily
required
by
an
API
call
and
then
use
back-end
environment
variables
to
obtain
that
token,
and
then
it
gets
stored
in
this
top-level
context
and
then
reused
when
creating
a
header,
and
then
we
can
take
API
information,
use
templates
to
strip
it
or
use
graph
QL
to
trim
it
and
then
send
it
along.
That's
that
way
we
can
expose
an
ad
hoc
endpoint,
which
does
no
logic,
but
just
as
transformation
and
an
authorization
to
the
to
the
client.
A
C
I
have
a
question
generally
from
another
dimension,
most
of
the
back-end
developer,
not
from
the
developer,
but
if
you're
talking
about
the
JavaScript
application,
though
the
front
of
the
application
like
TVA,
if
you
load
it
in
your
browser,
you
can
investigate
the
code
generally.
Can
you
found
talking
there
if
your
developer,
o.
A
Know
that
what
I'm,
what
I'm,
showing
you
here
is
a
description
of
server-side
behavior,
okay,
yeah
yeah.
This
describes
the
behavior
of
the
backend
for
front-end
server.
That
just
shows
the
app
shell
and
it
could
also
this
is
this-
is
experimental
code
I'm
just
showing
you?
It
could
also
expose
an
endpoint
which
uses
and
environment
variables
from
its
back-end
and
really
using
admin.
Username
and
password
is
not
ideal
in
the
first
place.
I
just
didn't
want
to
go
through
the
OAuth
process.
C
A
So
now
I'm
getting
that
out
of
the
way
again
just
showing
you
that
future
exposure
of
admin,
only
stuff
is
perhaps
possible
to
do
in
a
pinch
without
needing
to
wait
for
the
graph
QL
API
front-end
developer
could
potentially
just
edit
a
configuration
file
to
do
it
so
anyway,
since
that's
not,
there
I
think
we
need
to
expose
a
task
for
identifying
the
information.
That's
not
there,
there's
just
part
of
acceptance
criteria
and
then
creating
the
rest
API
as
a
back-end
task,
implementing
a
UI
that
consumes
that
rest.
A
A
C
F
A
E
B
E
E
A
A
B
C
A
So
I'll
get
right
out
in
front
of
this
and
say
that
infinite
scrolling
is
the
future,
but
it's
not
the
presence,
because
there
is
a
lot
of
state
management
to
be
done
if
that
is
to
be
usable
and
ultimately
I,
don't
think
it
makes
a
huge
difference
to
shoppers
it's
much
better
for
reading
volatile
information
like
posts
or
tweets
or
something
and
something
like
this.
It's
it's
nice,
but
not
necessary,
so
for
now,
I
think
we're
going
to
implement
a
plain
pagination
approach,
no
surprises
many
questions.
A
A
No,
please
no
ASMR.
If
we're
doing
the
pagination
this
way,
then
first
of
all,
the
the
tasks
include
discovery:
how
to
retrieve
the
product
data
from
the
rest
or
well
grab
ql
api.
Obviously,
because
that's
pretty
well
provided
the
pagination
technique
is
something
you're.
Gonna
have
to
to
look
up
and
figure
out,
then
there's
the
implementation
of
reusable
pagination
component
or,
if
you
want
to
you,
can
implement
thing
that
just
is
stuck
right
into
category
and
we'll
pull
it
out
later,
but
I
suspect
everyone
on.
A
A
D
C
C
A
C
A
C
A
A
Okay,
Benny
I
tried
to
spell
venir
right
like
six
times
so
presently
the
the
way
that
the
filter
works
am
I
gonna
be
able
to
pull
it
up
in
time.
Perhaps
not.
It
doesn't
include
a
concept
of
a
pagination
unit
and
if
you
look
at
graph
QL
tutorials,
there
are
several
approaches
to
pagination,
including
cursors.
A
Cursors
are
nice,
but
since
the
product
data
doesn't
change
that
much
they're
not
strictly
necessary
here,
so
it's
like
totally
basic
straightforward
page
info
page
size.
Current
page,
total
pages,
you're
not
gonna,
have
an
offset
index
of
records,
so
I
think
that's
pretty
pretty
nice
pretty
straightforward.
A
A
B
That
is
a
great
question.
I've!
Never
done
that
yet
and
then
but
I
wonder
if
that's
possible.
What's
it
well.
A
A
A
Now
we
update
okay.
So
let's,
let's
first
get
that
out
of
the
way.
I
think
what
we
can
do
is
talk
about
how
you
might
approach
doing
the
UI
story
anyway.
So
any
thoughts
on
how
you
might
at
least
come
up
with
a
pagination
UI
component
and
do
a
fair
portion
of
this
story.
Even
though
the
underlying
graph
QL
API
doesn't
adequately
support.
Pagination
I.
A
A
So
you've
got
experience
doing
something
like
this:
how
would
you
mock
it
out
so.
A
H
A
A
And
the
various
UI
states
that
it's
supposed
to
be
in
you
can
do
a
storybook
for
those
and
I
will
confess
that
my
recent
semi
absence
and
busyness
has
meant
that
I'm
not
up
to
date
on
everyone's
full
request.
But,
broadly
speaking,
do
we
have
story
books
that
we've
done
on
all
of
our
UI
stories?
No.
D
A
Been
a
weird
week
for
me:
I'm
just
you
know
it
opens
when
you
touch
it
so
the
react.
Storybook
is
similar
to
a
testing
utility
Aereo
sort
of
catalogue
that
lets
you
take
react
component
and
because
it's
a
component
can
put
it
in
isolation
in
the
sort
of
the
center
of
a
little
frame
and
then
plug
it
in
you
know,
matrix
style
to
a
mock
environment
that
puts
it
into
a
state
that
you
want
to
make
sure
is
visually
sensible.
So
shall
we
look
at
a
storybook
for
something
right
now,
I
know?
A
A
I'm
just
I'm
afraid
that
I'm
gonna
try
to
launch
the
storybook
and
it
won't
work
and
then
I'll
go
nuts.
So
when,
when
you
have,
when
you
have
a
storybook
again
very
similar
to
a
unit
test,
and
then
often
you
find
that
you
can
actually
reuse
modules
or
functions
between
the
storybook
in
the
unit
test,
so
you
know
be
on
the
lookout
for
that.
A
A
A
A
A
D
A
Mustache
love
it
I
will
take
a
look
though
so
again,
a
storybook
is
a
UI
that
is
based
on
analyzing,
the
metadata
of
the
things
that
you've
made
so
in
the
same
way
that
there
is
a
Doc's
folder
that
our
documentation
thing
sort
of
pulls
out.
There
is
a
test
folder
that
the
unit
test
framework
looks
for
there's
a
stories
folder
that
story
book
looks
for,
and
it
looks
like
this.
There
is
an
object
called
stories.
A
You
generate
it
by
naming
it
and
then
attaching
it
to
the
node.js
module,
and
then
it
has
a
nice
sort
of
fluent
API.
Where
you
add
stories
and
describe
the
story
use
case
and
before
react
components,
use
cases
can
be
very
small.
They
can
be
one
line.
Look
I
instantiated
the
component
like
this.
Okay
I.
Did
it
like
this
and
I?
Did
it
like
this?
A
A
A
So
if
you
create
a
storybook
for
something
like
this,
then
you
can
implement
it
entirely.
Separate
ands
then
have
a
very
simple
walkthrough
for
your
demo.
That
shows
off
the
different
states
that
it
can
be
in.
So
in
the
absence
of
a
full-fledged
API
that
supports
it,
I
would
recommend
doing
that
and
I
will
go
ahead
and
add
testing
documentation
is
appropriate,
I
will
add,
specifically
storybook
implementation
or
all
states
and
I
would
say
that
includes
first
page.
D
A
That's
one!
That's
zero
products,
I
assume
right
if
it
isn't
tournament
well,
usually,
when
I
see
that
that's
implemented
as
one
page
with
nothing
on
it,
am
I
right?
Oh
yeah,
that
seems
right
to
me,
I
mean
maybe
yeah
is
there?
Are
there
other
states
that
it
could
be
in
like
it
could
just
be
blank
or
something
yeah?
That's
what
I
was
imagining,
but
that
that
makes
more
sense.
I
mean
it
would
just
be
a
state
of
one
page,
yeah,
one
page,
nothing
on
it,
yeah.
G
G
Beres
yeah
I'm
at
what?
How
many
numbers,
for
example,
right
between
the
arrows
right,
that
that
that's
not
going
to
be
able
to
respond
to
how
many
you
know
down
how
much
with
there
is
there
and
that
the
the
available
area
might
change
in
response
to
how
wide
the
viewport
is.
You
know
they
might
want
it
to.
G
G
A
A
G
B
So
I
think
that's
reasonable.
I'm.
Also
looking
to
the
example
that
art
sent
and
chat
as
well
so
I,
don't
think
so.
I
mean
the
part
that
I
keep
thinking
about
is
making
any
determination
based
on
the
number
of
items
per
page,
which
gets
to
be
a
bit
of
a
sticky
wicket
because
of
the
changing
desktop
to
to
mobile
form
factors.
I
A
B
I
I
E
I
I
A
Message
received,
we
have
already
added
some
detail
to
it,
but
grooming
is
not
complete,
because
we
have
to
make
sure
that
the
design,
implementation
and
the
states
are
part
of
the
vini.
A
UX
story
and
just
to
be
clear,
Eric
may
have
made
the
the
prototype,
but
the
the
injunction
to
suddenly
look
at
configurable
products
and
pagination
came
from
this
guy,
because
we're
we're
thinking
about
quick
and
dirty
ways
to
increase
the
coverage
and
the
viability
of
a
store
for
demo
purposes
in
the
future
and
I
didn't
want
to
add
something
too
huge.
A
H
I
I
A
Let's
reiterate
this
being
a
grooming
session,
we
are
not
committing
to
implementing
the
stories
that
we
groom
as
soon
as
possible.
Please
do
not
use
your
Friday
to
finish
this
up,
just
recognize
that
we
have
set
it
in
an
order
of
priority
that
that's
just
something
that
you
can
do
during
grooming
and
we
needed
to
happen
some
sort
of
picture,
but
by
no
means
do
we
mean
for
it
to
be
normative,
since
we
haven't
done
this
before
it's
our
mistake
for
not
making
that
clear
at
the
outset,.
I
A
No
strong
reaction
I
think
it's
reasonable
to
keep
us
in
check.
Okay,
so
moving
past
pagination,
leaving
it
in
a
for
grooming
state
and
mindful
of
time
we
have
15
minutes
left
and
always
want
sessions
like
this
to
be
open
for
community
contribution
or
community
to
lead
us
into
a
different
direction.
We
have
few
more
things
we
could
potentially
discuss
configurable
product
details,
which
I
think
shares
in
common
with
the
pagination
saamiya
that
there
isn't
completely
finalized
UX
on
that
right.
I
F
A
Right
a
couple
considerations,
one
the
venÃa
catalog-
has
a
bunch
of
configurable
products
in
it.
You
might
have
encountered
this
when
you
tried
to
go
to
a
product
ad,
it's
a
cart
and
get
a
four
hundred
and
then
looked
and
inspected
the
JSON.
It
said
dude,
you
got
a
picture
of
Aryan
so
partly
because
of
that,
the
fact
that
we
have
that
as
a
catalog
and
partly
because
I
think
it
is
crucial
to
an
effective
demo
of
e-commerce
features
we're
going
to
push
on
getting
configuration
going
now.
I
think
this
is
a
stretch.
A
It's
there's
a
lot
of
little
bits
to
this
and
clearly
there's
there's
an
amount
of
metadata
on
each
configuration
option.
That
would
let
you
decide
between
swatches
or
numeric
things
or
etc.
So
this
is
not
small,
but
let's
talk
about
what
we
could
do.
That
is
so,
first
of
all
graph
QL.
Does
it
give
us
enough
information
about
product
configuration
options.
F
E
A
A
A
It's
always
nice
to
have
a
working
graph,
QL
environment,
ready
so
I'm,
starting
my
local
instance,
so
that
we
can
place
queries
against
it
and
understand,
what's
possible
for
us
to
observe.
But
while
that's
getting
started,
what
are
some
considerations
here?
First
of
all,
I
would
like
to
say
we
need
to
do
some
discovery
on
what
metadata
allows
us
to
choose.
Option
display.
Does.
E
A
A
We
go
a
lot
of
different
things.
I
mean
we
could
potentially
break
these
into
stories
for
each
of
those
little
options,
but
again,
knowing
that
the
talent
level
and
the
abstraction
level
of
the
of
the
staff
that
we
have
here,
I'm
sure
everyone
wants
to
do
the
the
reusable
thing
and
make
some
base
components
that
take
a
callback
to
render
the
UI
or
whatever
so
I.
A
A
G
H
G
H
G
A
Yeah
well,
while
you're
doing
that,
let's
say
that,
there's
a
there's,
a
certain
amount
of
information.
We
already
know
that
these
things
need
and
in
the
usual
pattern
of
container
2
presentation
component,
we
can
just
design.
Our
props,
however,
is
the
most
convenient
to
us
and
then
later,
when
there
is
binding
to
graph
QL
data
or
whatever
else,
then
we
can
implement
the
container
component
that
feeds
data
into
it
and
then
grabs
events
out
of
it
and
interprets
them
that
feeds
them
back.
So
yes,
product.
A
G
G
G
A
A
G
G
A
A
Alex,
thank
you.
So
much
for
your
help
have
a
good
weekend.
Sorry
I
saw
in
chat
that
he
has
to
leave
okay
great
see
if
you
can't
nail
estimation
for
this,
so
that
I
can
yield
the
floor
back
to
Eric,
who
probably
actually
wanted
to
run
this
in
an
organized
manner.
First
of
all,
does
everyone
agree
that
we
ought
to
separate
the
implementation
of
the
individual
components
with
all
of
the
UX
and
the
implementation
of
data
provisioning
to
them
in
two
separate
stories.
A
A
Okay,
so
then
we
have
three
things
to
implement.
Thank
you.
We've
got
a
numeric,
collector,
color,
swatches
and
text
values.
All
of
them
on
to
show
metadata
is
appropriate.
For
instance,
we
got
a
size
guide,
I,
don't
know
whether
that
goes
in
the
option,
selector
itself
or
whether
you
want
to
just
leave
that
off
or
later
injection,
but
I
would
like
it.
A
If,
for
instance,
you
know
the
swatches
did
have
tooltips
that
showed
their
names,
because
everyone
loves
the
names
of
colors
that
people
make
up
and
then
there's
they're
just
a
regular
selector,
so
they
need
to
show
out
of
stock
indicator
and
there's
also
ought
to.
In
my
view,
there
also
ought
to
be
a
notion
of
whether
you
will
have
such
a
thing
as
unselected
states
or
whether
you
begin
with
a
pre-selected
state
that
somebody
has
to
change.
A
G
F
D
B
D
F
A
D
H
E
A
A
A
E
A
E
A
We
can
be
fairly
nimble
here,
I
mean
we
can
take
the
two
stories
that
we
just
created.
I
haven't
implemented
this
I've
written
the
second
down,
but
we
can
take
the
two
stories
that
we've
created
and
easily
combine
them
into
one,
but
we
made
the
separation
in
order
to
mirror
the
architectural
separation
between
container
code
and
presentation
code
that
exists
in
the
paragon
type
of
implementation.
That
is
the
best
practice
to
react.
A
So
in
the
reason
that
you
do,
that
is
for
code,
reuse
of
the
presentation,
part,
and
so
I
would
say
that
there
is
two
types
of
business
value
being
delivered.
The
container
component
delivers
the
business
value
of
having
actions
and
reducers
wired
up
in
venya
for
processing
the
configuration,
so
that
directly
contributes
to
the
merchants
in
the
shop
or
the
ability
to
do
configuration,
and
it
also
gives
developers
hooks
to
put
in
their
own
components,
so
it
delivers
value
to
developers
and
to
shoppers,
of
course,
for
completing
a
configural
product
scenario.
A
The
the
presentation
story,
the
one
that
we're
looking
at
now
confers
two
types
of
business
value
as
well.
It
adds
to
the
toolbox
that
developers
have
when
implementing
UI,
so
it
increases
their
efficiency
and
it
adds
options
for
them
to
drop
in
things
and
and
of
course
it
completes
the
story
so
in
in
isolation.
Each
of
them
adds
business
value
to
one
or
another
persona,
either
Fredi
the
front-end
developer
or
Sheila
the
shopper,
but
together
obviously
they're
more
than
the
sum
of
their
parts.
You
know.
A
A
B
Always,
but
for
today,
no
just
to
thank
you,
so
thank
you
for
thank
you
for
covering
that
we
need
for
these
stories.
I
think
we
made
good
progress
on
the
few
we
did
cover,
including
close,
including
closing
out
the
order,
confirmation
piece
which
I
thought
was
good,
but
yeah.
Thank
you.
I
appreciate
everybody's
support
and
kind
of
thing
on
here
longer,
but
and
for
those
who
are
later
have
a
great
weekend.
Okay,
thank
you.
So
much
thank.