►
From YouTube: FE Pairing - 20230308 - Working on init_vue_app helper
Description
In this session we discuss the kind of API we'd like for an `init_vue_app` helper.
00:00:00 - Discussion issue scope of initializing Vue apps
00:03:43 - Introducing what was recently introduced
00:08:00 - Discussing idea of removing JavaScript side of glue code
00:31:00 - Start working on the rails-side helper
00:44:00 - Discussion provide vs. props preference
01:01:00 - Looking into providing and propping everything
01:15:30 - Testing out the changes
B
So
I'll
get
Peter
to
explain
in
a
moment
so
I
I've
read
the
description
of
the
issue
as
creating
a
standardized
way
to
initialize,
View,
apps
and
I.
Didn't
I
didn't
do
the
right
thing
and
dive
down
into
the
detail.
I
made
a
very
bad
assumption,
because
I'd
seen
that
I
believe
incubation
engineering
had
done
something
recently
where
they
tried
to
do
something
similar
or
some
kind
of
standardizing
simplifying.
B
When
I
looked
at
the
solution
that
they
put
in
place.
What
I
asked
and
questioned
and
hoped
is
that
we
would
literally
have
a
ham
or
helper
a
ruby
helper
that
we
could
call
in
in
a
hammock
and
that
would
kind
of
create
the
placeholder
the
div
create
the
JavaScript
to,
if
bootstrap's
the
right
term
to
then
bootstrap
and
inject
The
View
app
into
that.
Do
you
know
to
do
all
of
that?
B
C
Yeah
I
mean
so
maybe
I
can
just
give
some
context
on
why
I
created
the
issue
and
the
main
reason
is:
it's
just
been
like
a
pretty
big
pain
point
for
me
me
and
I
assume.
A
lot
of
other
Engineers
is
like
you
come
to
a
page.
You
need
to
debug
something
you
realize
it's
a
View
application.
You
find
the
div
you
find
where
the
and
it's
passing
some
data
to
the
back
end
or
to
from
Ruby
to
view.
C
So
you
find
the
helper
and
you
find
the
data
that
is
passing
and
then
you
figure
out.
Is
it
encoding
it
as
Json
or
is
it
doing
it
as
a
bunch
of
different
data
attributes
and
then
you
go
to
the
and
then
you
have
to
find
the
Javascript
file
and
you
have
to
figure
out
how
it's
parsing
it
and
how
it's
passing
it
to
view?
Is
it
passing
it
as
props
or
provide
and
then
yeah?
So
it's
just
like
a
bunch
of
different
things
and
then
you
could
go
to
a
different
view.
C
B
C
B
C
I
mean
that
was
my
initial
idea,
but
yeah
this.
So
the
proposal
that
I
put
in
here,
one
I,
haven't
tested
any
code
like
actually,
if
it
works,
it
was
just
I,
just
wrote
it
in
the
issue,
so
yeah
take
that
with
a
grain
of
salt
and
then
yeah,
it
was
just
my
first
idea
of
how
it
might
work
definitely
open
to
suggestions.
If
there's,
if
someone
had
an
idea
of
like
a
cleaner
way
to
do
what.
A
I'm
gonna
start
sharing
a
screen,
so
we're
kind
of
looking
at
the
same
thing:
yeah
yeah.
So
this
is
the
issue.
This
is
awesome
idea
and
I
really
like
this
part
about
creating
the
rails
helper,
because
doing
this
to
Json
thing
is
so
much
better
than
the
individual
data
parsing
the
whole
need
for
parse
Boolean
is
so
strange.
C
D
A
Eduardo
from
the
incubation
engineering
he's
he's
started
this
Mr
spinning
up
one
just
for
some
of
these
incubation
apps
wait.
Sorry
I
was
like
this
is
so
helpful
beyond
that,
like
we
need
to
make
this
just
a
general
helper,
so
we
whatever
we
build,
we
wanna
this
has
already
merged
in
this
init
Simple
app.
It
has
some
docs
around
it
too.
So.
B
A
B
A
B
E
A
So,
rather
than
creating
a
mapper
of
different
properties
to
all
that,
we
would
provide,
we
opted
to
just
have
a
standard
view
model
attribute
that
then
spreads
into
all
the
properties
that
we
would
receive
from
the
component.
So
this
takes
view
model
and
then
just
puts
it
right
into
all
the
different
properties.
A
So,
like
this
line
of
code,
this
is
so
sweet.
How
small
this
is
absolutely
so
I
think
would
be
really.
Cool,
then,
is
if
we
can
standardize
this
thing
yeah
and
even
have
like
some
named
argument:
safety
kind
of
thing
so
that
someone
doesn't
accidentally
create
something,
that's
not
a
view
model
or
whatever
here,
whatever
so
I
think
this
is
a
great
idea
and
you're,
not
the
only
person.
Thinking
about
this.
It's
such
a
good
idea,
like
I,
think
this
is
going
to
be.
A
A
B
B
A
We
would
need
webpack
to
like
here's,
how
I
think
you
could
feasibly
do
it.
We
would
need
webpack
to
read
haml,
which
it
doesn't
right
now
so
like
all
of
that
would
be
somehow
we
need
to
read
Hamill
and
use
that
to
figure
out
what
the
chunks
it
needs
to
create
are
yeah,
but
it's
it's
not
doing
that
right
now
and
be
really
interesting,
be
really
interested.
So.
B
B
A
You
know
I,
think
I,
think
I
know
what
you
mean,
but
like
so
the
other
situation
is
like
in
a
single
page.
We
have
maybe
10
View
apps
yeah.
So
how
do
we
map
one
con?
One
element
to
one
component
and
that's
the
that's
the
challenge
where
we
usually
generate
or
generate
come
up
with
unique
IDs
is
so
that
we
know
this
component
is
supposed
to
go
with
this
slot.
You
know
what
I
mean.
B
B
A
B
A
That's
that's
the
bit
that
why
we
don't
have
is
the
hammer
and
that'll
be
really
interesting,
but
like
right
now.
What
we
would
need
to
do,
then,
is
like
almost
pass
in
the
import
URL
to
the
component.
For
that
view
app
which
would
be
cool,
but
we
don't
have
any
like
compile
time
assertion
that
yeah
yeah.
B
A
B
A
B
A
E
I
think
my
gut
feeling
is
that
it
may
be
possible
with
a
combination
of
of
conventions
LinkedIn
and
things
like
that.
It
doesn't
seem
that
impossible.
The
idea
I
mean
what
Peter
and
Eduardo
suggested
is
also
a
great
step
forward
into
a
a
very
doable
and
very
simple
and
I
have
been
thinking
about
that
as
well,
because
it's
we
repeat
over
and
over
and
over
the
same
things,
and
it
is
something
that
we
should
pursue,
but
what
Lee
was
also
suggesting
is
also
I.
B
Is
it
I
guess
somebody's
saying
the
the
repetition
of
the
the
in
the
index.js,
the
the
repetition
of
the
the
bootstrapping
of
importing
the
component
and
put
it
tracking
that
and
massively
simplified
it?
And
that's
amazing
and
I'm
yeah,
maybe
taking
the
next
few
steps?
But
we
still
have
to
create
a
bunch
of
index.js's
which
don't
they
literally
just
call
this
method?
And
you
know
it
seems
like.
F
I
have
a
couple
questions:
can
we
make
a
rails
generator
for
these
index.js's,
like
that's
a
that's
a
possible
option?
So
let's
it's
really
easy
to
spit
one
out
and
then
it
lets
users
still
customize
it
if
they
have
to
and
then
another
thought
is
when
you
do
like
us
like
a
dynamic
webpack
import,
does
it
have
to
be
a
string
or
can
we
like
shove
things
in
a
variable
and
then
use?
Can
we
like
pass
the
import
path
in
through
gone
somehow
and
then
have
gone
like
I'm
Gatorade
over
I'm.
A
A
F
A
Mean
I
think
it's
really
possible
I,
wouldn't
totally
I
think
we
could
solve
this
from
the
webpack
site,
webpack
reading
Hamel
looking
for
these
calls
and
the
webpack
can
actually
generate
these
page
bundles.
It
already
is
doing
generating
page
bundles
by
looking
for
these
index.js's.
Instead
of
looking
at
these
index.js
and
Pages
the
Pages
directory,
we
can
just
look
for
top
level
Hammel
views.
F
F
C
B
F
Let's,
maybe,
let's
make
a
rails
helper
that
like
pushes
it
creates,
creates
the
the
ID
div
whatever,
but
then
like
pushes
that
ID
through
on
in
some
sort
of
labeled
way,
so
that
they're
mapped
together
and
then,
when
you
like,
and
then
your
your
Mount
script
doesn't
reference
some
raw
string.
It
just
references
like
gone
Dot,
ID,
OT,
ID,.
F
A
B
I'd,
so
the
only
I
I
think
you'll,
probably
Dabble
full
stack
there.
Anything
I'd
say
about
generators
is
so
we've
got
like
there's,
there's
a
rails
generator
for
generating
migrations
and
90
of
the
time
you
use
it,
and
then
you
end
up
throwing
away
most
of
what
it
generates.
Just
copy
pasting
from
previous
migrations,
anyway,
I
I
kind
of
wonder.
F
F
A
F
The
other
option
is
we
be
really
strict
about
the
generator
and
like
compile
them
like
we
do
our
like
fixtures,
where
I
mean
that's
like
a
mess
of
our
spec
right,
but
you
know
like
where
you
can't
edit
the
generated
files
they're.
Just
like
we
have
a
big
comment
at
the
top.
That's
like
this
is
machine
generated,
Don't,
Touch,
This,
put
it
somewhere
else
and
then,
but
then
you
have
to
like.
We.
F
F
D
F
D
F
F
F
A
Also
related
to
it
as
well:
yeah
Marco,
I'm
I'm,
reading
Marcos
common
in
Zoom
to
inject
the
index
could
be.
We
require
components
that
can
be
mounted
export
and
Mild
file
into
the
helper.
We
only
provide
the
ID
class
with
the
container
and
the
name
of
the
component
amount
on
it.
The
helper
would
inject
the
right
mounting.
Yeah
I,
think
I.
E
C
A
Yeah
I
think
I
think
it's
interesting
how
possible
this
feels,
but
I
think
at
the
end
of
the
day,
it
is
like
okay,
it
might
be
not
profitable
to
pursue
this
because
of
how
complicated
the
approach
would
be
to
implement
getting
webpack
and
all
of
and
rails
to
to
work
in
sync,
where
there's
just
a
single
source
of
Truth.
Here,
it's
probably
not
as
iterative
as
keeping
them
separate.
Maybe
we
can
like
add
some
linting
to
just
Ensure
they're
set
up
correctly.
F
A
F
C
F
D
C
D
C
A
That'd
be
interesting,
yeah
well,
I,
think
I.
Think
for
the
for
the
immediate
term.
I
think
that
the
existing
init
Simple
app
was
really
good
abstraction
to
be
building
on
top
of,
because
it
is
implementation
is
simple:
it's
just
here's
some
standard
we
can
adhere
to
I,
don't
know
if
there's
anything
we
want
to
improve
with
the
with
the
API
between
the
two
but
I
do
think
having
a
rails
helper.
That
just
is
symmetrical
with
the
JavaScript
helper
of
the
init
Simple
app
I.
B
A
B
D
D
E
A
I
think
if
it
can
I
think
if
it
can
mirror
what's
happening
on
the
front
end
that'll
just
really
heighten
the
what's.
The
word
I'm
thinking
of
that'll
really
heighten
what
the
intention
is
between
how
the
Hamel
and
front
I
need
to
use
this.
Does
anyone
want
to
maybe
drive
to
just
create
this
little
rails
helper?
Maybe
for
that
one
app
that
was
touched
by
Eduardo
in
that
Mr.
C
A
B
A
B
B
Bit
of
that
that
the
button
that
we
were
looking
at,
we
were
treating
it
quite
simply,
but
the
button
can
appear
like
when
you're
on
different
branches.
It
can
appear
when
you're
inside
of
a
merge
request
and
there's
there's
all
sorts
of
crazy
logic
in
there.
So
I'm
still
beavering
away
at
it.
But
it's
unfortunately
not
as
simple
as
we
hoped.
A
D
E
C
A
C
C
C
Don't
know,
maybe
just
let's
just
try
creating,
because
then
it'll
kind
of
give
us
an
idea
of
like
whatever
what
you
have
to
do
to
create
a
new
app
and
like
how
annoying
it
is
or
unannoying
so
yeah.
Let's
so,
let's
try
creating
the
helper
first,
which,
as
far
as
my
understanding
of
rails
helpers,
you
can
put
them
anywhere
and
they're
all
available
in
Hamel,
I.
Think
like
as
long
as
they're
in
the
helpers
directory
yeah.
E
E
A
D
A
C
B
C
B
D
A
A
A
D
B
It's
a
bit
more
standard
like
in
back-end
world,
like
when
you're,
when
you're
doing
that
things
you
tend
to
to
quite
often
you
pass
in,
like
let's
say
it's
service,
that's
doing
something
like
with
an
issue
service.
You
probably
knew
it
up
by
passing
it
a
project
and
then
maybe
the
current
user,
but
then
the
third
parameter
does
tend
to
be
a
haction
object.
E
C
A
B
B
Yeah,
so
if
you
look
I'll,
send
you
a
link,
a
base
container
service,
like
everything,
is
supposed
to
extend
about
all
services,
at
least
they're
supposed
to
extend
our
base
container
service,
and
it's
pretty
standard
pattern
that
we
we
pass
in
a
container
a
user
and
then
Brands
and
with
pretty
much
every
other
Ruby
thing.
That's
the
sort
of
pattern
that
I've
tend
to
see
that
you've
got
a
couple
of
standard
parameters,
but
then,
and
everything
else
is
just
passed
as
kind
of
an
object
or
a
hash.
At
the
end,.
A
E
B
B
F
C
A
C
B
A
A
A
A
C
C
I,
don't
know
yeah
I,
don't
know
I,
guess
I
kind
of
lean
towards
the
provided
one,
because
it's
not
reactive
by
default
and
two
because
then
it's
just
like
you
have
access
to
all
these
variables
everywhere
without
having
to
do
this
in
the
again
or
whatever,
like
a
lot
of
the
time.
It'll
be
it'll,
be
like
a
path
it'll
be
like
I
need
this
path
from
rails,
but
I
needed
like
three
components
down
or
whatever.
F
B
C
A
I
I
do
like
the
let's
lean
towards
a
convention
like,
let's
standardize.
The
goal
is
to
standardize
some
of
this.
So
I
like
let's
find
what
our
preference
is.
I
I
have
a
preference
to,
let's
be
really
explicit
about
what
we
provide
and
because
the
consumers
of
this
thing,
if
they
can
consume
by
prop
I,
think
that's
a
safer
preference
because
provide
is,
is
you
know
some
global
namespace
and
it's
just
helpful
for
some
props.
A
F
A
So
what
do
you?
What
do
we
think
of
this?
Then
we
accept
ID,
accept
the
component
and
then
set
accept
a
hash
of
options
and
one
of
the
options
is
I,
don't
know,
provide
keys
or
something
like
that,
and
that
is
just
what
we'll
pick
we'll
pick,
those
from
The
View
model
and
we'll
admit
them
so,
rather
than
having
a
mapping
function
like
this,
can
we
just
accept
an
array
of
keys
to
provide
versus.
F
B
A
D
B
F
F
F
B
C
F
Wanna,
if
you
want
to
explicitly
set
your
props
and
explicitly
set
your
provides,
you
should
be
able
to
do
both
you
shouldn't,
because
because
then
you
can
you
can
it
might
be
easier
for
it.
It
would
be
much
easier
for
me
personally
to
be
able
to
see
like
these
are
the
keys
that
are
available
for
both
and
and
not
necessarily
have
to
go.
Ruby
mining
for
my
Mount
functions.
C
C
A
B
B
A
B
B
B
B
I
was
thinking
that
we
were
passing
in
all
of
the
The
View
model
and
then
that
we
were,
we
were
re-specifying
which
of
those
bits
were
provided,
but
we're
not
we're
just
specifying
the
provided
ones.
They
were
all
grabbed
from
the
data
and
they're
all
assumed
that
they
all
need
to
be
passed
to
the
The
View
app.
E
B
C
So
Andrew's
previous
point
about
not
having
to
switch
context
back
to
the
Ruby
files,
Go
Ruby
mining,
to
figure
out
what
data
is
available
like
say
we
just
in
this
example.
We
just
provide
Foo,
then
they're
still
I,
guess
I,
guess
we're
defining
the
baz
prop
in
here,
but
we're
not
explicitly
saying
that
baz
is
getting
passed
as
a
prop.
We'd
have
to
go
back
to
here
to
see
that
it
is
back
to
the
Hamlet
or
whatever.
C
So
if
we're
explicitly
saying
like
this
is
the
provide-
and
this
is
the
props-
then
to
me
it's
easier
to
unders
like
come
into
it
and
be
like
this.
Is
the
data
I
have
available,
which
is
kind
of
one
of
the
one
of
my
goals
is
to
be
able
to
like
come
to
the
JavaScript
and
be
like
this?
Is
the
data
I
have.
D
B
A
C
A
A
Part
of
me
is
just
thinking,
let's
just
do
it
in
both
like
no
matter
what
we
could
totally
get
away
with
that,
because
if
we
pass
extra
props
here,
those
just
get
ignored
right
in
view
land,
so
I
only
need
to
the
root
component
only
needs
to
declare
what
props
is
actually
really
interested
in,
and
everything
else
really
can
be.
A
provided
and
Jack
I'm.
Fine.
If
we
just
want
to
do
both.
B
F
B
A
B
B
C
A
C
A
A
A
We
don't
declare
these
Keys
multiple
times,
because
the
keys
will
change
and
my
biggest
concern
is
like
okay,
it
looks
like
it
should
be
available,
but
actually
the
underlying
helper
key
changed,
and
so
this
isn't.
This
isn't
what
you
think
it
is
so
I
really
like
having
the
helpers,
the
single
source
of
Truth,
for
what
is
available.
C
F
C
C
Coming
from
the
back
Ruby,
so
it's
never
going
to
change
like
you
can't
mutate
props,
so
it
it
theoretically.
It
doesn't
need
to
be
reactive,
like
if
you're
passing
an
object
from
Ruby
right,
don't
want
view
making
it
reactive,
because
it's
unnecessary
right
so
yeah
we
should
I
guess
Simon
was
saying
you
can
use,
object,
dot,
freeze
or
shallow
ref
to
make
props
non-reactive.
A
C
C
A
Or
even
running
like
dot
sort,
an
array.sort
will
mutate
the
underlying
array,
and
this
can
cause
view
app
issues
when
children
mutate
things
that
are
owned
by
the
parent
okay,
which
is
why
we
have
the
whole
event.
You
know
component
Flow
State
stuff,
but
when
you
do
object,
freeze,
that's
native
JavaScript
way
of
saying
this
object
is
frozen.
You
can't
write
to
this.
You
can't
even
try
to
add
fancy
properties
to
it.
This
is
a
frozen
object
and.
F
B
A
F
A
A
D
A
F
A
D
A
D
A
A
F
F
B
E
A
Was
the
most
painful
stuff
I
remember
with
the
karma
tests,
because
karma
never
cleaned
up,
it'd,
never
clean
up
after
itself.
In
between
tests
we
had
so
many
ux
stores.
We
had
so
many
Vue
X
stores
that
were
Singletons.
So
what
this
meant
is
all
of
the
component
tests
touching
these
ux
stores
inherited
the
state
from
previous
test
runs,
and
it
would
just
always
run
into
each
other
and
create
gnarly
situations.