►
From YouTube: Discussion on how to make Package Pajamas Only
Description
Kicking off a Package Stage OKR, we discuss the process of creating or expanding Pajamas Components so everything in the Package UI is built using Pajamas Components. https://gitlab.com/gitlab-org/gitlab/-/issues/233116
A
B
B
The
reality
is
that
a
lot
of
times
I
have
a
bunch
of
these
videos,
and
I
forget
what
they
are,
so
I
just
add
a
little
introduction
to
the
first
part
of
each
one.
It
makes
it
easier,
so
we
have
an
issue
for
the
package
ui.
We
did
an
audit.
I
had
the
front
end
team
come
in
look
through
the
code
and
find
things
that
weren't
already
standard
components
we
identified
them
and
now
we're
trying
to
figure
out
how
to
move
forward.
B
B
A
Yes,
it's
the
same,
I
think
that's
a
great
question
because
looking
at
what
you
have
there
for
this
form
right
for
these
four
components,
I
think
we'll
be
worth
investigating.
If
we
could
create,
I
don't
know
a
potential
update
on
existing
components
or
if
yeah,
you
need
something
completely
new
like
the
one.
You
call
a
data
well
right.
I
think
this
is
really
it's
kind
of
could
be
reusable,
for
example,
for
the
merge
request
page
where
you
see
that
summarized
data,
but
it
could
behave
as
expanding
collapsing.
A
Then
you
already
have
a
different
component
in
the
background,
but
in
a
short
answer:
yes,
if
you're
creating
a
new
component,
ideally
you
create
a
new
proposal,
a
new
issue,
and
then
you
have
I'm
going
to
send
you
this
page
here
the
component
life
cycle
that
this
proposal
should
follow.
So,
if
you're
creating
something
new
from
the
scratch,
it
goes
to
the
create
process.
A
B
B
A
B
Is
there
a
process
in
place
for
being
able
to
find
all
of
those
instances?
So,
for
example,
the
data
well
exists
in
the
mr
page
outside
of
package,
and
it
is
in
the
commit
page
as
well
commit
detail
page.
Is
there
a
process
to
find
and
document
all
of
those,
or
is
this
kind
of
you
have
to
explore
the
product
to
find
it.
A
Yeah
you
have
to
explore
it.
I
had
this
issue
when
I
was
looking
at
your
description.
I
was
like
okay.
How
does
this
component
behave
right?
So
you
have
a
screenshot,
but
I
don't
know
exactly
where
it
lives
in
the
product.
So
when
I
was
working
on
components
a
couple
of
months
ago,
what
I
did
for
the
environments
dashboard
was
to
say:
okay,
this
is
how
the
ui
is
going
to
look
like
right.
A
It
was
a
cart
which,
like
a
pipeline
list,
avatar
whatever
within
that
component
and
then
I'll
just
say,
okay,
so
within
this
card
to
build
this
card,
we
need
to
use
all
these
components.
Avatar
list
link
pipeline
view,
whatever
so
they're
all
gonna
live
within
this
one,
but
because
it's
so
contextual
I
don't,
we
don't
really
have
a
process
for
yeah.
Here's
how
everything
on
this
page
we
look
like
yeah,
okay,
it's
a
big.
B
B
So
I
could
maybe
provide
an
example
when
you're
looking
at
a
list
component,
the
current
list
component
is
kind
of
an
ordered
list
or
it
might
have
an
action
on
the
side,
but
on
the
package
team.
Most
of
our
display
is
in
this
list
format
and
it's
a
lot
more
robust,
so
this
would
be
taking
the
existing
list
component
and
adding
additional
attributes
that
could
include
there's
the
primary
line
metadata
attached
to
it,
the
right
data
well
left
and
a
button.
B
A
It
makes
sense,
I
would
say
yes
and
no,
because
I
don't
have
to
go
over
everything
right.
Let's
say
that.
Imagine
that
you're
you
want
to
expand
this
list
view,
but
pajamas
as
in
the
documentation,
already
supports
that
it
says
that
the
list
should
be
flexible
and
that
you
should
add,
you
should
be
able
to
add
more
options,
more
buttons
whatever,
but
that's
not
specified
it.
A
Doesn't
it's
not
reflected
in
the
gitlab
ui
component
or
the
sigma
files,
so
I
think
you
have
to
very
big
there
and
then
kind
of
compare
your
vision
for
this
list
with
what
we
have
right
now
and
then
describe
how
that's
going
to
work
in
pajamas.
That's
why,
in
a
way,
it's
easier
to
have
one
epic
for
the
component
and
have
create
meal
style
integrate,
because
then
you
can
see
okay.
A
What
do
I
need
to
make
this
component
complete
and
approved
and
integrated
in
pajamas,
because
I
think
the
the
biggest
challenge
is
to
understand?
If
one
can,
I
use
this
in
pajamas
to
does
this
exist
today,
and
is
it
reusable
right?
Yes,
one
of
the
things
that
we
do
are
very
in
context
with
the
stage
groups.
So
if
it's
an
update
in
an
existing
component,
I
would
say
still
has
to
go
through
the
process,
because
you
need
to
update
all
these
instances
in
files,
documentation,
etc.
B
Especially
for
the
list
view,
because
the
way
we've
styled
the
list
view
in
the
package,
ui
is
very
similar
to
some
other
lists
that
we've
seen.
I
think
the
issue
list
could
be
one
where
you
have
the
main
title
metadata
underneath
it
and
then
data
on
the
left
hand,
side
sorry
right
hand
side.
So
that
makes
a
lot
of
sense.
Yeah.
Thank
you.
A
A
No
I'm
just
kind
of
on
this
the
same
line
if
it's
a
visual
change,
for
example.
This
list
right,
I
think,
who
left
a
comment.
One
of
your
developers
left
a
comment
in
the
issue
saying
that
you
cannot
really
use
the
list
paginate
list
because
it
doesn't
really
work
yeah.
This
comment
yeah
with
package.
So
if
you
cannot
use
the
paginate
paginate
list,
then
what
are
you
using?
Are
you
creating
a
list
just
for
package
or
should
developers
in
a
way?
Try
to?
I
don't
know,
improve
the
existing
component
so
that
you.
B
Yeah,
so
that's
a
really
good
question
for
the
next
part
of
our
conversation.
I
kind
of
wanted
to
go
through
the
four
items
and
discuss
your
feedback
as
well
as
how
to
move
forward
with
it.
So
we'll
capture
that
conversation
about
whether
we
should
create
a
new
thing
or
expand
on
what's
already
there
when
we
get
to
listview.
Does
that
work
for
you?
B
B
B
B
Right
now,
it's
actually
a
custom
thing
called
a
data.
Well,
it
was
this
correctly
yeah.
So
it's
an
info.
Well,
I
am.
I
apologize
info,
well,
not
data,
while
I'm
happy
to
change
my
normal
glacier,
but
it
is.
It
looks
anyway
like
a
unique
thing
that
doesn't
isn't
it
pajamas
component
or
view
component
yet
so
I
know
it
needs
to
be
added
regardless.
A
Yeah,
semantically
speaking,
if
I
look
at
this,
I
would
I
would
build
this
as
a
list.
You
know
this.
This
could
be,
for
example,
a
card
component
with
the
list
component
within,
but
without
the
headers
without
the
footer.
So
this
is
a
conversation
I
think
we
have
to
have
with
the
engineers,
because
they're
gonna
kind
of
try
to
validate
these
assumptions,
but
just
looking
at
yeah
there's
a
bunch
of
divs
inside
right,
well
segments
branch
info,
yeah
yeah,
so
it's
a
so
even
a
list
component
per
se,
it's
just
a
wrapper!
A
A
A
B
In
order
to
figure
this
out,
would
I
create
a
new
pajamas
issue
or
start
that
component
conversation
and
then
ping?
Someone
in
foundations
be
like
we
have
this
thing
in
the
ui
or
we
need
this
thing
in
the
ui.
Should
it
be
its
own
like
data?
Well,
should
be
a
thing
or
is
it
an
alternative
version
of
the
list
view
and
that's
how
we
should
figure
out
where
it
should
go,
is
kind
of
start
that
conversation.
A
But
I
think
it's
also
good
to
have
in
mind
the
reusability
of
this
component
that
we
I
mean
we
look
at
it.
I've
seen
this
thing
so
many
times
across
the
product.
It's
reusable
right,
but
it
doesn't
mean
that
it
needs
to
be
a
component
and
I
think
that's
a
conversation
you
need
to
have,
because
if
I
look
inside
of
it
it
has
a
bunch
of
small
components.
A
You
know
the
it
has
the
the
links
it
has.
The
pipeline
thingy,
the
the
with
the
icons-
and
you
could
build
this
as
a
list
list
item
styled
as
whatever
card,
or
something
like
that.
So
I
would
say
I'd
say
it's
good
to
have
this
issue
or
have
this
initial
questions
is
your
thoughts
there,
because
I
think
what
we
need
to
do
is
to
have
someone
with
the
engineering
background
or
the
foundations
or
gitlab
ui
background
to
help
clarify
these
questions.
A
B
Okay,
so
for
the
data
well,
the
first
step
is
identify
how
we're
going
to
update
pajamas,
whether
it's
a
new
component.
That's
a
data
well
or
if
it's
an
alternative
list
view
bring
in
someone
from
foundations
or
and
or
engineering
to
talk
about
the
best
way
to
build
it
and
then
make
the
decision
from
there
I'll
jump
into
the
next
thing,
because
this
is
another
example,
the
timeline
or
activity
feed
which
looks
like
this
and
if
you've
ever
seen,
an
issue
ever
you've
seen
this
before
it's
shockingly,
not
in
pajamas.
B
B
B
A
B
Perfect,
the
next
one.
Oh
sorry,
when
we're
talking
about
creating
these
issues,
do
you
create
an
issue,
get
a
response
and
then
build
those
four
stages,
the
issues
of
four
stages
for
the
epics
and
the
sub
issues
that
go
into
them?
Or
do
you
wait
until
you
get
a
response
and
then
build
the
rest
of
those
stages
out?
That's.
A
But
you
need
to
know
that
we
are
introducing
a
new
component
and
another
good
thing
is
that
when
you
create
an
initial
with
a
proposal
for
components,
there
is
a
template
that
you
can
use
for
the
issue
and
there's
a
bunch
of
check
boxes
there
telling
you
exactly
what
you
need
to
do
like
update
figma
file
here,
add
documentation,
ping,
maintainer,
etc.
So
you
can
refer
to
it
for
the
for
the
steps.
B
That's
wonderful
thinking
through
the
fact
that
I
have
four
of
these,
that
I'm
just
gonna
hit
the
ground
running
and
get
all
four
out.
Should
I
create
four
unique
issues
for
each
of
them
and
then
get
the
response
and
build
them
out,
or
should
I
have
one
like
hey
everyone?
I
have
a
bunch
of
questions
issues
which
is
going
to
be
more
more
well
received
by
the
team.
A
B
A
B
To
measure
that
make
total
sense
all
right
back
to
that
list
component,
this
one
as
we've
had
this
conversation.
Let's
see
if
I
understood
definitely
feels
like
we
should
take
the
list
component
that
already
exists
and
expands
upon
it
to
include
all
the
different
different
artif
pieces
that
we
include
in
our
list.
My
question
is-
and
maybe
this
could
go
in
that
initial
issue
as
a
question-
should
we
create
one
new
component?
That's
a
complex
list,
and
so
it
matches
everything
that
we've
seen,
which
this
is
actually
the
most
complicated
list.
B
I've
seen,
which
is,
it
has
a
header
or
a
main
title,
and
it
has
metadata
on
the
left
hand,
side
the
right
hand,
side
has
metadata
top
and
bottom
and
then
there's
actions
on
the
right
and
that,
I
think,
includes
every
permutation
I've
seen
in
the
list
view.
Do
we
create
one
component?
That
is
the
complex
list
and
you
and
engineers
can
not
have
or
disable
things
or
not
include
things
from
there.
B
Or
should
we
get
one
that
has
matches
the
issues
where
it
is
just
the
metadata
on
the
left
and
one
piece
on
the
right,
and
then
we
create
another
one.
That's
metadata
on
the
left
metadata
on
the
right
and
then
the
third
one,
that's
metadata
on
the
left,
metadata
on
the
right
and
a
button
or
actions
on
the
right,
which
makes
more
sense.
A
It
doesn't
matter
that,
like
having
two
components,
doesn't
really
matter
right
doesn't
make
sense,
because
you
have
one
list
and
you
can
have
it
at
least
an
avatar,
yes
or
no
like
what
you're
seeing
enable
or
disable
you
can
have
a
button
to
the
on
the
right
or
you
will
always
have
an
action
button
on
the
right,
but
some
lists
are
not
gonna.
Have
that.
So,
from
a
ui
point
of
view,
I
would
say
it's
the
same
component
but
you're
kind
of
powering
off
that
list.
You're.
A
But
for
engineers-
and
I
would
assume
that
they
will
also
just
extend-
or
you
know,
add
more
functionality
to
that
existing
list,
but
I
think
it's
a
conversation
to
have
with
them.
Do
you
want
to
separate?
Why
do
we
have
a
passionate
list
and
a
static
list?
You
know,
as
we
have
from
the
point
and
if
that's
something
that
is
super
critical,
it's
more
on
the
developer,
the
development
side,
but
the
design
of
the
list
is
still
the
same.
You
follow
the
same
guidelines.
A
B
A
A
Yeah,
because
if
it's
an
update
to
an
existing
component,
it's
a
small
change
like
in
in
this
case
right
where
you're
adding
complexity
in
a
way
it's
a
small
change,
you're
not
seeing
now
the
list
is
whatever
upside
down.
You
could
have
just
an
update
to
the
figma
kit.
You
know
with
those
variations,
maybe
some
updates
in
the
design
documentation.
A
B
A
B
A
And
discuss
the
usage
discuss
already
like
okay,
this
is
the
scenario,
and
this
is
how
the
component
will
behave.
This
is
how
it
would
affect
responsiveness,
you
know,
and
have
that,
like
kind
of
the
core
of
the
proposal
there,
because
it
might
be
that
the
change
is
so
small
that
you
just
change
documentation.
You
know
I
see
yeah.
That
makes
sense
for
the
design
part.
B
A
This
one
we
have
the
epic
like
when
I
when
you
mention
the
code.
I
was
like
all
of
them
so
because
we
already
had
discussions
actually
worked
on
some
of
the
documentation
for
the
code
snippet
and
the
just
the
code,
the
inline
code.
So
I
went
ahead
and
created
this
this
epic,
with
all
the
steps
and
the
existing
issues,
because
we
already
discussed.
B
A
In
the
past,
so
this
is
definitely
something
that
it's
used.
You
know
in
different
parts
of
the
product
and
you
well
you.
You
definitely
need
to
do
the
create
step,
which
is
adding
this
to
the
ui
library
and
same
document,
build
and
then
integrate,
but
this
one
this
is
the
one
that
seems
the
most
straightforward.
Okay,
it's
code,
snippet.
B
A
Could
potentially
be
you
could
put,
I
think
you
would
start
with,
let's
say
the
static
version
right
of
the
code
snippet
and
then
you
can
already
have
another
issue
or
have
the
design
proposal
for
how
it
looks
like
when
it's
I
know,
expanded
or
whatever,
with
the
interaction,
but
it
it's
just
like.
Let
me
open
it
up
here.
It's
just
like
the
we
got
so
many
components,
sometimes
different
things.
A
B
B
A
A
Propose
this
separately,
because
it's
gonna
make
your
life
so
much
easier
people
can
review
focus
on.
You
know
the
bare
minimum
that
what
you
need
for
now,
because,
from
my
experience,
this
design
reviews
they
tend
to
go.
You
know
they
can
extend
a
little
bit
outside
the
scope
of
what
you
want
for
now,
so
I'll
say,
separate
these
issues
and
only
open
the
create
build
style
integrate
as
later
on
once
you
have
okay.
B
Complicated
code,
I
apologize
I'm
taking
notes
as
a
summary,
and
then
we
can
let
you
get
to
your
meeting.
So
I'm
not
totally
disrupting
your
day.
Datawell
the
timeline
and
the
list
component
all
need
new
issues
in
pajamas
that
say
in
the
pajamas
project.
That
is
a
description
of
what
change
I
want
to
make
to
pajamas
and
then
that
should
open
up
the
question
to
foundations
and
engineering
about.
Is
this
an
extension
of
existing
components?
Is
this
a
whole
new
component?
How
like?
B
How
do
we,
as
a
group,
feel
that
we
should
move
this
into
pajamas
code
instructions?
I
need
to
work
on
the
create
stage,
because
it's
already
there
and
a
lot
of
people
have
already
talked
about
it
and
then
create
a
new
issue
in
the
pajamas
project.
That
is
the
code
instructions
on
steroids,
I'm
quoting
correctly.
A
That
makes
total
sense
and
if
you
have
any
questions
on
like
where
should
I
go
next
or
what's
the
workflow?
This
is
the
same
page.
I
said
before
so
have
a
look
at
this
workflow
because
it
says
okay.
This
is
my
next
step
in
the
process.
So,
if
you're
doing
a
component
open
the
issue
make
sure
you
have
a
visual
proposal
there
on
figma,
because
it's
always
easier
to
discuss
when
we
have.
You
know
the.
B
B
B
A
Is
a
reviewer
or
you
can
being
a
maintainer,
so
tori
pedro
nai.
You
can
also
tag
jeremy
because
I
know
if
you
want
to
talk
about
the
ui
so
feel
free
to
to
ping
me
there.
Okay
and
then
we
can
involve
the
conversation
or
I
see
people,
I've
seen
people
thinking
all
designers
using
you
know
the
the
gitlab
ux
to
get
feedback
for
more
people,
but
it's
really
really
up
to
you,
perfect,
okay!