►
From YouTube: Frontend Architecture at GitLab
Description
Filipa Lacerda and Phil Hughes present the frontend architecture at GitLab
A
A
While
some
view
codes
is
flex
and
other
areas
do
X
and
the
reason
why
we
documented
the
patterns
that
we
have
documented
so
about
I
think
it
was
over
two
and
a
half
years
ago,
everything
used
to
be
in
rails
and
CoffeeScript,
which
is
gray
normal
for
rails
code
base.
That
was
created
like
three
three
years
ago
and
then
it
was
very
very
hard
to
hire
people
that
knew
CoffeeScript
or
were
willing
to
work
with
CoffeeScript.
A
A
So,
on
top
of
that,
we
we
added
web
pack.
We
added
barbell
to
allow
us
to
do
Atma
script
6,
but
because
we
didn't
ever
stopped
writing
new
code
for
deliverables.
So
basically
we
added
web
pack,
but
our
code
was
all
still
on
the
on
the
window
object.
So
we
didn't
use
code
split
by
the
way
and
then,
on
top
of
that,
we
added
the
linters.
We
added
an
slings
and
when
we
did
that
every
single
file
would
have
all
the
rules
disables.
Because
then
again
we
didn't
stop
writing
new
code
for
shipping
deliverables.
A
It
was
something
that
we
did
step
by
step
file
by
file,
mostly
on
our
free
time.
So
at
that
time
we
also
moved
from
NPM
to
yarn
and
then
on
top
of
that,
because
it
was
very
very
hard
to
do
things
like
the
issue
boards
or
having
code
in
real
time,
which
you
query,
we
decided
to
add
you
and
at
the
time
that
we
decided
to
add
view
our
plan
in
the
beginning
was
not
webview
everywhere,
which
in
retrospect
it
doesn't
sound,
very
smart.
A
A
So
when
we
started
that,
in
view
after
like
three
or
four
features,
we
would
have
I
think
we
had
like
three
or
four
different
architectures
for
our
view
codes.
So
at
the
time
we
documented
this
pattern,
which
is
basically
a
flux
like
pattern
where
the
main
components
access
the
surface
and
the
services
is
basically
what
we
know
today
as
actions.
It's
a
class
that
will
make
host
the
API
and
then
the
main
component
would
tell
the
store
to
store
the
data.
A
So
this
is
basically
what
our
architecture
used
to
look
like.
We
would
have
an
mo
file
because
of
the
routing
which
is
still
dead
by
Rails,
the
endpoints
and
things
that
we
only
have.
Access
in
Grails
would
be
provided
through
the
data
attributes
to
the
JavaScript
in
our
panel
file,
and
then
we
would
mount
the
main
components
and
the
main
component
would
talk
to
the
service
and
ask
for
data
and
then
tell
the
store
to
store
the
data
and
then
the
small
components
or
the
child
components.
A
What
we
know
is
them
would
not
know
about
the
store
order
service.
Just
a
there
goes
down
and
events
go
up,
which
is
basically
what's
what
is
documented
in
the
official
view
documentation,
but
we
didn't
had
time
to
refactor
everything.
So
this
is
the
the
comics
page,
sorry,
the
PowerPoint
speech,
and
if
you
inspect-
and
you
will
see
this
in
several
different
pages-
you
will
have
more
than
new
ten
one
view
application
mounted.
So
in
this
specific
case,
we
didn't
have
time
to
move
everything
to
an
end
points,
and
we
also.
A
Sometimes
we
also
didn't
find
that
it
would
be
that
useful
for
the
user
to
have
everything
so
I
wouldn't
make
sense
to
have
one
or
two
developers
who
are
factoring
everything.
So
in
this
case,
for
example,
in
this
pipeline
page,
we
have
two
view
applications.
Now
we
have
more.
We
have
the
security
reports
and
in
this
specific
case,
these
two
view
applications
aren't
sharing,
sharing
the
same
data
and
the
same
endpoints,
and
it
would
be
very
costly
to
maintain
the
the
architecture.
A
I
just
showed
you,
we
took
few
applications
pulling
the
same
end
points
every
seven
seconds.
So
for
these
scenarios-
and
this
still
exists
in
our
code
base-
we
have
a
mediator
pattern,
which
is
basically
the
same
as
before.
Instead,
our
main
view
app,
it's
not
a
review.
App
is
a
mediator
class
and
then
of
our
main
view,
apps
actually
talk
to
the
service
order
stone.
Just
the
decay
is
provided
provided
down
through
the
mediator,
so
this
was
very
hard
to
maintain.
It
was
not.
A
It
was
not
easy
to
manage
complex
states
and
at
the
time
when
we
started
there
was
no
UX
and
then,
as
you,
exhale
it'll,
bit
more
stable
and
then
we
decided
to
add
view
X
into
our
code
base
and
after
two
or
three
teachers
with
new
acts.
What
happened
was
we
had
two
or
three
ways
of
doing
view
acts?
So
we
would
have
mutations
being
called
right
from
the
components
who
would
have
different
different
ways
of
dispatching
actions,
different
ways
of
separating
the
concerns.
A
So
we
decided
we
needed
to
document
a
pattern
and
the
reason
behind
the
pattern
we
have
today
and
well.
The
inspiration
is
mostly
redux
because
you
can
literally,
if
you
want
familiar
with
react
and
redux.
You
know
that
you
have
one
way
of
doing
things
and
with
you
Thanks,
you
can
have
several
ways
of
doing
things
and
it
will
still
work,
but
it
might
not
be
as
maintainable
as
we
wanted
it
to
so
we
decided
to
go
with
a
separation
of
concerns
of
everything.
A
So
if,
if
you
want
you
to
view
angst,
if
you're
just
here
for
like
one
month
or
if
you
didn't
have
the
time
to
go
through
the
docs,
this
is
this
will
explain
a
bit
of
our
of
our
documentation.
So
we
have
a
state.
We
have
getters
mutations
actions
and
modules
and
our
goal
is
to
have
a
flow
that
represents
a
user
flow.
A
So
when
a
user
clicks
on
something
that
will
basically
dispatch
dispatch,
an
action
and
that
action
will
commit
a
mutation
that
will
change
the
states,
so
we
decided
that
every
file,
every
every
concern
should
be
in
each
file
because
it's
a
lot
easier
to
read
and
it's
also
a
lot
easier.
Well,
they
are
a
lot
smaller
if
we,
if
we
split
them
into
several
files,
so
our
main
index
file,
we
create
a
store.
You
may
see
that
this
is
what
we
have
documented,
that
we
export
the
instantiated
store.
A
It
does
no
work
sometimes
when
we
need
the
same
store
in
several
applications.
For
example,
when
we
added
the
drop-down
for
the
projects
and
groups
that
we
have
in
a
main
bar,
we
were
exporting
the
store
like
this
and
using
it
for
projects
and
groups
in
the
same
page,
and
that
did
not
work.
So
we
had
to
export
change
the
documented
way
of
doing
that.
A
A
So
actions
are
a
pillar
of
information
that
sent
our
data
to
our
application
and
usually
they
have
a
time
and
they
have
the
payload
itself
that
basically
describes
what
happens
and
enforcing
our
goal.
With
this
pattern
is
that
is
enforcing,
that
every
change
is
described
as
an
action
in
the
human
in
the
human
way.
A
Sometimes
in
the
creative
method,
we
would
have
an
action
that
we
toggle
the
states
to
true
without
even
the
request
being
started.
So,
although
this
is
not
very
view,
X
like
according
to
the
dogs,
it's
it's
a
lot
more
inspiring
the
redux
ones
with
the
action
creators,
and
although
this
means
a
lot
more
boilerplate,
it's
useful
that
you
go
into
any
application
and
everything
is
is
the
same
you.
You
are
expecting
this
patterning
in
every
single
of
our
view,
applications.
A
The
the
front
end
team
is
easier
to
understand
exactly
what
the
state
is
being
changed,
so
the
mutations
are
basically
all
the
state
changes
and
well
I,
literally
copied
our
documentation
into
this
line.
To
these
slides
and
I
told
you
before,
when,
when
I
started,
explaining
the
architecture
that
sometimes
we
would
have
mutations
being
especially
dispatched
from
the
components
which
we
should
not
have
that
otherwise
we
kind
of
miss
the
flux
flow
of
one
single
direction.
A
A
Okay,
so
the
captors
are
basically
well
getters.
Sometimes
we
need
to
whoops
sorry.
Sometimes
we
need
to
to
get
state
or
filter
something
and
we
usually
go
with
getters,
because
view
will
cache
the
results,
which
is
basically
all
the
computed
property
props
work
and
the
mutation
types.
So
we
we
go
with
constants
because
it's
it's
very
easy
to
twelve
typos
and
it's
also
the
working
the
documented
the
recommended
way
in
their
official
documentation.
A
A
And
if
we
need
to
tell
components
to
handle
events,
then
we
will
omit
those
events
and
the
main
app
should
be
responsible
to
call
the
actions
in
the
store,
and
usually
we
include
the
store
in
the
main
app
itself,
because
this
also
makes
tests
so
easier,
like
you
can
import
the
application
and
you
already
have
to
store
them
by
having
child
components
not
accessing
directly
to
the
store.
It
also
makes
the
test
for
those
for
those
child
components
a
lot
easier,
because
you
don't
need
to
set
up
a
store
and
mocking
the
state.
A
So
this
is
the
reason
why
we
have
an
inconsistency,
an
inconsistent
could
days
because
we
were
moving
always
along
the
way.
We
never
actually
stop
and
say,
let's
refactor
everything
that
we
already
did
interview
or
because
we
never
stopped
these
shipping
new
features.
So
this
is
the
pattern
you
should
be
following.
A
Perhaps
if
you
bootstrap
and
ask
some
of
our
shared
components
and
the
reason
we
have
this
two
different
ways
of
doing
it
is
because
again
we
never
stopped
shipping
features.
So
by
the
time
we
realized,
we
had
a
lot
of
repeated
components.
We
started
the
view
shared
folder
and
we
moved
some
things
there.
We
still
have
the
buttons
and
the
dropdowns
and
all
the
UI,
all
the
UI
components
would
still
be
repeated.
So
in
the
meanwhile
we
started
have
UI,
which
is
still
a
working.
B
So
relatively
new
I
guess
we
have
graph
QL,
it
was
a
little
while
back
and
the
idea
was
that
we'd
started
convert
the
microswitch
it
into
what
we
know
back
to
your
transfers,
its
current
anyone
actual
app
that's
using
graphical
elements.
The
issue,
suggestions
and
I
would
ideally
suggest
that
everybody
starts
using
graphical
for
new
features.
It
would
be
grave
every
little.
Every
new
features
graph
killer
I
mean
it
might
not
be
possible,
some
features,
but
please
try
your
best
use
it
and
for
queries
and
mutations.
We
can
write
on
them
in
doc.
B
Graph
QL
files
left
path
will
compile
them,
some
get
pads
on
the
front
end
and
we
can
import
them
into
JavaScript
or
a
few
files
and
using
a
view
app,
you
can
use,
be
our
viewer
color.
So
you
can
use
the
query
component
or
the
mutation
component
and
the
chronology
done
in
the
template.
We
can
like
tweak
it
a
little
bit
in
the
script,
part
of
it.
B
If
you're
not
using
a
viewer,
you
can
just
directly
for
the
Apollo
client
and
that
should
be
a
link
to
the
actual
Apollo
fire
fire
and
you
can
just
issue
the
queries
mutations
through
that
and
if
you
need
any
local
state,
please
use
a
poly
link.
State
visits
brought
to
planet
Eire.
It's
simple,
I
didn't
even
force
about,
so
please
use
a
poly
link
state
and
you
can
try
on
get
lab
comm.
There
there's
not
very
many
queries
its
do,
but
it
should
give
you
a
rough
idea.
B
And
for
our
tests,
I've
not
really
listed
all
the
tested,
there's
a
few
more
like
we
have
a
spec
with
your
end-to-end
tests
and
they
take
the
application
from
sign
in
all
the
way
for
you
to
actually
testing
the
application.
You've
probably
noticed
some
failures.
If
you're
working
on
some
of
the
tests,
they're
relatively
simple,
to
understand
it's
just
a
case
of
finding
a
boiling
click
in
them
and
for
the
front-end
specifically
calm
is
the
older
one.
I
mean
they
all
run
in
the
same
browser
in
a
zoo.
B
Some
tests
can
interact
all
the
testing
ways
that
aren't
very
nice
and
you'll
see
families
that
just
make
no
sense
at
all,
and
then
we
have
all
an
old
Newmark
method.
It
looks
a
little
weird
and
there's
maybe
like
four
or
five
and
then
the
same
file.
There's
like
a
crate
component
about
components,
mode
component
story
comparison.
B
Ideally,
we
should
be
using
view
test
utils,
which
is
again
it's
relatively
it
being
relatively
new.
So
for
newer
tests,
please
use
for
you
to
test
utils
and
ideally
use
jess
with
you
actually
can
use
dot
too
much
snapshot
instead
of
just
career
in
the
elements
and
checking
it
exists.
All
right
snapshot
found
just
check
that
into
getting
pushed
up
as
well.
So
yeah
back
to
you,
Philippe
Thanks,.
A
Okay,
so
this
last
two
slides
are
not
about
that
could
base
itself.
But
how
do
we
work
regarding
deliverables?
So
our
deliverables
are
always
features,
they
are
always
big
and
they
always
have
UX
and
front-end
and
back-end,
and
it
can
be
a
bit
daunting
if
you
are
new-
and
you
have
so
many
things
to
do
in
in
a
deliverable-
and
sometimes
it's
easy
to
forget
that
we
we
always
aim
for
boring
solutions
and
that
we
rather
ship
something
working
that
not
shipping
anything
at
all.
A
So
the
advice
is
when
you
get
assigned
with
rigor,
go,
get
check
the
UX
mock-ups
and
identify
the
small
components
so
check
if
they
already
exist
in
either
declare
dy
or
if
you
shared
folder
or
if
you
are
unable
to
find
them
or
are
uncertain
as
commit
a
maintainer
or
anyone.
I
think
anyone
there
is
at
keep
up
over
them
like
six
months
will
be
able
to
twelve.
A
But
to
be
sure
you
can
ask
you
maintainer,
you
will
most
likely
need
a
few
extra,
so
the
the
advices
first
identify
all
the
state
properties,
and
with
this
you
should
write
a
spec
either
in
the
issue
or
you.
If
you
want
to
open
an
empty
movie,
quests
explaining
which
components
do
you
need
to
create
for
Europe,
for
your
deliverable
which
components
may
need
to
access
the
store?
Besides
the
view
application,
what
is
the
States?
A
What
is
the
year
key
of
the
components
and
what
actions
and
mutations
would
you
need
and
before
start
writing
any
code?
You
should
get
validation
from
a
maintainer
on
this
planet,
because
sometimes
it
happens
that
someone
is
writing
code
for
two
or
three
weeks
just
to
get
to
the
review
phase
and
realize
that
they
need
to
rewrite
everything
again,
because
it's
not
up
to
date
with
our
patterns.
A
So
this,
this
planning
step
should
happened.
It's
recommended
that
happens
in
the
first
week
and
we
also
advise
like,
if
you
have
smaller
components
that
you
need
to
create
to
break
into,
to
break
them
into
smaller,
more
sequence.
So,
instead
of
having
just
one
huge
merge
request
with
a
lot
of
changes,
ship
things
smaller,
because
maybe
you
have
a
new
a
new
component
that
needs
to
go
into
github,
UI
or
a
new
component,
and
it's
going
keep
alive,
see
and
maybe
be
reusable
by
anyone
else
in
the
same
milestone.
A
So
that
way,
we
we
keep
focusing
on
the
boring
feature
on
the
boring
solutions
and
shipping
fast
and
regarding
the
review
process,
it's
always
awkward
to
keep
in
mind
that
all
requests
need
to
be
with
a
maintainer
by
the
first.
If
this
does
not
happen,
it's
very
hard
to
guarantee
that
your
merge
request
will
be
merged
within
that
release.
It's
also
very
important
that
if
you're,
if
you're
merging
west
exchanging
anything
in
the
UI,
it
needs
to
be
reviewed
by
the
UX
portion
that
is
assigned
to
the
issue.
A
I'd
recommend
to
do
this
step
before
the
fronton
review,
because,
usually
you
ex
will
will
ask
for
some
change,
which
means
that
there
will
be
cool
changes
so
to
avoid
a
lot
of
back-and-forth
I
would
recommend
to
start
by
the
UX
review
and
that
move
to
the
front
and
review
and
I'm.
Just
a
couple
more
advices
before
before
considering
the
signing
to
a
maintainer
or
a
reviewer
is
take
the
time
to
read
the
code
yourself.
A
Make
sure
that
the
pipeline
is
green,
that
all
the
discussions
are
resolved
and
before
reviewer
or
a
maintainer
open
the
discussion.
Please
don't
dismiss
it
by
by
asking
another
maintainer
or
another.
If
you
were
to
review
it
before
the
first
maintainer
got
the
chance
to
to
follow
up
on
that
discussion.
C
Yeah
I
guess
I
do
in
get
lab
recently,
oh
by
the
way,
thanks
for
putting
all
this
together,
so
I
guess
where
I
was
always
a
little
bit
confused
coming
from
react
and
redux
was
in
your
experience.
When
is
it
appropriate
to
use
immediate
events?
Is
it
something
that
should
ideally
be
used
from
a
component
that
doesn't
have
access
to
the
view
X
store
I'm?
Could
it
be
used
in
components
that
do
use
the
view
X
store
yeah?
Do
you
mind
clarifying
that
of
it?
A
Let's
just
see
sorry
about
the
noise,
it's
it's
not
exciting.
It's
very
annoying!
Every
time
this,
like
every
year,
this
happens,
there's
a
university
year
and
there's
like
the
freshman's,
they're
doing
stupid
things.
So
I
think
I,
think
your
question
and
then,
though,
so
in
view,
it's
a
bit
different
than
react
in
view.
The
communication
is,
if
it
props
go
down,
events
go
work
and
when
you
add
view
X,
it's
exactly
the
same.
A
The
data
goes
down
and
they
things
go
up.
So
if
you
have
a
button,
there
is
a
shout
component
that
potentially
meets
an
events
and
the
main
ad
would
listen
to
it
and
then
call
the
action.
Obviously
you
can
include
the
store
everywhere,
but
that
would
make
things
harder
to
test
and
and
to
reuse.
So
if
we
have
small
components
using
the
story-
and
this
this
has
happened
in
the
past-
it's
a
lot
harder
than
the
next
milestone
to
realize.
A
Well,
we
need
this,
but
this
is
already
accessing
the
store
for
another
app
and
we
don't
have
time
to
refactor
this
now.
So
let's
just
create
a
new
component,
so
this
is
basically
the
two
main
reasons.
Why
we
advise
to
not
have
all
the
sound
component
success
in
a
store?
Obviously
there
will
be.
There
will
be.
Exceptions
sometimes
makes
more
sense
for
the
child
component
to
access
the
store
directly
but
I
think
a
good
rule
of
thumb,
base-emitter
events
up
until
the
main
application,
so.
C
A
A
C
Ok
thanks
and
sorry
and
then
the
follow-up
question
was
I.
Guess
this
is
a
side
effect
of
being
new
to
get
lab.
Do
we
have
like
standard
terminology,
for
it?
Has
the
UX
state
and
doesn't
cuz
I've
heard
things
yeah
I
mean
I,
don't
know
like
no
three
or
four
different
ways,
so
it
seems
like
it
easy
thing
to
resolve,
but
I
was
hoping
that
maybe,
since
we
have
everyone
here,
I
could
probably
open
a
follow-up
issue
just
to
the
sake
of
documentation
in
the
future.
C
D
I
have
a
question
regarding
stores,
because
I've
seen
everything
that
we
sometimes
create
stores
in
the
index
chairs.
Sometimes
you
create
stalls
somewhere
in
the
middle.
Sometimes
we
create
stores
in
the
in
the
component
like
in
the
route
component
or
something.
But
my
main
question
is:
would
it
be
okay
to
have,
because
sometimes
we
have
to
create
store
function,
because
it's
also
easier
for
testing
similar
to
the
state
function?
Would
it
be
okay
to
give
this
great
store
function
in
parameters?
So,
for
example,
one
use
case
I
would
have
we
have
insecure?
D
We
often
use
we
often
we
often
use
view
action
just
to
set
something
in
the
state
like
an
API
endpoint
that
never
changes
during
the
runtime
of
the
app,
and
it
would
be
just
easier
to
plug
it
in
directly,
rather
than
typing
it
through
the
view
app
to
the
VX
store
like
providing
it
directly.
For
example,
in
the
index.js,
when
we
read
the
API
endpoint
from
say.
A
No
because
you
would
have
to
have
the
store
in
the
index
and
not
the
main
app,
and
then
you
would
have
to
mount
the
store
in
this
in
the
in
the
tests
would,
and
that
would
not.
Actually
we
don't
have
good
end-to-end
tests
and
if
we
start
moving
things
out
of
the
main
component
and
then,
if
you
look
into
our
test,
you
will
see
a
lot
of
things
that
are
not
actually
testing
our
code.
They
are
mocked,
so
we
would
have
to
mock
the
store
with
the
parameters
that
we
are
providing.
So
I'm.
A
Pretty
sure
that
you
would
happen
that
we
would
have
code
in
production
without
an
an
endpoint,
for
example,
and
we
would
have
test
for
it.
They
there.
They
would
just
not
be
testing
the
awful
so
and
also-
and
because-
let
me
just
you
know,
also
if
we
start
doing
that,
we
will
have
one
more
pattern
and
we
already
have
so
many.
It's
not
that
costly
to
provide
the
endpoint
as
a
property
to
the
main
application.
So
I
know.
D
The
actual
problem
I
was
sitting
and
I'm
just
opening
the
issue,
because
we
are
out
of
time
already.
The
actual
problem.
I
was
sitting
that
the
stall
was
created
and
was
already
doing
requests
before
it
had
the
API
endpoint,
because
the
store
the
earth
was
not
mounted
and
wasn't
providing
it
down
to
the
app,
and
so
anyway,
I
will
look
into
it
and
create
an
issue
around
it.