►
From YouTube: Url sync component meeting
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).
A
Okay,
so
the
I
guess,
the
the
initial
purpose
of
this
meeting
was
so
I
could
hand
off
all
the
work
that
I
was
doing
on
the
url
syncing
with
security,
dashboards
and
beyond.
A
But
then
last
week
we
kind
of
found
out
the
hardware
that
the
defend
and
secure
were
kind
of
working
on
the
same
thing,
so
I
thought
it
would
be
useful
to
to
bring
savash
in
on
this,
since
he
was
kind
of
working
on
a
similar
thing
and
mark
as
well,
because
he's
been
helping
out
with
this
whole
thing,
and
I
think
you
created
the
original
issue
on
this
as
well
actually
mark.
A
So
we
can
kind
of
get
together.
I
can
say,
go
through
what
we
have
before
what
the
plan
was
where
I
got
up
to
and
then,
where
we
kind
of
overlapped
with
defend
and
then
in
theory,
we
should
be
able
to
come
up
with
a
plan
going
forward
as
to
how
we
do
this
across
the
stages,
so
we're
not
treading
on
each
other's
toes
too
much.
A
So
I've
all
got
the
the
agenda
document
there.
I've
I've
set
it
up
so
that,
while
I'm
waffling
through
the
first
few
points,
you
can,
you
can
add
questions,
so
we
can,
we
can
get
to
them
and
then
we'll
just
have
a
big
discussion
at
the
end
cool.
A
So
if
I
was
prepared,
I
would
have
totally
preferred
a
demo
of
of
what
we
had
before,
but
I'm
not
so
I
don't
have
that
demo,
but
what
we
did
have
before
when
security
dashboards
were
all
done
with
the
rest
endpoints.
So
before
we
had
the
instant
sorry,
not
instance,
standalone
vulnerabilities
based
security
dashboards.
A
We
were
using
view
router
to
sort
of
persist,
the
filters
in
the
url.
So
every
time
we
changed
the
filters,
it
would
send
an
event
or
whatever
it
is
up
to
to
view
router.
So
the
viewer
would
change
the
the
url
and
we
were
kind
of
treating
it
like
a
single
page
application
and
there
was
all
sorts
of
of
bugs
and
weird
quirks.
A
So
it
wasn't
ideal
and
using
view
router
was
maybe
a
little
bit
overkill
like
it
seemed
like
a
shortcut,
not
a
shortcut
but
like
a
simple
solution
at
the
time,
but
it
was
just
sort
of
more
more
hassle
than
it
was
worth
really
so
when
we
migrated
some
of
the
dashboards
to
the
standalone
vulnerability
stuff,
we
didn't
include
the
viewer
out
of
stuff
with
just
because
knowing
it
was
broken,
so
there
was,
they
didn't
see
much
point
in
shoehorning
a
broken
thing
into
into
the
dashboards,
so
we
kind
of
left
it
alone.
A
Knowing
that
we
would,
we
would
come
back
to
it
with
this.
I
will
share
my
screen
for
the
proposed
solution.
If
I
just
put
it
up
three,
I
think
it
is
yes.
So
where
are
we
okay?
So
this
issue
was
created?
A
It
was
like
a
year
ago
or
there
you
go
a
year
ago
by
mark-
and
this
was
when
we
were
initially
having
the
problems
with
the
the
vue
router
thing
and
syncing
urls,
and
the
idea
was
to
make
something
that
was
totally
reusable,
that
we
could
just
hook
into
this
dashboard
or
into
anything
else
in
gitlab
that
wanted
to
do
a
similar
thing
like
if
we
had
to
persist
filters
somewhere
else
or
persist
the
state
of
something
else
in
the
in
the
in
the
browser
and
the
url
or
whatever.
A
A
So
the
this
is
the
original
dashboard,
because
obviously
the
standalone
dashboards
didn't
have
them
in
at
this
point,
so
it
was
removing
it
from
the
old
dashboards
update
the
url
sync
mixing.
So
there's
a
url
sync
mixin.
That
was
it
yes,
ezekiel
had
created,
which
kind
of
did
basically
what
we
wanted,
but
the
problem
was,
it
was
a
mix
in
and
I'm
not
alone
in
hating
mixins.
I
don't
think
they
are.
There's
too
much
magic
in
them,
so
we
wanted
to
I've
said
I've.
A
Oh
actually,
this
isn't
the
plan.
This
was
the
first
draft
of
the
plan,
so
this
says
is
updated
to
watch
real,
deep,
like
so
I'll.
Just
I'll
come
back
to
that,
the
idea
was
to
to
move
it
to
a
component
so
that
it
would
make
using
it
a
little
bit
easier.
The
watching
real
deep,
like
part,
is
that
this
mixing
actually
only
watched
the
first
layer
of
an
object.
A
So
if
you
have
an
object
with
an
array
inside-
and
you
changed
anything
in
that
array,
it
wouldn't
actually
update
the
the
url,
because
it
could
only
watch
one
level
deep.
So
we
had
to
update
it
to
make
sure
it
watched
deep
enough
for
what
we
needed.
A
A
Do
do
the
one-way
kind
of
thing,
so
we
would
just
push
in
the
state
to
the
url.
You
couldn't
actually
go
to
a
url
and
get
the
fillers,
because
step
four
was
was
doing
exactly
that
so
wiring
it
back
in
so
that
if
you
go
to
security,
dashboard
filters
equals
severity,
critical
whatever.
It
would
then
change
the
filters
on
the
page
so
that
that
was
the
original
plan
and
we
we
got
so
far
through
this.
A
I've
probably
not
kept
this
up
today
have
not
now
I
have
so
we
we,
we
removed
the
root
logic
from
all
the
dashboard
stores
and
unknowingly.
At
the
same
time,
savash
was
re-adding
the
root
of
logic
to
the
dashboard
stores,
which
I
guess
makes
sense
if
you'd,
if
you
didn't
know
about
this
issue
and
what
we
were
trying
to
do,
which
is
why
we've
pulled
everyone
into
this
one
and
that's
still
in
on
the
standalone
dashboard
stuff
using
the
old
router.
A
So
we're
now
in
the
opposite
situation,
where
the
standalone
dashboards
has
it
and
the
other
dashboards
don't
anymore,
and
the
url
sync
component
is
created
and
merged.
So
we
have
this
this
component,
which
I'll
show
you
a
little
later
and
you
can
pass
it
a
query
and
then
it
will
watch
that
query
and
do
what
you
need
to
do
and
add
the
url
sync
component
to
the
security
dashboards.
I
started
on
this.
A
I
got
a
whip,
mr
in
where
it
kind
of
works,
but
also
not
really
and
and
that's
kind
of
where
we
were
up
to
it's
where
I've
brought
security
dashboards.
I
can't
actually
remember
which
ones
I
added
it
to.
Let
me
just
quickly
check.
A
Yes,
so
I
only
added
it
to
the
first
class
first
class
standalone,
that's
easier
to
say,
stand-alone
vulnerabilities
dashboard
in
this.
Mr
I'm
pretty
sure
this,
mr
can
be
scrapped.
We
can
just
use
it
as
reference
because
everything's
changed
since
I
wrote
this,
but
this
does
kind
of
show
how
it
works.
A
A
A
Eh,
oh,
I
didn't
scroll
up
there.
We
are
right,
okay,
so
I
have
used
there.
We
are
so
this
is
the
url
sync
component
and
all
I've
done
is
I've
passed
the
url
sync
component,
the
query
to
watch,
which
is
the
url
filters,
query,
which
is
up
here
and
it's
a
computed
property.
That's
that's
based
on
the
filters
object.
A
So
if,
if
we
were
to
pass
the
filters
object
directly,
it
would
just
write
a
lot
of
nonsense
in
the
url
bar
because
it
can't
handle
it
in
the
format
that
it
is
because
it
uses
sets
rather
than
actual
objects
and
things.
A
So
I've
just
looped
through
all
the
filters
and
basically
just
passed
it
so
that
it's
in
a
like
a
format
that
the
url
back
and
can
compass
or
whatever,
and
then
we
just
return
that
and
now
every
time
we
update
filters,
it
updates
the
url
filters
up
computed
property,
which
then
updates
this
url
sync
thing
and
updates
it
in
the
the
address
bar
which,
if
the
gdk
was
working
fingers
crossed
it's
not
yeah.
A
This
has
been
doing
this
for
about
two
hours
now,
so
I
don't
think
it's
going
to
start
so
there
there
is.
If
you
go
in
this
emma
there's
a
youtube
video
here,
I'm
not
gonna
play
it
for
you,
but
it
basically
demos
what
I
was
about
to
demo
for
you.
I
can
maybe
skip
through
and
get
to
the
bit
where
you
can
see
what's
happening
so
yeah
they
go.
I'm
changing
the
the
filters
down
here
and
it's
adding
them
to
the
address
bar
and
yeah.
You
get
the
idea.
A
I
don't
know
what
I'm
saying
at
this
point,
but
I'm
probably
saying
something
similar
to
what
I'm
saying
right
now:
there
you
go
back
and
forward
works
as
well.
It's
not
actually
updating
the
the
filters
down
here
as
we
change
the
address
bar,
because
that
wasn't
part
of
this,
mr,
but
that
is
something
we
would
need
to
do.
A
Okay,
I've
definitely
barreled
through
this.
But
if
there's
questions
or
anything
at
this
point,
I
have
yes.
B
So
this
the
code
assumes
that
the
object
is
a
source
of
truth
right.
So
we
are
updating
the
query
parameters
based
on
that
object,
not
updating
the
object
based
on
the
query
parameters.
A
Yes,
in
this
instance,
so
we
would
only
update
the
object
based
on
the
query
parameters
once
the
page
loads
and
then
that's
it,
that's
the
only
time
we
would
do
it.
A
So
if
you
went
to
that
url
you
would
load
in
the
you
would
you
would
populate
that
that
object
and
and
change
it
so
that
it,
the
filters
match
the
url,
but
then,
after
that,
only
changes
to
the
the
filters
would
change
the
url.
Otherwise
I
think
we
might
have
ended
out
in
this
situation
before
where
we
have
this
infinite
loop,
where
one
updates
the
other,
which
updates
the
other,
and
it's
just
it's
not
fun
time.
B
And
how
do
we
read?
Do
we
use
window
location
to
read
the
query
parameter
or
we?
We
use
the
url
sync
component
in
order
to
read
the
query
parameters
at
page
load.
A
I
don't
know
we
haven't
actually
written
that
bit
in
yet
so
that's
for
whoever
picks
this
back
up
to
to
to
work
out
the
url.
It's
weird.
So
it's
called
the
url
sync
component,
but
it's
one-way
syncing.
It
only
pushes
things
up
to
the
url
it.
I
don't
think
it
reads
things
back.
I
did
create
see
if
this
will
work,
yeah
right.
A
Yeah,
okay,
none
of
my
demos
are
working
today,
but
in
this
white
box
you
would
see
a
demo
of
where
I'm
I'm
pushing
it
up
to
the
to
the
url
and
then
there's
a
button.
I
can
click
that
just
pulls
it
back
down
from
the
url
I'll
I'll.
Add
this
to
the
docs
as
well.
It
just
in
case
that
starts
working
but
yeah.
So
there's
ways
to
do
it.
But
that's
not
part
of
of
the
mr
that
I
was
just
showing
you
it's
not
in
there.
Yet.
A
Okay,
I
did
have
a
question
myself.
Obviously
I'm
not
asking
it
to
myself.
This
is
to
to
everyone
else,
who's
on
the
call.
So
do
we
want
to
preserve
browser
history
in
the
browser?
So
if
you
change
your
filter
to
say
critical
and
then
you
click
back,
do
you
want
to
go
back
to
the
page
you
previously
on?
Or
would
you
want
to
undo
adding
that
filter?
So
currently
it
works
the
second
way
which
felt
right
at
the
time,
but
maybe
that
is
a
bit
weird.
B
The
with
the
changes
with
the
latest
changes
it.
It
follows
the
back,
so
when
you
click
back,
it
updates
the
filters.
B
So
if
we
don't
implement
this,
it's
stripping
out
this,
this
behavior,
which
is
introduced
lately.
So
I
don't
think
it's
a
problem,
but
I,
as
as
I
replied
in
the
in
the
dark
in
the
in
in
the
docs.
I
think
this
is
something
that
ux
people
might
need
to
be
involved,
because
to
me
it
makes
sense
that
when
the
user
clicks
back,
it
brings
it
to
the
previous
state.
B
But,
as
mark
pointed
in
in
the
issue,
it's
also
true
that
if
the
user
clicks
a
lot
of
filters,
then
they
will
have
a
long
list
before
they
can
go
back.
B
A
Yeah
I
mean,
I
think,
you're
totally
right
though
we
should
bring.
This
is
a
ux
question.
Isn't
it
it's
not?
It's
not
honest.
There
is
an
issue
that
was
created
off
the
back
of
one
of
these,
mrs
cameron,
which
one
it
was
about
being
able
to
pass
a
prop
to
the
url
sync
component
to
say:
do
we
pushed
it
or
replaced
it?
A
So
I
think
adding
that
in
to
the
url
sync
component
will
be
good
so
that
when
that
decision
is
made,
it's
just
a
case
of
changing
that
prop
and
then
everything
should
work,
so
we're
ready
for
it
and
then
other
people
can
do
it
as
well.
If
they
wanted
to
use
the
url
sync
component
for
whatever
they
were
using.
A
B
Okay,
so
perhaps
makes
sense
renaming
something
like
a
url
query,
sync
or
because
I
initially
initially,
I
thought
that
this
was
also
syncing
the
path,
so
it
was
really
mimicking
the
the
view
router.
C
I
think
that's
a
good
idea
and
it
touches
on
so
you
know
we
had
this
big
discussion
on
on
that
issue
or
mr,
I
can't
remember
where
about
you
know
why
not
just
use
v
router
and
the
argument
being.
That
is
too
heavyweight.
Well,
if
I
think
the
right
tool
to
use
really
depends
on
what
we're
trying
to
achieve
like
if
we
only
ever
want
to
like
the
simplest
possible
thing
that
we
could
do
is
read
the
query.
C
Parameters
on
load
update
the
store
accordingly
and
just
keep
writing
back
and
replacing
the
history
as
we
change
the
filters
that,
I
think,
is
where
something
like
the
url
query.
The
url
single
url,
query
sync
component
is
best
because,
like
it's
dead,
simple,
you
put
the
component
in
you,
read
it
in
initialization
time
what
the
url
is
and
you're
done
like.
That's
it.
I
guess
you
have
a
you.
Have
you
have
to
write
some
two
query?
So
we
have
you
have
to
write.
C
Some
like
sam
had
a
function
there
which
generated
the
query
params
from
the
state,
but
we
also
need
a
state
from
query
params
to
do
the
other
way
around.
So
we
have
that's
the
dead,
simple
case.
C
We
have
two
functions,
basically
read
and
write
to
do
the
bi-directional
thing
and
the
sync:
if
we
want
to
preserve
back
button
behavior,
that's
where
I
think
the
url
sync
component
is
potentially
not
the
best
case,
because
then
we
need
to
start
listening
for
history,
pop
state
events
and
stuff
like
that
and
where
would
that
live
without
living?
Url
sync,
I
don't.
I
don't
know
we're
at
that
point.
We're
replicating
quite
a
bit
of
what
view
router
offers.
C
So
I
mean
it's.
The
grass
is
always
greener
on
the
other
side,
like
part
of
the
thing
that
made
me
want
to
rip
out
view,
router
was
that
we
had
all
these
work
rounds.
It
was
like
I
want
to
get
away
from
this,
but
if
we're
trying
to
replicate
a
lot
of
the
behavior
we're
going
to
end
up
in
exactly
the
same
place,
so
I
think
url
sync
is
good.
C
If
we
want
to
really
simplify
the
browser
history
behavior,
but
if
we
want
to
keep
it
advanced
and
have
back
and
forth
and
so
on
and
provide
future
flexibility,
then
maybe
view
router
is
the
right
thing
to
stick
with,
which
sounds
like
I've
gone
back
on
what
I
said
before,
which
maybe
I
have
in
which
case
I
apologize,
but
that's
my
feeling
right
now.
C
A
Was
just
going
to
quickly
ask
if
I'd
been
naive
in
thinking
that
hitting
the
back
button
would
cause
it
hitting
the
back
button
is
a
totally
different
event.
Isn't
it
to
reloading
the
page
as
far
as.
A
C
C
I'd
forgotten
this,
when
you
change
the
filters,
it
triggers
a
reload,
an
actual
reload
of
the
page,
I'd
forgotten
that
detail.
That's
what
they're
doing
and
that's
why
they're
using
a
simple
like
url
sync
kind
of
thing,
because
they
just
refresh
the
page
and
then
they
don't
have
to
worry
about
browser
history,
state.
C
We
don't
want
that
or
no
we,
no,
I
wouldn't
recommend
it.
Okay,
no,
I
think,
there's
an
issue
somewhere,
that's
been
around
for
like
a
year
that
they
want
to
stop
doing
that
because
it's
it
takes.
As
you
can
see,
it
takes
forever
to
load
the
dashboard,
so
they
don't
want
to
keep
reloading
it.
Whenever
you
change
a
filter,
let's
not
do
it.
There
is.
B
There's
also
one
more
use
case,
I
think
it's
in
the
instance
level
dashboard
when
you
click
on
configure
dashboard.
It's
not
updating
the
url
at
all.
It's
just
changing
the
state
internally
and
then
based
on
the
state
change.
We
display
either
the
the
vulnerability
list
or
the
project
configuration
view
where
you
can
add
or
delete.
B
So
if
we
were
to
iterate
on
that
and
then
bring
it
to
next
level
and
then
keep
the
url
consistent,
so,
for
instance,
you
have
a
url
for
that
view,
instead
of
just
being
an
internal
state
change.
In
that
case,
the
back
button
would
make
sense,
for
instance,
so
you.
C
B
You
hit
on
the
configure
dashboard
and
then
it
updates
the
url,
and
then
you
click
back.
It
needs
to
go
back.
If
we
do
that.
C
C
I
don't
know
in
my
opinion,
which
sir
I've
implemented,
that
in
fact,
as
it
was
using
just
a
simple
state
thing,
because
I
thought
we
don't
want
to
link.
Why
would
you
want
to
link
to
this
page
specifically,
it
doesn't
need
to
be
a
part
of
state.
I
guess,
but
maybe
that's
debatable
so.
A
What's
what's
the
boring
solution.
C
Well,
the
other
ones
are
being
thrown
away
right
out
from
pipeline
yeah.
So
that's
not
a
and
the
pipeline.
One
doesn't
work
well
with
the
router,
because
something
else
on
the
page
is
already
manipulating
the
url.
So
that's
kind
of
out
the
window.
A
B
Just
remember
that
we
have
an
upcoming
issue
to
move
the
security
the
pipeline
to
the
so
that
the
vulnerability
list
to
a
tab
in
dmi.
So
in
the
mr,
you
will
have
a
new
tab
security
tab
so
clicking
on
that
one.
Should
it
so
do
we
use.
I
never
touched
that
code.
Do
we
use
the
router
there
or.
B
A
A
C
For
the
mr
page,
that
won't
be
standalone
vulnerabilities
that
would
be
vulnerability,
occurrences
winter.
C
B
Yes,
I
guess
so
so
I'm
just
brainstorming
here,
yeah.
B
But
I
think
there
we
don't,
we
don't
need
the
filters,
it's
just
a
list.
I
think,
if
I
remember
correctly,
I
just
reviewed
the
the
the
issue
for
the
planning
breakdown,
but
as
far
as
I
could
remember,
I
can
remember
it's
just
the
list.
No
filters
at
all.
B
C
No,
I
I
meant
well,
yes,
okay,
so
that's
yeah!
That's
the
thing
before
standalone
vulnerabilities
came
along
the
the
security
dashboard
had
no
concept
of
the
router.
It
just
simply
had
a
store
state
and
dumb
components.
C
The
router
was
like
a
plug-in
that
synced
store
state
to
the
url,
which
meant
that
that
allowed
the
pipeline
security
dashboard
not
to
include
any
of
that
functionality,
but
everything
else
did
do
the
filters
now.
Do
the
standalone
vulnerability
filters
component
assume
the
existence
of
a
router?
B
A
problem-
oh
sam's,
mr,
I
think
it's
the
the
the
whip
one,
it's
just
so
it's
plug
and
play
right.
You
just
use
the
url
sync
component
and
it
worked
except
the
back
button.
B
B
Okay-
okay,
just
remember
one
more
use
case,
so
we
I
think
the
the
issue
with
graphql
pagination
has
been
fixed,
so
we
may
reintroduce
pagination
in
that
case,
clicking
on
the
next
page
should
should
it
bring
like
if
we
don't
refresh
the
whole
page,
we
need
to
keep
the
browser
history.
C
Well,
maybe
well:
graphql
pagination
doesn't
support
you,
you
can
only
do.
Is
there
a
next
page?
Is
there
a
previous
page?
You
can't
say
take
me
to
page
four,
so
we
can't
maintain
any
state
there,
because
we
don't
know
what
page
we're
on.
If
you
see
what
I
mean,
we
can't
say
refresh
to
this
page,
because
we
don't
have
a
reference
to
what
page
we're
on
so
that
would
have
to
not
be
part
of
the
history
state.
B
C
It's
because
graphql
doesn't
allow
that
kind
of
pagination.
You
can't
do
that's
called
offset
pagination
and
graphql
algorithm
implementation
does
not
support
and
intentionally
doesn't
support,
offset
pagination.
A
A
So
this
is
why
it's
lazy
loaded
and
you
start
with
page
one,
and
then
it
just
gets
so
that
you,
you
kind
of
need
to
stop
thinking
about
it
in
pages
and
you
fetch
all
of
these
vulnerabilities
and
then
the
next
20
after
the
last
one
in
that
list,
and
then
the
next
20
after
the
last
one
in
that
list
so
pages,
doesn't
it
it's
it?
It's
a
weird
thing
to
so.
B
Yeah
true
makes
sense.
I
implemented
something
like
that
by
the
way
in
the
vulnerability
chart
component.
So
if
it's
90
days
the
the
the
frame
that
the
the
interval
that
we
need
to
fetch,
I
am
since
the
back
end
returns
only
10
results.
I
have
to
fetch
nine
times,
so
it's
like
I'm
doing
that
one
two
three,
four:
five:
nine
till
nine.
B
Okay,
so
I
think
then,
in
the
dashboards,
the
only
use
case
I
can
see
is
if
we
persist
the
the
the
history.
Otherwise
we
can
use
the
url
sync
component.
A
I
think
I
think
add
in
the
option
to
switch
it
to
replace
state
on
the
url.
Sync
component
would
be
a
good
step
anywhere,
because
then
people
can
use
it.
If
we
don't
need
to
use
it
fine,
whatever
it's,
it's,
not
a
huge
change.
Really,
you
know
we've
not
chucked
loads
of
work
away.
If
we,
if
it
never
ends
up
getting
used.
I
do
sorry
come
on
mark
sorry.
I
did
interrupt
you.
Please
continue.
C
Based
on
the
fact
that,
if
you,
if
you
push
history,
then
the
back
button
is
going
to
do
basically
nothing
useful,
which
suggests
to
me
that
replacing
history
should
be
the
default
of
this
function
of
this
component,
which
is
a
breaking
change,
but
no
one's
using
it.
Yet
right.
So.
A
C
The
option
as
in
you
just
change
the
function
you
call
based
on
the
prop
right.
I
feel
like
change
the
default
but
provide
the
option.
A
It's
currently
living
alongside
the
mixing,
because
the
idea
of
changing
the
was
it
the
metrics
dashboards
that
uses
it.
I
didn't
want
to
do
that,
if
I'm
being
honest
and
if
they
decide
they
want
to
use
this
component,
then
they
can
that's
great,
but
that's
kind
of
outside
of
our
scope.
I
would
say:
cool.
C
A
Yeah
for
filling
out
this
proposed
next
steps,
thing,
I'm
gonna
say,
add
default
option
to
use,
replace
state.
A
I'm
gonna,
I'm
gonna
write
dave
there,
but
it
doesn't
necessarily
have
to
be
dave,
and
then
I
guess
the
other
next
step
is
just
do
nothing
to
the
other
dashboards.
Unless
we
decide
that
we
need
to
use
the
replaced
it,
then
we
can
swap
it
with.
B
Well,
I
guess
so
I
would
suggest
to
go
and
ask
the
ux
first.
So
we
understand
what
we
need
to
do
and
then,
based
on
that
decision
we
can.
We
can
move.
B
Forward,
I
think
whether
we
should
keep
the
back
button
working
because
neither
of
them
supports
like
if,
if
we
replace
or
push
the
state,
it
doesn't
so
we
we
need
to
so
if
we
persist
that.
So,
if
we
keep
the
behavior
of
the
back
button,
then
we
need
to
do
the
two-way
binding
and
then,
in
that
case
I
think
viewer
after
makes
more
sense.
So
that's
why
I
think
we
first
need
to
figure
out
with
the
ux
whether
we
need
to
keep
this
behavior
or.
B
A
Does
that
sound?
I
don't
know
if
you've
all
got
the
document
open.
Does
that
sound
reasonable,
though
ask
for
ux
whether
we
should
replace
it
use,
replace
or
use
push
state
if
it's
pushed
it
just
keep
your
hour
because
it's
there
and
it
kind
of
already
does
that
if
it's
replaced
it,
we
could
consider
using
the
url
query
component.
A
Yeah
yeah,
we
can
just
call
it
slusk
or
yeah.
I
don't
know.
C
A
Yeah
naming
is
hard.
That's
why
I've
not
put
forward
a
name
for
this,
but
yeah.
I
think
I
think
savash
is
right.
Neyman
is
hard
and
we've
got
it
wrong
in
this
case,
because
it
does
not
describe
what
it's
really
doing
at
all.
It
makes
it
seem
like
it's
way
more
magic
than
it
is
okay,
so
they
seem
like
sensible
next
steps
for
me.
Do
people
want
to
take
ownership
of
these?
A
I
would
happily
do
it,
but
it
is
my
last
day
on
secure.
So
oh.
A
Well,
it
would
have
been
tomorrow,
but
sid
took
that
day
away
from
us,
so
I'm
sick
to
blame.
Okay.
A
A
A
Okay
and
then
I've
already
kind
of
wrote
dave
here.
So
unless
he
protests
would
you
I
mean,
I
guess
we
could
say
dave
and
then,
if
you're,
not
you
don't
have
the
availability
for
it.
Just
send
it
back
to
neil
and
you
can
you
can
re
re-jig
it.
C
A
C
A
Yeah
and
then
that
last
one
just
I
guess
whatever
right,
I'm
I'm
not
gonna
tell
anyone
to
come
up
with
a
name.
They
can
figure
that
out.
A
Cool
okay!
Well,
thank
you
for
this.
Is
there
any
concerns
questions
anything
anyone
else
at
this
point,
or
are
we
all
pretty
clear
on
where
we're
going.
A
Good
good
point:
I
will
upload
it
to
youtube
I'll
put
it
in
the
the
document
and
I'll
I'll.
Send
you
it
I'll,
probably
put
it
in
the
secure
and
probably
the
defend
channels
as
well.
Do
you
ever
defend
for
an
end
channel.
A
A
Okay,
well,
if
we're
all
happy,
then
I'll
see
you
all,
hopefully
later
we're
cool.
Take
care
thanks.