►
From YouTube: Initial call (Plan / Code Review): Architecture for global reactivity of Issues and Merge Requests
Description
Goal: Briefly discuss potential solutions and find active steps to validate those solutions
Relevant issues/reading:
[META] MR Page Architecture Walkthrough https://gitlab.com/gitlab-org/gitlab/-/issues/291035
[META] Issue page architecture walkthrough https://gitlab.com/gitlab-org/gitlab/-/issues/292992
Publish every new MR/Issue system note through a pubsub event system allowing any component on the page to subscribe to any kind of event [deprecated proposal, but some relevant discussions] https://gitlab.com/gitlab-org/gitlab/-/issues/280610
Slack channel: #f_global_reactivity_issuables
A
Hi
welcome
and
in
this
call
we're
going
to
be
talking
about
the
architecture
of
providing
global
reactivity
on
issues
and
merge
requests,
a
problem
that
has
been
on
our
tables
for
far
too
long,
but
we're
both
the
groups
are
trying
to
align
the
solutions,
and
so
the
object
of
this
call
is
just
to
briefly
discuss
potential
solutions.
Exploratory
work
that
we
might
be
doing
to
begin
validating
the
the
the
solutions
we
have
and
yeah.
So
there's
a
couple
of
reading
that
I
assume
everybody
at
least
took
a
passing,
look
and
yeah.
A
A
So
please
add
your
points
to
the
agenda
below
and
we'll
just
go
one
by
one
at
this
point
and
just
so
that
it's
clear
the
objective
is
so
that
when
something
happens
on
the
page,
it
replicates
across
the
page.
The
idea
here
is
not
to
address
the
problem
of
real
time
or
having
other
people's
changes
come
to
us
without
pulling.
A
B
So
like
right
now,
everything
in
issues
are
hard-coded
and
so
to
support
eventually
having
custom
fields
and
this
sort
of
configurability
on
a
per
customer
basis,
we're
basically
having
to
distract
out
and
isolate
each
field
like
these
honey
fields,
so
that
all
the
concerns
are
in
that
one
field
for
it
and
so
yeah.
I
natalia
had
some
great
perspective
here
and
I
just
wanted
to
highlight
it
and
let
her
surface
over
her
own
comments.
C
Okay,
so
I've
been
actually
asking
about
what
the
widget
is
and
what
functionality
should
we
have
there
and
what
do
we
want
to
have
as
well?
So,
basically,
first
of
all,
we
need
to
define
a
way
to
communicate
communication
between
widgets.
Currently,
the
main
way
of
communication
is
event
hub,
which
is
not
the
best
pattern
we
have
obviously,
and
it
would
be
nice
to
replace
it.
Currently,
it's
not
possible
completely,
but
we
at
least
should
start
to
look
the
way
to
do
this.
C
The
best
way
probably
would
be
have
some
shared
state,
be
it
apollo,
cache
or
view
x
also
with
ux.
We
can
replicate
part
of
event
hub
functionality
with
watch
and
subscribe
api,
but
my
main
question
was
about
how
do
we
want
widget,
because
we
want
widgets
on
issuables
to
be,
let's
say
connected
to
the
rest
of
the
application
and
the
gabe's
idea,
if
I
understand
it
correctly,
is
widget
defines
the
functionality
for
their
issuable
around.
For
example,
there
was
an
example
that
we
have
a
quick
action
for
assignees
right
on
issue
notes.
C
This
could
be
just
a
data
attribute
on
the
latest
stages.
It
should
be
defined
with
the
way
that
we
want
to
customize
a
page.
It
might
be
json
or
whatever,
I'm
not
sure
how
we
we're
going
to
define
the
structure
with
widgets,
but
anyway,
there
should
be
a
condition
when
we
display
this
widget
and
when
the
widget
is
provided
on
the
page.
C
This
could
be
done
with
old
functionality,
with
extending
view
prototype,
like
view
plugins
on
youtube,
or
we
would
provide
inject,
and
what
basically
I
wanted
to
have
here
is
our
component
widget,
whatever
it
be,
it
could
be
application
or
view
component
is
defining
external
interface,
external
methods,
and
this
external
interface
will
be
triggering
internal
methods
of
the
component.
I
understand
how
this
sounds
for
people
who
are
view
experts,
but
this
is
how
your
plugins
work
this
way.
For
example,
if
widget
is
provided,
the
node
could
be
triggering
a
quick
action.
C
A
D
Yeah,
so
natalia,
even
with
that
approach,
I
think
at
minimum
we're
going
to
have
to
get
on
the
same
page
in
that
every
widget
again
at
minimum
would
have
to
be
in
view.
So
I'm
wondering
if
we
should
get
a
line
there
right
or
would
your
approach,
because
I
think
that's
where
we've
had
a
bit
of
the
delay
in
moving
forward
on
kind
of
a
shared
architecture
and
that
we're
still
trying
to
account
for
some
of
our
like
hamil
views,
our
jquery
views.
Of
course
our
view
views.
D
A
A
A
So
we
have
a
bunch
of
components
across
the
page
and
not
everybo,
not
every
one
of
these
is
in
view,
and
some
of
these
are
simple
enough
say.
So
if
you
want
to
convert
the
milestone
to
view,
it
seems
simple,
but
then
again,
if
we
start
doing
them
right
now
on
our
own,
it
would
probably
collide
with
your
work
on
the
widget
for
the
extensibility
that
you're
doing
so.
What
my
opinion
here
is.
I
I
don't
want
us
to
stop
pursuing
an
ideal
path
with
view.
A
But
if
you
find
that
solution,
we
can
find
a
way
to
support
library,
agnostic
components,
we'd
be
able
to
ship
changes
to
users.
Much
sooner
so
say,
one
of
the
things
we're
looking
to
do
on
code
review
is
start
experimenting
with
a
quick
solution
for
the
status
of
the
issuable,
the
merged
label
at
the
top,
and
we're
going
to
be
trying
it
to
tie
it
with
the
merge
request.
A
That
would
allow
us
to
move
much
quicker
and
the
thing
is.
It
should
be
simple
enough
so
that
we
don't
have
to
dedicate
like
five
points
of
weight
for
one
widget
in
a
milestone.
It
should
be
something
like
as
quickly
as
like
a
1.08
for
each
widget.
Otherwise,
then
it's
no!
No!
No!
No
point,
yeah!
That's
my
short
answer.
C
We
don't
need
view
apollo
to
subscribe
to
this,
of
course,
making
hamel
part
a
widget
with
provided
methods
that
it
provides
is
hardly
possible,
but
if
we
think
about
a
part
of
the
application
that
needs
to
be
subscribed
to
the
store
and
listening
to
this
store,
we
can
do
this
with
vanilla,
javascript
and
apollo
client
on
itself,
with
apollo
watch
query,
for
example,
or
if
you
want
to
have
shared
status
qx,
and
you
want
to
check
ux
on
hamilton.
This
is
also
possible
with
vx
watchers
and
subscribers.
A
D
Sorry,
yeah,
natalia
just
sorry,
real,
quick
clarify
on
that
point.
Natalia.
Are
you
saying
that
there
is
not
because
my
main
concern
is
there's
a
point
that,
like
building
to
support
hamel,
becomes
more
work
than
it's
worth
like,
there's
a
point
there
where
it
makes
sense
just
to
go
ahead
and
refactor
the
components
to
use
view?
C
So,
for
example,
if
we
have
in
some
part
as
a
hammel,
but
we
need
to,
for
example,
re-render
this
part
if
our
shared
state
changes,
for
example,
if
I
change
change,
assignee
and
some
hammel
part
should
be
reacting
to
this,
this
is
doable
without
introducing
view
to
this
part.
We
can
just
subscribe
to
viewers
or
apollo
cache,
whatever.
A
Yeah,
just
one
thing:
we're
talking
about
a
hamel
but
a
lot
of
hamel
there's
a
mix
of
haml
in
javascript.
What
I
think
is
valuable
here
is
exactly
if
we
have
a
hook
to
that
central
state
each
case
or
each
bundle
of
javascript
and
haml
will
be
responsible
for
updating
reacting
to
whatever
happens
on
that
central
state.
A
B
Gabe
yeah,
I
think
natalia
answered
my
next
question.
The
other
would
be
we
do
have
this
new
architecture
and
evolution
workflow.
I
haven't
done
one
yet,
but
this
could
be
a
good
thing
for
the
front
end
engineers
to
spin
up
just
so
as
especially
because
cross
stage,
I'm
assuming
it
will
also
be
cross
company
as
more
and
more
stages
need
to
solve
these
problems.
B
A
B
Cool
the
other
thing
I
was
just
going
to
bring
up
since
we've
been
working
on
the
playing
stage
a
little
bit
too
in
terms
of
data
flow
in
one
view
like
you
can
have
shared
foreign
state,
but
we've
also
been
working
on
getting
websockets
production
ready,
and
I
think
we're
finally
unblocked
on
that,
but
sort
of
what
we
did
for
assanis,
for
example,
is
we.
This
is
assigning
a
subscribe
to
an
issue.
B
Basically,
on
the
server
and
anytime,
the
issue
changes
server
publishes
assigning
data
back
to
the
client
so,
instead
of
like,
when
you
do
the
quick
action
for
assignee
right
now.
Prior
to
this,
the
assigning
wouldn't
update,
because
there's
no
shared
front-end
state,
but
after
it
because
like
basically
the
one
assigning
component
or
widget
is
subscribed
to
the
server.
Whenever
it
data
changes,
it
automatically
gets
new
values
without
having
to
like
be
just
on
the
front
end.
So
I
think
whatever
we
build
here.
B
However,
we
approach
this
like
the
the
real
time
aspect
of
it
should
be
taken
into
consideration,
just
because
I
know
on
issues
and
I
think
probably
on
merge
requests.
There's
a
lot
of
desire
to
have
most,
if
not
everything
on
the
view
be
real
time,
and
so
it's
like
just
another
way
to
solve
the
kind
of
circular
data
flow
that
seemed
to
work
pretty
well
for
assignees.
So
I
just
wanted
to
highlight
that
and
raise
awareness
as
part
of
the
architecture
plan.
Long
term.
A
I
will
add:
yes,
I
think,
in
the
merge
request.
We
definitely
want
to
make
sure
everything
is
real
time
we're
starting
to
do
some
ground
work
to
prepare
the
merge
request.
Widget
phil's
okr
for
this
quarter
is
exactly
about
preparing
the
merge
quest,
rigid
state
to
be
in
graphql,
so
that
we
can
then
piggyback
on
on
the
work
that
real
time
is
doing.
Working
group
is
doing
so.
Yes,
the
plan
is
that
how
it
interacts
with
this
reality,
I
don't
really
know.
C
C
E
C
D
But
I
think
the
way
we
handle
that
kind
of
depends
on
the
like
what
we
decide
here,
because
more
than
likely
yeah
we're
going
to
use
apollo
and
we'll
be,
or
an
apollo
cache
we'll
be
able
to
abstract
that
out
from
the
plug-in
framework
and
then
the
either
subscriptions
or
whatever
we
add
on,
can
be
added
on
to
that
abstraction
layer.
So
I
don't
know
how
much
we
have
to
really
build
in
mind
for
websockets
right
now,
but
yeah.
D
D
A
Okay,
yeah,
I
think
everything
I
think
everything
you've
been
saying.
I
think
I
I
kind
of
agree
so
there's
no,
no
need
to
good
news
that
it's
not
really
attached
to
the
web
sockets.
That
way,
it's
not
a
lot
of
tight
coupling
there.
Okay,
so
this
one
has
been
answered,
we
can
skip
gabe
yeah
could
skip.
B
Okay,
yeah,
I
was
just
suggesting
that
we
should
consider
eliminating
front
end
overlapping
solutions
and
overlapping
api
solutions
and
the
same
views
just
going
going
back
to
our
boring
solutions
value.
When
I
read
the
article
that's
linked
there,
it
really
just
talks
about
being
intentional
when
you
do
introduce
something
that
is
an
overlapping
solution
with
your
existing
tech
stack
to
be
intentional
about
setting
a
date
where
you
want
to
commit
to
migrating
being
done
migrating
off
of
it,
so
that
there
isn't
overlapping
solution.
B
It
explicitly
calls
out
the
fact
that
when
you
do
have
these
overlapping
solutions-
and
you
have
to
create
additional
technology
to
make
those
overlapping
solutions
communicate
with
each
other,
which
then
just
leads
to
defects,
and
so
I
think
we
talked
about
that
already,
but
that
was
what
I
was
going
to
ask
the
question
about.
If
we
got
that's
good
right
now,.
A
I'll,
actually,
I
actually
had
a
few
thoughts
there,
because
I
think
we
haven't
had
the
opportunity
to
talk
after
that
issue
and
one
of
the
things
I
wanted
to
to
to
make
clear
is
that
that's
why
I
mentioned
that
thing
in
the
beginning
that
we
don't?
We
don't
go
into
this,
supporting
backwards,
compatibility
or
like
an
overlapping
solution
lightly,
but
on
on
merge
requests,
code
review,
sorry
on
code
review
and
specifically
on
the
merger
cast
application.
A
We
don't
foresee
a
future
within
the
next
year
that
will
have
the
merger
quest
diff
steps
in
graphql.
One
of
the
things
we
have
been
briefly
discussing
is
a
potential,
but
this
is
just
very
bare
bones.
It's
potential
to
start
a
exploration
of
a
pwa
for
code,
review
from
the
ground
up
thinking
about
offline
experience,
first
think
about
all
of
that
and
then
developing
the
graphql
endpoints
for
that.
But
then
again,
it's
definitely
not
even
discussed,
so
is
not
in
the
foreseeable
future.
A
So
that's
why
we
want
to
make
sure
that
we
support
other
technologies
and
impact
first,
but
this
is
very,
very
important
and
relevant.
So
thanks
for
raising
that,
because
we
definitely
don't
want
to
put
ourselves
into
a
corner
that
will
now
have
to
maintain
two
bundles
of
mess
messy
code
and
thanks
for
typing
that
out,
it
was
challenging
a
bit
of
rambling.
A
E
To
like
piggyback
off
the
piggyback
something
that
we
noticed
in
when
we
were
converting
components
in
issue,
and
then
we
have
overlapping
components
in
merge,
requests
and
other
issuables.
Is
that
having
that
like
reusability,
first
mindset
so
that
we
can
plug
in
these
components
at
a
future
date?
The
problem
that
we
would
run
into
is
how
the
store
was
architected
in
the
ux
was
different
depending
on
the
issuable,
so
how
you'd
access
the
same
state,
let's
say
confidential
or
was
another
one
yeah.
E
I
guess
confidentiality
in
epic
versus
issue
was
different.
So
then
the
watchers
would
have
these
like.
What
issuable
is
this
logic,
which
then
made
the
overall
implementation
a
little
bit
brittle?
So
if
we
decide
to
move
to
an
apollo
client
cache
implementation,
then
we'll
probably
have
the
we'll
have
like
a
separate
single
source
of
truth
solution.
E
I
don't
know
what
that
would
look
like,
but
it's
just
something
to
it's
like
notes,
for
example,
right
notes
are
real
time
using
polling
and
then,
but
how
I
access
a
note
in
an
issue
is
different
than
merge
request.
So
it's
like,
I
don't
know
at
what
point
we're
putting
the
car
before
the
the
cart
before
the
horse,
so
yeah
just
something
to
keep
in
mind
as
we
move
forward.
B
A
a
good
case
in
point
would
be
reviewers
in
the
sidebar,
like
issues
need
reviewers.
Ethics
want
reviewers,
it's
the
same
thing,
so
I'm
wondering
like
if
it
would
sort
of
make
sense
to
write
a
standard
shape.
First
state
that
all
issuables
follow
right,
because
there's
going
to
be
attributes
that
could
be
different
but
like
an
assignee
is
going
to
be
on
a
merge
request.
B
So
when
I
built
a
lot
of
front
end,
that's
why,
like
I
care
about
some
of
the
stuff,
I
would
always
normalize
my
store
using
a
normalizer
that
dana
abramov
wrote,
which
was
really
nice,
but
it
basically
hadn't
an
array
of
ids
that
I
could
do
lookups
and
then
it
would
actually
store
the
objects
in
an
object
tree
so
that
I
could
then
like
pluck
them
out
and
pick
them
out
and
stuff
like
that.
But
just
thinking
about
solving
that
problem.
B
That
would
also
probably
make
us
more
efficient
too,
especially
as
we
wanted
to
contribute
or
collaborate
with
each
other's
code,
because
we
wouldn't
have
to
go
in
and
like
the
weird
differences
in
different
state
objects
across
different
issue.
Walls,
if
it
followed
the
same
basic
pattern
and
shape.
That's
just
a
suggestion
to
solve
some
of
these
problems.
I
think.
C
E
Natalia
for
the
apollo
cache
stuff
would
so
like,
let's
take
confidential
for
in,
for
as
an
example
or
confidentiality,
would
you
would
you
add,
the
confidentiality
to
apollo
cache
schema
and
keep
the
view
x
ones,
or
would
you
at
the
same
time
like
phase
them
out
and
just
reference
the
one
and
is
there
like?
Do
you
have
a
mindset
of
how
you'd
like
to
phase
that
in
all
right.
A
Yeah,
I
was
just
going
to
say
that,
for
the
sake
of
time,
I
don't
want
to
go
over
time
because
we
probably
have
appointments.
None
of
this
is
incredibly
critical,
or
at
least
for
next
week
or
something
so
we
can
totally
pick
this
up
on.
The
next
call
I'll
move
the
points
to
the
next
one
discussion,
because
we
haven't
discussed
all
of
them
just
for
the
next
steps.
A
But
for
now
I
feel
like
this
has
been
very
productive.
Thank
you
so
much
for
everyone
who
attended-
and
please
refer
to
the
slack
channel
for
any
discussions
about
this,
we're
all
there.
I
think
so
feel
free
to
pull
out
all
the
people
in
and
start
threads
there,
but
we
will
have
a
more
formal
place
to
discuss
this
as
soon
as
we
have
that
process.
Last
anything
before
we
go.