►
From YouTube: PWA Community Update April 26, 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).
A
A
But
we
have,
we
have
a
few
updates
today
to
go
through
some
pretty
exciting
stuff
from
the
team.
I
think
first,
we'll
have
some
updates
from
jimothy
on
some
doc
update,
Doc's
updates.
We
have
an
update
from
Andy
on
authenticated
user
workflow
for
checkout.
We
have
an
update
from
Jimmy
today
for
the
Peregrine
search
component,
the
progress
that
we've
been
making
there
and
then
I
think.
Finally,
we'll
have
James
talk
about
anything
that
he's
been
working
on
over
the
last
couple
weeks
and
be.
B
A
C
Two
new
dot
updates
from
me.
First
one
is
a
new
topic
that
talks
about
client-side
caching
under
the
overview,
detection,
they're
basic
concepts,
and
it
basically
goes
over
different
cash
flow
strategies,
client-side
caching,
strategies
that
we
use,
particularly
specifically
in
lavinia
as
links
to
more
more
documentation
that
provides
more
details
on
each
strategy.
C
Summarizes
that
the
next
one
is
so
Magento,
you
has
a
page
that
lists
some
learning
resources
or
PWA
development
in
general,
not
specific
to
a
PD
mini
studio.
This
is
where
the
videos
for
setting
up
the
storefront
and
got
their
deployment
are
posted
as
there's
a
lot
of
links
to
they
useful
useful
training
sites
for
learning
how
to
use
the
technologies
that
we
use
in
PDA
studio.
D
If
a
user
was
signed
in
so-
and
there
were
a
lot
of
bugs
around
that-
like
hey
I'm,
attempting
to
add
this
item
to
my
cart,
I
can't
do
whatever
the
case
may
be
so
I
went
through
and
fixed
a
lot
of
that.
These
are
using
folks
are
familiar
with
the
rest
endpoints.
These
are
just
the
cart
splash
mine,
endpoints,
once
you're
already
signed
in
so
here's
the
PR
updates.
D
The
rest
calls
removes
thing
from
the
checkout
receipt
telling
you
to
sign
in
and
basically
the
big
thing
is
to
enable
an
authenticated
user
to
that
completely
check
out
so
and
here's
venya
by
signing
here
my
super
real
user
and
I
kind
of
have
the
console
open
up
over
here
right.
You
can
see
some
of
the
actions
and
stuff
that
are
being
taken,
but
here's
our
trusty
guy
Freddy
is
signed
in
and
then,
if
I
just.
D
D
D
D
D
E
I
would
love
to
I
will
certainly
start
by
saying
that
the
demo
that
Andy
has
done
everything
that
went
weird
with
it
was
totally
not
part
of
the
main
purpose
of
the
demo
like
authenticated
users,
is
a
tough
thing
to
achieve,
because
our
graphical
API
and
our
REST
API
s
are
not
designed
so
far
around
interacting
with
a
browser
in
this.
In
this
context,
when
you
talk
to
a
browser,
you
need
to
respect
cookies
and
the
API
endpoints
kind
of
don't.
Instead,
the
browser
is
required
to
like
manually
keep
sending
this
authentication
token.
E
That's
part
of
what
makes
it
hard,
but
when
we
switch
to
graph
QL,
the
graphical
team's
assured
me
that
they're
gonna
start
respecting
cookies
in
the
first
place.
So
that's
one
reason
really
separate
from
the
graphical
API
that
this
stuff
is
gonna,
be
easier.
That's
why
it's
been
challenging
thus
far,
keine
is
authentication.
Management
is
something
the
browser
knows
how
to
do,
but
the
api's
are
not
expecting
so.
E
Synchronization
by
placing
a
bunch
of
calls
and
then
doing
a
background,
query
to
get
updates
from
them
and
that's
going
to
reduce
our
request
load,
that's
really
good,
but
it's
also
going
to
require
that
we
do
some
direct
interaction
with
this
asynchronous
API
concept.
So
what
we
want
to
do
is
make
sure
that
people
who
implement
new
graph
QL
stuff
are
aware
of
it,
but
that
they
may
not
have
to
deal
with
it
if
we
can
get
a
good
abstraction
going,
because
no
in
most
cases
you
don't
want
to
do
job
control.
E
You
just
want
to
add
something
to
the
cart
and
when
it
done
it's
done,
we
would
like
people
to
be
able
to
use
this
same
simple
graph,
QL
request
and
ingress
request
patterns
that
they're
familiar
with
that
work
for
our
purposes,
but
we
want
to
allow
if
you
want
to
for
you
to
get
kind
of
under
the
hood.
So
just
let
me
take
a
few
minutes
since
we
have
some
left
in
this
to
show
you
the
poll
requests
over
in
the
Magento
architecture
repository
that
goes
into
this
in
some
detail.
E
A
E
E
So
this
is
a
proposal
by
Anton
copula,
one
of
the
senior
architects.
There
are
other
architects
who
you
can
converse
with
on
Twitter
or
through
the
community
engineering
chat
or
through
any
other
channels,
you'd
like
to
talk
about
this
proposal,
but
we
had
a
meeting
with
them
the
well.
Actually,
this
is
a
pull
request.
Let
me
view
the
actual
file
ding.
E
Now
you
can
view
it
with
a
little
bit
formatting.
So,
as
he
said,
and
as
I
said,
Magento
is
gonna
have
to
support
higher
higher
concurrency
of
operations
and
that's
the
best
road
to
performance
for
our
back-end
systems,
especially
with
graph
QL.
So
right
now,
when
you
do
create
empty
carts
in
the
graph
QL
edge
API
that
we're
not
using
yet
you
just
get
back
the
cart
ID
that
you
just
created,
so
that,
in
the
server's
point
of
view,
is
a
synchronous
operation.
Now,
instead,
what
we
want
is
to
start
returning.
E
These
things
called
operation
state
interfaces,
and
this
is
a
little
bit
strange.
I
think
if
you're
familiar
with
graph
QL
ap
is
that
other
systems
have
and
the
existing
graph
QL
api's.
We
have
today,
but
remember
that
this
is
mostly
to
do
with
the
change
in
how
mutations
work
so
actually
the
rest.
This
is
the
query.
E
So
the
mutations
are
the
main
change,
and
so,
if
you,
for
instance,
were
to
create
an
empty
cart
with
the
modern
mutation,
what
you
would
want
to
do
now
is
run
this
mutation
and
expect
to
receive
back
an
identifier
into
tightening.
The
type
name
is
going
to
indicate
the
status
of
the
request
and
the
identifier
will
be
an
ID
for
you
to
hold
on
to
where
you
can
query
the
status
of
that
request
later.
So
you
receive
something
like
this.
The
type
name
says
operation
accepted,
so
we're
gonna
use
a
built-in
feature
of
graph
QL.
E
That
lets
you
check
on
the
type
name
with
introspection
and
the
type
name
indicates
a
status.
That's
a
nice
little
usage
of
graph
QL
features.
So
once
you
have
this
operation,
then
you
need
to
place
a
follow-up
query
to
a
root.
Query
type
called
queue,
and
then
you
send
it
an
array
of
operation.
Identifier
like
this,
and
it
returns
an
operation
state
interface
collection,
so
that
you
can
query
the
status
of
a
number
of
different
operations
simultaneously.
So
with
this
create
empty
cart
identifier,
this
represents
the
job.
That's
going
on
to
create
an
empty
cart.
E
Who
knows
how
long
it'll
take
not
long?
You
just
want
to
be
able
to
do
job
control.
Then
we
can
keep.
We
can
query
for
that
and
other
operations
at
the
same
time
and
find
out
that
the
operation
was
accepted
and
then
once
you've
done
that,
then
you
can
actually
request
more
information
based
on
particular
concrete
type
of
that
operation.
E
When
you
run
this
queue
operation
as
you
proceed
through
the
PWA
and
navigate
around
the
client
learns
all
of
the
concrete
types
of
the
different
queueing
operations
that
it
does
and
then
your
query
gets
more
and
more
sophisticated.
It
asks
for
a
cart
operation.
Give
me
that
cart
back
and
give
me
the
change
in
items.
So
this
does
add
an
extra
layer
of
indirection
and
abstraction
to
dealing
with
our
graph
QL
api's.
E
That's
a
cost
that
they
essentially
are
passing
from
their
server
side
to
our
client
side,
and
you
could
think
of
that
as
bad
news.
But
what
we
plan
to
do
is
implement
a
link
in
the
Apollo
client
that
can
handle
this
type
of
operation,
silently
so
that
when
you
run
create
empty
cart,
it
will
conduct
the
this
pair
of
operations
and
then
return
the
cart
to
you.
From
the
final
concrete
check
on
cart
as
though
you
didn't
have
to
deal
with
any
of
this
stuff.
E
E
Magento
graph
QL
team
is
going
to
start
giving
us
mutations
so
that
we
can
get
rid
of
REST
API
completely,
but
those
mutations
are
going
to
have
an
asynchronous
pattern
that
requires
us
to
do
some
job
control
requests.
External
quests
are
bad,
but
we
can
group
simultaneous
operations
together
so
that
it
ends
up
being
a
very
efficient
type
of
request.
E
We
can
also
implement
a
change
in
our
own
client
so
that,
if
you're
doing
simple
things
and
building
UI-
and
you
don't
want
to
think
about
it-
then
you
can
use
synchronous
feeling
graph,
QL
API,
then
the
Apollo
client
and
the
service
worker
will
do
that
hard
work.
This
is
a
proposal
and
it's
in
the
proposal
state.
E
Currently,
you
can
always
look
up
proposals
by
going
to
the
Magento
architecture
repository
and
checking
out
what
is
in
process
of
being
proposed
and
the
feeding
approved,
and
so
what
this
means
is
you
get
a
sneak
peek
you
get
a
preview
of
the
way
that
in
the
future,
certainly
after
imagine,
probably
after
another
minor
or
major
release
of
pwace
to
do
your
graph,
QL
interactions
are
going
to
have
to
work.
So
this
is
a
big
subject
and
I
don't
expect
that
everybody
is
going
to
understand
all
of
it
immediately.
E
I
certainly
didn't
when
I
heard
about
it
first,
but
because
it's
gonna
take
some
time
to
process
an
intake.
I
wanted
to
start
talking
about
it
in
the
PWA
community
early
and
take
this
opportunity
during
a
call
to
bring
it
to
everyone's
attention.
So
does
anyone
have
any
immediate
questions
or
concerns
about
this
new
API
pattern
that
is
going
to
show
up
in
a
couple
releases
time.
D
A
B
E
E
B
E
E
When
we
talked
about
this
I
said,
you
know
very
few
user
interactions
from
a
UX
point
of
view
really
need
to
expose
this
asynchronous
job
control.
You
know
when
you
click
place
order.
You
don't
want
to
have
like
an
order,
maybe
running
in
the
background,
and
then
you
continue
shopping
like
not
knowing
whether
your
order
is
done,
but
there
are
some
use
cases
where
our
UX
people
are
exploring
the
possibility
of
some
operations
like
that
being
queue.
E
So
there
may
be
some
cases
where
you
use
this
API
directly,
but
in
a
lot
of
cases
too,
you
shouldn't
have
to
worry
about
this.
Like
David.
Empty
card
should
not
be
in
operation
that
the
shopper
sees
is
being
queued,
and
we
want
to
make
sure
that,
if
you're
implementing
some
card
functionality
that
you
can
just
write
a
simple
graphic,
you'll
request-
and
we
will
deal
with
it
in
the
plumbing
to
do
this.
Asynchronous
management
and.
B
Do
you
know
if
this
is?
Is
there
gonna
be
some
system
sitting
in
front
of
the
load
balancer
to
to
manage
these
queues,
and
you
know
kind
of
hand,
acute
requests
to
a
specific
node
based
on
you
know,
availability
that
node
or
is
it
always
gonna,
be
once
that
queue
starts
on
a
node?
It
stays
in
a
node.
That
is
a
question
that
you.
E
B
E
Try
to
use
simple
words
lately
I
help
by
like
hitting
myself
on
the
head
before
these
calls,
I'm
gonna,
say
revolutionary,
API
and
tooling
library
for
you
to
write
PWA
you
eyes
and
connects
them
really
simply
to
data
and
state.
If
you're
not
familiar
with
react
already,
then
we
can
go
over
them
briefly.
But
correct
me
if
I'm
wrong,
Andrew
and
Andy,
if
we
have
did
Jimmy,
go
through
react
hooks,
didn't
he
go
through
the
react,
Oaks
concept
in
an
earlier
PWA
community
sink
or
not.
E
Yeah,
so
his
blog
post
is
out
there
and
for
those
of
you
who
haven't
read
it
react
hooks,
is
a
new
feature
in
a
new
version
of
react
that
the
react
at
Facebook
team
has
been
working
on
for
months
and
months
to
try
and
create
a
new
ultra
simple
API
for
code
reuse
inside
functional
components.
One
of
the
most
important
consequences
of
it
is
that
you
no
longer
have
to
write
classes
in
a
matter
of
fact,
if
you
use
hooks,
you
can't
write
classes
for
your
react
components.
E
This
is
going
to
take
some
getting
used
to,
but
from
a
front-end
development
point
of
view,
it
means
less
boilerplate
and
less
to
worry
about.
If
the
hooks
work
correctly,
they're
just
functions,
you
call,
and
you
don't
have
to
think
about
the
state
management
that
can
often
be
so
hard
so
hold
on
just
a
minutes.
Let
me
get
my
watch
going
and
I'm
gonna
share
my
whole
screen.
E
I'm,
not
I'm,
not
subtweeting,
no
one!
So
can
you
all
see
code?
Yes,
okay.
I!
Try
to
make
the
code
parts
of
these
demos
very
brief,
but
the
new
search
bar
experience
is
in
component
in
venía
just
like
anything
else,
but
it
utilizes
something
called
autocomplete,
which
is
a
separate
individual
component
inside
the
search
bar
component
system.
This
is
part
of
if
you
look
at
the
PWA
studio.
Actually,
James
are
the
mr.
Calvin.
Are
the
the
code
structure
guidelines
published
I
forget?
E
E
E
Sorry,
I
wasn't
expecting
to
be
demoing.
This
so
you'll
have
to
forgive
me,
but
it
is
fun
to
demo,
and
this
is
the
code
requirements
of
project
standard
coding,
yeah,
okay,
so
inside
react
components,
they're
contained
in
a
single
folder
and
the
index
j
s5
exposes
their
api.
So
in
the
case
of
this
search
bar,
it's
the
search
bar
component
itself,
but
we've
separated
the
actual
autocomplete
functionality
which
handles
the
concept
of
checking
the
product
search
from
sorry.
E
My
cat
fell
off
the
handles
checking
the
product
search,
we've
abstracted
that
into
an
individual
component,
so
you
can
see
that
we
use
autocomplete
in
the
search
bar,
but
the
search
bar
itself
is
just
responsible
for
showing
and
hiding
itself,
which
is
nice.
You
might
also
notice
that
search
bar
itself
is
no
longer
a
class.
You
don't
see
class
search
bar
extends
component
and
you
also
don't
see
the
component
class
even
being
called
from
react.
E
Have
what's
taking
a
little
while
yeah
that
it
would
actually
be
a
good
fit
for
this
stateless,
functional
component,
because
those
things
are
supposed
to
be
a
direct
function
of
props
that
are
handed
to
them
and
the
idea
that
something
that
all
the
stayed
inside
it
would
be
a
straight
function
seems
like
it's
a
serious
performance
problem.
Here's
the
great
thing
you
might
notice
that
this
hook
that
this
component
search
bar
checks
to
see
every
time
it
runs
whether
there's
been
a
change
by
running
the
used
callback
hook.
E
Now
this
callback
hook
gets
executed,
asynchronously
and
react
optimizes
how
fast
and
when
it
is
run.
So
then,
this
thing
can
run
set
expanded,
which
is
also
something
coming
from
a
different
hook.
Use
drop-down,
which
abstracts
all
of
the
plumbing
and
handling
of
a
drop-down,
and
when
this
set
expanded
function
gets
called,
they
use.
Drop-Down
plumbing
eventually
runs
this
function
again,
so
what
you've
done
is,
instead
of
thinking
every
time
anything
changes
this
whole
component,
this
whole
function
executes.
E
Similarly,
here
in
the
autocomplete,
we
have
use
effect
hook
that
checks
to
see
whether
it's
visible
and
valid,
and
those
visible
and
valid
attributes
are
passed
into
the
second
argument
of
the
hook.
So
again
that
react
knows
when
it
needs
to
call
this
callback
again
and
how
to
check
what
has
changed.
So
again.
E
This
is
a
set
of
data
access
and
data
manipulation
functions
that
all
get
run
at
the
very
top
of
the
component
and
react
handles
returning
those
and
executing
these
really
really
fast,
and
then
once
it
has
assembled
all
of
the
state
that
it
needs
to
render
a
list
of
suggestions
then,
and
only
then
it'll
returned
on
and
then
whenever
it
turns
out,
then
it
turns
the
autocomplete
Dom
into
the
search
bar
component,
and
the
search
bar
component
will
then
render
it's
done
again
after
collecting
the
state
that
it
needs.
So
again.
E
E
Uh-Huh
and
now
here
we
are
in
another
Pei
and
then
tank
is
what
that
mystery
voice
just
suggested
that
I
try
those
delays.
Those
are
coming
from
the
graph
QL
API
like
you
might
expect,
but
if
you
actually
look
at
the
graph
of
performance,
there
are
a
couple
of
spikes
in
there,
but
the
actual
rendering
has
almost
no
significant
delays
in
it.
E
So,
what's
wonderful
that
that
is
that
you
we
were
able
to
accomplish
this
degree
of
performance
without
writing,
class
search
bar
extends
and
then
maintaining
our
own
state
and
running
set
state.
We
have
delegated
all
of
that
work
to
react,
and
so
this
concludes
the
code
looking
at
part
of
the
demo.
E
This
is
I
hope
that
a
lot
of
you
will
agree
a
little
simpler.
Even
if
it
takes
some
getting
used
to
then
managing
things
with
classes
and
then
passing
handles
and
references
around
in
those
classes,
you
can
think
of
them
as
mix-ins
use,
callback
use
drop-down
some
of
the
custom
Peregrine's
hooks
that
we've
created
like
use
query.
E
You
can
think
of
these
as
nixon's
in
that,
if
this
was
a
class,
you
would
just
declare
that
this
makes
an
adds
functionality
to
this
component.
The
difference
is
that
these
mix-ins
execute
each
time
and
that's
mysteriously
fast,
and
you
don't
have
to
worry
about
the
problems
you
get
with
mix-ins
in
other
systems,
where
they
cause
serious
performance
downgrades
and
they
can
end
up
colliding
with
each
other.
These
vixens
always
return
specific
return,
values
and
objects,
which
you
can
then
combine
in
the
way
that
you
need
during
every
render
cycle.
E
It's
a
really
robust
and
really
scalable
system,
and
so
Peregrine's
is
beginning
again,
as
a
collection
of
hooks
hooks
can
connect
you
to
data.
They
can
help.
You
manage
UI
and
we
have
hooks
for
grabbing
the
apollo
client
or
subscribing
to
an
effect
by
listening
to
an
event
on
the
document
to
the
window,
like
we
showed
you
by
managing
the
state
of
a
drop-down
for
you,
so
that
you
don't
have
to
put
this
plumbing
and
I,
read
out
and
drop
down
style
component
for
running
a
graph,
QL
query,
which
is
pretty
exciting.
E
So
this
kind
of
loose
coupling
and
this
kind
of
mixin
style
functionality
should
help
you
to
implement
components
that
connects
to
Magento
and
connects
to
the
graph
QL
API
without
having
to
encode
too
much
logic
and
two
types
of
functionality:
integration
into
your
components
themselves.
This
is
going
to
enable
you
to
import
venía
components
and
use
their
style
or
to
import
the
underlying
Peregrine's
hooks
and
write
a
very
thin
layer
of
UI
on
top
of
them.
E
In
addition,
we
may
end
up
with
some
build
time
utilities
which
can
modify
or
even
replace
the
functionality
of
some
of
these
hooks
themselves.
So
this
represents
a
lot
of
new
extension
points
and
represents
the
way
that
new
components
will
be
implemented
and
that,
ultimately,
from
community
we're
gonna
we're
gonna
hope
that
you
start
implementing
new
components
that
you
contribute.
So
that
is
the
code
part
of
the
demo,
and
this
is
the
holy
crap.
It
works
part
of
the
demo
pants.
E
B
E
So
Jimmy,
what
I
went
over
basically
was
the
justification
for
bringing
hooks
in
I
didn't
introduce
the
entire
concept
of
hooks
and
the
our
intention
to
make
Peregrine
the
repository
for
the
data
connections
and
the
library
out
out
of
which
you
kind
of
pull
the
plumbing
stuff
that
the
otherwise
you'd
have
to
replicate
in
a
lot
of
you
is
all
right,
then
I
showed
off
the
fact.
That's,
despite
them
being
functional
components,
they
don't
new
between
render
state
management
at
all.
They
are
still
super
performance.
E
F
Actually,
the
the
demo
that
you
had
done,
the
the
parts
of
it
I
saw
there
covered
it
really
well,
and
the
flame
graph
is
a
helpful
way
of
understanding
one
of
the
major
benefits
of
switching
over
to
hooks
from
from
classes.
That
lets
me
react
solution
to
to
really
fine-tune
render
performance
in
a
way
that
doesn't
require
us
to
manually
optimize
it
all
the
time
right.
Then
this
really
helps
us
interact
with
with
their
schedule,
which
is
which
is
good,
but
the
other
thing
that
it
does
for
us.
F
It
can
not
be
opinionated
about
the
exact
Dom,
that's
returned,
and
so,
if
you
wanted
to
do
something,
that's
a
really
common
operations
such
as
render
an
input
field
right.
If
the
field
component
we
provide
does
not
include,
let's
say,
for
example,
a
label
that
depends
on
the
value,
you
can
actually
change
the
rendered
output
of
of
the
input
of
all
inputs
by
using
an
input,
specific
hook
that
we
have
and
then
rendering.
In
addition
to
an
actual
input
element,
you
can
wrap
it
with
a
div.
F
A
F
A
F
In
NVIDIA
right
we
have,
we
have
a
bunch
of
logic
and
then
ultimately
we
return
some
Dom,
but
what
we
will
eventually
end
up
with
likely
here
is
something
more
akin
to
this,
where
this
is
the
same
kind
of
component,
but
we've
taken
all
that
logic
and
put
it
into
us
as
Ellen
described
it
a
mix
in
abused
textfield.
We
pull
out
basically
props
I'm
from
this
function,
and
then
you
could
either
use
text
input
which
gives
you
an
element
or
if
you
really
wanted
to
customize
it,
you
could
just
use
the
hook
itself.
F
B
F
Any
rate
Zetland
demoed
the
majority
of
that
of
that
work,
which,
which
did
not
include
this,
this
particular
breakdown
of
components
into
into
hooks
everywhere,
so
we're
starting
slowly
or
soliciting
feedback.
We've
got
a
couple
more
features
lined
up
for
hooks,
but
this
isn't
going
to
be
a
total
refactor
overnight.
This
is
just
we're
slowly,
integrating
these
things
and
we're
looking
for
feedback.
So,
if
you're
interested
take
a
look
at
the
open
PR
about
about
search,
leave,
some
comments,
open
an
issue
and
and
we'll
move
forward
with
them.