►
From YouTube: Opinionated React - Juan Fabrega
Description
Juan Fabrega talks about team dynamics and setting up your projects for success. Juan also shares his opinions to reduce spaghetti code in your React Code Base.
#charlestonjs #reactjs #javascript
Slides can be found here:
https://github.com/juanfabrega/charlestonjs-opinionated-react
Check out our CharlestonJS Meetup, we meet every Thursday at 5pm EST
https://www.meetup.com/CharlestonJS
https://charlestonjs.com
B
So
this
is
called
avoiding
the
giant
spaghetti
single
pitch
application
monster.
So
hopefully
you'll
find
this
helpful
here
we
go
so
so
about
me.
My
name
is
juan
fabrega,
I'm
a
software
engineer
at
palmetto
solar.
We
are
hiring
if
anybody's
interested
in
anything
like
that,
so
just
go
to
the
website
and
see
what
what's
up
going
on
over
there.
B
I've
worked
on
so
currently
I'm
I'm
the
core
maintainer
for
the
palmetto
component
library,
which
is
a
react
kind
of
design
system
component
library,
as
well
as
our
token
library,
which
powers
the
the
component
library
and
then
previously
I
worked
at
a
local
company
here,
rhinogram,
maintaining
the
that
component
library
called
rhino
style.
So
these
are
both
open
source
projects.
Actually,
so
you
can,
when
you
have,
whenever
you
have
a
chance,
you
go
to
go.
Take
a
look
at
what
what
those
look
like,
so
why?
B
Why
did
I
want
to
give
this
talk?
So
the
the
main
reason
I
think
is
like
for
me,
everything
is
ux
and
you
know
I
actually.
I
work
in
ux
pretty
much
all
day.
I
build
component
libraries,
so
it's
both
ux
in
terms
of
the
interfaces
that
get
built
out
of
those
components,
but
also
the
the
consumers
themselves,
which
are
other
developers
and
use
their
experience
with
what
we're
building
for
them,
and
I
think
one
of
the
key
things
I've
noticed.
B
B
It
is
a
pain
point
when
I
have
to
think
about
how
to
solve
a
problem
and
not
not
necessarily
about
problems
that
we
haven't
solved
before
or
challenges
with
with
creating
a
feature
itself,
but
more
of
more
of
the
the
meta
of
solving
a
problem
so,
for
example,
think
things
that
I
don't
want
to
think
about.
So
the
goal
should
be
not
to
eliminate
thinking
altogether
like,
like
in
the
book.
Don't
make
me
think,
but
to
eliminate
time
spent
on
things
that
are
inconsequential
to
think
about.
So
what
are?
B
B
Should
I
create
a
css
class
or
just
some
inline
styles
again?
I
never
want
to
have
to
ask
this
question
ever
in
a
codebase,
I
want
to
know
exactly
how
we
style
things
as
a
team
and
just
get
it
done.
So
what
are
some
questions
that
I
do
want
to
ask
possible
scenarios
correctly
for
this
feature?
That's
something
that's
very
hard
to,
I
think,
to
create
patterns
for,
but
it's
something
that
I
want
developers
to
spend
their
time
thinking,
not
necessarily
some
of
the
other
inconsequential
things.
B
B
So,
for
example,
routing
view
has
like
a
specific
component
maintained
by
the
core
team
or
sorry
a
package
maintained
by
the
core
team,
which
is
a
view
router
in
react.
You
have
lots
of
ones
and
I
actually
that's
not
a
typo.
The
reason
I
put
react
router
there
twice
is
because
every
time
they
change
a
major
to
a
new
major
version,
it's
a
completely
new
api.
So
so
same
thing
with
global
state
view
view
has
vue
x,
which
is
again
maintained
by
the
official
core
team.
B
React
does
not
have
a
state
management
library
to
go
along
with
it,
although
unofficially,
I
would
say
it's
probably
redux,
although
there's
mobx
and
recoil
as
well
in
terms
of
building
components
with
vue
you'll,
most
likely
99
of
time
be
doing
single
file
components
in
react,
you
could
be
doing
functional
components,
class
components
and
then
also
who
knows
where
the
styles
are
going
to
go,
because
that's
very
much
all
over
the
place
in
react.
Apps
local
state
with
view
I
like
to
say
it's
magic.
B
Obviously
it's
not,
but
it's
kind
of
close
to
magic.
It's
kind
of
it's
just
binding
variables
to
a
data.
Object
and
with
react:
you
have
things
like
hooks
and
set
state
if
you're
doing
classes,
so
there's
some
discrepancy
there
in
terms
of
how
you
want
to
approach
something
and
then
something
like
scoped
styles,
which
I
think
a
lot
of
people
find
helpful.
B
B
I
have
to
make
a
lot
of
choices
for
my
react
code
base,
not
to
say
that
you
absolutely
need
all
these
things,
but
most
large
scale
applications
will
have
a
version
of
one
of
these
patterns
implemented
and
you
do
have
to
make
those
choices,
no
matter
what
cool
so
so
again.
The
goal
is
to
reduce
kind
of
the
friction
of
thinking
about
these
things,
and
I
think
the
natural
question
is:
where
do
we
start?
So?
B
So,
let's
I'm
not
going
to
talk
about
that
because
I
feel
like
that
could
be
a
whole
talk
in
and
of
itself,
but
for
the
time
being,
let's
assume
that
you've
got
management
product
buy-in
to
actually
work
on
your
architecture
alongside
the
features
that
you
need
to
build.
So
there's
a
few
questions.
People
usually
ask
themselves.
So
is
this
a
brand
new
code
base?
B
It
stands
for
a
benevolent
dictator
for
life
and,
in
this
case,
obviously,
for
life
is
very
subjective
because
most
of
us
work
for
companies
and
we
probably
won't
work
for
those
companies
for
the
rest
of
our
lives.
But
I
think
that
the
core
concept
is
very
applicable
and
the
general
idea
by
the
way,
this
picture
is
van
rossum
who's,
the
creator
of
python
and
also
was
it's
been
benevolent
dictator,
for
I
think
two
decades
or
something
like
that.
B
But
the
idea
behind
this
person
is
that
they
can
evaluate
what
the
team
needs.
Obviously
they
consider
input
from
everybody.
You
know
it's
not
a
dictator
in
the
strict
distance.
That's
why
the
benevolent
part
is
very
important,
and
but
but
at
the
end
of
the
day,
they
do
make
and
enforce
decisions
that
are,
in
essence,
unilateral
right
after
the
feedback
has
been
obtained
and
after
things
that
a
lot
of
things
have
been
considered,
the
decisions
are
unilaterally
made
by
by
this
person
or
in
this
particular
case.
B
I
would
advocate
that
you
don't
necessarily
need
it
to
be
a
single
person,
but
but
at
least
a
group
of
people
and
hopefully
not
the
entire
team,
because
then
it
becomes
too
difficult.
So
I
think,
to
summarize
this,
I
would
say
that
you
probably
want
to
elect
your
benevolent
dictator
democratically,
but
then
let
them
rule
thereafter.
B
Okay,
so
next
up
is
some
basic
process.
So
for
me
the
the
important
process
portion
here
is
the
architecture
meeting.
So
I
think
it's
important
as
teams
to
have
these
and
have
them
on
a
schedule.
Now
the
schedule
may
vary
per
team
and
also
based
on
the
size
and
available
availability
of
everybody,
but
but
in
general
they
should
be
on
a
schedule.
B
I
usually
recommend
something
like
once
a
month
for
an
architecture
meeting
and
the
main
things
you
want
to
be
doing
in
this
meeting
are
identifying
any
problem
areas
so,
for
example,
things
that
you
find
irritating
or
just
just
badly
implemented
about
your
code
base
that
you
want
to
change
now.
The
important
part
is
you?
Don't
just
change
them
willy-nilly,
right,
like
that's.
That's
the
whole
idea
behind
having
an
opinionated
writing
an
opinionated
application
and
kind
of
maintaining
a
team
culture
that
that
respects.
B
That
is,
you
don't
just
change
something
as
you
want
to.
So
you
identify
the
problem
areas
in
an
architecture,
meaning
you
also
identify
any
novel
needs
so,
for
example,
something
that
you
have
not
needed
until
now,
but
now
you
do
and
you
need
to
figure
out
the
best
possible
solution
to
it.
You
still
listed
some
team
feedback.
B
So
that's
where
the
business
buying
comes
in
and
that's
why
this
is
a
really
really
important
part:
the
inserting
the
work
into
upcoming
sprints
so
that
the
actual
stuff
actually
can
get
done
in
the
code
base.
Hopefully
over
time
is
improved
now,
in
this
particular
case,
I'm
talking
about
a
code
base
that
requires
that
improvement.
Obviously,
if
it's
a
brand
new
code
base,
then
you
probably
you
probably
stop
at
the
making
decisions.
Part-
and
you
start
implementing
things.
B
Okay,
so
next
up
documentation.
So
I
think
that,
as
part
of
this
effort,
there
should
be
more
to
your
readme
than
hey
just
run,
yarn
start
and
run
the
application,
and
that's
it.
That's
all
you
need
to
know,
which
is
what
I
typically
see
in
a
lot
of
code
bases
is,
which
obviously
is
like
boilerplate
from
create
react
app
or
something,
and
it
was
just
left
there
forever
and
ever
so.
B
What
I,
what
I
usually
recommend
is
some
sort
of
contribution,
guide
or
style
guide
for
the
code
base
itself,
and
I've
actually
brought
an
example
here
of
the
one
that
we
have
currently
for
the
palmetto
components.
Open
source
project
take
a
look
at
it,
I'm
not
through
the
whole
thing,
but
just
to
give
everybody
an
idea,
so
distribution
guy
for
our
code
base
and
so
first
of
all,
table
of
contents,
a
whole
primer
on
how
to
develop
locally
any
guiding
principles.
So,
for
example,
how
we
view
desktop
mobile
support,
cross
browser
accessibility.
B
Basically,
all
the
things
we
feel
are
important
for
people
to
have
kind
of
in
the
context
in
the
back
of
their
minds,
while,
while
they're
working
on
something
so
and
then
also
just
a
very
quick
hey,
how
do
you
build
a
component
right?
So
this
is
what
the
component
folder
would
look
like,
and
these
are
all
the
things
that
you
want
to
have
in
your
component
folder
and
each
each
of
them
has
a
specific
purpose
right.
So
in
things
like
syntax,
for
example,
this
is
how
you
define
our
types
type
interface.
B
B
People
include
in
their
contribution
guide,
or
you
can
just
put
in
the
readme
too.
That
doesn't
need
to
be
a
separate
document
if
you
don't
want
to
cool.
So
next
up
is
culture.
I
think
it's
important
that
the
team
understands
the
added
value
of
of
the
good
codebase
ux
right.
So
that's
that
should
be
really
kind
of
one
of
the
top
items
on
the
agenda
is
hey.
B
I
think
that
that's
always
okay,
so
you
know,
for
example,
I
don't
like
some
of
the
things
that
we
do
in
our
own
code
bases,
but
I
actually
even
put
in
that
contributing
guide,
but
I
found
them
to
be
good
compromises
to
some
of
the
needs
that
other
team
members
had,
and
I
prefer
the
consistency
over
just
getting
my
way
all
the
time.
So
that's
what
we
did
so
anyway
code
reviews,
I
think,
should
be-
should
include
style
review.
B
So
obviously,
when
you
do
a
code
review,
the
more
important
thing
is:
does
the
does
the
code
work?
Does
it
work?
Well,
does
it
perform?
Well,
you
know
obvious
that
that's
what
you
want
to
look
for,
so
you
don't
introduce
bugs
into
your
code
base
or
into
your
product,
but
I
also
think
that
they
should
include
a
style
review
and
I
think
a
lot
of
people
bristle
at
this
idea,
because
it
makes
code
reviews
seem
super
superficial.
B
What
I
would
say
is
that
that
typically
happens,
because
because
a
lot
of
reviewers
do
that
based
on
their
own
opinions,
so
if
you
get
a
cold
review,
that's
that's
all
style.
Based
on
the
reviewer's
opinion.
It's
not
worth
a
whole
lot,
because
everybody's
opinion
is
different
and
you
still
end
up
with
a
code
base,
that's
kind
of
messy
based
on
the
reviewer
of
that
of
that
pull
request.
So
what
I
would
advocate
is
hey.
Have
it
be?
B
Have
there
be
a
style
review
with
every
with
every
code
review,
but
that
style
review
should
be
completely
based
on
the
guide
that
you've
already
laid
out,
so
it
shouldn't
be
hey.
I
prefer
things
to
be
broken
out
this
way,
or
I
prefer
to
be.
I
prefer
to
have
imports
done
this
way
it
should
just
be.
This
is
the
way
we
do
it
and
the
story.
B
So,
let's,
let's
just
all,
do
the
same
thing
so
that
we
don't
end
up
looking
at
different
things,
all
day
cool,
and
so,
lastly,
if
the
if
the
benevolent
dictator
for
life
is
responsible
for
reviewing
all
code,
then
something
has
gone
terribly
wrong.
This
is
something
that's
really
important.
I
feel
like
a
lot
of
teams
fall
in
this
pitfall
of
hey.
This
guy
is
our
this
guy
is
our
back
end
lead
or
this
guy
is
our
front
end
lead,
so
he
has
to
look
at
every
pull
request.
B
So
I
think
the
ideal
scenario
is
that
again,
the
style
guide
kind
of
permeates
the
culture
of
the
folks
reviewing
the
code,
and
that
way
anybody
on
the
team
can
issue
a
style
review
to
anybody
else
at
any
point
in
time
and
say:
hey,
you
didn't
follow
the
style
guide
in
this
particular
case,
so
it
doesn't
necessarily
need
to
be
the
one
person
or
the
committee
who
that
reviews
everything
that's
this
is
really
important
cool.
So
so,
what's
the
guide
and
light
behind
making
decisions
about
the
tech
stack?
B
So
I
think
you
know
a
lot
of
people.
Do
ask
hey
okay!
So
now
I
know
that
you
know
we
want
to
have
an
architecture
committee
or
a
person
that
actually
can
make
these
decisions.
But
how
do
the
decisions
get
made
right
like
what's
the
best
way
to
say
to
decide
which
component
library
to
go
with
or
which
which
pattern
to
use?
And
I
think
for
me,
the
answer
is
simple-
is
just
pick
something
and
stick
with
it.
B
This
is
more
important
than
anything
else,
and
the
reason
for
that
is
that
you
follow
principle
number
two,
which
is
that
you
have
to
be
moderately
boring
right,
so
you
don't
have
to
be
extremely
boring.
So,
for
example,
you
don't
have
to
necessarily
use
tech
that
was
used
25
years
ago.
If
you
don't
want
to,
you
can
use
stuff.
B
That
is
relatively
new,
but
you
also
want
to
be
moderately
boring,
and
I
think
that
if
you're
moderately
boring-
and
by
that
I
mean
you
pick,
things
that
are
relatively
stable-
have
been
in
the
ecosystem
for
long
enough
to
be
battle
tested
and
also
have
a
large
enough
developer.
Mind
share
that
you
could
get
help
when
you
need
it,
then
you
are
okay
with
pretty
much
any
decision
right
like
there's
very
little.
You
could
do
to
screw
things
up
if
you
go
with
something,
that's
tried
and
tested.
B
A
B
Deck,
but
now
you
know
I
did
I
did
say
this
was
talk,
called
opinionated
react,
so
I'm
just
going
to
give
you
my
opinions
and
I'm
going
to
go
through
a
variety
of
things
that
we
usually
need
to
decide
upon
when
we
work
on
a
react
code
base
and
just
tell
you
what
I
think
and
and
again
just
remember
this
previous
slide,
so
you
don't
jump
down
my
throat.
Almost
any
decision
is
correct
as
long
as
you're
moderately
boring
so,
but
I'll
give
you
my
my
personal
opinion
on
some
of
these
things.
B
So,
first
of
all
component
types,
I
think
a
while
back
there
was
a
debate
about
classes
or
functions.
If,
I'm
being
completely
honest,
I
feel
like
functions,
have
won
over
classes
in
the
react
ecosystem
pretty
clearly
in
terms
of
developer
mindshare
like
most
developers.
These
days
are
invested
in
functional
components
over
function
over
class
components
and
in
fact
I
feel
that
almost
every
interview
that
I
have
sat
on
in
the
last
probably
year
to
two
years
by
that
I
don't
mean
that
I'm
into
that
I'm
being
interviewed.
B
But
I've
sat
on
an
interview
with
a
lot
of
folks
in
the
room
view
class
components
as
passe,
so
you
know
take
that.
Take
that
as
you
will,
but
I
feel
like
that.
That's
there's
a
clear
winner
here.
So
if
you're
starting
a
new
code
base
or
if
you're
thinking
about
making
creating
consistency
across
your
code
base,
I
would
probably
go
with
a
functional
component
approach
over
a
class
which
is
also
useful.
I
mean
it
can
be
used
pretty
much
in
any.
B
B
The
exact
same
recommendation,
which
is
don't
overthink
it
so
I
would
actually
follow
their
advice.
I
think
this
is
really
important.
This
is
not
one
of
the
things
that
I
would
spend
most
of
my
time
on.
I
would
probably
just
pick
one
and
stick
with
it
now
in
terms
of
what
what
I
like
I'll
just
add
some
opinions
here.
I'm
not
a
huge
fan
of
atomic
design.
B
Now,
for
anybody,
who's
not
familiar
with
atomic
design
is
the
idea
that
your
application
has
atoms
molecules
and
organisms,
and
each
of
these
is
essentially
a
kind
of
a
a
a
different
size
of
component
based
on
how
you
look
at
it.
So,
for
example,
an
atom
would
be
something
like
a
button.
A
organism
might
be
something
or
sorry.
A
molecule
might
be
something
like
a
card
which
has
a
button
and
a
few
other
things
in
it,
and
then
an
organism
might
be
like
a
whole
page
now.
B
The
reason
I'm
not
a
huge
fan
of
it
is
because
I
feel
like
there's
no
strict
delineation
between
what
different
things
are.
It's
very
easy
to
have
a
very
blurred
line
of
what
is
an
atom
versus
a
molecule:
what's
a
molecule
versus
an
organism
and
it
just
gets
really
confusing.
So
for
me
not
not
my
favorite
again
pick
one
and
stick
with
it.
B
So
that's
that's
the
rule,
so
I
like
component
subfolders,
so,
for
example,
what
what
you
saw
in
the
contributing
the
contribution
guide
that
I
showed
for
our
component
library,
which
is
that
under
the
component
subfolder
and
a
react
project,
you
would
create
folders
for
each
of
the
components
that
you're
working
on
so
again,
going
back
to
the
example
of
a
button,
the
button
would
have
a
folder
and
inside
would
be
a
button
component.
The
tests
for
that
button,
potentially
the
styles
for
that
button.
B
If
you
have
separate
style
sheets
and
all
kind
of
in
a
single
directory
substructure,
I'm
not
a
huge
fan
of
multiple
layers
of
nesting.
So
I
like
the
component
subfolder,
but
I'm
not
a
huge
fan
of
when
people
start
nesting
in
there
two
or
three
layers
deep.
I
find
that
to
be
highly
confusing
and
just
very
difficult
to
to
it's
very
difficult
to
maintain
the
consistency
of
that
so
they'll.
B
When
people
start
doing
this
usually
you'll
end
up
with
an
application
where
a
component
folder
will
have
one
one
single
layer
of
nesting
or
another
would
have
two
and
another
would
have
three
and
then
it
just
gets
very
muddled.
So
I'm
not
a
huge
fan
of
nesting
beyond
the
the
typical
hey.
This
is
my
component
folder
and
that's
about
it.
B
And
lastly,
I
like
separating
views
and
components
mostly
because
I
I
like
having
a
bird's-eye
view
of
kind
of
what
the
application
actually
feels
like
to
the
user,
and
I
feel
like
views,
are
the
quickest
way
to
to
do
that.
Views
are
really
what
the
user
is
seeing
right,
there's
a
login
view
and
a
signup
view
and
there's
a
user's
view
and
the
dashboard
view.
So
to
me,
that's
that's
a
very
quick
way
to
understand
an
application
from
a
from
a
high
level.
So
I
like
that.
B
Linting
just
use
airbnb
and
don't
think
about
it.
So
yeah,
that's
what
I
would
recommend
pretty
much
everywhere
that
I've
worked
or
any
code
base
that
I've
worked
on
either
consulting
freelancing
or
for
full-time
employment.
It
has
not
been
worth
the
time
to
create
a
custom
configuration.
So
that's
that's
what
I
would
recommend.
In
most
cases
there
are
some
minor
modifications
that
folks
may
want
to
make,
but
start
start
from
here
and
then,
maybe
just
add
a
few
bits
of
customization.
B
If
you
really
want
them
testing,
I
would
really
recommend
just
the
standard
library.
That's
that
included
with
create
react
app,
which
is
just
a
test.
Runner
plus
react
testing
library,
so
you
can
use
this
to
test
pretty
much
any
basic
component
functionality
like
you
know,
user
interfacing
with
something
or
data
being
rendered
in
the
right
way,
and
you
can
also
use
it
to
create
snapshots
now.
I
personally,
I
don't
like
snapshots
because
I
feel
like
they
test
implementation
details,
so
I
don't
really
do
snapshots
so
instead
of
snapshots.
B
B
B
There's
no
way
for
that
snapshot
to
tell
me
that
I
screw
something
up,
because
the
class
name
is
exactly
the
same,
and
I
could
have
just
completely
destroyed
the
styles
for
it
and
we
would
be
none
the
wiser
now.
Conversely,
if
you
remove
that
class,
let's
say
that
was
an
empty
class
and
you
removed
it
from
your
markup.
It
really
made
no
difference
at
all
to
your
ui,
but
jess
is
going
to
scream
at
you,
because
the
snapshot
doesn't
match
anymore,
because
the
class
is
not
there
anymore.
B
So
again,
I
think
that
something
like
chromatic
is
a
lot
more
useful
in
the
sense
that
when
you
make
a
change,
it
actually
tells
you
visually
whether
that
affected
the
the
component
or
the
view
or
whatever
it
is
that
you
you're
rendering
in
the
story-
and
it's
actually
and
it's
very
easy
to
mock
data,
to
recreate
views
in
storybook
and
then
just
have
chromatic
create
snapshots
for
your
entire
application.
So
I
like
that,
a
lot
integration.
B
I
don't
really
like
recommending
stuff
when
I'm
talking
about
react
because
I
feel
like
this
is
very
context
dependent
and
by
nature.
Integration
and
end-to-end
really
should
include
the
entire
stack.
So
we're
not
talking
about
the
entire
stack
here.
We're
talking
about
react,
so
I'm
not
going
to
give
any
thoughts
on
this
one
routing.
So,
similarly
to
linting,
I
would
say
just
pick
out
react.
Router
and
call
it
a
day,
there's
a
few
other
options,
but
honestly
nothing
has
as
much
mind
share
and
personally
I'll.
Just
I'll
be
honest.
B
This
is
one
example
where
earlier
when
I
was
saying
hey,
nobody,
not
everybody,
has
to
like
everything
about
the
code
base.
Personally
react.
Router
is
not
my
favorite
library
to
use
I
kind
of
have
a
bit
of
a
chip
on
my
shoulder,
because
every
time
they
update
they
change
versions,
the
api
is
just
drastically
different
and
when
you
maintain
applications
for
more
than
a
year,
that's
that's
pretty.
That's
pretty
impactful,
so
you
know
I'm
not.
I
haven't
been
a
huge
fan
of
them,
but
again
it's
the
most.
B
So
I
think
it's
okay,
when
things
get
really
really
big,
to
break
things
down
in
ways
that
make
sense,
but
I'm
not
a
huge
fan
of
breaking.
Let's
say
you
know
two
or
three
routes
here,
four
or
five
routes
over
here.
I
would
rather
have
a
complete
context
of
of
the
of
the
route
of
all
of
the
views
available
in
the
application.
B
Okay,
next
up
global
state
management,
so
first
rule
for
me
is
decide
why
you
need
it
and
that
should
inform
how
it's
going
to
get
used.
If
you
don't
know
why
you
need
it,
then
you
probably
don't
need
it.
This
is
something
I
think
a
lot
of
people
don't
think
about
anymore.
They
just
say:
okay.
Well,
we
gotta
have
redux,
so
we
had
to
have
something
for
global
state
manager.
If
you're
not
sure.
Why
you're
doing
that,
then
don't
then
don't
do
it.
B
If
you
don't
know
what
to
pick,
but
you
really
have
a
use
case
for
a
global
state
management
library,
then
I
would
pick
redux
and
use
redux
toolkit
for
anybody
who's
not
familiar
with
redux
toolkit.
It's
just
an
opinionated
way
to
write
redux
to
write
redux
code.
Essentially
it
gives
you
utility
functions
where
you
can
create
stuff
like
slices
and
kind
of
reduce
the
boilerplate,
that's
created
by
redux,
which
is
actually
its
number
one
complaint
when
working
with
it.
B
So
I
would
highly
highly
recommend
that
and
then
part
two
for
global
state
management
is,
if
you
have
lots
of
nested
data
structures.
I
really
highly
recommend
normalizing.
Personally,
I'm
a
huge
fan.
I
do
understand
that
it
can
be
that
it
can
feel
complex
at
first.
Here
is
a
guide
that
that's
from
the
actual
redux
redux
docs.
So
if
anybody
wants
to
check
that
out
after
the
talk,
please
do
that
I
personally
love
normalizing.
B
The
reason
I
love
normalizing
is
because,
if
you
stick
to
it
and
you're
strict
about
it,
then
any
anytime,
you
need
to
get
data
from
the
global
store.
The
pattern
is
always
the
same
right.
It's
hey.
I
want
to
get
a
user,
so
I'm
going
to
go
to
users
and
then
get
that
id
so
user's
bracket
and
the
user
id.
B
If
I
need
to
get
documents-
and
I
do
documents
bracket
document
id,
so
everything
is
in
a
very
shallow
hash
map
with
a
normalized
state
and
there
is
just
no
confusion
about
what
shape
the
data
is
in
ever
now.
There
is,
there
can
be
confusion
about
the
actual
objects
that
are
included
in
a
particular
thing.
So,
for
example,
unless
you
use
typescript,
you
know
where
you
have,
let's
say
a
user
object,
and
you
know
what
that
what
that
has
you're,
not
necessarily
going
to
know
what
keys
a
user
has
in
their
object.
B
B
Okay
style,
so
styles
are
interesting
and
I
feel
that
in
react.
Styles
are
probably
the
number
one
turn
off
for
any.
Anybody
who
has
never
done
react
but
has
done
web
development.
So
people
who
are
on
the
jam
stack,
who
do
html,
css
javascript
and
have
come
to
the
react
world.
I've
noticed
are
very
turned
off
by
the
lack
of
basically
reacts
for
a
long
time.
React
didn't
think
of
styles
as
a
first
class
citizen,
and
so
you
had
to
have
all
these
loaders
and
figure
out.
B
You
know
libraries
to
pair
with
it
and
it
was
kind
of
messy.
So
so
I
think
this
is
an
important
one,
and
typically
what
I
recommend
is
if
your
team
likes
writing
css,
then
just
do
that.
React
has
a
lot
of
ways
to
avoid
writing
css
and
still
style
your
application.
So
if
you
want
to
do
that,
obviously
go
for
it.
But
if
your
team
likes
writing
css,
then
just
just
do
that
and
these
days
it's
relatively
simple,
so
I
think
react
has
made
it
a
lot
better
with
with
the
boilerplate
in
create
react.
B
App
to
just
have
styles
be
easily
imported
into
apps,
I'm
mostly
talking
about
a
lot
of
years
ago,
when
that
wasn't
the
case,
if
your
team's
csl
skill
set
is
lacking.
So,
for
example,
if
you
have
lots
of
people
who
are
really
strong
on
the
javascript
side
of
the
front
end,
but
they
don't
really
know
a
lot
of
css.
So
let's
address
that
in
the
next
slide.
B
So
do
you
need
a
library,
so
this
is
probably
what
I
would
recommend
if
you,
if,
if
the
folks
in
your
team,
don't
aren't
very
strong
with
css,
then
don't
have
them
write
any
kind
of
styling,
whether
it's
css
and
js
or
css,
or
anything
at
all.
Just
you
just
use
a
library.
So
if
you
don't
need
cost
custom
components
for
react,
then
use
tailwind
highly
recommend,
tailwind
super
easy
to
use
and
just
makes
beautiful
applications
right
out
of
the
box.
B
So
I
love
it
and
but
if
you
prefer
custom
components,
I
think
we're
going
to
go
back
to
our
original
principle
pick
one
and
stick
with
it.
Any
of
the
top
players
in
the
space
will
work.
Just
fine
and
you
can
see
and
they're
pretty
much
all
themeable,
I
would
say
the
hardest
one
if
I
had
to
make
a
call
the
hardest
one.
If
you
want
custom
theming
is
probably
something
like
material
ui.
B
I
mean
they
have
a
lot
a
lot
of
theming
capabilities,
but
but
they
also
have
very
opinionated
styles
and
they
can
they.
It
looks
a
certain
way.
It
very
much
looks
a
certain
way.
It
looks
like
material
design,
no
matter
how
you
look
at
it,
so
that's
a
little
difficult,
most
other
ones.
So
things
like
ant
design,
even
the
react.
Bootstrap
libraries
are
a
lot
easier
to
kind
of
make
your
own.
So
again,
any
one
of
those
will
will
do
just
fine.
I
think
for
99
of
use
cases
don't
create
your
own
component
library.
B
So
it's
funny
because
I've
maintained
created
maintain
two
component
libraries
for
previous
companies,
so
I
feel
like
I'm
the
wrong
person
to
be
saying
this,
but
the
reason
I
say
it
is
because
I
feel
like
most
people
don't
have
the
use
case
so
and-
and-
and
this
is
part
of
this
slide
right.
So
if
you're
asking,
if
you
need
a
library,
because
you
don't
because
you're
not
really
great
at
writing,
css
right,
then
then
you
don't.
You
shouldn't
create
your
own
now,
if
you're
really
good
at
writing.
B
Css
already,
and
you
need
to
create
a
library,
because
your
business
has
a
specific
need
based
on
on
what
you're
building
then
yeah.
Absolutely
that's
the
right
way.
Good
work
right
way
to
go,
but
I
feel
like
if,
if
you've
made
it
to
this
slide-
and
you
have
this
question,
do
I
need
a
library?
Then
you
do
not
need
to
be
creating
a
component
library.
B
B
So
for
me,
my
recommendation
is
use
it
only
if
you
have
a
lot
of
confidence
in
your
ability
to
architect
this
thing,
because
I
have
seen
in
a
few
code
bases
already
using
styled
components
that
it's
very
easy
to
to
create
inconsistency
everywhere.
You
go
right
because
it's
so
easy.
I
mean
it's
kind
of
a
benefit
honestly
of
the
of
these
libraries
right.
B
It's
so
easy
to
create
styles
right,
but
at
the
same
time
it's
also
very
easy
to
just
fall
completely
outside
of
any
any
sort
of
constraints,
which
means
that
your
application
ends
up
being
really
really
inconsistent.
So
that's
the
one
reason
I'm
not
really
into
this
idea
unless
folks
have
like
really
strong
grasp
on
architecture
or
or
css
right,
and
then
what
about
css
modules?
It's
a
similar
thing
I
have
used.
I
have
used
css
modules,
our
palmetto
component
library
uses
css
modules,
so
I
like
them
a
lot.
B
I
feel
that
they're
used
as
a
crutch
a
lot
by
teams
because
they
don't
want
to
think
about
the
architecture
at
all.
So
you
know
css
modules
just
takes
care
of
making
sure
you
have
no
class
collisions
and
no
classes
overriding
each
other
and
typically,
what
ends
up
happening.
Is
people
write,
custom
classes
everywhere
all
over
the
place
or
anything
that
they
need
and
don't
focus
on
making
anything
reusable
at
all.
So
I
don't
know
if
you
think
about
a
class,
it
should
be
reusable.
That's
why
it's
a
class!
B
I
think
there's
a
couple
others,
but
I
think
you
probably
want
to
use
format
so
going
back
to
our
core
concept,
pick
one
and
also
be
relatively
boring,
so
I
think
formic
has
been
in
the
space
longer
than
a
few
of
these
other
players
and
has
kind
of
a
larger
community
around
it.
So
I
trust
it
a
little
bit
more.
B
I've
also
rolled
my
own
form
of
tractions.
I
don't
think
this
is
the
right
approach
for
everybody,
but
but
I've
actually
found
it
to
be
pretty
okay,
there's
a
lot
of
things
that
I
would
not
do
myself,
because
they're
just
highly
complicated.
So,
for
example,
I
wouldn't
create
my
own
test
runner.
I
just
used
yes
and
call
it
a
day
and
I
would
not
create
my
own
react
router.
I
also
think
that's
kind
of
too
much
form
validation
and
things
of
that
nature.
I
feel
like
a
little
more
shallow,
so
I
feel
like
they're.
B
Data
fetching
this
is
interesting
because
I
think
there's
been
a
lot
of
changes
in
this
space.
The
one
recommendation
I
would
have
here
is
just
abstracted
into
a
service
anywhere
whatever
you're
doing,
because
a
lot
of
times
I
see
folks
making
like
fetch,
requests
in
a
component
and
that
that's
just
that.
I
don't
like
that
at
all.
I
feel
like
it's
really
ripe
for
errors
and
code
duplication
right
so
like
typing
up
an
actual
url
and
a
component
that
you're
fetching
data,
not
a
good
idea.
B
B
But
I'm
gonna,
I'm
gonna
go
ahead
and
slightly
break
rule
number
two,
which
is
to
be
slightly
to
be
more
moderately
boring
and
I'm
gonna
say
to
try
react
query.
So
it's
a
relatively
newish
library
I
mean.
Maybe
it's
not
that
new.
Maybe
I'm
not
caught
up
on
everything
all
the
time,
but
but
it's
a
fantastic
library
and
it
handles
almost
every
use
case
that
you
could
need
for
fetching
asynchronous
caching.
B
Brief
is
handled
and
in
most
cases,
by
the
way,
you're
not
you're,
not
gonna,
get
out
of
me
going
through
this
documentation.
So
I'm
just
gonna
go
back
in
most
cases
it
can
actually
replace
redux
for
a
lot
of
people.
So
it's
a
it's
a
very
good
library.
I
would
highly
recommend
it
and
or
at
least
playing
with
it,
if
you
want,
if
you're,
considering
a
change
from
what
you're
currently
doing
cool
and
that's
it
thanks
for
coming
to
my
ted
talk.
B
A
B
Yeah,
that's
right!
So
sorry
for
that
confusion
there.
So
there
are
slides
about
styles.
That
specifically
are
about
styling
the
application
itself
right,
so
you
know
css
libraries,
component,
libraries
etc,
and
at
some
point
I
also
talked
about
enforcing
a
style
guide.
So
that's
that's
the
code
style
guide
that
I
was
talking
about
so.
A
B
Other
words,
you
know:
how
do
we
you
know,
how
do
we
use
redux?
How
do
we,
how
you
know,
even
our
jss
syntax,
so,
for
example,
how
you
even
break
down
jsx
that
can
actually
vary
from
team
to
team,
how
long
your
lines
are
or
how
you
break
down
the
props
on
a
large
you
know
component
or
how
you
do
ternary
operators
on
in
react
or
whether
you
use
render
functions
to
abstract
things
away.
Things
like
that.
I
think
all
of
those
things
should
be
covered
by
a
style
guide
and
it
it's.
B
It
can
seem
daunting,
but
the
truth
is
it
usually
comes.
Naturally,
usually
what
I've
seen
happen?
Is
you
create
a
style
guide,
that's
very
basic
and
at
some
point
somebody
writes
something
that
looks
unfamiliar
and
then
the
team
kind
of
looks
around
and
goes
hey
that
looks
unfamiliar.
How
do
we
want
to
do
that
from
now
on?
Do
we
want
to
do
this
thing
that
this
guy
had
just
put
in
his
pr
or
do
we
want
to
do
it
differently
and
it's
just
a
quick
kind
of
like
just
a
break
right?
B
It's
like
everybody,
takes
a
break
and
goes
hey
yeah.
I
like
it
this
way.
I
like
it
that
way,
and
eventually
you
know
whoever's
in
charge,
can
make
a
decision
and
say
hey.
You
know
for
this
kind
of
thing,
we're
going
to
do
it
this
way
and
then
that
goes
into
the
skylight.
So
eventually
the
style
guide
just
becomes
a
lot
larger.
It
doesn't
need
to
include
everything
right
off
the
bat,
so
a
good
example
at
my
previous
company.
This
happened
a
lot
and
we
had
a
lot.
B
I
mean
it
happens,
probably
every
week
where
we
have
a
use
case
where
we're
like
we're,
not
100
sure
this
seems
kind
of
new.
You
know,
and
so
you
have
to
write
new
stuff.
So
a
good
example
is
we
were
rolling
out
a
new
utility
class
system
in
in
our
in
our
component
library
and
but
but
I
wanted
to
make
sure
that
people
weren't
abusing
it
so,
for
example,
I
don't
want.
I
didn't-
want
to
see
like
10
utility
classes,
on
an
element,
and
so
you
know
we
wrote
a
rule.
B
That
said,
hey
don't
go
over
x
amount
of
utility
classes,
because
that
probably
means
you
want
a
custom
class
for
this
thing
and
that's
very
highly
subjective,
so
neither
of
those
things
is
necessarily
right
or
wrong.
It
was
just
what
we
wanted
so
at
the
end
of
the
day,
it
helps
because
when
you're
writing
code,
you
just
know
what
to
do
right.
You
say
I
need
to
write
a
custom
class
for
this.
A
Cool
and
one
more
question
for
me
is,
I
guess
the
react.
Ecosystem
is
very
innovative
and
constantly
changing.
So,
as
you
have
the
the
bdfl
on
your
teams,
and-
and
I
understand
wanting
to
be
boring
and
moderate,
but
as
new
things
happen
in
react,
you
guys
have
kind
of
a
process
you
go
through
as
far
as
like
creating
proof
of
concepts
or
prototypes,
or
how
do
you?
B
Yeah,
for
sure
I
mean
that'll,
that'll
really
vary
based
on
the
on
the
team
culture,
I
would
say
so,
and
it
has
varied
for
me
as
well
in
the
different
companies
that
I've
worked
at,
but
I
can
tell
you
something
that
I
think
works
for
me,
so
I
I
definitely
like
this
idea
of
the
architecture
meeting
right
and
the
idea
being
that
when
something
new
comes
up,
the
main
thing
to
remember
is
we
don't
have
to
change
everything
right
now
right.
So
the
a
good
example
for
me
was
at
my
last
company.
B
We
maintained
a
pretty
large
react
application
and
also
the
the
component
library,
and
so
I
was
I
was
quote-unquote
the
bdfl
for
both
of
those
things,
and
that
was
around
the
time
that
hooks
came
out.
Actually,
I
think
they've
been
out
for
six
months.
Maybe
when
we
started
looking
at
them-
and
you
know
we
did
have
a
lot
of
discussions
around
because
our
entire
at
that
time,
our
entire
code
base-
which
I
was
not
involved
in-
writing-
necessarily
because
I
came
in
after
it
had
a
lot
of
it-
had
been
written.
B
So
that
I
mean
that's
one
example
where
I
wasn't.
It
wasn't
my
favorite
pattern,
but
I
will
say
that
we
stuck
to
it
and
it
it
always
felt
familiar
like
when
you're
going
on
a
code
base.
You
always
knew
what
to
do.
You
know
so,
for
example,
there's
there's
a
lot
of
prop
drilling,
that's
involved
with
the
container
pattern
which
can
be
annoying.
We
didn't
like
that,
but
at
the
same
time
we
never.
B
We
never
had
an
issue
knowing
what
to
do
right
now
again
going
back
to
the
original
question.
That
was
around
the
time
that
hooks
were
kind
of
starting
to
get
popular,
and
we
did
have
to
make
decisions
about
how
we
were
going
to
do
things
moving
forward.
So
we
found
the
best
way
to
do
that
was
essentially
to
boy
scout.
B
You
know
and
slowly
start
moving
the
application
to
hook
so
by
boy
scouting
I
mean
making
things
better
than
where,
where
you,
when
you
left
them
or
when
you
found
them,
is
that
the
right
can't
remember
exactly
what
what
the
phrase
is,
but
essentially
is.
If
you
touch
something
leave
it
better
than
you
found
it.
So
we
use
that
approach
for
refactoring
and
kind
of
moving
to
different
patterns.
B
So,
for
example,
if
somebody
was
touching
a
view
that
had
been
previously
done
with
the
container
architecture,
then
we
we
expected
them
to
move
it
to
a
potentially
new
architecture
that
we
had,
and
we
had
already
talked
about
this
we
said
hey.
This
is
going
to
be
the
new
architecture
moving
forward.
We
want
these
things
to
be
shaped
this
way,
and
this
is
how
we
do
data
fetching,
and
this
is
how
we
do
loading
states
and
all
these
other
things
right.
We
didn't
necessarily
just
say
change
it
to
hooks
right.
B
So
so
that's
what
we
did-
and
you
know,
there's
also
a
lot
of
there's
also
a
lot
of
decisions
that
aren't
as
easily
made
so,
for
example,
in
some
components,
it's
really
easy
to
do
that
or
in
some
views.
It's
very
easy
to
do
that,
because
they're
not
as
complex
or
or
large
and
there's
others
where
it's
really
really
difficult,
and
so
in
those
cases
we
just
made
judgment
calls
and
we
say:
hey,
you
know
it's
not
worth
the
effort
right
now
to
move
this
to
the
new
architecture.
A
All
right,
well,
I
think
we'll
end
that
there
any
other
comments
or
thoughts
that
the
community
would
like
to
bring
up.
I
do
want
to
talk
about
in-person
meetings,
I'm
kind
of
looking
for
maybe
around
july
at
the
new
charleston
tech
center,
but
still
just
just
let
me
know,
let
me
know
I'm
still
trying
to
keep
track,
but
that's
what
the
cdc
seems
to
be
recommending
now
is
july
august
will
be
a
good
time
to
to
do
a
get
together.