►
From YouTube: 2023-08-29 Code Review: Diffs SSR Discussion
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
Yeah
thanks
everyone
for
coming
to
this.
This
discussion
event
today,
I
think
we'll
start
with
a
little
presentation
by
me:
I'll
explain
the
ideas
behind
the
GIFs
that
I
have
and
then
we
can
discuss
them.
B
So
the
future
of
this
app
yeah,
big,
Banks
and
stuff,
like
that
so
I'll
start
right
away
with
pointing
out
our
current
problems
with
virtual
scrolling
I.
Think
I'll
hide
this
window
because
passes
up.
B
So
our
common
problems
with
social
scrolling
is
Ctrl
f,
basically
causes
the
whole
app
to
be
rendered
from
scratch
and
on
large
tubes.
It
can
take
seconds,
especially
if
you're,
on
a
low
power
device
and
also,
as
you
might
know
recently,
we've
had
bugs
with
scrolling
again
so.
B
Been
like
a
repetitive
theme,
with
virtual
scrolling
that
each
time
we
try
to
adjust
something
in
in
that
regard,
something
is
already
broken,
and
that
has
a
big
problem
because
we
are
not
100
sure
if
everything
works
as
expected,
and
we
have
all
the
feature,
tests
and
unit
tests
for
that.
But
we
still
can't
catch
all
of
the
bugs
and
they
continue
to
reappear.
B
A
A
B
Yes,
let
me
explain
that
a
bit
sorry
for
the
animation,
rendering
means
that
we
have
to
calculate
the
file
size.
So
when
we
render
these
divs,
we
don't
know
exactly
the
height
of
which
the
file
in
order
to
understand
what
the
height
is,
you
have
to
basically
place
it
somewhere
in
the.
C
B
C
B
Just
making
it
more
sparsed
out
in
time
not
doing
it
synchronously
right
right
away
thanks.
C
A
Exactly
it's
an
imperfect
solution,
I
think
we're
all
we're
all
in
agree
with
that.
That
was
a
temporary
solution
and
should
look
further,
so
yeah
go
ahead.
A
B
This
SSL
versus
virtual
scrolling
on
steroids
and
I'll
explain
a
little
bit
what
I
mean
by
two
of
these
terms.
So
SSR
is
something
that
we
used
to
do
previously
and
it.
B
Reals
apps
usually
do
it.
You
will
have
very
long
page
loads,
and
the
reason
for
that
is
that
if
you
start
server-side
rendering
everything
you're,
basically
tying
your
page
load
time
to
the
amount
of
files
you
have
to
show
to
the
client
so
for
match.
Request
with
like
500
changed
files.
It
will
take
like
a
lot
of
time
to
see
any
anything.
B
Anything
on
the
page,
and
the
second
problem
here
is
that
even
if
we
rendered
most
of
the
page
on
the
rail
side,
the
user
will
not
see
anything
until
the
whole
page
is
rendered,
which
is
a
problem
because,
usually
you
don't
care
about
the
last
like
50
files
in
the
div.
You
want
to
start
reading
code
right
away
or
start
reading
discussions,
and
you
can
do
that
because
it's
not
rendered
yet
and
also
an
opio's
downside.
It's
slower
than
virtual
scrolling.
B
You
have
to
render
everything
on
the
client
as
usual
and
I
mean
like
printing
HTML,
not
not
so
rendering
it
using
JavaScript.
You
still
have
to
do
the
rendering
phases
with
layout
with
wristband.
B
So
that's
an
obvious
downside
and
there
is
also
what
I
call
Advanced
visual
scrolling,
which
is
something
GitHub
uses
and
they
shared
it
with
blog
post,
so
how
it
works
is
really
similar
to
usual
virtual
scrolling.
B
But
the
main
limitation
here
is
that
it
doesn't
work
with
Dynamic
Heights,
for
example,
with
divs,
because
with
this
you
usually
wrap
the
lines
and
if
they
reach
the
end
of
the
viewport,
they
start
wrapping
to
the
next
line,
and
you
can't
can't
know
this
in
advance.
Unfortunately,
so
this
text
area
hack,
won't,
won't
work
for
us
and
also
imagine
having
discussions
on
top
of
these
div
files.
So
you
would
have
to
consider
discussions
height
in
the
textury
as
well,
which
is
also
problematic
and,
of
course,
it's
very
complex
to
maintain
and
Implement.
B
There
is
no
open
source
solution.
Right
now,
to
let's
say
proposed
is
their
own
internal,
like
code,
that
we
we
can't
really
use,
unfortunately,
so
considering
all
of
that
I
think
we
should
probably
stick
with
divs
with
server-side
rendering
and
get
back
to
the
server
side.
C
B
Try
to
explain
here
how
they
are
going
to
help
in
fixing
basically
server-side
rendering
approach,
SSR
and
AD
streaming.
There
then
we'll
explain
web
components,
a
classification
can't.
Last
but
not
least,
a
very
important
technology
here
is
Russian
tool,
content
visibility.
C
B
Use
web
components
to
do
the
enhancement
part,
so
they
will
be
our
main
glue
layer
between
our
current
View,
apps
and
static
views,
and
also
web
components
can
handle
some
UI
logic
sets.
For
example,
we
don't
want
to
move
to
view,
for
example
like
collapsing
files
that
can
be
handled
by
web
components
as
well.
B
B
B
B
Real
support
supports
fragment
caching,
so
we
can
actually
combine
the
cached
HTML
and
our
Dynamic
data
that
we
have
from
backend.
So
it
will
it
should.
It
should
work
out
of
the
box,
and
the
last
component
here
is
Russian
doll,
content
visibility,
so
I've
told
you
about
the
rendering
step
that
is
really
really
expensive
and
it
gets
more
expensive
when
you
add
more
content
to
the
page.
So
if
you
have
200
files,
it
is
200
times
more
expensive
to
add
new
content.
B
B
And
inside
the
files
it
hides
multiple
lines.
So
if
your
file
has,
for
example,
500
lines
changed,
it
will
still
work
because
it
will
split
them
in
in
smaller
groups,
and
you
won't
have
to
render
a
very
large
file
in
the
viewport.
So
this
would
allow
us
to
technically
support
any
kind
of
merger
quests
that
have
lots
of
small
files
or
have
not.
A
No
I'm
just
saying
because
the
I
article
this
ship
is
forming
in
in
my
head.
Go
ahead.
B
So
this
is
how
it
looks
when
you
load,
the
page
looks
like
a
regular
juice
page,
except
for
the
design
is
kind
of
weird,
but
it's
fully
functional
web
page.
You
can
actually
start
working
here.
You
can
click
on
online
to
start
commenting
and
also
clicking
inside
part.
Just
works.
It's
using
regular,
like
hashlings
and.
B
When
it
rolls
the
page
so
when
we
first
load
the
page
of
obviously
not
everything
is
loaded,
but
you
can
see
stuff
in
the
set
bar
is
grayed
out,
so
you
can
actually
track
the
stuff
that
is
not
loaded
yet,
and
it's
not
clickable,
and
once
it's
loaded
it
will
be
with
regular
opacity
and
you
can
work
with
it.
So
that's
how
it
works,
and
once
it's
loaded
you
can
see
there
are
no
programs
with
scrolling,
no
problems
with
selecting
text.
I.
A
B
Yes,
I
see
that
too,
but
for
me
it's
it's
like
one
or
two
frames
of
of
flashing.
Okay.
A
No,
it's
definitely
if
we
break,
if
you
put
into
the
perspective
that
the
content
is
there,
it's
just
the
browser
catching
up,
I
think
that's
definitely
better
than
the
virtual
scrolling
and
all
the
work
they
were
doing
to
catch
up
with
what
we
need
to
re-render
and
everything.
B
A
B
It's
content,
visibility,
trying
to
render
the
file
and
because
we
have
a
lot
of
files
it
takes
like
one
or
two
frames.
So
if
you
are
not
scrolling
too
fast,
it
works.
Okay
and
also
no
issue
when
I,
for
example,
click
on
the
file
and
sell
bar,
you
don't
see
a
flash
for
another.
Second,
for
example,
it's.
B
So,
okay,
so
that.
B
A
B
B
Also,
these
are
shown
immediately
after
load.
I,
don't
know
if
you
noticed,
but
as
soon
as
the
page
loaded,
you
could
already
start
reading
code,
which
is
quite
impressive
and
no
more
scrolling
issues.
You
can
scroll
whatever
you
want,
you
can
click
on
sidebar,
it
just
works,
and
the
good
thing
is
that
big
portions
of
code
could
be
used.
So
I've
shown
you
discussions
there,
the
already
existing
discussions
and
I
think
you
discussion.
That
is
actually
using
view
code.
I
didn't
write
a
new
app
just
for
that.
B
A
B
B
A
A
B
Say
yes,
I
I
tried
to
launch
it
without
content
visibility
in
Chrome
it
can
work.
The
problem
is
that
you
are
basically
blocking
my
infrared
for
too
long.
It
can
take
like
10
seconds
and
for
this
10
seconds
you
won't
be
able
to
track
this
page.
B
B
A
B
We
have
no
native
support
for
streaming
and
rails,
which
I'm
using
on
this
demo,
so
I
sort
of
hacked
it
to
support
streaming
by
using
paginated
responses,
which
is
something
we
also
do
right
now
we
split
the
tips
in
patches
in
larger
chunks
and
it
sort
of
works
with
streaming,
but
it's
not
as
native
as
you
would
like
to
be
so
set
is
basically
it.
That
is
a
whole
presentation,
so
we
can
join
for
a
broader
discussion.
A
So
the
biggest
question
for
me
when
you
say
loaded
and
unloaded
with
the
visibility
thing
that
takes
care
of
the
weight
on
the
browser
side
of
performance,
but
in
terms
of
like
memory
usage,
it's
like
we're,
leaving
in
terms
of
like
the
loading,
the
data,
all
of
that
into
the
front-end
like
application.
That
is
still
happening,
and
it's
incrementing
as
the
page
loads
itself.
Did
you.
B
B
Virtual
scoring
solution,
basically
because
I
I
have
the
POC
that
supports
both
virtual
scrolling
and
subset,
rendering
yeah.
B
B
A
Have
yeah
quick
measures
just
a
quick
check,
yep
yeah
we've
seen
seen
some
memos
in
back
in
the
old
days
reach
out
a
gigabyte
before
we
did
all
the
bunch
of
improvements,
one
of
them
yeah
the
virtual
scrolling.
So
we
already
like
this.
It's
like
a
fork
in
the
path
like
one
optimization
for
memories,
which
is
the
virtual
scrolling.
The
other
is
not
doing
the
virtual
spoiling
doing
something
else,
but
yeah.
So
we
understand
that
Phil.
Do
you
have
any
questions
any
thoughts,
any
things
you
wanna.
C
I
think
it
makes
sense
I
think
we
kind
of
hit
a
limit
with
you,
but
it's
always
kind
of
awesome,
because
you're
still
torn
on
it
like
after
this
one
makes
sense
but
get
lab
is
a
completely
investors
in
The
View
yeah.
It's
like
how
can
we
go
kind
of
like
split
in
the
fork
and
do
our
way,
plus
the
company
or
go,
and
this
way
and
I
guess
that
this
still
uses
view
like
the
discussions
and
stuff.
But
it's
like
kind
of
seems
like
with
this.
For
makes
sense.
C
C
So
that's
all
kind
of
scared
me.
It
makes
sense,
but
that
is
a
complain
like
what
we
do
view
for
everything.
So
does
that
one
thing
for
you
stars
out
on
the
POC
face
discussion
is
sets
up
a
view,
app
very
magical,
sweat.
A
lot
of
discussions
is
that
gonna,
eventually
kind
of
whack
the
memory
usage
up
of
the
page,
a
lot
more.
B
A
B
We
can
basically
skip
everything
outside
of
your
board
depends
how
we
approach
it.
C
C
C
Yeah
my
concern
is:
how
easy
is
it
for
them
to
then
add
into
it?
Without
always,
talent,
I
mean
we
should
gatekeep
it
anyway
and
that's
kind
of
the
problem.
We
end
up
with
the
magical
widget,
for
example,
but
I
just
curious
about
the
actual
developer
experience
of
working
with
it
and
adds
new
features
to
it.
B
Yeah
developer
experience
is
definitely
going
to
suffer.
I,
don't
know
how
much,
but
since
we
are
not
inside
of
your
ecosystem
anymore,
yes,
you'll
have
to
dig
a
little
bit
deeper
to
understand
how
the
view
app
connects
to
the
diff
itself,
what
it
can
do
it.
What
and
what
it
can
do,
because
you
can't
mess
up
City
file
and
just
leave
it.
B
Probably
if
you
want
to
add
new
functions
to
the
existing
connected
apps
like
if
you
want
to
add
something
to
discussions,
it's
not
a
problem
and
unless
you
want
to
add
something
new
that
is
not
has
been
integrated,
it's
a
static,
div
yeah,
it's
it's
going
to
be
a
little
bit
more
challenging.
I
would
say.
C
C
My
concern
is
that
doesn't
always
happen
and
it's
sometimes
things
that
should
come
through
once
don't
come
through
us
and
have
we
considered
just
go
and
crazy
if
we're
going
this
the
fork
in
the
roads
and
saying
we're
not
doing
View
left
on
the
client,
we
go
all
crazy
and
just
say
no
View
at
all,
and
we
just
do
every
single
thing
in
web
components.
B
B
A
C
A
C
C
Makes
it
slow?
What
I'm
saying
is
that
if
the
developer
experience
here
so
before
I
understand,
the
proof
of
concept
is
through
discussions,
we
had
set
up
a
new
view
act
for
every
discussion
that
exists
on
the
div.
What
if
we
just
had
a
web
component
that
just
get
to
put
on
the
page
and
the
web
can
kind
of
handles
all
the
rendering
would
that
get
rid
of
the
views?
Overhead
side
of
things
yeah.
B
B
C
A
C
The
problem
there,
though,
with
a
lot
of
developers
knowing
view
is
then
we
then
add
this
new
way
of
doing
the
SSR,
and
then
we
attach
new
components
on
the
flight.
It
kind
of
doesn't
feel
fair
if
you
like
so
I,
think
if
we're
gonna
go
I'd
say
well,
it's
going
to
go
crazy.
We
go
the
full
crazy
way
should
be
faster
and
to
be
fair,
like
a
lot
of
the
discussions,
none
of
it's
really
Dynamic
data
it
like
get
renders
once
and
then
the
chances
of
being
updated
like
relatively
Slim.
A
I
want
to
introduce
a
little
context
here,
because
these
Explorations
from
stanislav
we're
trying
to
get
the
current
the
current
merge
request,
page
layout
and
content
to
fit
and
to
take
it
to
the
next
level.
But,
for
example,
we've
had
discussions
in
the
past
where
the
discussions
would
not
be
interspaced
with
diff
clients.
They
will
be
showing
on
the
side
as
the
sidebar,
which
removes
a
bunch
of
like
hurdles
in
terms
of
like
Dynamic
Heights
and
all
that
stuff.
A
Although
you
still
have
the
wrapping
lines,
but
there's
a
couple
of
things
that
can
be
alleviated
by
that,
but
the
the
point
of
Phil
of
going
a
little
bit
crazier.
It's
not
out
of
the
question,
so
we
I
think
that's
going
to
be
clear.
Once
we
start
discussions
about
the
architecture,
design
workflow,
because
the
the
trying
to
I'm
trying
to
organize
my
words
the
way
that
we
are
envisioning.
The
app
today
is
one
thing,
but
we
do
want
a
drastic
improvement
instead
of
being
like.
A
Maybe
maybe
that
that
Mr
isn't
exactly
the
best
example,
because
it's
difference
between
160
and
100
I
know
that
it's
like
roughly
measured.
That's
fine.
But
what
I
expect?
What
I
think
we
should
strive
for
is
regardless
the
size
of
VMR,
the
performance
doesn't
suffer
or
or
at
least
we
are
able
to
talk
about
thousands
of
files.
On
the
page
easily
we
thought
of
sweat.
A
We
thought
we
thought
the
browser
catching
up,
but
that's
the
thing
that
that
that
is
kind
of
like
in
the
back
of
my
mind
is
the
trick
that
I
saw
in
Thomas's
app
was
that
he
didn't
break
per
line.
So
just
got
the
blob
of
the
diff
of
the
patch
whatever
and
put
that
in
the
content
in
a
con
in
the
container
it
didn't
iterate
over
each
line.
It
was
just
like
straightforward
inner
HTML
dunk
it
there
right.
A
That
could
be
the
first
step
of
this
like
approach
where
for
the
command,
F
search
thing,
but
then
at
a
certain
point
it
needs
to
be
restructured
into
a
an
actual
diff
that
we
can
interact
with,
because
for
now
going
from
the
text
area
that
it's
invisible
to
something
that
it's
like
full-on,
editable
or
just
selectable
and
played
around
with
there's
a
whole
difference
in
layout
until
visibility.
A
But
maybe
we
can
do
a
little
bit
better
on
on,
like
which
moment
it
is
that
we
Define
that
we
decide
to
start
in
enhancing
the
content
that
it's
there
I
don't
know
where
was
I
going
with
this
I
don't
know.
B
Like
there
are
still
links
to
the
to
what
browser
can
handle,
because
there
is
no
Universal
solutions
that
can
handle
ten
thousands
of
changes
divs
on
one
page
and
the
browser
doesn't
crash,
I,
don't
think
there's
this
solution.
Yet,
unless
you
go
like
full
canvas,
you
fully
Implement
your
search
and
start
basically
Reinventing
browser
inside
your
app.
B
A
B
A
That's
a
good
point,
and
yes,
there
is
that
that
brings
the
topic
of
you,
know
future
parity
and
how
important
it
is
and
and
I
think
that
also
speaks
a
bit
about
the
strategy
that
we
see
this,
because
there's
one
way
of
seeing
these
as
a
replacement
straight
straight
up
as
a
replacement
for
the
queer
Mrs.
A
We
could
also
entertain
the
idea
of
having
a
like
a
sidekick,
a
lighter
version
of
Mrs.
The
the
bigger
question.
If
you
go
in
that
route,
is
what
happens
to
the
current
one
and
are
we
ever
going
to
achieve
parity
in
the
next
I?
Don't
know
six
months
like
between
those
two
things,
and
then
it
gets
to
a
point
that
it
crosses
over
and
starts
having
more
features,
because
it
is
there's
so
many
things
on
about
the
Mrs
that
not
reusing
the
code
makes
me
nervous.
A
So
if
we
don't
reuse
the
code
of
the
markdown
editor,
for
example,
that's
problematic,
because
one
will
expect
that
experience
when
they're
leaving
a
comment-
and
we
never
we're-
definitely
going
to
need
to
support
that
at
that
level
to
have
something
convincing
for
the
user,
because
otherwise
you'll
be
just
like
the
one
by
five
by
file,
which
is
it's
a
great
alternative
for
people
to
see
really
large
Mrs,
not
everybody
likes
it.
Even
less
people
use
it.
A
So
we
need
to
start.
We
definitely
want
to
aim
to
improve
the
default
experience
of
the
Mrs.
That's
that's!
That's
the
goal,
the
target
kind
of
thing,
but
a
lot
of
these
approaches.
For
me,
it
shows
a
bit
of
like
the
content,
visibility.
Russian
doll
approach
definitely
is
interesting
from
the
perspective
of
like
unloading,
the
browser
from
taking
care
of
work,
that's
not
being
visible.
A
A
C
A
Okay,
that's
where
I
think
we
need
to
start
like
thinking
exactly
what
are
we
caching
so
we're
caching,
the
output
of
a
Hamel
template
being
rendered?
Is
it
a
Hamel
template?
Yes,
okay,
which
you
can
live
with?
We
can
live
with
some
repetition
and
having
to
do
that,
template
twice!
That's!
Okay,
because
again
we
wouldn't
do
it
as
an
ideal.
But
if
you
drive
the
performance
like
a
Quantum,
Leap
Forward,
then
for
sure
it's
understandable
to
repeat
ourselves
a
little
bit
on
those
static
bits
which
you
said
very
well
in
the
presentation.
A
We
need
to
separate,
what's
static
and
what's
Dynamic
and
because
the
way
I
see
it
like
if
I
had
to
close
my
eyes
and
imagine
something
that
would
be
really
quick
to
render
it's
aesthetic
Parts
the
static
parts
of
the
diffs.
It's
really
fast
in
terms
of
like
we
don't
have
any
direction.
We
don't
have
anything
to
you
know
to
add
listeners
to
it's
just
like
boom
just
render
that
a
table
so
to
speak.
It
isn't
the
table,
but
you
know
what
I
mean
and
then
becomes
the
point
of.
When
do
they
make
them?
A
When
do
we
make
them
alive,
when
do
we
grab
the
thing
that
the
server
side
gave
us
and
sprinkle
the
fairy
dust
and
make
them
alive?
That's
the
part
that
it's
a
little
bit
heavier
to
pull,
but
it
also
depends
on
the
UI
that
is
interactable
with
could
already
be
there.
A
We
just
make
it
alive
once
the
user
interacts
with
it,
which
makes
it
far
less
heavy
for
the
browser,
because
you
only
enhancing
the
things
you
actually
need
to
grab
with
things
get
a
bit
thicker
once
we
start
talking
about
the
data
so
because
of
these
interactions,
like
the
hovers
the,
how
does
this
react
to
something
clicking?
On
the
other
side?
Like
you,
you
click
view.
How
do
we
update
the
tree?
There's
a
couple
of
like
hidden
questions
there
that
we
might
need
to
like
explore.
I
would
say.
A
But
correct
me
if
I'm
wrong,
when
you
say
streaming
status,
live
setting
up
like
responses
in
parallel.
Are
you
passing
Jason,
or
are
you
passing
a
rendered
HTML
from
a
hammer
file
as
well.
B
B
And
while
we're
searching
I
also
mentioned
I've
tried
native
real
streaming
because
you
might
be
surprised,
rails
actually
supports
streaming
responses
and
it's
insane
as
low,
so
I
think
they're,
probably
running
a
query
for
each
element
in
the
loop
so
for
each
divs
there
are
still
facing
calls
the
divs
to
include
the
work
and
it's
insanely
slow.
So
it
didn't
work
for
me.
A
A
C
Yeah
I
think
I've
got
like
so
many
questions,
but
the
kind
of
questions
the
combat
is
right
now,
I,
don't
know
how
to
do
it
data,
so
there
isn't
really
an
answer
to
it.
So
that's
all
that's
going
through
my
it's
like
suggestions.
How
will
suggestions
work
on
the
viewpower
if
we
don't
have
the
like
the
discs
or
so
faction,
the
Json
stuff,
there's
like
questions
around
that
that
I,
don't
think,
could
be
answered
right
now,
but
it's
like
before
we'd
even
consider
rolling
it
out
at
all.
C
It's
these
type
of
questions
that
need
to
be
answered,
and
then
we
get
into
the
point
of.
Is
it
worth
it
like
right
now,
where
it's
just
rendering
the
diffs
and
discussions
in
it
works?
It's
fast.
It's
fine!
It's
then,
when
you
start
to
add
all
the
little
features
on
top
that
we've
accumulated
over
the
years.
That's
when
I'm
concerned
that
we
then
start
to
go
back
to
our
old
performance
or
the
current
performance
at
least
we're
just
with
that.
Like
overhead
of
to
it.
B
I
have
the
same
concern
like
it's
it's
fast,
because
it
doesn't
have
a
lot
of
features,
but
this
is
really
true,
but
what
it
gives
us
is
an
option
how
we
work
around
these
features
if
a
feature
is
not
immediately
necessary
right
now,
if
we
don't
see,
for
example,
a
div
file,
and
it
has
like
an
expansion
button,
we
don't
immediately
want
to
initialize
the
logic
force
that
button
we
can
wait.
We
can
use,
for
example,
event,
dedication
as
I've
used
in
the
in
this
demo
already.
B
A
A
View
components
where
they're
repeating
a
lot
of
this
logic,
error
component
components
will
get
significantly
lighter,
but
that
Improvement
could
be
done
separately
without
from
all
the
things
I
mean
you
could
live
on,
install
as
an
improvement.
B
I,
don't
think
that
can
can
live
on
its
own,
because
it's
all
view
view
paste.
You
basically
click
on
the
button.
You
fire
up
event,
yeah
and
csc's
approach
definitely
needs
you
to
reconsider
how
you
how
you
build
features
in
the
code.
Definitely-
and
the
most
important
thing
is
how
you
attach
logic
to
your
user
interface.
The.
A
Question
Styles
is
this
like
if
we
can
find
a
way
that,
instead
of
having
the
view
app,
The
View
component
be
tied
to
the
behavior,
and
we
make
all
of
those
view
components
in
view
component
threads,
so
to
speak,
if
the,
if
they
all
stop
doing
what
they're
doing
and
all
they
do
is
trigger
something
that
is
caught
by
the
delegated
event
handler
at
the
root.
A
All
of
these
features
that
are
going
into
the
air
to
the
component
tree
gets
lighter
again
some
of
the
things
we
won't
be
able
to
tweak
too
much
because
they're
reusable
like
the
markdown
editor.
Okay.
A
If
we
can
get
it
all
around
all
the
buttons
of
Mr
actions
or
diff
sections,
you
can
remove
all
of
that
and
make
or
just
update
that
approach.
We
would
definitely
have
an
impact.
The
question
remains
by
how
much
what
I'm,
starting
to
entertain
a
little
bit
more
is
what
are
the
layout
changes
we
could
introduce
to
support
the
performance
work,
the
performance
hunt
if
there
are
things
that
we
can
do
in
the
layout,
that
change
it
not
for
the
performance,
but
for
experience
of
the
user,
but
that
benefit
is
the
performance.
A
Then
we
can
definitely
consider
it.
One
of
them
was
putting
this
the
comments
on
the
sidebar
like.
Should
we
work
on
putting
the
comments
on
the
sidebar
and
moving
that
from
the
stream
of
diffs
that's
being
rendered,
and
every
time
you,
you
know
as
you're
scoring
the
diffs
having
a
bit
more
interactable
experience,
interaction,
interacting
yeah,
where
you're
scrolling,
the
diffs,
but
on
the
on
the
other
side,
you're
getting
the
comments.
A
B
A
No,
that's
fair.
That's
fair!
That's
definitely
fair.
So
the
takeaways
from
this
meeting
from
this
demo
is
that
this
approach
is
possible.
A
I
think
the
biggest
hurdle
for
me
from
like
just
a
pulse
check
is
like
that
content.
Visibility.
Bug
is
kind
of
like
a
deal
breaker.
If
you
want
to
ship
this
to
like
the
wider
audience
of
the
Mars,
do
you
agree
absolutely.
C
A
The
other
things
that
I
come
out
of
this
discussion
is
how
much
can
we
rely
on
back-end
caching
and
we
still
have
I
think
that's
a
question
for
different
meeting,
but
in
the
example
of
gitlab
or
gitlab,
for
example,
the
the
the
comparison
between
the
branches
are
always
happening
right.
A
A
A
B
I
think
we
already
have
some
caching,
it's
just
one
quite
different
level.
It's
it's
caching,
some
data
structures
on
the
backend
side.
It's
not
caching
the
response,
but
we
have
HTTP
header
support
for
caching.
So
if
you
already
loaded
system,
it
won't
be
loaded,
anymore
and
I.
Think
with
caching.
We
have
to
be.
B
A
little
later
onset
approach,
so
I
don't
think
we
should
be
caching
a
lot
of
stuff.
We
should
catch
just
the
latest
div
if
you're,
comparing
the
latest,
commit
against
Master
branch,
and
we
also
shouldn't
be
getting
smaller
Mars
like
a
Mars
that
take
up
10
files
or
or
not.
We
shouldn't
measure
that
in
files,
but
in
lines
like
if
it's
it
has
100
lines
changed,
we
shouldn't
care
set,
it's
just
wasting
wasting
resources,
not
giving
us
any
benefits,
but
for
the
larger
marks
it
should
definitely
make
a
difference.
B
Okay,
okay
and
for
like
Branch
comparison,
I.
Think
if
you
are
willing
to
compare
a
specific
commit
to
Target
branch,
I,
think
it's
okay
for
you
to
wait
a
little
bit
longer
to
see
the
results,
because
it's
not
something
that
usually
happens
in
the
measure
Quest.
What
do
you
mean
comparing
like
switching
the
active
branch?
A
Sure
no,
what
I
mean
by
that
is
like
the
the
Mr
currently
is
compared
between
you
know
the
source
branch
and
the
target
Branch
at
the
head,
like
the
latest,
commits
awesome,
which
means
like
every
time.
Somebody
changes
the
target
Branch
like
the
main
branch
or
feature
whatever
the
commits
being
compared
they're
different
they're,
different
hashes
right,
but
the.
C
A
Of
it
should
be
the
same
if
nothing
else
was
changed
in
those
files,
and
that's
that's
interesting,
because
that's
a
backend
mechanics
that
we
need
to
review
and
to
make
sure
that
we're
able
to
and
I
think
that's
what
I
heard
is
that
the
patchetti
will
help
us
get
that
that
mechanic,
but
I
feel
like
that's
that
plus
caching.
A
The
first
page
of
the
of
the
merge
request,
if
rendered
HTML
into
the
store,
definitely
needs
validation
and
validation
of
the
perspective
of
what
how
many
gigabytes
would
that
mean
in
any
normal
day
of
increase
for
redis?
Is.
A
In
for
infrastructure
and
the
awareness,
whether
this
is
infeasible
or
not,
but
for
us
to
go
there,
we
also
need
to
be
able
to
quantify
how
quick,
because
again
like
Phil
was
saying,
we
cannot
forget
the
feasibility
of
this
and
also
the
value
that
this
brings.
It
could
be
really
clever
Improvement
than
the
forward
getting
is
like
a
five
percent
Improvement,
but
at
the
end
of
the
day
it
won't
be
worth
it
all.
The
effort
that
we
put
into
that
it's.
B
So
it's
hard
to
measure
right
now.
The
the
question
you're
raising
is
I,
don't
know
how
to
compare
right,
our
current
approach
and
gives
SSR
because
research
for
scrolling
it's
it's
different
experience
like
we
don't
have
fully
calculated
sidebar
height
and
it's
faster,
but
it's
a
different
experience
and
if
you
start
comparing
it
by
numbers,
of
course,
the
virtual
scrolling
will
win
because
it
just
does
less
less
work
on
the
client.
B
B
A
Yeah
I
think
we
need
to
detail
what
that
is.
What
goals
are
we
talking
about?
Which
metrics
do
we
care
about
which
metrics
do
we
not
care
about
because,
for
example,
TBT
could
be
horrible?
Tbt
could
also
be
not
bad,
impacting
The
Experience.
What
I
mean
by
that
is
like
they're,
not
the
starting.
The
the
finish
of
the
story
and
yeah
I
think
we'll
we'll
get
we'll
join
together
and
like
document.
A
lot
of
this
goals
like
performance
is
a
key
factor
for
us.
How
do
we
quantify
it?
A
How
do
we
quantify
in
terms
of
like
how
quick
things
appear
on
the
page?
How
important
that
is,
but
also
how
important
it
is
to
scroll
through
the
page
and
see
the
diffs,
and
also
how
quick
does
a
comment
box
show
up
after
I
click
it
like
those
are
all
perceived
performance
parameters
that
we
should
quantify,
potentially
even
tests.
A
If
we
have
yeah
I
think
we
have
tools
for
that,
whether
it's
there's
a
timing
API,
whether
it's
user
Journey
dashboards,
that
we
have,
we
can
definitely
definitely
start
tracking
those
things
and
use
those
as
parameters
for
our
improvements.
A
I'm
trying
to
think
what
else
we
need
to
talk
about
today,
because
right
now,
the
goal
of
this
is
like
the
demo,
what
we
have
currently
in
there.
We
don't
have
any
particular
so
the
path
for
getting
you
know
what
happens
to
this
experiment.
Now,
it's
not
clear.
A
We
need
to
kind
of
like
Get
Like,
digest
this
a
little
bit
and
then
eventually
discuss
this
a
bit
more
potentially
talk
between
ourselves
and
maybe
in
an
issue,
so
that'll
probably
be
the
next
step.
Status.
Live,
have
an
issue
for
discussing
this.
A
If
you
already
have
one,
we
could
just
choose
the
one
that
you've
been
assigned
to
and
we're
going
to
have
a
discussion
there
or
we
could
an
epic
because
I'm
not
convinced,
yet
that
we
need
to
start
this
in
the
next
Milestone
right
away,
like
Full
Speed
Ahead,
especially
with
the
conversations
ahead.
However,
this
can
inform
those
conversations
ahead.
Okay
is.
B
A
Okay,
so
let's
let's
get
an
issue
and
put
it
in
the
agenda
pick
it
pick
an
issue
or
just
open
a
new
issue
like
for
feedback
on
this
demo
and
just
put
the
links
for
anybody
can
participate
so
that
other
people
in
front
of
them
might
want
to
take
a
weigh
in,
and
we
can
share
this
video
with
them
and
then
we'll
will
will
learn
from
that
and
that
will
inform
our
decisions
going
forward.
C
C
A
C
C
C
We've
got
to
this
point:
should.
A
We
play
around
with
it
more
like
check
out
the
branch
play
around
a
little
bit
more
with
it.
Do
some
testing
and
and
share
the
thoughts
there
on
the
issue
that
he'll
that
he'll
create.
That
could
be
the
ask:
yep:
okay,
okay,
stats,
gonna,
prepare
the
issue
and
share
it
in
the
slack
Channel
yeah.
A
I'll
leave
it
up
to
you.
Feedback
issues
usually
work
good
in
terms
of
like
capturing
just
that,
if
you
use
it
already
created
one,
it
has
all
the
back
discussions
that
you
don't
want
to
the
only
people
to
wait
on
those
on
those.
We
want
them
to
weigh
another
demo,
so
yeah,
maybe
a
new
one,
would
make
sense,
link
it
from
the
other
issue,
but
anyone
makes
sense
all
right.
That's
that's
all!
A
Thank
you.
So
much
thanks.