►
From YouTube: A real world application using Vue.JS - Sello Mkantjwa
Description
In this session I will be talking about some of the core concepts of VueJs, including:
* Components
* Vue-router
* Vuex
* Events bus. The talk will be structured around how to use the above concepts to build a real world application, in this case a music streaming service - or at least the front-end of such a service.
This talk was recorded for the Jozi.JS meetup on 22 March 2018.
https://www.meetup.com/Jozi-JS/events/248463266/
Disclaimer: The opinions in this talk are those of the individual and do not necessarily represent those of this channel, the meetup group, or it’s sponsors.
A
Hi
everyone
like
she
said
my
name
is
Salam
Kendra
and
I
work
for
a
company
called
incentivize,
and
today
we're
going
to
be
looking
at
a
real-world
application
using
view
Jas
and
this
application
that
we're
going
to
be
looking
at.
Is
it's
a
music
streaming
application
that
I
wrote
about
a
few
months
ago
as
a
side
project
I'll
show
you
what
it
looks
like.
A
A
So
the
concept
that
we're
going
to
be
looking
at
are
components,
and
this
should
be
familiar
to
most
people
most
front-end
frameworks.
These
days
are
based
on
components,
so
your
angular
react.
So
if
you
used
any
of
those
frameworks,
you'll
recognize
components.
We're
also
going
to
talk
about
view
Ruta,
which
is
the
official
routing
and
the
library
for
for
view,
and
they
were
also
going
to
look
at
view
X,
which
is
your
data
store
or
your
central
state
management
right
components.
I
mean
there's
a
lot
going
on
on
this
screen.
A
You
look
at
the
screen,
sure
there's
a
lot
going
on
here,
but
you
can
probably
already
see
where
the
components
are
on
the
screen.
So,
for
example,
if
you
look
at
they
on
the
Left,
you
have
that
sidebar.
So
that's
a
component
right
there,
and
then
you
have
a
list
of
tracks
here,
each
of
which
is
a
component
on
its
own
and
then
any
takers.
For
where
the
other
components
are,
you
guys
see
any
that's
right,
so
the
little
player
at
the
bottom.
A
A
So
we
have
this
holistic
app
made
up
of
all
these
little
sub
components
and
the
reason
why
you
might
want
to
sort
of
structure
application
like
this
is
I
think
it
is
easier
to
work
on
or
to
sort
of
work
on
the
a
player
component
than
it
is
to
work
on
a
player
portion
of
a
whole
app
and
what
I
mean
by
that
is,
if
you're
working
on
the
component-
and
you
can
concentrate
solely
on
that
component
on
its
own.
So
you
can
drown
out
all
the
noise
of.
A
A
Gonna,
look
at
some
code
now
and
the
code
that
I
want
to
look
at
is
for
that
little
component
at
the
bottom,
that
little
player
down
there
and
the
reason
I
chose
this
component
is
because
there's
so
many
things
happening
in
they
will
be
able
to
cover
or
cover
a
lot
of
ground
will
be
able
to
talk
about
a
lot
of
things.
Just
by
looking
at
that
component,
okay,
cool
and
the
first
thing,
you'll
notice
with
view
components
is
everything
is
in
this
components.
Right
so
I
mean
you
have
your
template
there.
A
All
of
your
HTML
is
in
this
component,
alright,
and
then
you
also
have
you
sort
of
your
business
logic
right
there.
You
have
your
JavaScript
also
in
this
component
and
then,
if
you
go
down
a
little
bit
more,
you
also
have
your
Styles
defined
in
the
same
component,
and
that
might
look
a
bit
weird
for
some
people.
A
It
was
definitely
a
bit
weird
for
me
when
I
first
encountered
it,
but
as
you
build
more
and
more
components
using
this
style,
it
just
it
sort
of
makes
sense,
mainly
because
you
don't
have
to
keep
jumping
out
of
an
in-between
files.
So
you
don't
have
to
jump
into
your
JavaScript
files
and
then
your
CSS,
this
sort
of
it
becomes
natural
and
it
just
makes
sense.
And
if
we
look
at
that
our
template
day
at
the
top,
this
is
sort
of
the
structure
of
the
component
from
a
visual
point
of
view.
A
Perhaps,
for
these
little
custom
tags
yeah,
so
we
have
one
here
that
says
current
track:
that's
not
a
standard
HTML
tag.
This
player
controls
there
as
well,
there's
also
a
seat
body.
Does
anybody
know
what
those
are?
Those
are
components,
so
these
are
sub
components
that
are
used
as
sort
of
building
blocks
for
this
player
component.
Alright,
and
if
you
go
down
a
little
bit,
you
will
see
here
we
have
and
the
JavaScript
portion.
A
This
is
sort
of
the
meat
or
the
logic
of
this
component
and
the
way
you
would
define
or
declare
component
is,
you
would
export
simple
JSON
object
with
a
few
properties.
One
of
those
is
the
name
which
is
actually
optional.
So
when
you
define
your
component,
you
don't
have
to
give
it
a
name,
but
it's
usually
a
good
idea
to
give
it
a
name
so
that
when
you're
debugging,
you
can
see
straight
off
the
bat.
As
soon
as
you
see
that
message
you
can
see,
which
component
is
throwing
this?
It's
throwing
this.
A
It's
throwing
that
your
exception.
We
also
have
props
here,
as
anybody
heard
of
props
for
props.
So
if
it's
a
common
concept
in
most
of
these
frameworks,
react
for
example,
and
what
props
are
parameters
that
you
can
pass
in
from
the
parent
into
this
component
so
that
you
can
initialize
it
so,
for
example,
here
we
have
a
track
prop
so
which
means
that
this
component
is
not
responsible
for
going
out
and
getting
the
track
that
we're
supposed
to
be
playing
instead,
the
parent,
that's
sort
of
defining
this
component
well
pass
the
track
into
that
component.
A
Then
we
have
methods,
you
can
also
define
methods
on
your
component
and
these
methods
are
any
functions
that
you
want
to
expose
on
your
on
your
template.
So,
for
example,
here
we
have
a
double
loop
method
and
all
that
does
is
if
we
look
at
the
screen
and
we
take
a
look
at
these
buttons
yeah.
So
this
all
this
does
is
it?
Let
us
know,
are
we
in
looping
mode
or
are
we
not
in
looping
mode?
So
all
that
means
is
at
the
end
of
the
last
song.
A
A
And
there's
another
one
here:
another
method
that
we
expose
to
the
template:
any
methods
that
are
not
even
if
you
have
functions
in
your
component,
any
methods
that
are
not
part
of
that
methods.
Property
will
not
be
visible
on
you
on
your
template
and
then
you
can
also
specify
any
sub
components.
So
the
building
blocks,
if
you
have
any
components
that
form
the
building
blocks
of
this
particular
component,
you
can
list
them
there.
So
these
are
the
components
that
we
spoke
about
earlier.
So,
for
example,
here
you
have
your
current
track.
A
You
have
your
player
controls
and
you
have
your
seat
bar
these
components
are
the
ones
that
are
used
here.
One
thing
you
might
notice
is
it's
it's
kebap
case
there
pascal
case
here,
but
that's
fine
that
that
translation
is
done
automatically
for
you,
and
I
just
I
think
it
looks
a
lot
a
lot
cleaner
when
it's
when
it's
in
that
case
cool
and
then
also
you
can
define
what
accord
watches
on
your
state.
A
So
what
that
means
is,
if
a
particular,
a
particular
property
or
variable
on
your
state
changes,
you
can
be
notified
of
those
changes
and
then
react
according
to
those
changes.
So,
for
example,
here
we
have
we've
defined
the
watch
on
other
track,
which
is
remember.
This
is
a
prop
that's
coming
in
from
the
parent,
so
that
could
change
at
any
time.
So
we
want
to
know
when
that
changes.
Let
us
know
and
then
what
we
do
here
is
we
take
that
new
track
and
then
we
committed
to
our
central
store.
A
So
now
that
track
is
every
component.
That's
looking
for
the
current
track,
that's
playing
and
is
going
to
retrieve
this
track,
that
we've
just
committed
here,
cool
and
then
also
you
can
have
your
computer
properties,
which
I
think
the
easiest
way
to
understand.
This
is,
if
you
have
a
component,
for
example,
that
takes
in
two
props,
a
and
B
and
then
and
it
displays
the
sum
of
those.
So
a
and
B
would
be
your
props
and
then
you
can
have
a
computed
property
C,
which
is
the
sum
of
those
two,
those
two
props
cool.
A
So
these
are
some
of
the
basic
sort
of
properties
that
you
can
have
a
new
component
and
there's
a
lot
more
that
we're
not
going
to
go
into.
For
example,
there's
hooks
on
your
on
your
component,
I,
don't
know
if
you
guys
have
in
other
frameworks
if
those
are
yeah
exactly
so
during
the
lifecycle
of
your
component.
Certain
events
get
fired.
A
For
example,
had
we
decided
not
to
pass
in
a
prop
into
our
component
and
decided
to
go
and
fetch
that
track
ourselves
to
play,
then
we
might
say
once
this
component
is
created,
then
go
out
to
some
service
and
get
that
track
loaded,
and
then
we
can
play
it
cool
and
then
a
little
bit
below.
That
is
the
actual
styles
for
this
component
and
I.
Think
the
most
noteworthy
thing
here
to
note
or
to
mention
is
that
these
styles
defined
here
are
only
they
are
only
available
or
visible
to
this
component.
A
So
that's
really
good,
because
these,
if
you
have
any
sort
of
CSS
properties
or
CSS
classes,
defined
on
your
global
scope
or
sorry
on
your
global
styles.
These
are
not
going
to
interfere
with
that.
So
these
are
not
going
to
override
that.
This
is
not
particularly
a
view.
J/S
thing,
but
I
think
is
pretty
cool.
It
works
straight
off
the
out-of-the-box
like
that,
okay
cool,
so
those
that's
a
example
of
a
component.
Are
there
any
questions
so
far?
Yes,.
A
A
Yes,
you
can
so
yeah
yeah,
yes,
yes,
yes,
which
is
what
I
did,
incidentally,
when
I
started
out,
so
what
I
did
is
I
had
my
HTML
in
my
view,
file
and
then
you'd
have
your
JavaScript
in
a
separate
file.
So
I
mean
that
simple
in
my
case,
in
this
case,
I'm
using
webpack,
so
I
mean
I,
can
import
that
CSS.
Simply
so,
I
can
just
do
a
require
on
the
CSS
or
require
on
the
JavaScript.
A
A
A
Yes,
that's
fine,
so
what
you
can
do,
in
fact,
if
you
check
there,
there's
there's
a
few
imports
yeah,
so
you
can
import
your
Styles
into
this
component
as
I.
Did
there
cool
anymore,
all
right
cool?
So
that's
it
four
components.
The
next
thing
that
we're
going
to
look
at
is
if
I
can
just
check
my
yeah.
Yes,
the
next
thing
we're
gonna
look
at
is
the
view
Ruta,
and
this
is
going
to
be
a
really
short
section.
A
But
basically,
what
the
view
Ruta
is
it.
It
allows
you
to
define
what
happens
when
you
hit
a
particular
route.
So,
for
example,
if
we
land
on
the
home
page,
what
component
must
be
loaded
or
what
must
happen
as
soon
as
we
hit
that
route
and
view
has
you'll
find
that
view
has,
unlike
react,
I
don't
know,
but
when
I
started
working
with
react,
I
found
that
a
lot
of
the
other
things
you'd
have
to
go
out
and
found
on
your
own.
A
So
if
you
need
a
route
you
have
to
make
a
decision
about
which
one
do
I
use.
You
could
use
like
any
arbitrary
one
if
you
need
at
state
management,
you'd
go
out
and
pick
pick
any
one
that
you
want
there
weren't
any,
so
you
aren't
necessarily
forced
or
there
weren't
any
recommended
ones.
What
view
does
it?
It
has
official
plugins
or
libraries
that
they
recommend
that
you
use,
and
these
are
mostly
developed
by
the
core
team
as
well
cool.
A
If
we
take
a
look,
just
want
to
show
you
what
I
standed
ruta
will
look
like
it's
very
simple,
so
the
one
thing
about
a
root
is
that
it's
it's
an
extension
of
a
view.
So
it's
sort
of
like
a
plugin
that
you
have
to
install
and
you
do
that
by
using
view
dot
use,
root
app.
So
now,
once
you've
done
that,
then
you
can
use
that
in
any
of
your
components
as
well
and
the
way
to
define
a
root
which
is
basically
all
of
the
routes
that
are
available
on
your
app.
A
Sorry,
is
you,
you
initialize
a
new
route
app
and
you
give
it
an
array
of
all
of
the
routes
that
will
be
available
in
your
app.
So,
for
example,
here
we
have
the
home
routes
just
give
it
a
path.
So
when
we
hit
home,
this
is
the
component
that
will
be
loaded
and
you'll,
see
that
that
home
component
we
get
from
right
share.
So
we
import
that
component
and
then
once
we
hit
the
home
root,
that
is
loaded.
A
You
don't
really
need
to
give
it
a
name,
but
once
again
it's
recommended
because
it's
very
easy
for
debugging
and
also
sometimes
it's
much
easier
to
navigate
to
a
route
using
its
name
rather
than
than
the
actual
path
and
then
also
like
with
components.
You
can
hook
into
certain
events
that
happen
or
that
are
fired
when
you
change
from
one
route
to
another.
A
A
A
Say,
for
example,
on
the
upload
route
we
wanted
to
say
upload
and
then
a
specific
track,
but
that
track
is
like
an
ID.
We
give
it
an
ID
yeah
sure,
so
you
can
do
that
by
doing
that.
So
anytime,
you
go
to
slash
upload
that
last
slash
upload
and
then
slash
something
else.
That
last
piece
is
a
variable,
a
parameter
and
it
will
be
the
track
theorem
same
cool,
any
other
questions
on
sorry.
A
A
Ruta,
so
that
ruta
is
the
actual
route
that
you
are
right
and
so
all
of
those
the
query
string
and
the
path
everything
will
be
listed
on
that
on
that
object,
cool
any
other
questions
there
all
right.
So
the
final
thing
I
want
to
show
you
is
view
X.
This
is
the
the
central
store
or
the
your
central
state
management
system,
similar
to
react.
Vedic
so
actually
just
read
acts,
and
this
is
also
one
of
the
official
libraries
provided
by
view.
A
A
A
So
the
view
X
or
your
store
similar
to
the
Routan
is
a
plugin
that
you
have
to
specifically
or
explicitly
install
into
view
and
there
we
have
that
line.
That
says
view
dot,
use
view
X
and
similar
to
the
router
you
would
initiate,
or
you
would
initialize
a
new
store
with
JavaScript
object
and
give
it
a
few
properties.
The
first
one
is
the
state.
So
this
is
almost
always
on
your
on
your
store.
A
Sorry
and
what
the
state
is
is
basically
a
list
of
all
of
the
variables
that
are
in
your
state.
So,
for
example,
here
we
have
the
available
tracks
and
if
you
look
at
oh
now,
we
like
that
sorry
I'm,
just
like
in
real
quick,
and
so,
if
you
look
at
on
that
on
that
home
screen,
when
you
land
and
there's
a
whole
list
of
tracks
that
I
shown
there
that's
from
our
state,
so
these
tracks
they
are
controlled
by
that
available
tracks,
variable
similarly
the
active
tracks.
A
So
you
remember
we
we
committed
the
track,
that's
currently
playing
when
we,
when
we
load
it
onto
or
when
it
changes
on
our
player.
So
that
is
the
active
track
and
the
way
you
can
change
or
the
way
you
should
change
your
state
and
in
view
X,
is
through
the
use
of
mutations.
So
if
you
think
about
even
a
medium
medium
sized
app
write,
your
state
is
changing
all
over
the
place
and
in
variables
you
have
100
components.
For
example,
your
stage
is
all
over
the
place.
A
You
don't
know,
what's
changing
what
variables
at
what
time
so
what
view
X
does
is
it
gives
you
a
place
to
store
all
of
your
shared
state
for
your
application,
and
it
also
gives
you
a
consistent
way
to
update
that
state.
So
now,
if
anything
changes
it
has
to
go
through
this
alright,
so
you
can't
just
change.
You
have
no
access
to
the
actual
state.
You
have
to
go
through
one
of
these
mutations
to
change
your
state.
For
example.
Here
we
have
a
mutation
to
remove
I
track
from
the
available
tracks.
A
If
we
go
back
to
the
app
here,
there's
a
little
button
e.
If
you
click
on
that,
you
should
probably
have
like
a
little
thing
to
say:
are
you
sure
you
wanna
do
because
what
it
does
it
actually
removes
it
from
the
database?
All
reference
is
created.
It
removes
it
from
the
server
so
yeah
so,
but
when
you
click
on
that
eventually,
this
mutation
here
will
be
cold,
it
will
be
cold
and
then
all
it
does
is
it
looks
at
your
state.
A
So
all
mutations
get
access
to
that
state
property
and
all
it
does
is
eventually
it
finds
the
track
that
you're
trying
to
remove,
and
then
it
removes
it
from
your
state,
and
you
saw
that
once
I
click
that
button
it
was
removed
from
from
the
actual
view
as
well.
So
that's
because
everything
is
in
this
state
and
when
this
changes
everything
changes
or
updates
in
the
actual
app,
we
have
another
one
here
to
update
the
available
tracks,
which
is
slightly
different
from
the
first
one.
A
So
when
someone
logs
in
onto
the
app
we
have
to
show
them
all
of
the
apps
that
they
have
available
and
what
we
do
is
we
go
down
to
the
server
pull
down
all
their
tracks
and
then
we
persist
those
those
tracks
using
this
mutation,
all
right
cool,
so
mutations
are
one
way
just
one
way
to
to
mutate
or
to
change
your
state.
Another
way
is
actions
and
okay,
so
another
way
to
change
your
state
is
through
the
use
of
actions.
A
The
thing
with
mutations
is
that
they're,
very
simple:
all
you
get
is
a
state
parameter,
so
you
get
the
state
and
then
some
parameters
that
you
can
use
to
mutate
that
state
and
you
can't
do
or
you
shouldn't
do
any
asynchronous
operations
in
your
in
your
mutations.
I,
don't
know
what
happens
if
you
do,
but
it
is
very
much
recommended
as
you
don't.
A
Your
actions
are
very
much
different,
so
there's
slightly
more
powerful
than
your
mutations,
because
when
you
get
in
an
action
you
get
what's
called
a
context
which
is
basically
a
whole
store,
and
in
that
context
you
have
this
state.
You
have
access
to
other
actions.
You
have
access
to
mutation,
so
within
an
action
you
can
action
and
you
can
call
mutations.
You
can't
do
that
in
in
your
mutations,
because
all
you
get
is
the
state
all
right.
A
So
now,
when
I
say
to
you,
click
here
right
and
it
removes
the
track
from
the
view
it
removes
it
from
everywhere.
What
happens?
Is
we
actually
call
this
a
remove
track
action?
We
don't
directly
call
the
mutation.
This
action
will
eventually
call
the
remove
available
tracks
mutation,
and
the
reason
why
we
put
this
in
here
is
because
we
have
to
do
a
few
things.
A
There's
a
few
things
involved
in
removing
an
actual
track,
and
one
of
those
is
first,
you
remove
it
from
the
from
the
state
and
then
you
initialize,
the
tracks
that
are
left
or
the
tracks
that
are
available.
I
mean
your
state
has
changed
the
available
tracks
that
are
different.
Now,
alright,
so
you
yeah,
there's
a
few
things
happening
in
the
background
here
that
you
do
in
the
initialized
tracks.
So
it's
not
as
simple
as
when
you
the
play
order,
for
example,
of
the
tracks,
there's
a
few
things
that
are
happening.
A
Some
Adina's
happening
in
there
and
so
that
ugliness
is
hidden
away
in
another
action,
called
initialized
tracks,
so
yeah
actions
much
more
powerful
than
mutations.
You'd
generally
use
this
to
do
ad
asynchronous
actions
and
to
do
more
complex
operations
on
your
state.
If
you
want
to
get
access
to
any
of
your
state
variables
from
outside
the
store
itself,
you
need
to
define
those
variables
as
getters.
So,
for
example,
we
have
a
guitar,
therefore
available
tracks
and
all
you
get
in
a
guitar
is
a
function.
A
You
get
the
state
and
then
you
return
something
from
that
from
that
state.
So
these
tracks
yeah
for
this
component,
this
little
tracklist
component
to
get
those
available
tracks.
It
uses
that
guitar
to
retrieve
them
from
the
state
cool
and
then
so.
One
final
thing
with
Buicks
is:
if
you
can
imagine
a
complex
app
right
say
you
have
a
lot
of
components,
a
hundred
components.
Now
you
have
each
of
those
components
have
some
sort
of
variables
that
they
contribute
to
the
state
right.
A
Your
state
can
get
pretty
big
pretty
quickly,
but
there's
a
way
to
manage
that.
What
you
might
want
to
do
is
you
might
want
to
sort
of
chunk
it
into
sort
of
modules
that
make
sense.
So,
for
example,
here
we
have
a
module,
that
is,
that
deals
mostly
with
player
related
things.
So,
for
example,
if
we
go
in
here,
this
is
another
view
X
store,
but
this
is
sort
of
like
a
sub
module
for
our
main
store
for
the
app,
and
this
deals
with
things
that
are
mostly
related
with
the
app
so
the
current
track.
A
That's
playing
is
the
player
playing
the
play,
progress
percentage,
so
those
kind
of
things
that
are
they
might
be
required
by
some
other
components,
but
they
are
owned
by
the
player
store
all
right.
So
this
is
a
good
way
to
sort
of
keep
your
store
in
check
and
make
sure
that
it
doesn't
I
mean
it
doesn't
become
overwhelming
into
big
store.
A
A
Okay,
so
there's
one
for
your
upload
component
as
well.
We
also
do
a
lot
of
things
with
auth
in
the
background
there's
no
explicit
component
for
that,
but
we
have
like
a
separate
store
that
handles
all
of
you,
your
authentication,
related
queries
or
information.
So
is
this
user
authenticated?
What
is
they
user
ID?
All
of
that
kind
of
information
cool
and
that's
it
also
for
view
X,
and
that
is
that
actually
brings
me
to
the
end
of
my
talk
just
in
time
just
intense.
A
So
just
one
more
thing,
the
the
app
that
we
were
looking
at
is
you
can
find
it
at
didi
pal
comm.
You
can
so
you
can
go.
Take
a
look
at
it.
I'd
appreciate
your
feedback.
If
you
have
any
okay,
I'd
appreciate
your
feedback.
If
you
have
any
and
then
I'm
available
on
mail,
if
I
close
that,
oh
that's
interesting,
the
batteries
did
here
is
it
here,
but
it's
still
showing
me
okay
anyway,
so
yeah
so
available
on
mail.
My
email
is
GI.