►
From YouTube: Quit Writing Everything Yourself by Evan Lucas, Help.com
Description
Quit Writing Everything Yourself - Evan Lucas, Help.com
Maintaining the separation of business logic and data validation in JavaScript can easily become difficult. Writing similar data validation code over and over again gets boring quite quickly. In this session, we will explore how to generate code that will help take away the busywork of writing data validation and allow developers to focus on writing the business logic.
A
Validation,
whether
that
be
you
know,
validating
like
throughout
the
lifecycle
of
an
HTTP
request,
there's
request
body,
query,
string
parameters,
headers
response
bodies:
you
want
to
make
sure
that
you're
getting
and
receiving
the
data
that
you're
expecting.
It
said
that
takes
a
lot
of
time
to
write
that
same
code
over
and
over
again,
you
know
a
lot
of
its.
Is
this
a
string?
Is
this
a
UUID
or
an
array?
That
kind
of
thing
then
there's
also
like
function.
Arguments
so
say
you
have
a
function
that
takes
an
option
and
options
object.
You
want.
B
A
Make
sure
that
the
the
options
that
are
passed
in
or
the
properties
on
that
object
or
what
you
expect
them
to
be
and
then
another
pretty
common
input,
validation
that
we
do
is
for
message
formats
so
like
sending
data
over
TCP
UDP
things
like
that,
so
it
kind
of
ties
back
into
the
request
and
response
as
well,
so
that
gets
really
old
really
fast.
In
my
opinion,
just
writing
the
same
thing
over
and
over
again,
and
so
it
helped
one
thing
that
we
tried
to
come
up
with
us.
A
A
We
want
to
make
sure
you
know
we're
not
doing
something
synchronous
inside
the
lifecycle
of
an
HTTP
request
and
that
kind
of
thing,
but
this
is
important
in
many
ways,
one
being
the
different
types
that
are
in
JavaScript,
like
type
of
array,
is
gonna
return,
an
object
type
of
null.
It's
going
to
return
an
object,
so
these
are
checks
that
a
lot
of
people
know
to
make.
A
Some
people
are
still
learning
on
that
and
if
they
don't
have
to
write
that
every
single
time,
then
we
can
you
know-
and
we
can
generate
that-
then
we
can
guarantee
like
this
is
written
in
a
way
that
it's
going
to
perform
for
us,
how
we
expect
it
to
so.
How
can
we
enforce
that?
Besides?
Linting
linting
is
kind
of
the
first
obvious
thing,
but.
A
Yes,
code
gin
is
a
somewhat
popular
package
that
allows
you
to
pass
in
well
from
the
readme.
It's
it's
a
neck,
mascara
code
generator
from
Mozilla's
parser
api
AST,
so
it
takes
in
an
object
or
an
array
of
objects
that
define
this
standard
format,
the
es
tree
format
of
how
you
can
represent
JavaScript
code
in
in
ASD,
which
is
an
AB
Trax,
abstract,
syntax
tree
sorry.
So
this
is
just
a
little
site
that
I
have
that
shows
the
actual
code
and
it's
parsed
to
show
the
represented
AST.
A
So
four
plus
five
generates
a
lot
of
stuff.
You
have
an
expression
statement
that
has
a
binary
expression
inside
of
it.
The
left-hand
side
is
a
literal
with
a
value
of
for
the
operators,
the
plus
and
then
the
right-hand
side
is
a
literal
with
the
value
of
five.
That's
a
lot
for
four
plus
five,
but
this
is
more
of
one
of
the
more
basic
types
of
binary
or
one
of
the
more
basic
binary
expressions
that
you
see
a
lot.
A
We
have
been
doing
more
code
generation
at
help
lately,
and
one
thing
that
we
noticed
is
when
using
es
cogent
is
that
you
pass
in
these
objects
and
when
you
don't
pass
in
the
correct
thing,
you
don't
get
the
best
error
message.
So
that's
part
of
what
we've
been
working
on,
but
we've
also
been
trying
to
come
up
with
a
way
to
make
it
easier
to
construct
those
objects.
A
So
this
is
actually
something
that
we've
open-sourced
today
and
it's
available
on
NPM,
but
we
can
kind
of
go
through
it
to
see
what
kind
of
benefits
we
get
out
of
it.
So
say
this
is
a
function
that
we
want
based
on
apps,
based
on
different
kind
of
configuration
that
we
pass
in.
So
we
say
we
have
an
object,
like
a
user,
where
you
know
we
have
the
user's
name,
we
have
their
email,
maybe
a
display
name,
lots
of
different
properties.
Writing
each
one
of
those.
A
A
So
this
is
what
we
want
here,
and
this
is
just
a
you
know
a
simple
example
as
far
as
the
validation
goes,
but
you
know
once
you
get
multiple
properties
on
an
object
there.
It
gets
pretty
long
so
to
use
build
ast.
You
first
require
it
and
then
you
can
call
it
and
that
will
create
a
new
builder
and,
as
you
can
see
on
line
6
here,
we're
calling
you
strips
so
we're
going
to
put
it
the
entire
file
in
strict
mode
and.
A
Then
for
say
we
want
to
do
a
type
of
ops,
dot,
name
equals
string
or
does
not
equal
string.
So
we
can
do
builder
or
B
dot
type
of,
and
that
will
create
the
object
necessary
to
create
a
unary
expression
for
type
of,
and
then
we
can
do
B
dot
string,
which
will
create
a
string
literal
and
then
we
can
pass
both
of
those
as
the
left
and
right
to
not
equals.
And
that's
just
going
to
be
like
not
equals.
A
Then
we
want
to
create
a
new
type
error
if
that
name
is
not
a
string,
and
so
we
can
do
just
beat
a
type
error
with
the
error
message
there
and
then
we
can
create
the
block
inside
the
block
for
that
conditional
statement
where
thee
we're
checking
the
type
of
so
we're
gonna
declare.
If
you
look
on
line
25
in
the
error
block,
we're
gonna
declare
er
as
a
the
type
error
and
then
we're
going
to
return,
set
immediate,
calling
the
callback
with
the
air
and
so
dot
build
here
returns
an
array
of
ast
nodes.
A
A
So
finally,
we
get
to
build
it,
and
that
brings
up
the
actual
validate
function
that
we
export
so
I
know
with
a
single
property.
It's
like
hey.
We
had
to
write
more
code
than
we
would
end
up
having
to
write,
but
you
know
once
you
have
these
multiple
requests,
responses
that
share
these
same
properties.
It's
old
writing
the
same
thing
over
and
over
again.
So
that's
that's
one
thing
that
has
really
made
it
easier
for
us
to
really
write.
You
know
api's
and
that
kind
of
thing
faster.
A
We
also
use
them
for
without
ating
arguments
to
functions
as
well
like
I've
mentioned,
so
it
can
save
you
a
lot
of
time,
but
being
as
we
can
do
it
in
a
config,
driven
way
where
we're
passing
in
like
hey,
we
need
these
properties
with
these
types.
This
one
can
be
null.
This
one
cannot
be
null.
We
can
actually
generate
the
documentation
for
that
at
the
same
time.
A
A
So
I
guess
I
can
show
that
actual
I
can
show
that
actual
one.
This
is
the
full
file
here,
can
you'll
see
little
bigger,
so
better,
more
okay
cool,
so
we
require
our
our
builder
here,
and
this
is
these.
Are
descent
is
the
same
code
from
the
slides,
but
it
shows
them
all.
All
together
and
I
tried
to
make
it
commented
a
little
bit
but
yeah
we
have
our.
We
have
our
builder
and
we're
constructing
this
same
type
of
check
here.
A
A
This
death
actually
doesn't
build
documentation.
At
this
point,
we
do
have
tooling
that
we're
trying
to
get
ready
to
open
source.
This
was
kind
of
the
you
know,
one
of
the
first
Legos
that
we
built
to
allow
us
to
generate
the
code
and
the
documentation,
but
we
do
currently
build
both.
We
generate
code
and
documentation
for
all
of
our
api's
using
build
AST
just
been
a
pretty
fun
experience,
but
yeah
that
was
a
hell's
all
I
had.
Did
anybody
have
any
questions
so.
B
A
Be
honest
with
you,
I
feel
like
there
are
different
goals,
I
know
for
us.
We
are
not
looking
to
have
a
strongly
typed
language,
but
we
are
looking
to
be
able
to
make
assumptions
about
our
route
handlers
and
things
like
that.
Like
hey,
this
isn't
going
to
be
called.
Unless
all
of
these
you
know
unless
the
validation
passes,
which
I
know
typescript,
does
give
you
in
a
lot
of
cases,
but
yeah
I
think
that
they're
just
two
different
ways
to
achieve
similar
goals.
B
A
We
could
definitely
do
that.
That's
that's,
definitely
an
option.
One
reason
we
do
like
the
generator
and
I
guess
you
can
generate
documentation
from
the
jason's
json
schema
as
well
just
a
different
way
of
doing
it.
To
be
honest
with
you,
they
both
work.
One
thing
that
this
does
allow
is
we
are.
These
functions
are
specific
for
each
request
body
or
each
response
body,
and
so
that
allows
us
to
not
be
dynamic,
and
so
we
do
get
a
little
bit
of
performance
gains
out
of
that.
A
C
Yeah
I
think
one
of
the
differences
may
be
interesting
to
see
if
you
can
show
them
kind
of
the
nano
prop
stuff
and
how
that
gets.
Converted
to
this
you'll
see
the
difference
between
JSON
schema,
and
this,
and
one
thing
about
JSON,
is
that
it's
really
easy
to
miss
type
in
JSON
and
you
get
completely
the
wrong
thing.
So.
C
Actual
type
checking
and
things
like
that
and
then
to
address
when
you're
thinking
about
like.
What's
the
difference
between
this
in
typescript
typescript,
isn't
gonna
tell
you
like
what
a
regex
matches
for
an
input
or
like
what
the
string
length
of
visit.
So
you
can
use
this
for
like
type
validation.
But
it's
also
things
like
you
know:
what's
the
length
of
a
property
or
what's
an
enum
or
these
types
of
things
which
are
gonna,
go
well
beyond
typescript
yeah.
A
A
We
can
also
nest
them
this
way,
and
so,
when
you're
going
through
like
this,
is
significantly
easier
to
write,
then
if
typeof
admins
not
equal
object,
if
the
email
and
the
admin
object
is
not
an
actual
valid
email
address,
that
kind
of
thing,
so
that's
that
kind
of
goes
into
detail
about
why
we're
using
it
to
generate
but
be
at
school.
We
can,
you
know,
validate
nested
array,
values
and
properties
inside
objects
and
nested
arrays,
and
things
like
that.
So
this
is
the
first
of
hopefully
many
of
our
packages
that
allow
us
to
do
this.
B
I'm
pretty
much
doing
something
very
similar,
so
like
I'm
into
the
business
of
generating
client-side
code
from
swagger
specs
and
your
swagger
specs
in
the
model
definitions,
you
have
all
your
JSON
module
definitions
right,
so
I
create
a
mapper
and
that
mapper
has
pretty
much
all
these
niceties
like
min
length
max
length.
Reading.
B
A
Also
yeah
we're
we're
using
it
for
generating
client
code
as
well,
so
it
it
kind
of
allows
you
to
automate
more
and
more
the
more
you
buy
into
it,
which
is
nice,
because
we
we
do
use
a
micro
service
pattern.
So
writing
those
client
packages
for
yeah.
It
just
gets
repetitive
so
cool
there.
Any
other
questions.