►
Description
In this session we resurrect an old MR to introduce a component `form-fields` which will encapsulate creating a design compliant form.
- https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/2586
A
A
A
A
B
A
Oh
gosh,
my
brain
is
I'm
on
a
one
thread
brain
right
now
it
regularly
comes
up
to
me
about
form
validation
and
it's
such
a
pain
to
re-implement
every
single
time.
We
need
to
do
it
because
there's
a
lot
that
goes
on
with
it.
There's
just
different
states.
You
have
to
manage
with
it
and
like
so
encapsulating
form,
validation,
I
think
is,
could
go
a
long
way.
D
A
C
A
A
F
Well,
I,
don't
know
if
this
is
what
Paul's
saying,
but
you
might
be
saying
like.
Could
we
make
it
so
that
a
field
can
have
can
support
multiple
rules?
Saying
like
it's
required
and
it
has
a
minimum
length
of
eight
or
something
like
that?
And
then
it
just
runs
the
rules
and
like
the
order
that
you
define
them
and.
B
G
F
That'd
be
pretty
sweet,
I
was
kind
of
playing
right
when
I
was
playing
around
with
this
I
was
playing
around
with
that
idea
as
well,
and
instead
of
having
like
a
a
validate
function,
I
just
had
like
a
a
key
called
rules.
That
was
an
array,
an
array
of
objects,
and
then
each
object
has
two
keys,
validator
and
message.
So
then
you
can
just
say,
like
these
are
all
the
rules,
and
then
this
is
the
order
you
put
them
in.
G
A
A
F
A
F
A
Kind
of
like
the
idea
of
you,
you
brought
up
a
good
idea,
Paul
of
like
multiple
functions
here
and
we
that
sounds
like
a
really
really
easy
implementation,
but
a
really
flexible
way
to
declare
so
I,
don't
have
to
do
a
whole
bunch
of
if
statements
here
and
I
could
just
have
a
list
of
functions
here.
Marco
I'm,
looking
at
the
chat
and
Marco
you
mentioned
about
whether
this
is
works
with
view
or
Hamill.
A
D
D
A
A
F
Yeah
yeah
one
one
note
about
that,
though
one
use
case
that
we
use
a
lot
in
in
in
gitlab
is
we'll
have
a
form
that
you
just
submit
the
normal
way
like
with
a
normal
htu
ml
request
to
the
rails
controller.
So
the
name
of
the
input
might
be
like
have
weird
brackets
in
it,
which
is
you
can
you
can
define
an
object
like
that,
but
it's
kind
of
kind
of
funky.
Looking
I,
don't
know
it's
not
like
a
clean
like
camel
case
key.
Do.
A
A
D
But
the
so
the
rails
controller
depends
specifically
on,
like
the
input
name
attribute
right,
which
is
kind
of
disconnected
from
the
key.
If
you're,
if
you're
doing
this
to
like
spit
out
some
sort
of
pre-shaped
object
that
that
I
think
in
my
mind,
is
separate
from
like
they're
disconnected,
so
we
should
be
able
to
override
it
right.
A
C
A
A
A
I
F
To
wear
it,
what
we're
gonna
say.
One
thing
that
kind
of
confused
me
about
the
current
array
where
we
have
the
name
key
is
that's
used
for,
like
the
ID
attribute
and
the
name
attribute.
So
it's
a
little
bit
confusing
of
a
name
yeah.
So
if
what
we
could
call
it
like
either
we
could.
In
my
opinion
we
could
either
call
that
t
or
the
object,
syntax
kind
of
takes
away
the
the
arbitrary
part
of
it.
D
H
D
A
G
D
D
F
D
A
But
we
could,
but
it's
a
good
point
too
like
we
do
need
to.
We
do
need
to
respect
the
input
name
and
that's
that's
why
we
want
to
know
your
all
right
and
you
bring
up
a
good
point.
I
think
that's
why
an
object
is
a
really
great
idea
for
the
API,
because
that
that
has
symmetry
with
the
model
that
we're
gonna
get
back
right,
yeah,
it
Rhymes
exactly
it
Rhymes.
A
H
D
A
E
A
A
B
I
A
I
F
G
A
A
G
H
A
D
F
A
The
with
labels,
as
soon
as
I
discovered
this
I
abandoned
IDs
all
together,
but
you
can
actually
put
your
input
inside
of
a
label
Tack
and
you
don't
need
to
do
the
four
binding
because
it
just
knows
the
labels,
for
whatever
is
inside
of
it.
It's
very
strange,
but
it's
h,
you
know
it's
par
for
the
course
for
HTML,
but
yeah.
Maybe
we
don't
need
IDs.
E
A
B
G
B
F
H
H
E
F
A
Yeah,
what
I'm
realizing
I'm
trying
to
14
months
ago,
man
I've,
really
neglected.
This
thing,
I
was
what
was
helpful
about
sorry.
I
just
want
to
click.
I
want
to
clarify
the
intent
here
was
before
this
meant.
Validators
always
got
a
string,
so
the
validator
needed
to
do
the
transform
and
then
to
actually
get
the
model
I
needed
to
transform
it
as
well,
and
so
it
it
just
wasn't
very
pleasant
and
I
toyed
around
this
idea
of
like
this
is
what
I
really
wanted
to
be.
A
C
D
A
C
F
A
F
A
F
A
A
D
A
I
E
A
A
E
F
G
A
F
Yeah
I
think
that's
what
I
when
I
was
playing
around
with
it.
That
was
a
little
confusing
to
me
where,
when
we
ran
when
we
Mount
the
the
component,
there's
no
default
value
for
any
of
them,
I
think
or
like
the.
If
you
look
at
it
in
the
view,
Dev
tools
like
the
model
is
just
black
I
think,
instead
of
having
like
each
one
defined
and
then
it
it
gets
to,
once
you
actually
input
into
a
field,
then
it
gets
defined
in
the
model.
I
think
yeah.
E
A
F
Well,
like
yeah
I
guess
in
the
created
like
in
the
created
hook,
we
could
just
Loop
through
all
the
fields
and
then
just
put
a
default
value
of
an
empty
string
and
return
it
yeah
or
emit
the
input
event
mm-hmm.
But
then
you
start
off
with
like
the
model,
with
a
default
string
for
everything.
I
don't
know
if
that
makes.
But
then
we
don't
have
to
do
weird
things
and
get
value.
I,
don't
think.
A
Right
I
think
we
could
do
that.
I
think
what
what
what
Peter
is
mentioning
is.
This
can
totally
happen.
So,
if
I
don't
touch
anything
yeah,
this
is
the
model
you
see.
The
model's
empty,
yeah
I
hit
submit.
What's
going
to
happen,
so
we
lost
our
our
rhyming
and
symmetry
between
the
model
and
the
fields.
D
D
A
E
D
A
F
D
A
D
B
G
F
A
B
A
D
A
H
A
A
A
A
I
think
I
want
to
call
it
fields:
okay,
I
get
what
you're
saying
I
get
what
you're
saying
but
I
just
know
like
on
my
head:
I'm
thinking,
I
gotta
declare
the
fields
and
it's
like
I'm
gonna,
if
I
See
Fields.
This
is
how
I
get
my
Fields
like
I,
think
that's
gonna
appeal
to
autocomplete
that
I
think
I'll
call
this
we'll
call
this
values
to
mirror
the
fields.
F
H
A
H
D
G
G
A
A
D
A
A
H
D
A
A
A
A
H
F
H
F
The
value
to
play
Devil's
Advocate:
why
are
we
transforming
it
to
a
array
when
we
could
just
keep
it
as
an
object
and
always
have
it
as
an
object?
It
seems
like
we're
kind
of
like
I.
Don't
know
if
we
just
if
we
keep
it
as
an
object,
and
we
that
is
O
is
an
object
then,
but
if
we
transform
it
to
an
array,
then
we
have
one.
That's
an
array
and
one
that's
an
object
and
it
seems
like
it
might
get
more
confusing,
but.
A
F
A
A
A
A
A
A
Right,
oh
yeah:
this
is
the
default
one,
so
I'm
basically
going
to
just
then
I
think
we
could
just
do
this.
We
could
say
if
we
have
this
yeah.
So
we'll
say:
if
is
a
function?
Yeah
sorry,
I'm,
I'm,
all
right,
I'm,
I,
skipped
ahead
of
my
and
and
I
am
simplifying
I.
Think
what
we're
doing
here,
because
we
do
it
a
couple.
We
do
it
some
somewhere
else
and
I.
Think
let's
just
move
to
its
own
function.
A
A
A
A
H
F
C
A
F
I
was
running
into
this,
and
I
actually
was
playing
around
with
actually
putting
GL
form
the
actual
form
component
inside
form
fields.
And
then
then
you
can
listen
to
the
submit
event.
You
can
check
if
there's
any
errors,
and
then
you
can
admit
the
submit
if
it's
valid
or
you
can
emit
like
invalid,
submit
or
something
like
that.
F
A
F
A
A
F
A
C
A
A
I
A
H
A
Along
the
way,
what
what
what
Paul
identify,
which
is
a
really
good
point,
is
we
only
show
validation
messages
when
they're,
dirty
or
when
the
form
has
been
submitted
is
when
we
do
the
validation
check,
and
so
we
can
test
for
dirtiness
here.
That's
great
form.
Submission
is
a
little
more
tricky,
so
we're
considering
opening
up
the
scope
of
this
thing.
F
So
I
I
mean
I,
think
that
would
work
but
like
what
what's
the
I
still
don't
understand
the
use
case
for
not
rendering
the
or
like
having
I.
Don't
still
don't
understand
the
use
case
for
passing
an
ID
instead
of
just
rendering
the
form
in
this
component
like
the
yeah?
What,
when
would
you
do
that
like?
When?
Would
you
want
to
render
just
the
fields
but
not
a.
H
A
That's
the
other
thing
is
like
yeah.
We
could
just
pass
along,
but
the
idea
is
oh
now.
This
component
is
doing
a
lot,
and
maybe
we
want
to
decouple
creating
the
form
from
this
component
and
I.
Don't
know,
but
maybe
listening
outside
of
the
component
is
a
lot
already
and
I
I.
Get
that
that's
not
ideal,
I
would
I
know.
We
have
some
really
gnarly
forms
like
like
the
merge
request.
Description
is
one
large
form
like
the
or
updating
a
merge
request.
A
F
F
Yes,
yes,
and
we
totally
have
that
yeah
yeah
I,
know
I,
guess
the
word
I,
just
hate
kind
of
enabling
people
to
create
that
type
of
stuff
which
I
I
do
all
the
time,
but
it
like
just
kind
of
feels
like
we're,
enabling
just
like
being
able
to
create
those
forms
that
are
like
part,
Hammel
part
view
it's
just
kind
of,
but
at
the
end
of
the
day
we
have
a
lot
of
that
stuff.
So
we
kind
of
got
to
deal
with
it.
So.
A
F
F
F
H
A
A
A
F
A
A
D
So
like
what?
If
so,
what
if
this
is
our
I'm
I'm
building
out
a
form
right-
and
this
is
like
the
the
top,
the
the
top
level
component
for
my
form
and
then
in
in
that
form
we
pass
in
it's
a.
We
have
a
scope
slot
and
we
pass
in
like
a
form
or
a
modal
or
something
so
that
we
can.
We
can
start
passing
functions
down
into
our
whatever
our
like
form
container
is
and
then
inside
the
container
can
go
all
the
fields
like.
Is
that
doable
and
is
that
too
complicated
man.
A
D
A
It's
going
to
overwrite,
so
the
default
content
there's
no
way
to
get
access
to
it
from
the
parent.
The
default
content.
That's
what
you
kind
of
want.
You
want
a
function
that
returns
so
that
you
can
call
it
wherever
you
want
to
which
you
could
do
in
react,
because
it's
like.
Oh,
this
is
part
of
my
slot
scope.
I
get
this
function.
I
can
just
call
it
wherever
I
want
to
yeah.
A
I
think
we're
getting
pretty
close
to
doing
the
form
ID
listening,
because
I
almost
feel
like
because
I
feel
like
I
feel,
like
my
other
idea,
would
be
like
I
I
sense.
Another
component
wanting
to
come
from
this
of
like
this
is
the
form
Fields
container
or
like
this
is
the
one
that
creates
the
form
and
there's
now
some
sort
of
relationship
between
the
two.
But
this
is
almost
just
like.
A
We
should
just
listen
to
at
that
point:
you're
already
listening
to
a
parent
somehow,
but
now
you,
let's
just
listen
to
the
parent,
so
I
think
just
to
get
this
out
the
door,
we're
just
gonna,
listen,
we're
gonna,
require
form
ID
and
that
will
be
our
submit
listener
and
we'll
figure
it
out
a
more
elegant,
more
elegant
ways.
Another
time,
but
at
least
we
won't
have
to
worry
about
foreign
validation.
F
H
F
A
A
G
A
F
A
H
A
D
F
A
H
D
It's
not
see,
that's
the
thing,
but
it
it
is
a
a
group
of
things
that
collect
information
and
then
gets
submitted
to
the
server
right
so
like
theoretically,
it
should
be,
but
this
the
if
you
scroll
up
a
little
bit
the
approval
stuff.
We
have
these
like
little
individual,
edit
buttons
that
make
the
field
editable
and
then
it.
H
A
H
A
F
H
A
H
A
That
one
is
very
weird
because
that's
that's
one
that
I
worked
on
depending
on
where
you're
editing
it
from
the
app
sometimes
it's
submitting
as
a
controller
action
and
sometimes
it's
submitting
as
an
API.
So
when
it's
a
controller
action,
we
have
to
mount
whatever
model
that
we
normally
just
submit,
gets
mounted.
I
create
a
separate
component
as
like.
Here's
all
our
hidden
inputs
to.
G
D
A
A
A
You
know
what
it
would
be
cool.
You
know
what
we
might
be
able
to
do
all
right
or
we're
over
engineering
this
and
and
it's
and
it's
time,
but
one
thing
bothered
me
because,
like
yeah,
what
if
we
have
a
form-
and
we
want
to
use
two
instances
of
form
Fields,
like
that's
gonna-
be
so
wild?
Let's
just
ignore
that.
F
Yeah
I'd
like
to
take
a
look
just
so
you're
aware
like
when
I
kind
of
proposed
the
other
solution
which
I
don't
like
anymore
I
like
this
better
but
anyways,
I
kind
of
asked
for
feedback,
and
there
were
some
people
that
were
interested
in
kind
of
taking
a
look
at
some
third-party
libraries
and
I.
Don't
know
if
we
want
to
just
say
like
we
should
look
into
that
as
well
or
we
should
go
with
this,
but
it
might
be
worth
just
like
kind
of
taking
a
look
just
to
it.
A
F
Just
making
you
aware
that,
like
there's,
definitely
some
people
out
there
with
opinions
that
a
third
party
Library
might
be
a
better
solution,
but
I
don't
know,
and
there
is
also
an
RFC
about
adding
a
validation
Library.
So
that's
kind
of
why
I
bring
it
up
this
like
in
the
past.
It
has
been
like
something
where
we're
trying
to
get
everyone's
input
yeah
before
we
go
a
direction
which
we
never
actually
kind
of
did
really.
So
just
so,
you
know
yeah.