►
From YouTube: Magento PWA Studio Community Meeting Sept. 13, 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
D
Alright,
happy
Friday
everybody
and
welcome
back.
We
skipped
last
week.
Obviously
so
this
week
we
have
a
few
updates
coming
from
the
work
over
the
last
couple
weeks,
including
some
Doc's
review
by
Mr
taco
pink,
we
have
Jimmy
who's,
gonna,
join
and
talk
about
all
the
work
that's
been
going
on
with
Peregrine
and
and
the
new
kind
of
capabilities
of
Peregrine.
We'll
talk
a
little
bit
about
what's
coming
with
the
4.0
release
and
then
we'll
kind
of
wrap
or
open
up
to
anybody
else.
D
A
Right,
you
guys
see
my
screen,
so
yeah
talk
updates.
We
have
a
couple
of
topics
that
address
this
issue,
that
community
member
created
back
in
architecture.
Caching,
basically
it's
an
overview
of
storefront
architecture
based
on
an
outline
gains
queenan's
you
can
get
to
that
in
the
overview
section
and
it'll.
Be
these
three
topics
really
a
storefront
architecture.
A
A
C
I
mean
I
expect
that
the
folks
on
this
call
who've
been
looking
for
a
little
bit
more
clarity
about
how
we
expect
a
deployed
store
to
work
and
how
we
expect
the
store
to
deploy
will
be
interested
in
reading
this,
but
it's
probably
in
a
you
know.
We're
gonna
need
some
time
to
read
this
before
we
get
feedback
right.
Yes,
let
me
tell
you
I
having
had
reading
this
already,
it's
good
thanks.
It's
really
good
and
it
should
clarify,
but
you
know
please,
please,
please
I
think
the
best
thing
to
do
well.
C
C
G
F
That
was
our
vision
for
this
separation
between
Peregrine
and
Vania,
but
that,
obviously
that's
not
what
Peregrine
has
been
Peregrine's,
mostly
up
until
now,
just
been
a
library
of
utility
functions.
You
know
in
like
reusable
tools
and
stuff,
so
we
had
a
lot
of
work
to
do
in
order
to
get
closer
to
that
vision.
So
the
last
few
weeks,
Stephen
and
I
have
been
part
of
work
actually
implementing
this
stuff.
F
It
doesn't
make
sense
for
Peregrine
to
depend
on
app
state
from
Vania
when
many
of
the
imports
and
depends
on
Peregrine
for
all
the
work
so
app
state
and
most
of
the
interactions
with
this
should
happen
in
Peregrine.
So
we
had
to
move
a
lot
of
stuff,
so
I
broke
that
work
down
here
into
six
tasks
that,
from
the
first
place,
we
would
look
at
whether
we
needed
to
keep
Redux
or
not.
We
ended
up
deciding
to
keep
it.
F
F
F
You
know
this
is
this
is
not
so
much
an
overhaul
of
Dakota's
just
moving
things
around,
which
is
ideal,
so
basically
what
we've
done
so
far
as
we've
done
these
first
four
steps
we're
working
on
this
fifth,
one
now
and
in
the
next
couple
of
weeks,
we'll
work
on
the
last
step
and
so
pretty
quickly.
Here
we're
going
to
have
merged
into
develop
Paragon
for
real,
and
this
is
basically
going
to
look
pretty
familiar
if
you've
seen
the
work
we've
done
with
context
before.
F
Connecting
them
to
the
store,
so
the
provider
gets
them
as
props
and
then
coerce
them
into
our
familiar
array,
format,
which
is
state
followed
by
an
API
object
that
has
all
the
actions
on
it
and
then
we're
passing
this
context,
value
to
the
provider
which
will
make
this
context
value
available
to
any
component
in
the
tree
and
the
whole
app
to
consume.
So,
just
by
calling
this
use
user
context
function
from
within
any
component,
you
can
get
access
to
user
state
and
user
API.
F
We
have
one
of
these
for
each
of
the
slices
of
state
and
in
this
way,
if
we
ever
decide
to
make
changes
to
the
Redux
layer
of
our
system,
that
will
happen
inside
Peregrine's
invisibly
to
every
component.
That
consumes
it.
So
that
way,
if
we
have
further
changes
to
the
structure,
all
the
apps
that
people
are
building
on
top
of
this
won't
have
to
change.
C
Have
some
questions
some
which
I
know
the
answer
to,
but
I
just
want
to
get
somewhere.
You
know
I'm
sure,
so,
first
of
all,
since
we're
keeping
redux
but
you're,
adding
this
alternative
way
of
getting
door
state
from
the
context
API,
instead
of
through
just
react,
Redux
map
state
to
props
bindings
the
connect
function.
F
F
You
won't
have
to
make
a
container
component,
but
since
Peregrine's
just
has
pure
dependencies,
an
app
like
Benyus
should
have
access
to
the
connect
function
and
they'll
have
access
to
the
store
through
context,
so
you
can
still
connect
if
you
have
an
advanced
use
case
where
you
want
to
like
map
this
patch
thing
you
have,
it
do
a
custom
function
just
for
your
component,
so
you
know
the
doors
still
open
there,
but
yeah
recommend
context.
So.
B
H
C
F
So
this
is
that's
actually
a
good
question,
so,
while
we've
been
working
on
this
I've
been
trying
to
avoid
spending
too
much
time
during
the
development
on
enforcing
a
particularly
structure
there,
but
as
we're
getting
ready
to
merge
these,
you
know
in
to
develop
and
start
using
them.
We're
gonna
have
to
pick
a
pattern
like
that
that
we
want
to
recommend.
So
that's
something
that
I
hope
will
get
feedback
on
in
these
PRS
and
be
able
to
actually
document
a
recommended
structure.
C
Last
thing
is:
do
you
think
store
slices
are
a
thing
now
like
do
you
think
they're
a
public
API
when
you
start
to
describe
as
like?
Well,
that's
combination
of
actions
and
reducers
and
context
that
we
expose
them
like
here
is
is
to
be
document
for
slice
instead
of
just
kind
of
referring
to
it
as
a
redux
concept.
I
think.
F
So
I
think
that
actually
makes
sense.
You
know
one
of
the
major
motivators
for
doing
this
in
the
first
place
is
that
it's
hard
to
extend
a
Redux
tour.
You
know
if
you
wanted
to
add
your
own
state
to
it,
because
it's
kind
of
like
all
private
and
and
there's
really
no
way
to
extend
it.
You
should
have
to
go
straight,
modify
it.
F
So
if
you
had
a
new
slice
of
state
you
wanted
to,
have
you
don't
even
have
to
touch
the
store?
You
just
add
a
new
context
provider
in
your
app
and
follow
the
same
pattern
that
we
used
for
creating
it
so
gotcha
you
say
yeah
we
need
to.
We
need
to
make
the
concept
more
clear
that
it's
like
you're,
interacting
with
slices
and
not
just
the
store.
G
F
C
And
the
hook
functions
is
the
same
type
of
loose
coupling
that
having
a
container
that
are
presentational
component
used
to
do
with
the
great
advantage
that
now
you
don't
always
basically
need
to
pass
both
of
those
around
together
for
it
to
be
useful.
Now
you
really
do
have
the
ability
to
replace
a
hook,
because
the
presentational
component
is
calling
the
hook
from
inside
itself,
which
is
which
is
a
nice
upgrade
to
modularity.
F
Right
when
you
connect
to
the
store,
you
know,
obviously
the
Store
updates
when
any
slice
on
any
part
of
the
story,
changes,
Redux
issues
update
and
then
so.
The
connect
function
has
to
slice
up
the
whole
store
and
like
decide
whether
a
relevant
update
has
happened
and
then
notice,
you
know
and
then
sort
of
for
surrender
of
the
component.
F
D
In
the
chat,
but
maybe
just
a
one
last
chance
here,
obviously
it
goes
without
saying
that
more
information
will
be
coming
right.
Documentation
will
be
following
you
know,
so
I
think
this
is
an
early
sneak
peek
at
all.
The
work
that
Jimmy
at
Stephen
and
the
rest
of
the
team
have
been
putting
into
Peregrine's,
but
you
know
we'll
definitely
have
more
opportunities
to
get
some
feedback
from
the
broader
audience,
but
we've
one
last
opportunity
here
on
the
call
for
anyone
has
any
commentary
or
feedback
or
questions.
C
Very
much
like
the
documentation
I
understand
that
this
thing
call
people
haven't
had
much
of
a
chance
to
digest
this
and
react
to
it.
We're
gonna
have
another
sink.
Next
Friday
I
am
flying
to
Munich,
but
I
would
hope
that,
if,
if
y'all,
if
anyone
on
this
call
has
taken
a
look
at
the
documentation
or
mr.
Cal
Cubans
summation
of
the
run
tinybuild
time
architectures
or
for
Jimmy
and
Stephens
huge
body
of
work
about
Paragon,
that
you
record
those
questions
and
bring
them
to
the
next
community.
D
Call
up
so
quickly,
I
will
share
my
screen
and
pull
up
the
jimothy
issue
and
PR
for
the
4.0
release
notes.
So
assuming
everyone
can
see
my
screen,
so
the
issue
number
16
47,
but
it
obviously
links
to
the
PR
which
is
1676,
I,
would
say,
I'm
not
going
to
go
through
all
of
the
details
in
here.
But
if
you're
interested
in
what's
coming
out
in
the
upcoming
release,
you
can
see
that
the
team
has
done
a
ton
of
work
in
here
for
not
only
quality
work
with
bug
fixes
and
refactor
work.
D
D
So,
if
you're
interested
in
what's
coming
out
and
getting
an
early
preview
of-
and
you
have
questions
about,
it
feel
free
to
come
out,
go
to
the
issue,
go
to
the
PR,
which
is
again
1676
and
check
out.
What's
going
on
there
and
ask
us
any
questions
either
in
the
slack
channel
or
on
the
issue
or
PR
itself,
anything
else
to
add
their
team.
D
D
G
D
So
that
was
it
on
our
side
again,
I
think
open
up
to
the
broader
audience
here
on
the
call
there's
anything
anyone
has
specific
questions
about
as
you've
been
working
with
PwC
PWS
to
do
questions
about
the
direction
we're
headed
or
you
know
if
anybody
on
the
call
Jordan,
Artyom
or
anyone
wants
to
take
the
opportunity
to
show
off
anything
you've
been
working
on.
This
is
a
great
chance
to
do
that.
I.
C
C
For
you
to,
if
you'd
like
to,
because
the
scaffolding
PR
is
so
significant
and
because
it
actually
has
implications
for
the
use
of
say
fallback
studio,
it's
an
alternative.
I
think
do
that,
although
fallback
studio
is
the
more
familiar
paradigm.
For
extension,
the
scaffolding
to
us
is
more
sustainable
for
building
a
project
that
consumed
the
other
stuff
as
dependencies
rather
than
as
as
overrides
I
would
love
it.
C
If
you
take
a
look
at
that
and
offer
some
feedback,
the
core
team,
typically,
we
review
each
other's
PRS
and
we've
had
some
impact
from
community,
but
you
know
I
want
you
to
feel
free
to
just
jump
into
our
conversations
and
interruptus
so
be
great
at
everything.
Yeah.