►
From YouTube: Session #1: Discussing: Improve maintainability & performance of the FE of Merge Request Diffs
Description
The first of several calls to discuss approach to improve performance and maintainability of the Frontend MR Diffs app.
Epic: https://gitlab.com/groups/gitlab-org/-/epics/2852
Slack: #g_create_source-code-fe
A
B
So
hi
everyone
thank
you
for
making
to
this
call
I'm,
recording
it
just
for
for
later
sharing
and
basically
the
idea
of
the
skull
is
to
have
sort
of
like
a
a
think
tank
so
that
we
can
and
analyze
the
problems
we're
facing
on
the
merge
request.
Diffs
app
they've
been
plenty
over
the
past
couple
of
months
in
years.
B
Actually
so
and
I'm
just
gonna
give
you
like
an
overview
of
what
we've
been
doing
and
I'm
gonna
put
the
link
to
the
epic,
the
pop,
so
that
you
can
all
go
and
see
in
the
idea
that
that
we
have
here
is
so
that
we
we
and
source
code
can
get
together
and
discuss
it
as
a
team.
So
we
had
a
couple
of
external
invitees.
So
thank
you
for
the
experts
joining
us
on
this
call.
The
idea
is
that
this
is
sort
of
a
brainstorming
session,
so
there's
no
really
bad
idea
or
something.
B
So
definitely
if
you
have
crazy
ideas,
definitely
want
to
hear
them
because
out
of
those
we
might
able
to
squeeze
out
actual
steps
and
then
things
we
can
do
from
from
those
crazy
ideas.
So
once
we're
talking
and
if
you
have
crazy
ideas,
steam
and
brewing
in
the
back
of
your
head
document
them
in
the
document
and
then
we
can
discuss
it
briefly,
the
idea
out
of
this
call
is
I
will
have
sort
of
a
list
of
things
that
we
need
to
pursue,
whether
to
validate
or
to
break
down
into
actual
deliverables.
B
C
B
Okay,
Thomas
you're
in
sorry
for
that
yeah
I
hadn't
noticed
that
he
had
stepped
up
cool,
so
continuing
up
continuing
on
to
the
overview
of
recent
history.
So
just
good
here,
section
three,
so
the
merge
request,
divs
and
discussions
app
was
refactoring
to
view
in
2018
resonating
around
June.
It
was
refactored
interview.
That's
when
this
history
starts
the
factory
interview
and
out
of
this
refactor,
we
came
to
a
bunch
of
regressions
and
problems
that
happened
with
the
rollout
at
the
time.
B
We
thought
it
giving
too
much
thought
about
performance,
so
we
learned
a
lot
since
then.
So
after
that
rollout
we
had
to
deal
with
all
the
regressions
and
somewhere
along
in
2018
Tim,
built
the
rendering
queue
which
is
basically
a
flag
in
the
components
of
the
tips
that
that
says,
render
it
or
not,
and
then
we
progressively
enabled
them
so
that
they
can
render
it
as
a
cue
and
then
we
carried
on
optimizing
and
improving
some
some
sets
of
components
to
make
them
more
lightweight.
And
apart
from
that,
it
was
basically
business.
As
usual.
B
We
started
developing
sorry.
We'd
have
start
developing
features
on
top
of
it
and
we
added
merge,
request
reviews
and
we
added
optimizations
in
how
unresolved
discussions
were
were
resolved
and
then
handled
and
navigated.
So
there
was
a
lot
of
work
being
done
on
top
of
that
initial
approach
to
the
view
to
the
diffs
viewer
factor.
So
with
time
features
were
added
and
more
recently
we
started
addressing
stuff
like.
B
Oh,
it
takes
a
very
long
time
to
toggle
files
contents
and
more
than
that,
he
just
came
painfully
aware
that
really
large
Amar's
had
a
stroke
really
struggled
rendering
the
whole
of
the
the
application.
When
we
looked
into
the
profiling
and
everything
we
realized
a
lot
of
the
the
holdups
were
in
actual,
but
the
view
code
tearing
tearing
down
the
component
trees
and
building
them
back
up
as
things
moved
around
the
the
state
anon
on
the
app
which
kind
of
started,
pointing
at
some
pain
points.
B
Here's
when
we
started
thinking
of
approaches
that
came
after
which
were
somewhere
in
2019,
we
started
discussing
and
building
towards
batch
Tiff's
floating,
which
what
it
is
is
basically
instead
of
loading
the
diffs
Jason
that
has
all
the
information
for
the
diffs
file
at
once.
We
started
loading
them
in
batches.
So
what
this
does
is
like
one
request
for
meta
information
for
the
murder
for
the
diffs
and
then
1
or
1
to
n
requests
for
diffs
contents
right.
B
So
that
was
the
first
approach
that
we
had
to
optimize
the
performance
and
so
that
we
had
immediate
or
almost
immediate
display
of
the
diffs
and
then
progressively.
We
would
load
the
data
from
the
server
in
batches
and
then
closing
20-19
opening
20
20.
We
work
on
splitting
in
line
and
parallel
diff
data.
B
So
we
split
the
way
that
we
loaded
that
we
started
loading
just
the
active
mode
and
then,
when
the
users
switched
to
another
mode,
we
pulled
down
from
the
server
that
other
piece
of
information.
These
are
all
rolled
out.
They
are
behind
feature
flags.
So
let
me
just
put
here
so
behind
feature
flags.
They
are
currently
enabled
and
default
the
true,
but
the
more
we
worked
on
it
and
especially
working
on
the
batch
Tiff's,
which
was
pretty
much
everyone
in
the
team
worked
on
it,
but
especially
just
in
Thomas
and
Phil.
They
were.
B
You
were
all
involved
in
some
way
into
this
effort.
The
complaint
started
to
be
even
louder
and
louder
in
how
hard
it
was
to
work
with
the
current
state.
The
debt
that
we
have
accrued
over
the
next
over
the
past
couple
of
months
were
just
becoming
a
little
bit
too
much
to
bear,
and
every
time
one
of
the
maintainer
had
to
review
code,
he
was
easier
to
let
something
slip
or
just
the
complexity
is
just
so
high
to
to
grasp
right.
B
So
what
we're
looking
here
is
two
it's
two
way
to
two
perspectives:
one
we
need
to
increase
and
to
improve
the
performance
of
the
overall
app,
but
also
the
maintainability
of
the
code
itself,
like
it's
not
easy
to
work
with.
We,
we
find
ourselves
very
frequently
just
understand
duress,
mating
the
the
effort
of
any
feature
that
we
need
to
work
with.
B
B
D
I've
talked
with
a
handful
of
people
about
this
idea,
while
we
were
wrestling
with
the
maintainability
of
this,
but
now
that
we're
discussing
it
more
I
can
see
how
this
affects
the
performance
as
well,
but
and
the
M
R
dips.
We
have
quote
unquote
state
management,
meaning
that
we
use
view
X
check
that
box,
but
for
the
most
part
we
just
take
whatever
the
be
e
model
is
the
backend
model,
and
we
just
shove
that
at
this
door,
maybe
we're
just
selecting
certain
field
to
make.
D
We
convert
them
to
camelcase,
but
we're
taking
it
as
it
looks
in
the
backend,
which
doesn't
necessarily
serve
the
front-end.
Well.
So
what
this
means
is
throughout
all
of
our
components
and
different
getters,
and
it's
spread
across
there's
no
encapsulation
here,
but
that
single
state
to
actually
be
useful
kind
of
gets
transformed
before
it
actually
gets
rendered
onto
the
page
multiple
times,
and
so
something
I've
been
really
thinking.
A
lot
about
is
trying
to
solve
problems
at
the
data
level
first.
D
So
when,
as
soon
as
we
get
that
back
in
tomorrow,
if
it
doesn't
look
like
what
we're
gonna
need
to
use
in
the
front
end,
let's
transform
it
right
away
before
we
save
in
our
state
management
and
it's
ok.
If
our
state
management
doesn't
look
like
our
back-end
and
I
think
then
it
dawned
on
me.
Oh,
this
is
when
everyone's
talked
about
model
view
viewmodel.
This
is
what
everyone
was
talking
about.
D
Was
you
have
this
view
model
which
is
different
than
your
model
and
that
helps
maintainability,
because
there's
a
clear
encapsulation
with
what
things
transforming
things
from
the
back
end
to
the
front
end
I.
Did
this
a
little
bit
with
the
approvers
feature
and
a
back
end?
I
was
able
to
fix
a
bug
or
whatever
on
the
front
end
code,
just
because
it
was
just
in
one
file.
D
D
Gonna
significantly
help
performance
because
there's
so
many
less
Watchers,
because
all
that
business
logic
is
at
soon
as
we
get
the
data.
We
transformed
it
to
look
like
what
is
our
view
actually,
rather
than
having
our
component
have
to
watch
everything
and
having
smart
components
and
fancy
Gators
all
wrapped
up
in
each
other.
That's.
B
C
Like
it,
a
lot
I
like
how
it
kind
of
gives
us
an
intermediary
step
between
what
we're
getting
from
the
back
end,
what
we're
doing
on
the
front
end,
especially
since
our
worker
cues,
don't
line
it
up
with
each
other
very
well.
I
feel
like
we're
doing
too
much
manipulation
on
at
the
component
level
to
try
and
get
things
to
be
in
the
shape
that
we
expect
them
to
be
so
Paul's
kind
of
data
first
approach.
It
makes
sense
to
me
just
as
from
a
fundamental
level
of
that's
how
that
should
work.
C
We
don't
always
have
the
sort
of
benefit
of
letting
the
backend
do
it
for
us.
First,
we're
actually
having
an
issue
right
now
with
a
multi-line
comment
situation
where
I've
been
speaking
with
Robert
and
they're,
still
probably
two
or
three
milestones
away
from
being
able
to
get
that
into
a
shape
that
the
front
end
could
just
consume.
C
So
weird
I'm
doing
a
lot
of
work
on
the
front
end
to
make
that
work,
and
this
type
of
approach
I
think
encapsulate
it
in
such
a
way
that,
yes,
it
back
under
it
can
hopefully
understand
it
and
ideally
remove
it
when
it's
ready
to
get
put
back
into
the
back
end
where
it
should
be
and
I
think
I
think
you
mentioned
something
about
us
just
kind
of
assuming.
This
is
a
way
they're
gonna
go
forward.
I
think
that's,
probably
pretty
accurate
I
think
it
helps
a
lot
yeah.
A
Can
speak
to
a
point
that
I'm
writing
at
the
moment
we
could
potentially
run
into
some
additional
performance
problems
with
this
thinking
optimistically,
ideally,
transforming
them
right
right
as
soon
as
we
get
data
from
the
back
end
would
actually
reduce
performance
problems,
ultimately,
and-
and
even
at
that
moment,
but
right
now
we're
doing
a
ton
of
transforms
like
say,
merging,
merging
the
DIF
that
you
don't
have
into
the
one
that
you
have.
You
know
if
you're
looking
at
90
load,
parallel
merging
those
two
together
into
one
diff.
A
It's
a
lot
of
performance
issues
with
that
and
it's
actually
fairly
slow
on
the
front
end
to
do
those
transforms.
Ideally,
we
wouldn't
have
to
do
big
heavy
lifting
like
that.
It
would
just
be
like
okay
take
this
key
and
make
it
this
name
or
or
transform
it
this
way,
and
it
wouldn't
be
a
big
heavy
lift,
but
we
do
have
some
from
dishes
now
with
doing
some
transforms
on
load,
and
this
could
be
potentially
worse
if
we
don't
slim
down
the
trans
type
of
transforms
that
we're
doing.
E
A
I'm,
okay,
with
this
approach
or
just
wonder,
if
it'd
be
simpler,
to
just
reduce
the
amount
of
black
in
dates
that
comes
to
us
like.
Are
we
just
getting
too
much
status
and
time
away
and
that's
the
problem?
I?
Don't
it
yeah
very
likely?
In
fact
I
am
I
mentioned
lower
on
one
of
Justin's
points.
One
of
the
comments
in
the
epic
is
I.
Don't
think
that
we
actually
need
two
different
styles
of
diffs
I.
A
Think
that
if
we,
if
we
carefully
constructed
what
a
DIF,
what
a
diff
looks
like,
we
could
use
that
same
diff
for
both
in
mine
and
parallel,
and
that
would
slim
down
well
that
was
them
down
what
we're
getting,
but
we
wouldn't
even
need
to
do
the
split
dips
at
all.
You
just
get
one
style,
but
yeah
I.
Think
at
the
moment
we
are
loading
too
much
data.
B
Yeah,
sorry
for
the
noise
of
the
keys,
I
didn't
notice
that
I
was
muted
yeah
on
that
sense.
I
think
that,
from
what
I've
seen
we've
just
been
avoiding
doing
all
that
computation
on
the
front
end.
You
know
again
for
performance
reasons
and
benefiting
from
the
logic
that
we
already
had
on
the
back
end.
I.
B
So
yeah
I,
don't
I,
don't
I'm
mentally
sure
if
it's
worth
moving
that
computation
to
the
front
end,
because
you're
gonna
have
to
be
doing
a
lot
more
computation,
which
is
what
exactly
what
we
kind
of
want
to
avoid
at
a
certain
point,
and
the
same
point
of
for
the
transformations
is
also
a
good
point
about.
Potentially
we
putting
ourselves
into
a
corner
here
where
any
requests
you
do
to
the
front
to
the
back
end,
we
have
to
transform
it.
B
So
what
I
think
is
we
need
to
validate
that
cost
of
those
kinds
of
transforms?
What's
the
kind
of
pattern
approach
we
might
take
to
those
transforms,
but
it
is
one
way
possibility
about
reducing
the
data
from
the
back
end
yeah.
We
can
definitely
if
we
diet
down
a
little
bit
of
the
payload
on
the
back
end.
We
might
benefit
a
bit
of
the
timing
that
the
responses
are
getting,
but
then
we
have
to
do
more
calculation
on
the
front
end,
so
we
need
to
be
wary
of
that.
B
Maybe
we
can
do
an
audit
and
check
on
the
on
the
payload
of
the
back
end
requests
what's
coming
down
the
pipe
to
see
if
we
need
all
of
that
information,
because
I'm
not
entirely
sure
if
the
problem
is
the
number
of
bytes
in
this
state
or
just
the
effort
we're
doing
to
rework
this
state
every
time
we
need
it.
Yeah.
F
D
Bring
up
a
good
point
about,
and
this
idea
of
you
know
the
back
end
isn't
gonna
give
us
what
we
want.
There's
a
very
pessimistic
idea
of
like
hey.
You
know
front
end
we're
on
our
own.
We
got
this
stuff
from
the
back
end.
What
are
we
gonna
do
and
sometimes
we
can
manipulate
what
the
backend
gives
us
definitely
and
I
think
I
think
in
some
cases
we
can't
because
the
back
end
has
more
clients
than
just
this
view.
So
there's
not
a
whole
lot
of
flexibility
of
shaping
that
response
data
but
I
think
I.
D
Think
it's
a
good
point.
That's
lay
out
what
is
a
good
full
stack
solution
here.
There
is
a
downside
to
okay.
Things
are
working
nicely
in
the
client-side,
but
we
have
to
do
lots
of
transformations
on
the
back
end.
We
could
end
up
hitting
the
initial
response
for
everybody
like
if
our,
if
our
back-end,
for
whatever
reason,
if
we
need
we
move
transformations
up
to
the
back
end
there,
there
could
be
a
more
broader
performance
hit
in
that
case.
So.
B
B
D
B
That's
why
I
wanted
to
hear
also
Natalia
in
the
perspective
of
graph
QL?
How?
Because
the
transformation
that
we're
talking
about,
might
very
well
be
repurposing
the
representation
of
the
entities.
We
have
right
now,
like
TIF
files,
TIFF
lines,
and
if
we
do
that
that
update
on
the
back
end
of
graph
QL,
when
it's
served
on
the
graph
QL
API,
it
could
be
in
a
completely
different
shape.
That
is
more
beneficial
to
the
front-end
and
we
get
graphic
you
all
to
boot.
The
try.
We
have
any
thoughts
on
that
so.
B
That's
a
good
question,
I
think
right
now,
the
the
what's
holding
up
there.
There
is
the
cost
of
just
we
working
everything
into
graph
QL
and
then
updating
the
front-end,
which
is
a
fair
point.
So
I
don't
know
if
it's
a
feasible
thing.
The
question
I
have
at
this
point
is:
is
it?
Is
it
even
worth
considering
putting
that
on
the
table
for
the
back-end
team?
Would
we
benefit
from
it
and,
if
so,
is
that
the
better
approach
than
having
transforms
on
the
front-end
using
the
recipe
is
well.
F
If
we
will
be
able
to
collaborate
with
a
back-end
and
shape
our
graphical
schema
properly
and
I
mean
our
front-end
is
for
now
at
least,
is
our
main
user
of
the
graph
feel
like
we
are
the
main
customers?
So
we
can
try
to
shave
the
scheme
of
this
ways
that
we
don't
need
any
kind
of
transformations,
because
we
will
fetch
only
those
data
we
need,
and
if
there
is
no
deep
nesting
there,
we
can
just
use
whatever
we
have,
but
it
will
come
with
a
price,
because
we
have
a
view.
B
Yeah,
that's
a
great
point:
yeah!
That's
when
we
were
having
the
crazy
ideas,
conversations
rebuilding
it
from
scratch.
We
always
thought.
Oh
yeah,
that's
that's
nuts,
but
let's
try
to
take
some
too
bits,
and
you
always
come
down
to
the
point
of
there's
so
much
logic
to
rewrite
that
the
time
for
us
to
do
the
rewriting
we
should
want
to
move
it
to
Apollo.
It
would
be
definitely
non-negligible
will
be
very
considerable.
So
that's
a
fair
point.
B
B
Wonder
if
there's
any
kind
of
technology,
like
remember
I,
don't
know
if
anybody
remembers
those
XSLT
XSLT
the
xml
transformations
that
we
had
in
xml
times.
Is
there
anything
like
that
for
jason,
that
we
could
have
like
a
layer
from
the
backend
like
sending
that
to
a
layer,
just
repurposing
that
and
through
a
test
I'll
shoot
he's
dead,
that's
something
that
exists.
I.
B
D
C
D
Part
of
us
using
single
page
view,
apps,
is
to
get
this
very
quick
response
and
yeah
we're
trying
to
offload
some
of
the
logic
on
the
client
for
a
reason,
you're
gonna
have
to
do
some
transformation
where
that
lives
is
a
is
a
really
good
question
and
I
think
we've
kind
of
leaned
towards
some
transformation
living
on
the
front-end
and
that's
okay.
We
just
can't
have
it
spread
everywhere.
D
If
we
have
there's
no
rules
like
a
component,
if
I
need
this
I'm
gonna,
add
computers
and
I'm
gonna
make
my
day
to
look
how
I
want
it
as
components.
Gonna
make
his
day
to
look
how
he
or
she
wants
it,
and
that's
gonna,
be
when
it's
spread
across
the
whole
front.
End.
That's
where
we
see
performance
issues
this,
but
if
it's.
C
D
At
an
entry
point
in
the
front,
as
soon
as
I
add
this
architectural
boundary
of
as
soon
as
I
get
stuff
on
the
back
end,
I've
transformed
it
it's
different,
so
I
I'm
just
raising
a
we're,
just
a
concern
of
like
but
I'm,
not
too
eager
towards.
Let's
push
this
on
the
back
end,
because
we
could
then
they
really
architecture
ourselves
to
hold
another
slew
of
performance
concerns
and
now
effects
like
we're,
seeing
weird
Peaks
and
CPU
or
whatever.
So
I'm.
D
I
think
that
front
ends
gonna
have
to
do
some
transformation
and
I
think
that's
why
we
like
using
view
and
single
page
applications
but
yeah
a
little
concerned
when
I
hear
about,
let's
just
shove
it
onto
the
back
end,
because
I've
seen
that
what
scale
that
distance
up
we've
just
pushed
the
problem
now
to
everyone.
Yeah.
E
Dude
to
chime
in
and
dislike
yeah.
This
is
totally
on
point
what
Paul
said,
but
we
kind
of
forget
this,
like
everybody
by
now,
mostly
using
a
very
powerful
machine.
So
that's
a
lot
of
like
free
resources.
Cpu
we
get,
we
don't
need
to
pay
for
right.
Everything
we
put
in
the
back
end
is
like
kind
of
building
up
our
cost,
some
kind.
E
We
need
more
infrastructure
and
everything,
but
the
other
side
is
also
because,
like
handling
data
between
back
and
front
them
is
almost
like
costly,
because
we
need
more
overlap
in
terms
of
our
teams.
We
need
to
kind
of
collaborate
with
them.
There's
a
lot
of
like
discussion
and
conversations
happening,
there's
always
kind
of
make
some
of
the
process
a
little
harder.
So
if
we
on
the
front
end
discover
oh,
we
need
this
change
down
this
format.
E
Can
you
change
it
again
on
the
back
end
like
then,
we're
always
like
in
there
in
the
run
after
basically.
So
if
we
take
this
on
our
own
and
say,
ok,
we
get
the
data,
we
know
what
we
have
keep
it
up
consistently
in
the
back
end,
then
we
can
iterate
wet
much
faster
and
kind
of
like
change
things
to
our
liking
and
we
can
try
different
experiments
with
datasets.
B
So,
for
the
sake
of
time,
I'm-
probably
gonna,
move
on
to
the
next
topic,
but
I've
already
took
one
point
as
a
takeaway
from
this
discussion,
which
is
transform
data
from
backends,
probably
on
request,
and
we
need
to
know
what
kind
of
transforms
will
be
useful
for
the
front-end.
So
that's
probably
something
that
I'll
create
like
an
epic
or
an
issue
for
us
to
drill
down
on
the
actual
changes,
and
we
can
discuss
that
as
synchronously.
But
this
is
all
very
useful.
B
Thank
you
all
and
there's
one
particular
point
I
want
to
jump
to,
which
was
the
functional
components,
could
help
here
and
I'm
interested
there
on
the
thoughts
of
not
just
the
experts
on
the
call,
but
also
the
teams,
and
also
the
context
of
view
3
coming
down
the
pipeline,
because
it
could
also
be
a
timing
thing.
We
could
do
this
update
when
we're
jumping
over
to
view
3
so
keen
to
hear
your
thoughts
Roman,
you
wanna,
take
it
away.
E
Sure
so,
I'm
personally,
you
kind
of
huge
advocate
for
functional
components.
Just
for
the
sake
of
like
ok
force,
to
see
you
sometimes
to
kind
of
rethink,
how
you
kind
of
structure
your
components,
because
if
you
want
to
used
to
like
to
render
functions,
there
is
sometimes
super
shitty
to
right.
So
you
have
to
think
very
closely
and
what
kind
of
HTML
you're
packing
it
into,
and
you
don't
you
try
to
avoid
as
much
as
possible,
but
the
other
side.
E
You
unlock
a
lot
of
powerful,
like
how
you
use
your
JavaScript
and
helpers
and
those
kind
of
things,
and
you
realize
ok,
what
is
actually
necessary
to
render
that
piece
of
code
that
are
one
half
of
the
page,
so
functional
components.
Interestingly,
I'm,
currently
working
on
a
video
course
and
just
I
was
kind
of
looking
into
some
performance
benefits.
E
You
gain
out
of
this
one
and,
for
example,
here
rendered
a
list
of
like
Oh
worth
1000
like
JSON
objects
or
so
and
just
by
switching
the
same
logic
from
like
a
normal
component
of
functional
components,
I
kind
of
almost
cut
it
like
in
half
and
millisecond
like
rendering
time
from
122
kind
of
70,
which
is
quite
nice,
and
it
was
like
this
took
me
literally
like
five
minutes.
In
this
case.
E
Of
course,
it's
like
a
small
example,
but
what
I
think
we
can
gain
is,
in
general,
there's
a
lot
of
little
things
we
render
over
and
over
on
the
page
and
if
we
kind
of
like
try
to
kind
of
find
the
right
spots,
work
and
chime
in
and
ideally
we
start
like
bottom
up.
So
we
don't
have
to
kind
of
deal
with
a
lot
of
issues,
kind
of
inheriting
things
downwards,
but
really
bottom
up
or
so.
E
C
C
B
F
B
E
Think,
like
everything
and
always
like
not
to
let
the
goal
here
right,
it's
more
about
like
finding
the
right
little
spots
where
it
makes
sense.
What
actually
gives
you
something
just
saying:
oh
I
can
do
it
doesn't
make
sense.
I
should
do
it
right,
but
I
totally
understand
the
point
of
saying
like
okay,
you
three
in
general
is
a
huge
performance
boost
and
then
the
gain
is
way
smaller.
Then
it
might
be
something
where's.
Okay,
maybe
it
doesn't
make
too
much
sense
to
invest
in
it
right
now.
Just
one
of
firms,
yeah.
B
That's
very
that's
very
useful
because
we
will
jump
to
view
three
and
the
gains
that
we'll
have
performance
wise
there.
It
might
make
some
of
the
cost
that
of
the
development
experience
not
worth
it.
That's
that's
that's
very
interesting
and
let
me
just
think
I
wanted
to
say
something,
but
I
forgot.
C
Talk
in
the
gate
lab
you,
our
working
group
around
moving
a
bunch
of
those
components
into
functional
components
as
I
again
when
I
was
looking
at
their
performance
increases
before
some
of
the
biggest
ones.
That
I
saw
that
we
use
a
lot
of
times,
especially
on
something
like
merge
request.
If
swear.
Every
row
is
a
component,
and
inside
of
that
you
have
two
or
three
icons
and
two
or
three
buttons
like
that
adds
up
very
quickly,
and
the
icons
in
particular
are
not
a
functional
component.
B
D
We
may
want
to
use
real
collaborators
versus
fake
collaborator
collaborators,
so
we're
making
sure
we
have
the
right
we're
looking
at
the
right
state
key
or
whatever.
Does
that
question
make
sense
like
if
I
do,
map
test?
If
I
do
map
states
I
get
something
blows
up
if
I'm
throwing
a
wrong
key
in
there,
I
get
a
consular
and
then
our
unit
test
fails,
but
map
state
isn't
available
in
like
functional
components
and
if
I
say,
if
I
have
in
my
props
key
like
I
expect
this
prop
and
it's
gonna
be
a
type
string.
D
I
bypass
a
type
object
in
any
way
and
my
test
it's
gonna
blow
up,
but
I
know
that
with
functions
upon
us,
we
don't
get
those
checks
and
so
I'm
just
suggesting
hey.
We
we
should
and
I
don't
think
we've
explored
this.
That's
some
missing
that
some
test
assumptions
that
we've
kind
of
offloaded
to
view
when
we
do
just
rake
the
full
view
components,
but
we
do
functional
opponents.
D
We
probably
need
to
make
sure
that
I,
wouldn't
I
would
suggest
leaning
more
towards
using
real
collaborators
rather
than
mocking
outst
or
something
so
that
we
can
just
assert
were
an
integration.
These
are
looking
for
the
right
keys
and
the
right
types
and
stuff,
but
Natalia
selling
me
on
view
3
again
so
I'm
I
can't
wait.
A
F
Is
it
too
early?
We
shouldn't
start
I,
think
4.
We
get
lab,
it's
smart
to
wait,
and
then
we
have
a
stable
release,
maybe
even
first
minor
release
after
ps3
like
3.1,
but
definitely
I
would
encourage
anyone
to
start
looking
at
v3,
but
that
is
like
it
should
be
like
next
week
out,
together
with
some
documentation
like
we
still
have
some
parts
missing,
but
when
the
better
is
released,
we're
not
rewriting
components,
but
it
would
be
really
nice
to
build
some
sorry
for
the.
B
Hope,
I
captured
your
answer.
Well
yeah.
So
that's
a
good
point
that
I
think
part
of
the
solution
here
would
still
analyzing
the
the
components
we
have,
because
some
of
them
are
really
heavy,
especially
the
default
header,
for
example,
has
a
lot
of
logic
that
could
probably
be
obstructed.
There's
some
things
that
we
have
to
plan
to
take
into
account.
B
I
know
that
we
had
some
crazy
ideas
to
statically
render
just
a
dump
of
HTML
on
a
view
component
for
the
diff
file,
while
it
hasn't
been
active,
while
it's
still
like
the
users
there
at
the
very
top
the
ones
at
the
bottom,
don't
need
to
be
rendered
per
se,
so
kind
of
like
virtual
scrolling
concepts.
One
of
the
things
we've
been
very
we've
been
very
mindful
of
is
that
users
on
the
merge
request
page
do
a
lot
of
common
F.
So
we
don't
want
to
break
that
native
search
functionality
for
usability
perspective.
B
So
if
we
do
end
up
going
with
virtual
scrolling
ideas,
we
need
to
find
a
way
for
just
like
Google
Doc
does.
If
you
want
to
try
it
on
the
Google
Doc
right
now,
like
command
F,
which
we
were
a
native,
think
now
some
users
hate
this,
but
that
the
fact
is,
if
you're,
using
virtual
scrolling
is
the
only
way
to
get
around
it.
B
So
just
to
bear
in
mind
that
if
you
want
to
pursue
something
like
that,
like
making
the
components
number,
we
need
to
somehow
replicate
the
whole
feature
set
that
we
have
are
now
showing
the
disk
content
and
be
be
interactive.
Like
have
the
discussions
place,
that
sort
of
thing,
so
it's
it's
not
as
straightforward
as
it
might
sound,
but
it
is
something
that
we're
bearing
in
mind
as
we're
moving
forward.
So
right,
let's
bear
in
mind
that
functional
that
functional
components
number
more
efficient
idea.
We
probably
will
do
a
like
an
audit
yeah
pompons.
E
B
Good
thanks
for
that
I
was
gonna,
try
to
kick-start
GDK
on
my
other
window
and
so
that
we
can
show
the
tree
of
components.
So
it
gives
somebody
some
of
you
hasn't
seen
that
recently.
But
while
that's
happening
I'll
put
that
in
the
oven
does
anyone
have
any
other
thoughts
here?
Phil.
You
probably
have
some,
but
I've
already
voiced
some
of
your
ideas.
But
do
you
have
any
comments
on
this
thing
that
we
might
have
not
have
covered
yet
nope.
A
B
We've
been
discussing
this
for
a
very
long
time,
so
a
lot
of
what
I
say:
I
just
repurpose
ideas
from
others,
looks
like
dumb-dumb
being
dumping
things
on
the
under
component
to
stuff
that's
kind
of
the
team's
exploratory
work
we
have
been
doing
so.
I.
Take
no
credit
for
that
right.
So
maybe
we
can
move
on
to
maintainability
couple
side
effects.
D
We
like
in
line
next
to
creating
an
action.
We
like
also
create
a
polar
and
stuff,
and
so
none
of
these
things
we
really
clean
up
well,
and
it
also
has
a
lot
of
complexity.
So
components
are
kind
of
just
like
fancy
state
Watchers,
so
I
strongly
suggest
taking
those
side
effects
such
as
polling
and
things
that
are
hard
to
test
and
is
putting
them
in
their
own
box
components
make
sense
to
me.
D
D
We've
run
into
a
lot
of
these
kind
of
issues
and
refactorings
and
the
justice,
but
it
also
helps
maintainability
of
a
significant
amount,
because
we've
just
abstracted
those
complexities,
so
any
kind
of
polar's
or
things
that
are
writing
to
native
Dom
or
using
something
that's
I
would
claim
as
hard
to
test.
It's
also
hard
to
maintain.
Let's
put
that
functionality
in
a
component
a
renderers
component
and
we
can
write
to
it.
D
There
and
I
included
a
link
to
an
M
R
where
we're
creating
a
local
storage
sink
component,
which
is
gonna
sink
something
in
our
Felix
state
to
local
storage
and
that's
a
problem
that
we
can
abstract
and
solve
for
everybody.
One
go
and
I
think
we
could
do
the
same
thing
for
polling
and
other
things.
I
keep
saying
polling
and
that's
cuz
I
had
some
bad
feelings
about
polling
and
testing,
but
this
is
a
maintainability
suggestion.
B
A
I,
like
that
Theon,
it
makes
sense
and
I'm
slightly
concerned
of
like
Oh.
Everything
render
a
lot
of
components
so
having
more
components.
The
guard
saw
like
initialized
and
stuff,
whether
we
do
that
after
we
fix
all
the
other
components.
I,
don't
know
well
like
moving
the
stuff
out.
The
components
make
sense.
He
saw
like
just
expand
every
time.
Everyone
just
started
forever
encoded,
and
then
that
was
it.
D
Yeah
there
is
a
downside
to
put
in
this
component,
so
I
these
Rendell's
components,
in
my
opinion,
are
really
just
like
they're
just
stayed
Watchers,
so
you
could
just
make
them
function.
You
make
him
components,
someone
could
naively
put
it
in
a
Lego
like
a
line
item
component
and
now
we're
like
syncing
to
local
storage
so
hundred
times
like
that.
It
is
a
concern
so
where
we
put,
these
render
list
components
a
big
deal,
and
maybe
we're
so
concerned
about
that
we
don't
want
them
to
be
components.
D
D
Right
so
something
like
that.
We've
kind
of
solved
in
this
hybrid
mixin
approach
and
we've
kind
of
put
as
much
of
that
in
the
mix
in
that
kind
of
key
binding.
Those
something
I
think
we
could,
let's
like
make
a
component
out
of
that
key
buying,
will
be
interesting
and
and
then
we
can
even
totally
get
rid
of
that
mixin
and
some
of
that
complexity
with
how
things
are
happening.
So
this
is
these
are
my
thoughts
recently
I,
don't
know
totally
how
they're
related
to
diffs
yeah.
D
So
it's
probably
the
cost
might
be
the
same,
because
it's
is
adding
Watchers
they'll,
add
whatever
you
give.
It's
gonna
add
Watchers
to
it,
yeah
so
yeah,
it's
something
that
you
don't
want
to
do
at
the
lower.
It's
just
a
component.
It's
something
you
don't
want
to
do
at
the
lower
level
of
your
the
ideas
for,
like
our
god,
components
that
are
doing
way
too
much.
We
can
abstract
some
of
those
side
effects
into
top
level
components.
We
don't
want
to
do
this
at
the
lower
level
and
that's
my
suggestion.
I.
C
E
Just
want
to
say,
like
I,
think
the
main
idea
behind,
like
render
less
components
in
this
case
was
also
their
thought
for
library.
Authors.
If
you
don't
want
to
let
control
what
is
like
rendered
inside
there
and
you
don't
know
or
so,
but
you
just
want
to
expose
a
bunch
of
logic,
I'm,
not
sure
if
it's
worth
in
our
case
cuz,
we
know
exactly
what
would
try
to
render.
So
it's
more
like
okay,
an
artificial
rapper
who
put
there
just
to
kind
of
hide
some
logic,
another
component,
but
yeah
that
the
cost
is
dry.
B
That's
a
great
point:
Roman
and
I'll
just
throw
this
in.
There
is,
if
you
have
to
choose
between
performance
and
maintainability,
I
believe
performance
comes
first
and
developer.
Experience
comes
second.
This
is
not
true
to
all
parts
of
github,
but
in
the
merge
request,
page
for
example,
we've
been
facing
so
many
problems.
That
seemed
a
great
idea
in
the
beginning
and
comfortable
and
I
remember
having
conversations
with
Fatih
when
he
built
the
first
version
of
the
refactor,
where
he
was
just
creating
components
for
everything.
B
One
component
for
the
road
one
component
for
the
sell
of
the
gutter,
one
component
for
the
sell
of
the
content
of
the
diff,
so
each
row
would
have
like
five
or
six
components
for
one
row,
and
this
sounded
like
a
great
idea
for
the
developer
experience
but
then
turned
out
to
be
very
costly
on
the
performance
level.
So
I
would
just
throw
that
in
there.
If
we
have
to
choose
between
the
two
performance
comes
first
developer,
experience
comes.
Second.
Anybody
objects
to
that.
D
Think
yeah
I
think
I
think
it
makes
sense.
We
need
to
prioritize
the
user
experience
it's
it's
funny
that
these
things
are
related
like
if
you
have
a
bad
developer
experience.
They're,
gonna,
you're,
gonna,
open
yourself
up
to
more
problems,
because
it's
hard
to
maintain
but
I,
think
I,
don't
think
we'll
see
a
performance
head,
yeah
we're
talking
about
adding
components
and
sounds
like
components
or
the
problem,
but
it's
not
it's
not
like.
We
have
n
number
of
components
we
can
maintain
on
a
state
or
on
a
view.
D
If,
if
components
are
the
problem
like
we
need
to
limit
the
number
of
we
can't
introduce
new
components,
then
maybe
view
isn't
something
we
should
be
using
if
they're
so
expensive.
The
problem
is
how
we're
doing
components
is
that
at
the
low
level,
we're
doing
very
logic
and
then
at
our
logic
is
spread
all
over
the
place.
So
I'd
be
a
little
concerned.
If
we
weren't
so
afraid
of
you
introducing
components
because
our
components
aren't
performance
so
now
components
are
the
problem.
D
C
This
particular
example:
it
is
kind
of
an
interesting
exception,
because
a
merge
request,
diff
can
be
so
large
components
may
not
necessarily
be
the
right
answer
here,
like
that's
what
that's
what
I
kept
coming
back
to
over
and
over
again
and
I?
Think
a
lot
of
what
prompted
this
meeting
is
just
that
overall
concept,
it's
just
doing
too
much,
and
the
only
thing
I
ever
saw
that
so
real
performance
in
improvements
was
getting
rid
of
the
components
which
was
that
static
thing
that
I
linked,
which
is
me
doing
a
lot
of
things.
C
The
hard
way
that
view
gives
you
for
free,
because,
when
like
Andre
alluded
to
when
I
first
came
into
that
problem,
it
emerges
was
built
like
almost
textbook
perfectly.
As
far
as
the
component
structure
was
like
the
view,
Docs
tell
you
to
do
and
nine
times
out
of
ten.
That's
the
right
way
to
do
it,
but
in
this
particular
case,
where
I
happen
to
have
a
hundred
thousand
lines
of
code
that
we're
trying
to
shove
onto
a
screen,
it
wasn't
so
I.
C
D
And
I
think
it's
a
really
good
point
is
yeah.
It's
not
like
components
are
like
everything
has
to
be
wrapped
in
its
own
component.
I
agree
with
that
too
I
just
don't
want
us
to
be
so
afraid
of
fusing
components.
Now
that
would
be
that
would
open
up
another
world
of
problems,
so
I
think
I
think
whatever
we
doing
as
long
as
we're
intentional
sounds
like
it
and
it
sounds
like
we
are.
We
wouldn't
be
having
this
meeting
if
you
weren't
intentional
back
yeah.
B
So,
for
the
sake
of
time
and
I'm,
sorry
for
interrupting
potentially
in
fight
ideas,
so
I
think
there's
still
a
lot
to
discuss
here.
I'm
gonna
take
the
liberty
of
scheduling
another
the
same
slot
next
week
for
us
to
continue
this
discussion.
Until
then,
I
would
ask
if
you
have
any
insight
ideas
that
you
haven't
captured
just
dump
them
on
the
documents
today,
right
after
this
call,
if
you
can
and
jump
on
the
epic,
if
you
have
any
other
thoughts,
I
just
want
to
show
you
here,
like
the
current
state
of.
B
If
you
haven't
seen
this
in
the
recent
months
or
whatever,
this
is
kind
of
like
the
structure.
It
sounds
simple
like
if
you
open
header,
it
starts
to
getting
a
little
bit
more
complicated
and
a
lot
of
components
that
we
were
using
for
just
UI
stuff.
That
is
coming
from
good
lab
UI.
But
the
problem
is
then,
when
you
multiply
this
by
500
files,
the
whenever
something
moves,
just
the
the
profiling
goes
crazy,
trying
to
tear
it
down
and
stuff.
So
with
that,
does
anybody
have
any
more
comments?
Oh
Justin,
that
your.
C
Last
comment:
nother
thing
you
showed
is
that
most
of
that
is
static.
Content
like
we
have
a
ton
of
there's
a
lot
of
Watchers
and
computed
values
over
there
and
almost
everything
you're.
Seeing
there
is
static
content.
It
doesn't
change
once
we
get
the
data
from
the
database,
so
there's
lots
of
room
for
improvement
in
there.
So.
B
It
doesn't
change
the
data
from
from
the
database,
but
the
the
state
will
change
with
direction
of
the
user
yeah
the
header
right
right,
not
on
the
header
right,
that's
a
good
point.
Okay,
does
anybody
have
any
last-minute
thoughts
that
they
want
to
share
with
with
everyone
before
we
go
and
I
can't?
Thank
you
enough.
For
this
call,
it's
been
extremely
useful.
Does
anybody
have
any
other
thoughts
before
you
go?
My.
D
Last
thought
is
I'm
blown
away
at
the
iterative
split,
divs
and
batch
gives
those
huge
efforts
of
his
work
to
improve
the
performance.
This
is
an
is
a
gnarly
piece
of
code,
but
these
did
make
a
significant
difference
and
that's
a
lot
of
that's
really
great
work
and
I
know
that
it
was
a.
It
was
a
wrestle
getting
them
enabled
by
default.
But
it's
cool
to
see
this
iteratively
work
time.
B
Thanks
fall,
the
team
has
been
putting
a
bunch
of
effort
and
and
I
take
the
word
for
them
and
thanks
from
everyone
of
them,
so
we're
at
time
so
I'm
moving
this
to
a
section
at
the
top
of
the
document.
The
ones
I
didn't
make
it.
So
we
can
start
off
with
those
next
week.
Please
participate
as
synchronously.
If
you
have
any
ideas,
jump
dump
them
on
our
channel.
G
create
source
code,
Fe
I'll
put
here
at
the
top,
and
apart
from
that
I'll
just
again
write
I'll
write
it
later.
B
I'll
just
stop
sharing
the
screen
and
facing
you
all
I'll
just
like
to
thank
you
every
much
for
the
participation.
It's
been
amazing.
Getting
feedback
from
everyone,
not
just
from
within
the
team
but
also
outside
I,
think
we're
gonna.
Do
this
more
and
more,
but
next
week,
I'm
gonna,
just
repeat
the
event
for
for
next
week
and
then,
if
we
just
can't
make
it
for
that
time,
slot,
let
me
know,
and
we
could
try
to
work
something
out
until
then
have
a
great
week.
I'll
see
you
on
another
call
and
thanks
everyone.