►
From YouTube: FE Pairing - 20220902 - Changing the top nav view model
Description
In this session we dive into how we can adjust our top nav ViewModel builder to satisfy some new UX requirements.
A
A
There
are
some
mock-ups
here
in
from,
I
guess,
there's
just
screenshots
of
sigma.
I
think
you
can
see
the
the
you
know
the
bold
header
thing
here
so
I've
been
looking
at.
It
looks
like
code
that
you
touched
like
18
months
ago
or
something
that
generates
all
this.
It's
just
kind
of
a
json
blob,
that's
fed
to
the
front
end.
Do
you,
I
guess
I
was
gonna,
ask
for
your
advice
on
how
you
would
approach
changing
the
code.
A
That's
there
to
do
this
without
I
don't
rewrite
the
whole
thing
yeah.
I
assume
I
see
you
have
like
a
primary
and
secondary
kind
of
bucket
of
of
I
guess,
menu
items
that
that
get
added
to
here.
I
think
the
secondary
was
just
used
for
like
the
admin
yeah
yeah.
I
was
thinking
of
just
breaking
that
down
further
into
buckets
for
each
of
these
headers.
B
The
the
intense
the
intent
with
the
way
we
we
set
it
up
was
that
the
back
end
had
all
the
information
for
when
we
want
to
hide
and
show
these
things
right.
So,
let's,
let's
back
and
build
that
model,
but
let's
let
it
build
it
in
such
a
way
that
it's
actually
helpful
to
the
view.
So
it's
like,
so
I
would
classify
this
as
a
view
model,
so
it
doesn't
have
to
be
like
a
like
very
denormalized
state
thing.
It's
like
this
is
a
presentation
model
that
we're
just
gonna
give
to
the
view.
B
B
A
Yeah-
and
that
makes
sense-
I'm
not
sure
how
it
currently
works,
I
mean:
does
it
currently
just
read
it
in
order
and
place
the
menus
and
the
options
in
the
same
order
that
they're
they're
given
yeah?
What
we
would
be
doing
is
kind
of
like
taking
an
array
and
collating
set
the
right
word,
just
organizing
them
by
some
sub
property
before
rendering.
B
So
I
think,
I
think,
that's
an
option.
I
was
even
thinking
even
simpler
than
that.
So,
like
my
the
I,
the
suggestion
I
would
give
is
like,
let's
try
to
have
the
front
end,
do
as
little
as
possible,
okay,
and
so
what?
If
the
back
end?
What?
If
that
array
where
it
was
getting
where
we
had
a
list
of
like
primary
menu
items,
I
guess.
B
B
A
Another
thing,
I'm
not
sure
if
they
accounted
for
all
of
the
possible
options
in
this
design.
Now
that
I'm
looking
at
it,
I
know
there's
some
that
are
kind
of
conditionally
hidden
like
the
geo
options,
yeah.
Obviously
the
admin
stuff
there's
a
lot
of
options
there
yeah
and
I'm
not
sure
presume
that
goes
under
your
dashboards
or
maybe
just
at
the
bottom,
under
a
divider
like
it
probably
is
now
so
yeah.
C
A
B
B
B
Okay,
the
easiest
way
I
can
I
can
see
this
happening
is
rather
than
actually
creating
a
view
model
that
has
some
sort
of
nesting
structure.
Yeah.
Let's
just
create
one
flat
list,
but
in
the
list
we
have
separators
type
yeah,
we
say:
here's
the
header
type,
here's
the
item
type
and
we
just
that
just
sounds
the
easiest
to
me.
C
A
C
C
A
C
A
A
B
Is
only
admin
pages,
it's
there's
no
project
clips
or
snippets.
You
can
just
visit
the
admin
page.
The
other
other
thing,
I'm
not
seeing
in
these
designs
is
the
responsive
menu.
So
one
of
the
big
wins
of
doing
this
view
model
approach
also
means
we
use
the
exact
same
model
for
building
the
responsive
presentation.
Oh
the
you.
B
A
B
C
A
A
C
C
B
A
B
C
B
C
A
B
B
B
B
C
B
C
A
A
B
B
B
A
A
B
C
A
B
A
C
A
B
A
B
A
A
B
B
B
A
B
A
C
I
mean
the
rendering
you
the
thing
is:
how
do
we
want
the
data?
I
think
flat.
Data
with
the
heading
is
good
because
in
the
end,
you
still
could
change
the
rendering
to
run
multiple
ul's
like
hey.
If
you
encounter
a
heading
close
existing
ul
start
a
new
ul
right
like
you
could
do
that
as
well
and
I'm
a
proponent
of
flat
data.
I
potentially
would
refactor
the
right
hand
side
to
be
flit
data
as
well
right.
You
know,
yeah.
A
I
think
that
makes
sense
either
way.
I
think
they
should
both
be.
You
know,
rendered
from
the
back
end
in
the
same
way
just
for
consistency.
So
maybe
we
go
with
what
we
were
talking
about.
What
we're
in
the
middle
of
implementing
here
with
the
the
flat
headers
and
I'll,
create
a
separate
issue
to
go
back
and
kind
of
refactor
this
to
use
that
same
method.
B
A
C
B
A
B
A
B
B
C
B
So
so
the
way
I
see
this
being
used,
one
of
the
benefits
you
get
with
the
menu
items
approach
is,
I
can
tell
does.
Does
this
section?
Have
no
items,
therefore,
don't
create
the
header
like
just
remove
the
whole
thing
yeah
when
we
go
to
that
helper,
the
top
nav
helper.
I
have
an
idea
for
how
to
fix
this,
but
if
we
go
to
the
top
nav
helper.
C
B
What
what
I
was
thinking-
oh
that's,
a
that's
an
interesting
idea.
I
was
I
was
thinking
potentially
something.
Maybe
less
performant,
but
maybe
more
okay,
going
back
more
elegant
would
be,
let's
just
always
add
the
header
and
at
the
very
end,
we'll
clean
up
headers
that
that
don't
have
items
following
them
and
you
can
actually.
C
B
Yeah
yeah,
so
as
long
if
it
doesn't
have
an
item
after
it,
you
remove
it
so
like
we
could,
just
we
always
add
it,
but
then,
when
we
do
the
dot
build
on
the,
and
so
we
can
actually
encapsulate
this
on
the
the
menu,
the
top
nav
menu
builder,
and
that's
that
builder's
build
method.
That's
when
we
can
do
that.
Header
cleanup
step.
That's
one
approach!
I
I
have
you
know
reservations
because
it's
it's
a
weird.
You
know
after
processing
thing
to
do,
but
it
does
make
interfacing
with
it
simpler.
B
B
C
B
So
do
you
know,
what's
you
know,
what's
so
cool
we
can
we
actually
can
get
rid
of?
Oh,
this
would
be
so
sweet
we
we
can.
We
can
get
rid
of
that
public
method
for
add
primary
menu
header.
Let's
just
accept
an
argument
of
what
is
the
header
title
from
where
we're
adding
a
menu
item
right
and
let's
just
do.
A
B
C
A
A
C
B
A
A
A
C
C
A
A
A
C
A
C
A
C
A
B
C
A
C
A
C
A
C
A
B
A
B
A
B
C
C
C
B
B
A
While
I
have
you
on
here,
I
wanted
to
ask
something
else.
I
know
we
have.
We
had
a
like
ad
menu
item
with
shortcuts,
like
the
thing
in
here
as
well.
I
don't
remember
where
it
is.
Yeah,
add
primary
menu
item
with
shortcut
and
it
looks
like
it
just
adds
shortcuts
to
its
own
separate
bucket,
and
then
it
renders
these
in
like
a
hidden,
yes
ul
somewhere.
Just
for
our
shortcuts
to
to
to
use.
Is
that
or
is
there
a
reason
it
was
necessary
to
implement
it?
That
way,
it
just
sounds.
B
I
mean
that's
just
keeping
in
line
with
how
the
shortcuts
this
is
without.
We
don't
want
to
touch
the
shortcuts
code,
but
we're
changing
how
we
rendered
these
and
shortcuts
were
coupled
to
it's
looking
like
that,
and
so
this
was
okay.
I
don't
want
to
change
how
shortcuts
are
done,
which
we're
done
in
a
really
interesting
way.
So,
let's
just
move
short
yeah.
A
B
B
A
B
C
A
C
C
C
A
A
B
A
B
B
A
B
We
could,
even
just
at
the
very
least,
this
is
the
least
performant
way,
but
we
could
simply
search
for
the
header
and
maybe
looking
optimizing
by
seeing
a
set
of
exactly
and
then
just
splice
it
at
the
end,
like
I,
I
like
thinking
of
that
as
an
implementation,
you
know
rather
than
let's
change
the
whole
mind.
Api
yeah,
because,
like
yeah,
google
is
keeping
this
front
end.
Stupid,
simple
and
yeah.
B
A
A
A
A
C
A
C
B
A
A
C
B
A
A
B
C
A
A
A
A
C
C
B
A
B
C
B
A
C
It's
not
included
in
the
mock-up
because
they
probably
are
not
aware
that
the
responsive
view
exists.
I
think
this
could
also
be
a
quick
ping
right.
I
mean
this
would
also
could
also
be
a
ping
on
dmr,
but
I
think
hey,
hey,
nick,
look,
we
have
the
responses,
you
should
be
at
the
groups,
yes
or
no.
It's
not
like
that.
You
don't
have
enough
horizontal
space
right
vertically,
like
I
don't
know
enough
space
to
show
the
group
stare
as
well
right.
C
A
C
B
B
C
A
C
I
I
I
think,
I
think
probably
the
condition
right
now
would
be
like
super
easy,
because
you
would
just
need
to
do
the
gl
on
whatever
feature
flag
pushing
and
then
you
could
just
have
a
look
at
your
that
you
could
just
have
a
look
in
the
component
where
we
had
added
the
in
the
loop
editor
vf
could
just
render
it
conditionally
there
as
well
so
yeah.
That's
probably.