►
Description
In this session, we resurrect an old MR to introduce a reusable Vue component that encapsualtes some common logic about form fields.
MR: https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/2586
A
Having
this
form
component
that
is
doing
apollo,
stuff
and
rendering
feels
dynamically,
and
it's
really
useful
but
is
doing
a
lot,
and
so
we
tried
to
this
was
already
an
iteration
towards
a
further
goal,
so
we're
trying
to
now
iterate,
maybe
over
this
component
and
clean
up
the
maybe
the
responsibilities
and
to
reusable
beds,
because
what
if
we
were
in?
How
could
we
reuse
this
if
we
weren't
using
apollo-
and
maybe
things
like
that?
A
So
the
idea
here
is
this-
is
the
presentation,
responsibility
component
of
presenting
these
lists
of
form
fields
and
managing
the
the
interactions
there.
So
looking
at
this
component
that
it's
inspired
from
some
of
the
props
are
fields,
there's
a
handful
of
props
about
the
query
that
will
actually
submit
when
this
thing
gets
submitted.
A
B
Yeah,
so
existing
model
was
that
sorry
paul
yep
yep
yeah.
So
that
was
the
idea
again.
We
might
decide.
We
need
more
abstraction,
but
the
idea
is,
you
can
use
this
for
create,
in
which
case
I
guess
you
don't
pass
an
existing
model
or
you
can
use
it
as
an
update
form,
in
which
case
yeah
you
would
pass
it
a
model.
A
A
Oh
yeah,
so
there's
the
fields,
there's
three
fields
and
I've
specified
the
types
of
the
fields
which
isn't
being
included
in
the
props
and
that
value
is
getting
emitted
as
the
model
is
changing
for
these
fields
and
so
yeah.
This
does
not
include
like
the
submit
button,
but
that
validation
state
would
get
passed
down
of
like
if
we
need
to
show
field
level
validation
like
if
I
hit
submit
and
then
I
can
show
the
field,
level,
validation
or
something
like
that.
A
A
A
B
C
A
A
A
A
A
E
A
D
B
A
B
B
A
A
A
B
For
seasoned
experts,
like
you
paul,
maybe
not
so
much,
but
I
think
they're
life
savers,
because
there's
nothing
worse
than
pushing
up
on
the
main
gitlab
project,
and
then
you
get
a
failure
on
like
prettier
or
eslin
or
ruby
cop,
or
something
like
that,
and
it's
like
okay,
I've
just
wasted
three
hours
of
pipeline
minutes.
This.
A
A
B
B
A
A
A
D
A
A
B
A
A
B
So
the
thing
that
it's
probably
not
answering
the
question
that
you've
asked,
but
the
the
thing
that
I've
got
in
the
back
of
my
head-
that
I
can't
see
just
from
this
is,
I
don't
know
when
well,
I
do
know
when
we
write
this
in
january,
but
when
how
the
form
component
has
subsequently
evolved.
So
now
we've
got
gl
inputs,
we've
got
jill
drop,
I'm
not
sure
if
it's
drop
drop
down,
but
a
drop
down
and
we've
got
check
box.
So
that's
one
of
the
things
that
would
be
really
nice.
B
If
we
could
work
on
this
so
that,
yes,
you
can
provide
a
template,
a
slot,
a
name
slot
because
sometimes
we'll
want
a
color
picker.
Sometimes
we'll
want.
You
know
some
weird
and
wonderful
stuff
yeah,
but
that's
one
of
the
things
that
would
be
nice
to
either
today
or
in
the
future
iteration
or
at
some
point
ensure
that
we
can
handle
some
of
that
stuff.
B
The
other
thing
is
I've,
never
written
a
render
function,
and
I
might
say
that
it
would
take
me
longer
to
interpret
understand
and
potentially,
if
I
was
to
raise
an
mr
to
add
more
functionality
to
this
component
in
the
future.
That
being
said,
I
think
when
we
sat
together
and
worked
for
it,
it
kind
of
made
sense
and
I'm
sure
that
you
know
yeah
yeah.
A
A
C
A
A
A
A
A
A
A
A
A
A
C
A
C
D
A
Oh
yeah
yeah
yeah
yeah.
No,
this
is
because
why
did
I
do
a
render
function?
Is
this
you
know
like
how
the
template
works
where
you
can
just
do
v
bind
and
it
will
go
to
attributes
props.
It
doesn't
matter
it'll
just
go
there
like
that's
great
well,
with
render
functions
you
have
to
know,
is
it
going
to
props
or
attributes?
B
A
A
A
D
A
C
A
A
D
A
E
A
B
A
A
A
C
C
A
E
A
A
A
B
A
A
A
Why
in
the
world,
oh
my
gosh,
that's
gonna,
be
so
much
easier
to
test.
Like
I
mean
it's,
the
same
thing
it's,
but
for
some
reason
having
this
template
is
really
nice
at
knowing
like
what
you
need
to
test
like.
I
usually
just
look
at
the
template
to
know.
This
is
what
I
need
to
test
when
you
have
a
render
function.
It's
like
whoa.
A
B
A
D
E
B
A
B
A
B
C
C
I,
like
the
uppercase,
so
it's
uppercase
for
the
user
as
well
like
exactly,
I
think,
I'm
thinking
about
not
so
much
of
design
perspectives,
but
what
are
ux
if
the
interface
you're
working
with
will
transformation
uppercase.
I
think
it
feels
it's
just
the
right
thing
to
show
this.
So
if
you're
dealing
with
some
case
issues,
at
least
there
will
be
an
indicator
that
just
automatically.
B
A
Because
yeah,
that's
where
I
would
say
that
is
not
the
responsibilities
component.
This
component
is
responsible
for
presentation,
yeah
yeah,
it's!
This
is
all
about,
probably
transforming
what
we
present
and
what
we
transform
we're
going
to
present.
So
we
have
something
we
want
to
do
behind
the
scenes.
Yeah,
do
you
make
sense
to
happen
somewhere
else?
Yeah,
absolutely.
B
A
B
A
A
When
I
start
validating
you
know
this,
this
doesn't
have
any
validation,
but
that
does
oh,
that's
pretty
nice,
so
those
ux
needs
that
we
have
out
of
the
box
of
needing
revalidation
and
stuff
like
that
is
all
way
more
data
driven
which,
which
is
exciting,
so
cool.
I
guess
I
will
commit
this
push
it
up
and.
A
A
B
B
Yeah,
I've
had
a
lot
of
a
lot
of
pain
with
that
recently,
actually
working
on
different
projects
and
unsafe
yeah
yeah,
even
to
a
point
actually
where
at
the
moment,
when
I
save
a
javascript
or
view
file
in
the
gitlab
project,
it's
I
think
it's
using
a
completely
different
formatter
to
prettier.
So
it
then
I
need
to
prettier
right
to
fix
it.
So
I
need
to
figure
out,
what's
going
on
there,
yeah.
A
All
right
this
is
it
cool?
Well,
thank
you
all
for
your
help.
Thanks
I'm.
I
think
this
will
be
much
easier
thanks
for
pushing
it
forward.
Paul
appreciate
it
well,
I
think
it'll
be
much
easier
to
push
forward
now
that
it's
not
so
complex,
so
wow,
that's
a
lot
easier
to
push
forward.
We'll
see
the
one
thing
to
be
thinking
about
I'd,
love,
to
hear
your
async
thoughts
on
this
yannick
and
lee
and
I'll
ping.