►
From YouTube: Encapsulating Ruby on Rails views - Open Source Friday
Description
With the recent release of version 6.1, Ruby on Rails now supports the rendering of objects that respond to render_in, a change we introduced to the framework. It may be small (the two pull requests were less than a dozen lines), but this change has enabled us to develop a framework for building encapsulated views called ViewComponent.
https://github.blog/2020-12-15-encapsulating-ruby-on-rails-views/
https://github.com/github/view_component
0:00 - Start
1:18 - What is a Rails ViewComponent
5:20 - What inspired this?
8:11 - Adoption at GitHub
10:53 - How does interact with design systems?
17:08 - Who else is using this?
23:48 - Contributions in the wild
26:42 - CSS in JS
35:00 - Rails open source conventions
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
A
B
A
Yeah
sure
so
my
name's
joel
I'm
an
engineer
at
github.
I've
been
working
here
since
2018..
I
work
on
a
team
called
design
systems.
We
own
really
it's
a
system
of
systems
like
all
the
tools
that
people
use
to
build
user
interfaces
at
github,
whether
it's
mobile,
apps
or
icons,
or
we
have
a
css
library
that
you
can
kind
of
think
of
as
something
like
bootstrap.
We
have
react
components
and
we
also
have
what
are
called
view
components
and
that's
what
we'll
be
talking
about
today.
A
We,
my
main
role
at
the
company,
is
to
work
as
the
lead
maintainer
of
the
view
component
framework
and
basically
the
corresponding
internal
work
around
the
project.
I
invented
view
component
in
late.
I
guess
it
was
in
2019
yeah
and
I've
been
working
on
it
ever
since
in
an
increasingly
full
capacity.
It
is
now
my
and
has
been
my
full-time
job
for
about
a
year,
but
it
was
like
a
side
project
when
I
first
got
started
on
it.
A
Sure,
yeah,
you
can
switch
to
my
screen
and
I
can
I
can
do
some
demos.
So
if
you
this
conversation,
obviously
assumes
that
we're
you
are,
if
you
all,
are
watching
you're,
somewhat
familiar
with
ruby
on
rails.
Is
it's
a
web
framework
for
building
web
applications
written
in
ruby
and
a
it
uses?
What's
called
the
mvc
framework,
so
in
rails
applications
you
have
models
that
inherit
from
action
view
base.
A
You
have
controllers
that
inherit
from
action
controller
base,
but
when
you're
writing
templates,
they
are
not
inheriting
from
any
rails
construct.
They
are
written
as
something
like
an
erb
or
a
slim
file.
So
at
a
very
high
level
of
view
component
is
it's
a
way
to
express
your
views
using
objects
like
you
would
express
models
as
objects
and
controllers
as
objects?
So,
if
you
think
about
it
that
way
at
the
highest
level,
if
you're
familiar
with
react,
a
lot
of
the
work
we've
done
on
view
component
is
a
direct
inspiration
of
working
in
react.
A
So
what
we've
really
kind
of
our
philosophy
on
the
project
has
been
react
is
doing
all
these
great
cool
things
and
it's
causing
some
people
to
want
to
use
react
instead
of
the
traditional
rails
view
stack.
So
how
might
we
take
some
of
those
cool
ideas
and
bring
them
back
into
rails
in
a
way
that
makes
sense
for
the
framework
so
view
component
is
kind
of?
A
A
So
a
view
component
is
really
two
files:
it's
a
ruby
file
and
a
and
a
traditional
template
that
sits
right
next
to
it.
So
you
can
do
ruby
object
things.
You
can
have
a
an
initializer.
You
can
include
modules,
you
can
do
all
sorts
of
things.
You
can
have
private
methods,
all
the
things
you
know
and
love
about
working
in
ruby.
A
You
can
do
in
view
components
and
then,
alongside
the
ruby
file,
you
have
a
template
that
looks
fairly
traditional
and
then
together
what
you
end
up
doing
with
the
view
component,
is
you
instantiate
it
and
you
pass
it
to
railsrender
method?
This
is
a
change
that
was
added
to
rail61
that
I
get
have
contributed
to
the
framework,
so
you
instantiate
a
ruby
object
and
you
pass
it
into
render
and
then
it
returns
the
rendered
output.
B
B
Component
archit,
like
basically
the
idea
or
the
hypothesis
for
how
to
leverage
components,
have
kind
of
spread
in
other
javascript
frameworks.
So
it's
cool
to
see
this
here
in
the
the
render
method,
but
also
super
cool,
to
hear
that
github
contributes
back
to
rails
itself
too,
as
well,
because
we
do
build
a
lot
of
our
platform
on
rails.
A
A
It
wasn't
in
the
end
a
lot
of
lines
of
code,
but
it
was,
you
know,
significant
changes
that
allowed
us
to
do
this
without
doing
what's
called
a
monkey
patch,
where
you
just
like,
basically
go
in
and
rewrite
part
of
part
of
rails
like
in
your
own
application.
That
was
pretty
messy.
We
do
have
that
monkey
patch
if
you're,
using
like
an
older
version
of
rails.
So
this
one
really
interesting
aspect
of
this
framework
is
that
we
have
implemented
it
in
a
very
backwards
compatible
fashion.
A
B
A
Yeah,
it's
it's
been
really
kind
of
poetic
because,
like
what's
been
really
fun,
is
that
because
we're
trying
to
take
ideas
from
react
and
bring
them
into
rails,
we're
ending
up
with
that
kind
of
dynamic
internally
at
the
company?
So
like
on
my
team,
we
build
view
components
that
people
then
reuse
throughout
the
company.
A
That's
the
prime
review
components,
library,
and
we
also
have
a
team
that
builds
the
react
components
that
you
just
said,
you're
familiar
with
from
your
demos
yeah,
but
we
actually
have
a
lot
of
collaboration
between
the
two
teams
and
like
trying
to
make
our
apis
like
named.
This
like
feel
the
same
way
so
that,
like,
if
you
were
to
drop
into
our
our
rails,
stack
that
you
would
be
right
at
home,
even
though
you're
using
a
different
technology.
B
Yeah,
that's
great
to
hear
and
folks
it
seems
like
people
are
really
digging
this
so
far.
So
if
anybody
has
any
questions
on
the
approach
or
how
we
implement
this
at
github,
joel
is
here
as
an
engineer
at
github
and
is
happy
to
address
any
questions
as
well,
which
is
the
one
question
why
twitch?
Because,
because
you're
here,
that's
why
we're
using
twitch.
A
I
I
see
another
comment
from
damian
about
how
widely
used
our
view
components
in
the
github
browse
app.
I
can
speak
to
that.
Pretty
specifically
awesome
chat
about
that,
so
we
use
view
components
a
lot
like
I
I
get
this
question
a
lot
and
people
are
often
like
this
seems
like
kind
of
like
bleeding
edge
like
how
much
are
you
actually
using
this,
and
our
adoption
is
very
significant.
I
can
give
you
an
idea.
A
Our
application
has
about
4
800
templates
in
it
about
40
of
those
templates
render
a
view
component,
so
a
good
chunk
of
our
application.
I
would
guess
that
at
this
point,
you
can't
really
load
a
page
in
the
application
without
using
a
view
component
in
some
fashion.
We
also
have
that's
in
terms
of
how
they're
used
in
terms
of
how
many
view
components
we
have.
A
B
B
Yeah
yeah
and
it
what
was
the?
I
guess,
here's
a
question
that
I
have
for
you,
which
is
the
adoption
like.
Was
it
an
easy
pill
to
swallow
for
and
so
there's
a
reason
why
I
asked
this
question
I'll
get
to
the
adoption
for
engineers
at
github,
because
a
lot
of
folks
were
rendering
templates
differently.
We
went
through
this
with
graphql,
like
a
lot
of
people,
didn't
want
to
use
the
the
data
through
graphql,
but
also
popular
opinion
from
dhh.
A
Yeah
I
mean
I
think
that
there's
been
a
couple
interesting
aspects
of
the
adoption
that
I
can
speak
to.
One
has
been
that
we
had
an
existing
abstraction
that
served
a
similar
role
called
view
models
which
are
basically
the
presenter
pattern
where
you
have
like
an
object.
You
instantiate
and
you
pass
down
into
it,
and
then
it
exposes
some
methods
and
but
you
just
pass
that
one
object
into
a
template
and
it
interacts
with
them.
So
it's
kind
of
like
just
the
ruby
part
of
a
view
component
and
not
the
template.
A
Part
like
it's
just
this
top
this
top
bit
and
not
this
bit.
So
for
a
lot
of
teams.
The
path
was
pretty
simple
to
just
like,
take
existing
view
models
and
convert
them
into
view,
components
and
the
reason
that
was
important
for
these
teams
that,
like
really
drove
adoption,
was
that
when
you
test
a
view
model
you're
generally
testing
the
instance
methods.
So
you
could
imagine
if
this
was
a
view
model,
you
might
have
a
method.
That's
like
def
title.
A
So
when
you
would
test
that
view
model,
you
would
assert
that
title
is
equal
to.
You
know,
like
my
title
and
as
a
string
or
something
like
yeah
the
different.
The
problem
is,
though,
is
that
that
doesn't
actually
make
sure
that,
like
what
you
rendered
on
the
page
is
at
all
correct,
like
what
you're
showing
to
users
is
correct
and
typically
in
rails.
You
would
do
that
with
like
a
test
where
you
open
up
a
browser
and
like
look
at
the
page
and
be
like
okay.
A
B
A
A
B
The
there
was
one
question:
oh
so
damian
actually,
and
he
previously
was
the
one
that
was
had
the
revelation
about
react
and
using
react
or
using
components
or
basically
paying
attention
to
it,
which
is
his
question
is
how
do
other
view
components
interact
with
primer
view
components?
Are
there?
Are
they
using
inheritance?
Are
you
combining
them
in
templates
or
some
sort
of
component
objects.
A
B
A
That's
a
great
question:
composition
versus
inheritance
is
a
classic
oo
question.
So
we
do
composition.
Is
the
one
is
like
the
one
sentence
answer,
but
I
can
maybe
provide
a
little
more
color
about
how
we
think
about
it,
which
is
that
it's
really,
we
think
of
components
as
falling
into
one
of
two
specific
approaches.
A
Those
are
what
we
call
like
domain
specific
components.
Those
are
none
of
those
are
open
source,
but
then
we
write
a
second
kind
of
component,
which
is
the
prime
review
components
which
are
the
opposite.
They
have
nothing
to
do
with
the
domain,
but
they
have
to
do
with
a
certain
design
pattern.
So
one
example
would
be
like
a
like
a
blank
slate
component,
which
is
the
component
we
display
when,
like
a
page,
is
empty.
A
That
has
nothing
to
do
with
any
specific
domain
with
any
specific
domain
model,
so
you
might
have
a
repository
blank
slate
that
wraps
the
primer
blank
slate
that
composes
over
it.
So
what
we
end
up
having
is
we
have
a
lot
of
domain,
specific
components
that,
under
the
hood,
use
one
or
more
of
the
primer
view
components
to
build
up
the
design,
okay,
cool
yeah.
A
We
do
a
ton
of
that,
that's
like
that's,
basically
how
we
do
it,
and,
and
so,
whenever
we
have
a
generic
component
that
isn't
coupled
to
a
specific
part
of
the
domain,
we
put
it
in
primer
and
open
source.
So
what
you
see
in
the
prime
review
components?
Library,
is
all
these
patterns
that
we've
realized
have
nothing
to
do
with
any
specific
domain
model
at
github,
and
it's
our
really
just
general
purpose.
B
A
You
can't
yeah
those.
Actually,
this
is
open
source
friday.
This
is
a
great
open
source.
Friday
story
contributor,
one
of
the
contributors
to
the
framework.
His
name
is
john
palmer
who
lives
in
boston.
He
I
believe
he
actually
contributed
the
change
to
storybook
to
allow
server
rendered
components
and
then
wrote
a
gem.
You
can
use
with
view
component
to
use
it
with
storybook
so
for
prime
review
components.
If
you
go
to
the
primary
duponts
docs,
we
have
storybook
integrated.
B
A
A
To
say,
like
this
test
makes
three
database
queries
and
that's
not
something
that
we
previously
had
for
writing
view
code,
and
it's
really
enabled
people
to
recognize
like
like
be
forced
to
recognize
that
their
view
code
has
database
side
effects
which,
in
the
rails
context,
is
generally
not
a
good
thing
like
it's.
It
can
be
okay,
sometimes,
but
it's
something
you
want
to
be
aware
of.
A
B
A
A
Our
intention
design
wise,
though,
has
been
that
it
will
be
something
that
we
will
keep
as
close
philosophically
and
like
api
design
wise
with
rails.
So
that,
like
you
know,
say
we
land
on
v3
or
v4
and
we're
super
happy
with
it,
and
the
community
is
happy
with
it
that
it
will
be
an
easy
sell
that
it
will
be
like
an
easy
migration
into
rails.
In
its
current
state,
though,
I
don't
think
it's
ready.
A
The
main
reason
is
that
when
you
use
view
components,
it's
like
a
separate
folder
like
rails
applications
all
have
a
view
folder,
and
this
is
different,
and
I
think
that
that
would
be
really
confusing
to
news
new
rails
developers
like
you,
wouldn't
want
them
to
come
into
a
project
and
be
like
wait.
What
do
I
put
in
views?
What
do
I
put
in
components
like?
What's
the
difference
like
yeah.
B
If
this
is
where
this
would
make
it
to,
you,
know
upstream
rails
and
as
part
of
like
what
comes
with
rails
new,
it
had
to
be
a
lot
of
decisions
and
perhaps
have
to
come.
I
think
rail
seven
is
here
and
have
to
come
as
like
a
rails.
Eight
thing
well,
this
is
what
my
thought
is
is
probably
would
like.
We'd
want
to
wait
until
this
is
a
thing
and
convinced
that
more
than
just
github
or
other
large
companies
are
going
to
be
able
to
benefit
from
this,
which
is
my
question.
A
I
mean
this
is
honestly
the
paradox
of
open
source
yeah,
it's
so
hard
like
so
like
we
build
this
project.
We
have
over
100
people
who
contributed
to
it.
The
used
by
on
the
sidebar
says
like
500,
but
that's
only
open
source
yeah,
so
yeah.
If
you
scroll
down
to
the
side
like
you
see,
yeah,
there's
over
500
used
by
and
we
have
over
100
contributors
like
I
know,
and
I've
spoken
to
some
people
privately
like
because
you
said
oh
dfe
is
probably
the
coolest
one.
A
That's
the
uk
government
department
for
education,
okay
they're,
they
they're
using
it
and
they
actually
have
their
own.
Like
view
components,
library
they
they
publish,
but
I
actually
it's
tricky
because,
like
I
can't,
I
know
some
places
that
are
using
it.
But,
like
it's
been
told
to
me
in
confidence
like
a
lot
of
people,
a
lot
of
companies,
they
don't
talk
openly
about
their
tech
stack
and
I
respect
that,
like
that's,.
A
B
A
Yeah
I've
heard
of
a
heard
from
a
couple
people
that
are
doing
it.
There's
one
I
can
there's
one
financial
services
company
that
is
using
it.
They've
built
an
internal
design
system
and
they're
using
it
in
like
20
rails
apps,
or
something
like
that,
which
is
amazing,
they're,
actually
reusing
their
design
more
than
we
are
at
github,
yeah
yeah.
There's
a
there's
a
lot
of
people
doing
systems.
I
think
someone
started
to
build
a
bootstrap
view
component
implementation,
but
I
don't
think
they
finished
it.
A
What
I've
been
hearing
from
people
is
that
generally
people
do.
This
is
an
internal
thing
kind
of
like
we
basically
open
sourced
our
internal
view
components,
but
a
lot
of
people
are
doing
kind
of
what
you
see
in
primary
components.
I
get
a
lot
of
questions.
I
get
almost
as
many
questions
about
that
repo
as
about
the
framework,
because
a
lot
of
people
are
at
that
point
where
they're
like
okay,
we
want
to
do
the
same
thing
you're
doing
for
prime
review
components
like
what
have
you
learned
like
what
you
do?
B
Yeah,
that's
it.
I
mean
that's
fascinating,
to
hear
that
too,
as
well,
because
the
I
think
it
sounds
like
a
lot
of
folks
are
trying
it
out,
regardless,
if
they
publicly
talk
about
their
tech,
stack
and
stuff
like
that.
But
it's
got
to
feel
pretty
good,
though,
to
have
an
idea.
Have
it
get
some
adoption
at
the
company
you
work
for
and
then
get
adoption
and
other
companies
and
other
developers
sort
of
like
leveraging
it.
B
A
Oh
gosh,
it's
the
thing
is
it's
been
such
a
slow
boil.
Yeah
like
the
temperature,
has
been
rising
slowly
since,
like
gosh,
I
put
I,
I
built
a
prototype
in
december
2018.,
it's
been
a
long
time.
That's
that's
a
long
time
in
technology
I
mean
it
started
out
as
a
little
prototype.
We
tried
it
a
couple
places.
A
I
worked
on
it
with
aaron
patterson
tenderlove
worked
at
github
at
the
time
and
he
provided
a
lot
of
the
like
really
core,
like
technical
underpinning
work
at
the
beginning,
and
we
just
kind
of
did
a
it's
been
a
really
honestly
a
slow
process.
It
hasn't
been
like
some
like
overnight
switch.
We've.
We've
attacked
it
in
many
different
directions.
Like
some
of
it
was
at
the
start.
It
was
really
curiosity
driven.
It
was
like
we're
doing
it
and
some
people,
the
company,
would
see
we're
doing
it.
A
A
Okay,
the
the
level
of
curiosity
was
well
aligned
with
our
level
of
attention.
We
could
give
the
project
and
honestly
that
really
hasn't
changed.
It's
just
that.
There's
been
more
curiosity
and
there's
more
people
working
on
it
like
we
now
have,
depending
on
how
you
count
it
for
people
working
on
it,
full-time
plus
many
other
people
who
are
like
strongly
involved
in
the
project,
both
in
the
community
and
at
github
that
are
just
like
they
make
contributions
here
and
there,
but
it
really
has
been
like
fairly
organic
there.
A
B
A
B
A
We're
we're
in
it
for
the
long
haul
we're
the
way
we
think
about
maturity
has
to
be
different
than
like
a
startup.
That's
building
something
new.
You
know
we
have
all
this
code.
That
is
what
I
like
to
call
revenue
code,
not
legacy
code.
We
have
a
bunch
of
revenue
code
that
exists
and
needs
to
be
maintained,
and
we
need
to
make
engineering
decisions
in
light
of
that
fact,
so
that
to
me
changes
the
time
horizon
I
operate
on,
I
operate
on
like
a
five
year
time
price.
A
When
I
think
about
my
work,
I'm
not
like.
What's
the
new
hot
thing
we
can
ship
today,
let's
get,
let's
like
experiment
with
this
thing
and
get
it
out
tomorrow
like
we
need
to
be
much
more
intentional,
because
everything
we
do
just
gets
magnified
over
this
gigantic
rails.
App
like
nothing,
is
small
once
it
becomes
mature
here
I
mean,
I
think
that
one
of
our
core
engineering
philosophies
here
is
that
we
try
to
we.
A
One
of
the
things
we
optimize
for
is
the
ability
for
people
to
come
into
the
company
be
productive
in
the
application
like
for
a
long
time.
We
made
it
the
goal
that
every
new
engineer
made
a
production
deploy
in
their
first
week
and
to
have
an
engineering
organization
and
architecture
that
enables
that
requires
you
to
use,
I
should
say,
requires,
but
like
pushes
you
towards
using
technologies
that
are
more
public
than
private,
so
we
learned
a
big
lesson
with
our
use
of
rails.
We
were
on
rails
fork
for
a
long
time.
A
Many
people
who
are
watching
this
are
probably
familiar
with
either
chantel's
talk
on
how
we
went
from
a
rails
fork
to
being
on
rails
maine.
But,
having
seen
that,
like,
I
literally,
I
think
she
gave
that
talk
the
spring.
I
gave
my
railsconf
talk
at
in
minneapolis.
I
think
she
gave
that
it
was
the
same
same
one,
so
that
is
a
really
important
context
for
why
we
open
sources
project
very
early
on
was
that
we
didn't
want
to
end
up
in
a
situation
where
we
were
developing
this.
A
It's
been
like
a
really
cool,
like
I
think
the
term
win-win
is
cliche,
but
it
really
has
been
that
kind
of
situation
where,
like
we
have
benefited
from
a
company
from
by
open
sourcing
it
and
the
community,
I
believe,
has
benefited
quite
a
bit
by
us
doing
the
same.
So
it's
very
mutual
yep
there
you
go
so
you
can
see
that
has
a
little
banner.
It
says
this
component
uses
javascript,
so
if
you
you
can
actually,
we
can
actually
check
two
things
off
the
list
at
once.
There's
a
storybook
link
there.
A
A
B
A
It
for
that,
and
then
we
are
currently
in
the
process
of
building
out
our
practices
around
doing
that
internally
in
our
application
too.
That's
for
javascript,
the
the
this
is
a
great
segue
into
contributing
to
the
project.
If
you
go
to
github
slash
view
component
and
go
to
the
pull
requests,
you
can
see
if
you
scroll
down,
there's
a
css
encapsulation
pr,
it's
877,
I
think,
seven,
seven,
six,
seven,
seven
yeah
yeah.
A
Since
march,
so
yeah
yeah,
so
so
this
is
a
proposal
we're
working
on.
This
is
actually
quite
out
of
date
at
this
point,
because
we've
kind
of
gone
back
to
the
drawing
board
internally,
but
one
of
the
things
we're
looking
at
is
you
know,
you
know,
I
said
we
were
taking
ideas
from
react
and
putting
them
into
rails
yeah,
one
of
those
ideas.
A
Well,
let
me
take
a
step
back.
We
purposely
started
with
the
ideas
and
react
that
were
non-controversial
very
easily
ported
into
rails,
like
just
we're
really
kind
of
hitting
us
over
the
head.
That
was
so
clearly
like
a
good
idea.
Yeah
we've
crossed
a
lot
of
those
off,
though,
at
this
point
so
now
we're
starting
to
look
at
some
ideas
that
we're,
like
I
don't
know
like.
Maybe
this
will
be
a
good
idea.
Maybe
it
isn't,
and
one
of
them
is
css
and
javascript.
So
a
lot
of
a
lot
of
react.
A
Applications
today
use
css
and
js
in
some
form,
whether
it's
emotion
or
any
of
these
other
frameworks.
So
we
started
to
experiment
with
trying
to
solve
the
same
problems
in
rails,
so
the
problems
are
like
encapsulation
of
styles,
like
css
is
global.
By
default.
It's
a
mess.
You
can
only
those
folks
watching
the
stream
can
probably
only
imagine
the
madness
that
is
14
years
of
custom
css
having
been
written
at
github.
Like
that's
a
lot
of
it's,
it's
just
a
lot
of
custom
css.
A
So
so
one
of
the
things
my
team
is
responsible
for
is
like
really
the
technical
data
around
that.
So
this
is
this
work
is
looking
to
see
what
ideas
from
the
css
and
javascript
landscape.
We
can
bring
two
rails
through
view,
components
and
the
the
thing
that
css
and
js
ultimately
gets
at
is
that
you
are
writing
css
alongside
your
component
and
because
you
do
that
you
can
do
some
programmatic
guarantees.
A
What
we
use
the
reason
we're
into
it
is
that
that's
what
we
use
on
the
react
side,
the
on
primer,
react
reason,
style,
components,
okay,
so
we're
starting
to
really
what
we've
been
doing
with
this.
That,
I
think,
is
fun.
Is
that
like
because
we're
on
such
a
long
time
horizon
what
we're
doing
is
we're
saying?
Okay,
react
has
spent
seven
years
in
this
space
now
at
this
point,
yeah.
A
B
A
A
We
assume
that
they
are
available
as
a
technology
for
us
to
use,
given
that
fact
how
much
of
the
css
and
javascript
learnings
really
still
apply.
We
don't
know
so
we're
trying
to
like
reconcile
like
the
current
technologies,
with
like
the
lessons
from
from
react
and
put
them
into
something
that
works.
We
do
actually
run
something
like
this
in
production
today,
it's
very
minimal,
but
we
are
actually
doing
some
production
experiments
around
this
work.
A
It's
some
settings
page,
that's
buried!
It's
it's
very
trivial.
It's
like
a
technical
proof
of
concept.
There's
nothing
like
we're,
not
even
doing
anything
that
you
couldn't
have
done
without
it.
It's
just
like.
Does
the
stack
work
got
it
it's.
It
treads
into
a
lot
of
tricky
waters
like
around
post,
css
and
web
packer
and,
like
all
these
areas,
where
we've
kind
of
intentionally
avoided
on
the
new
component
project,
but
kind
of
feels
like
an
inevitability
like
we're.
B
A
I
I
did
an
apprenticeship
at
a
at
a
software
consultancy
and
that's
based
in
rhode,
island
called
mojotec.
It
was
right,
as
boot
camps
were
starting
to
be
a
thing
yeah,
that
they
would
do
a
couple
apprenticeships
where
you
just
came
in
and
they
paired
you
with
a
senior
and
you
paired
for
like
three
months.
A
B
Yeah
I
applied
for
that,
but
I
didn't
get
it
so.
I
ended
up
just
learning
online
through,
like
the
rails
guides
and
a
ton
of
other
places.
Yeah.
That's
that's
fascinating,
but
also
I
was
gonna,
say
yeah.
It's
gonna
be
nice
to
be
able
to
do
something,
that's
kind
of
cutting
edge
like
regardless
of
this
like
well.
It
sounds
like
the
the
css
stuff
is
going
back
to
the
drawing
board,
but
it's
got
to
be
fun
to
be
able
to
like
solve
problems
and
like
event.
Solutions
too,
as
well.
A
Yeah,
I
mean
that's,
I
don't
know
I'll
be
honest.
Man
like
this
is
a
dream
job
for
me,
like
yeah,
the
the
mix
of
what
I
have
right
now,
where
it's
like
roughly
a
third
on
the
framework,
a
third
on
primer
and
then
a
third
just
like
helping
people
with
the
company
use
them
both
properly
like.
I
I'm
pretty
happy
guy
getting
to
do
all
that.
B
A
A
Yeah
pretty
good,
pretty
solid
team,
they,
oh
my
goodness,
it's
just
so
much
fun
like
I
took
some
time
off
this
week
to
go
see
family
post
vaccine
and
I
just
came
back
you
know
this
morning,
looked
at
slack
and
they're
cranking
away
shipping
code
writing
issues.
It's
it's!
It's
really
that's
been.
I
think
the
most
fulfilling
part
of
this
project
has
been
like
realizing
that
to
execute
on
a
vision.
This
big
I
need
to
work
with
other
people
and
just
seeing
the
fruits
of
that.
A
So
I
I
focus
a
lot
on
equipping
other
people
to
to
make
good
contributions
to
the
project,
whether
they're
in
the
community
or
not,
like
I
regularly
like
some
people
in
the
chat
might
even
be
on
this
list
that,
like
if
someone
files
a
good
issue
on
the
project
and
it's
something
that
like
we
all
agree,
we
need,
especially
if
something
would
be
useful
for
us
internally
I'll,
be
the
first
to
go
to
email
and
say
hey,
let's
just
pair
on
it,
I'll
help.
You
get
started.
B
A
A
B
B
That
is
solving
a
whole
nother
problem
to
then
eventually
give
you
enough
fuel
or
ammo
to
basically
say:
okay,
let's
not
even
attempt
the
jekyll
thing
right
now,
because
jared's
having
some
issues
so
like
we
should
just
help
jared
help
him
solve
it
and
then
now
you
have
this
whole
another
stream,
a
consciousness
and
at
bats,
to
be
able
to
solve
a
problem
that
you
don't
have
to
focus
on
and
you
can
focus
on
the
css
stuff
or
something
else.
So
it's
nice
to
see
that
I
see
the
value
in
open
source.
B
A
B
A
And
this
just
happens
over
and
over
and
over
again,
so
like.
I
think
that
the
alignment
with
the
community
has
been
our
kind
of
way
in
like
if
you've
contributed
to
anything
in
rails.
You
could
come
into
this
framework
and
feel
right
at
home,
because
we
name
things
the
same
way.
We
use
the
same
documentation
tool
the
same
test
framework
like
we're
doing
a
lot
of
the
same
stuff,
and
it's
I
think
it's
shown.
There's
a
lot
of
a
lot
of
people
lining
up
to
write
code,
just
pretty
cool.
B
A
Yeah-
and
I
think
that,
like
that's,
also
been
a
big
lesson
on
asking
for
help
on
this
project-
is
that,
like
I
love
taking
vacations
like
they'll,
I
just
took
the
last
like
two
and
a
half
days
off.
I
didn't
bring
any
work
stuff
with
me
and
because
we
have
really
strong
community
a
really
strong
community
internally
and
externally.
I
feel
comfortable
stepping
away
for
a
couple
days
or
for
a
little
while,
because
I
know
that
I'm
not
the
only
I'm,
not
the
one.
B
Yeah
for
sure
yeah,
that's
that's
I
mean
that's,
that's
a
wonderful
thing
to
hear
too
as
well,
because,
like
there
is
a
question
I
spoke
at
pycon
yesterday
and
there's
a
question
that
came
up
in
the
the
q
a
about
burnout,
because
I
spoke
in
the
lightning
track
round,
so
we
all
q
and
a
together,
and
there
was
one
person
that
talked
about
mental
health
and
how
it
applies
to
programming
and
yeah.
But
burnout
is
real,
even
if
it's
your
day
job,
because
there's
always
gonna
be
issues.