►
From YouTube: Node.js Loaders team
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right,
we
should
be
yeah,
we
are
live
on
youtube.
This
is
the
september
15
2021
meeting
of
the
node
loaders
group.
I'm
going
to
eat
my
lunch,
so
I'm
going
to
turn
off
my
camera
and
kick
it
off
to
and
we
have
jacob
and
bradley.
If
you
guys
don't
want,
don't
mind
I'll
start
the
document
and
add
the
people
and
stuff
so.
A
Yes,
yeah,
so
since
the
since
the
yarn
folks
couldn't
make
today,
I
was
thinking
we
might
as
well
keep
this
week's
meeting
and
then
I'll
have
to
negotiate
with
them
to
figure
out
a
time
that
works
for
them.
But
now
that
we
landed
jacob's
big
pr
that
collapses
the
hooks
into
the
new
api,
then
the
natural
next
step
would
be
to
do
the
the
chaining.
I
think
I
think,
there's
like
kind
of
two
steps
here.
A
We
need
to
get
the
chaining
design
written
down
on
a
document
that,
like
everyone,
is
okay
with
and
then
obviously
implement
it,
but
like
there,
there
is
a
like
if
you
go
to
the
home
page
of
the
loader's
repo
there's
a
link
there
that
says
design
that
design
is
like
the
design
for
chaining
that
I
wrote
like
a
year
ago
so
and
jacob
wanted
to
potentially
change
it.
So
I
think
step
one
would
be
like
a
pr
to
basically
replace
the
well
replace
or
update
depending
that
file,
with
whatever
the
new
design
is.
A
A
C
All
right,
so
I
have
not
updated
this
for
our
discussion
in
slack
earlier,
but
basically,
we've
got
the
two
leading
proposals
for
how
to
go
about
chaining.
C
The
primary
one
to
refresh
memory
was
involving
a
next,
which
would
be
whatever
the
next
loader
is
in
the
chain,
so
the
first
loader
called
is
responsible
for
calling
the
next
one
and
then
that
next
one
calls
the
next
one
in
sort
of
like
an
inception
kind
of
pattern,
and
it
can
do
that
or
not
do
that,
and
then
the
alternative
proposal
is
a
done
like
function,
so
the
main
different
or
the
main
impetus
for
this
was
to
facilitate
short
circuiting.
C
For
instance,
if
you
have
a
some
kind
of
mock
loader,
it
does
its
mocking
and
says.
Nothing
else
needs
to
happen.
Stop
in
the
next
version
of
this.
It
would
just
not
call
next
and
instead
return
something
and
in
the
done
version
it
would
explicitly
call
whatever
this
done
function
is,
and
that
would
signal
that
it
should
stop.
C
The
main
reason
behind
this
was
for
the
alternate
proposal
was
that
with
the
next
function
it
seemed
to
me
that
it
would
be
very
easy
to
make
a
mistake
and
accidentally
short
circuit,
which
in
fact
happened
to
me
when
I
was
doing
the
original
implementation
and
was
writing
tests
and
then
suddenly,
all
of
my
stuff
started
behaving
very
strangely
in
a
way
that
was
not
very
clear
what
was
happening,
so
the
updates
to
come
of
this
are
for
the
alternate
proposal.
C
A
Not
to
say
that,
like
we
shouldn't
like,
I
just
want
to
step
back
for
a
second
when
you
talk
about
the
like,
forgetting
to
call
next
problem,
so
not
to
say
that
we
should
go
with
that
design
versus
the
other
design,
but,
like
you
know,
also
that
design
could
certainly
be
improved
on
its
own
merits,
so
that
we
could
ask
with
this,
like.
I
know,
you're
about
to
talk
about
simplifying
these
five
return
values
to
something
less
than
five.
So
you
know
it
might.
A
It
might
be
that
we
want
to
like
kind
of
develop
both
designs
to
the
best
versions
of
themselves.
To
that,
and
then
compare
and
contrast
them,
but
or
maybe
that's
not
necessary,
but
like
one
thing
I
was
thinking
of
with
talking
about
forgetting
to
call
next,
I
feel
like
there
should
be
some
way
to
like
sort
of
completely
change
the
design.
There
should
be
some
way
to
like
catch.
That
or
error
like
maybe
a
hook,
always
needs
to
return,
something
you
know
and
and
it's
either
the
expected
return
value
or
true
or
whatever.
A
A
C
When
I
encountered
the
problem,
it
was
not
that
straightforward,
it
was
that
something
was
getting
returned
and
the
thing
that
was
getting
returned
was
valid,
but
it
was
not
what
it
should
have
been,
and
that
was
when
you
were.
A
C
B
C
Necessary
to
have
something
like
an
explicit
case
to
handle
that,
instead,
you
could
merely
just
call
done
or
whatever
we
decide
to
call
it,
and
that
would
effectively
achieve
the
same
thing,
because
false
is
just
a
a
a
a
flavor
of
a
short
circuit
and
I'm
thinking
that
instead,
you
could
just
call
done
with
an
object
and
empty
values
for
it,
and
then
those
empty
valves
would
just
get
used,
and
the
use
case
for
that
is,
let's
say
I
don't
know,
you're
loading
an
image
and
the
image
is
not
used
or
like
you're
loading
json
and
the
json
is
not
necessary
in
this
context.
C
So
instead
you
just
say
like
ignore
this.
This
this
file
import,
is
not
important,
and
that
would
basically
then
leave
us
with
done
and
a
valid
return
and
then
potentially
nullish,
where
knowledge
would
say
like
this.
Loader
did
nothing
and
that
kind
of
allows
the
loaders
to
sort
of
like
opt
in.
So
the
loader
couldn't
have
say
like
if
the
file
extension
is
typescript.
I
am
a
typescript
loader.
I
should
do
my
thing.
If
it's
not,
then
I
do
nothing
and
then
it
just
goes
on
to
the
next
one.
B
So
next,
when
you
are
at
the
user,
loader
similar
to
what
happens
with
the
default
hook,
implementations,
you
can
call
up
the
chain
and
the
thing
up
the
chain
can
respond
down
to
you
and
then
you
can
respond
further
down,
because
how
does.
B
B
A
So
jacob
do
you
mind
maybe
pulling
up
the
other
design
like
the.
If
you
go
to
the
loader's
home
page
and
click
on
design?
A
C
B
D
B
C
Right
so
let's
say
it
could
be
a
different
loader
right.
So
let's
say
you've
got
loader
foo,
loader
bar
and
then
default
loader
loader
foo
is
furthest
from
default.
Loader,
so
loader
foo
is
calling
loader
bar
and
litter
bar
is
calling
default
bar
calls
default.
Does
something
changes
it
in
some
way
returns
that
goes
to
foo.
C
B
C
A
A
Though
jacob
like,
I
guess
this
is
a
good
example
in
that
it's
like
the
line
you
have
highlighted
like
we
could
modify
the
specifier
that
we
pass
in
to
whatever
the
next
loader
on
the
chain
is
right,
yeah
and.
C
A
A
Let's
say
you
have
like
loader
and
loader
b
and
then
default,
and
they
were
supposed
to
run
in
that
order
right,
loader,
a
or
sorry
loader.
So
letter
a
you
know,
and
it's
a
resolve
chain,
loader
a
gets.
B
C
That
that
says
whatever
the
previous
loader
did.
That's
this.
If
it's
the
first
one,
then
it's
some
kind
of
initialized
value
or
nothing
empty
string.
What
have
you
and
then
it
still
has
access
to
the
original,
unadulterated
values.
I
forget
how
where,
but
it
does
so.
I
would
probably.
B
C
Yes,
I
just
don't
remember
what
I
sticked
stuck
them
under,
but,
yes,
I
did
consider
that
it
might
need
access
to
whatever
the
original
stuff
was,
but
I
figured
that
it
would
most
commonly
want
to
operate
on
whatever
the
result
of
the
the
previous
thing
was.
So
that's
this
first
argument
here.
C
Right
so
in
the
natural
okay,
so
like,
for
instance,
if
you
have
foo
at
bar
and
default
in
this
done
pattern,
if
foo
returns,
nothing,
it
would
go
to
bar
and
if
bar
did
nothing
default
would
run,
but
all
loaders
in
the
chain
have
access
to
default,
because
it's
sort
of
like
a
special
thing.
So
if
foo
uses
default
that
doesn't
preclude
default,
getting
called
at
the
end,
it
just
says,
like
here's,
this
utility,
that
you
can
use.
C
So
have
anything
it
starts
out
as
an
empty
string.
C
Good,
I
think
I
put
it
as
empty
string
because
it's
of
type
string
and
then,
if
it's
an
empty
string,
it's
still
falsy.
C
Not
exist,
sorry,
I
misspoke.
If
it's
the
first
one
in
the
chain.
The
value
of
interim
result
is
the
original
specifier
and
then
original
specifier
is
also
persisted
under
context.
It
can't
be.
A
C
Yes,
so
like
the
url
would
be
original
specifier.
A
A
Do
something
else
return
interim
result
as
in
if
this
is
not
the
first
loader
in
the
chain
like
it,
it's
a
pass-through.
It's
like,
as
a
does
nothing
type
of
thing.
You
know
whatever
the
whatever
the
loader
ahead
of
this
one
returned
should
just
continue,
could
should
continue
to
be
the
result
of
this
one.
A
Well,
it
does
raise
the
question
of
like
what
am
I
returning
like
shouldn't.
If,
if
interim
result
is
like
interim
result,
it
feels
like
it
should
be.
The
mutable
result
of
the
whole
loader
chain,
like,
if
I
just
like,
say
interim
result.url,
equals
something
that
should
be
enough.
I
shouldn't
have
to
return
it.
You
know.
C
I
think
it
would
just
ignore
it
because
it
would
be
checking
the
return
value,
but
we
could
set
it
to
check
interim
result
and
check
for
mutations
and
whatever
on
it.
But
I
think
it
would
be
safer
to
check
something
returned.
B
Is
there
any
mechanical
difference
because
interim
result
can't
be
shared
amongst
loaders,
so
why
not
just
be
an
option
from
other
loaders
yeah?
So
if
we
have
foo
and
bar
if
foo,
for
some
forbidden
race
conditioning
reason,
has
an
operation
that
mutates
interim
result
after
bar
gets
interim
results,
that's
bad!
A
C
Like
if
you
called
done
and
gave
it
a
value,
that
value
would
be
considered,
the
final
value,
if
you
have
interim
result
in
this
scenario,
is
merely
an
input.
So,
if
you
return
interim
result.
B
C
So
so,
in
the
next
example
like
in
the
the
next
proposal,
it
would
be
like
not
calling
next
and
just
merely
returning.
B
C
Okay,
yeah,
you
could
return
interim
result
and
achieve
the
same
kind
of
thing.
I
was
thinking
that
it
would
be
a
little
bit
cleaner
to
allow
it
to
just
do
nothing,
and
then
you
can
like
put
at
the
top
of
your
file
like.
If
not
https
return.
You
could
say
they
must
return
interim
result
or
something,
but
that
seems
putting
more
burden
on
the
user
to
know
that
I
think
interim
result
is
required.
B
C
C
Yeah,
so
how
I
was
imagining
the
implementation
of
this
being
is
I
would
check
to
see
that
the
return
value
is
an
object
and
then
pluck
format
and
urls
values
from
that
and
if
those
are
truthy
or
whatever
create
a
new
object
with
those
values
and
then
pass
that
to
the
next
loader
and
discard
the
old
interim
result.
C
Okay,
that's
fine,
okay,
cool,
but
if
we
want
to
require
them
to
return
interim
result
instead
of
returning
nothing,
I
think
that
could
also
be
okay.
Just
seems
like
a
little
bit
extra
that
we
don't
need
to
make
them
do.
B
I
mean
it's
about
clarity.
Well,
it's
don't
we
also.
B
C
So
you
could.
That
seems
more
dangerous
to
me,
but
maybe
it's
not.
B
Okay,
but
no
I
mean
overall,
seems
fine
seems
about
the
same
level
of
concern
as
what
we've
got
right
now.
My
main
concern
still
is
it's
one
direction.
You
can't
pass
in
both
directions.
A
B
A
Well,
that's
that's
what
I
was
going
to
say
that
was
like.
What's
the
what's
the
new
default
one
ever
doing
in
this
case,
because
it's
like
it's
human
here!
Well,
no,
but
it's
like
node's
default
is
always
the
end
of
the
chain.
So
just
like
nodes
default
resolve
kind
of
like
if
intra
result
exists
return.
It
else,
take
the
original
inputs
and
do
the
regular
node.
C
Yes,
and
I
think
it
would
be
like
if
you
return
an
incomplete
something,
then
the
default
loader
at
the
end
of
the
chain
would
step
in.
If
you
returned
the
completed
stuff,
it
would
say,
like
quote,
there's
nothing
for
this
to
do,
because
you
still
have
access
to
default,
resolve
or
whatever.
What
have
you
in
the
second
to
last
one?
So
if
you
needed
it,
you
still
can
use
it.
B
B
C
Sorry
default
resolver,
I
don't
remember
a
default.
Resolver
does
oh
like
if
the.
If
the
file
is
javascript
like
dot
js
and
it's
it's,
it
would
normally
handle
this
itself.
I
don't
know
if
you
would
need
to
default
resolver,
for
instance,
in
results.
A
B
A
A
You
know,
I
don't
think
this
is
possible
in
the
new
design
because,
like
the
new
design,
it's
possible,
but
it's
a
little.
C
A
Like
say,
you
wanted
to
write
a
loader
that
always
replaced
underscore
with
lowdash
okay,
so
you
would
see
the
specifier
would
be
under
specifier.
There
would
be
like
if
specifier
is
underscore
return,
next
low,
dash,
comma
context
right
and
that's
a
way
of
like
I
just
replaced
the
specifier,
but
I
didn't,
I
didn't
replace
it
with
the
url.
This
is
not
a
valid
url.
A
C
C
Okay,
so
let's
say
foo
does
that
foo
detects?
Let's
say
you've
got
underscore
slash
for
each
and
it
changes
that
to
lowdash
slash
for
each
that's
fine.
It
can
pass
that
along
to
bar
and
then
bar
will
look
at
that
and
say,
like
I
don't
know.
Maybe
bar
is
for
unpackaged
or
something,
and
it
says
like.
I
need
to
go
fetch
this
from
somewhere
or
it's
so
then
it
replaces
it
with
an
https
like
actual
url.
A
B
B
B
B
C
Do
it
either
way
so
yeah?
I
think
the
main
difference
would
be
for
the
load
hook
where
in.
A
C
A
No,
it's
yeah,
because
you
have
the
same
issue
there.
It's
like
here,
scroll
down
a
second
to
the
example
with
the
load.
A
If,
if
I
wanted
to
maybe
go
to
the
copy
script,
one
because
it
might
be
simpler
than
this,
let
me
do
something
real
quick
here.
A
I
see
yeah.
Basically,
I
want
to
share.
C
Okay,
so
on
the
right
is
the
design
document
and
on
the
left
is
the
proposal
issue.
A
Okay,
all
right!
So
if
we
go
to
the
conference
group
loader
on
the
on
the
right.
A
So
load
gets
url
and
returns
format
and
source.
Okay,
so
let's
say.
A
Trying
to
think
of
an
example
but
like
let's
say
this
load
hook
for
some
reason,
wanted
to
rewrite
the
url
that
the
next
load
hook,
processes.
A
Like
well
maybe
the
htbs
exam
was
a
better
example.
If
you
scroll
down
like
say
so,
this
is
the
https
loader
right.
Imagine
there's
another
loader
called
the
http
loader
right
that
all
it
does
is
that
if
it
sees
a
url
that
starts
with
http
colon
slash
it
rewrites
it
to
https
and
then
calls
the
you
know
the
next.
The
next
loader
yeah.
A
Shouldn't
that
have
happened
in
resolve,
but
yes,
but
it
could
happen
here.
C
You'll
encounter
like
weird
cash
issues,
because
url
as
it
is
provided
to
load
is
the
cache
key
and
then,
if,
for
now,
the
the
load
hook.
A
C
Okay,
well,
if
the
load
hook
starts
like
doing
arbitrary
things
and
not
respecting,
basically
what
is
the
canonical
value,
then
I
think
you'll
get
yourself
into
trouble.
I
don't
understand
what
you
mean
canonical.
C
Well,
sorry
official,
I
just
mean
like
as
far
as
official
as
it
can
get
the
value
passed
into
url
is
the
resolved
value.
So
I
think
the
resolved
value
is
intended
to
be
like
the
god's
truth
like
that's,
that
is
what
the
the
url
of
this
module
is.
B
C
A
B
A
Throw
something
out
there
like,
I
almost
feel
like
the
two
approaches
are
almost
like
summarized
by
like
the
one
on
the
right
here.
Next
is
essentially
recursion
and
the
one
on
the
left
is
essentially
like
iteration
like
yeah
it.
The
one
on
the
left
is
like
you
run
up
a
bunch
of
functions
in
series,
almost
as
if
you
had
an
array
of
function,
calls
and
the
one
on
the
right
is
like
you
run
one
function
and
then
inside
that
function
it
calls
the
next
one
inside
that
one.
It
calls
the
next
one.
A
So
it's
like
recursion,
then
it's
like
adding
up
the
call
stack,
yeah
so
similar
actually
similar
to
recursion.
You
can
forget
to
like
break
out
of
it,
but
it
lets
you
be
more
elegant
and
that
you
don't
need
as
many
inputs
and
outputs
like
we
don't
have
to
have
the
variation
of
the
function.
Arguments
versus
the
or,
like
the
original
arguments
versus
the
interim
result,
because
it's
always
just
the
arguments
you
know
like
that's
the
recursion
elegance
in
play.
C
Maybe
well
typically,
when
you're
using
recursion
instead
of
iteration,
it's
because
it's
a
little
bit
more
like
human
mind
friendly.
I
don't
know
if
that's
really
not.
C
That
reminds
me,
so
we
do
not
expect
to
have
tons
of
loaders,
so
we're
not
going
to
get
into
like
a
stack
overflow
kind
of
situation,
probably
well.
A
A
Like
express
middleware,
each
piece
of
express
middleware
calls
the
next
one.
So
if
you
set
a
breakpoint
in
like
one
of
your
route
handlers,
it's
got
a
tremendous
call
stack
of
like
you
know,
however
many
pieces
of
middleware
you
had
in
your
application,
because
they're
all
wrappers
around
whatever
you
set
the
breakpoint
on.
A
B
B
D
C
C
C
Of
the
loaders
loads
loads
sticks
something
huge
into
memory.
That
memory
cannot
be
released
until
all
of
this.
The
the
inception
chain
kind
of
like
collapses
back
up
into
reality,
right.
D
D
B
Let's
say:
fu
calls
bar
bar
allocates
a
hundred
megabytes
of
memory
for
an
image
or
something
it
returns,
a
result
to
foo
unless
bar
is
leaking
memory.
Only
foo
now
has
the
reference
to
the
hundred
megabytes
bar.
Doesn't
if
food
doesn't
keep
it
somehow
purposefully,
it'll
be
garbage
collected.
C
But
I'm
thinking
so,
let's
say:
you've
got:
let's
switch
to
letters,
a
b,
c
d
e
f
each
one
of
those
like
a
is
calling
b
and
then
b
is
calling
c.
C
But
a
and
b
each
one
that
calls
before
each
one
of
those
is
loading,
a
hundred
megabytes
of
images.
So
when
you
get
down
to
like
f
the
previous.
A
C
Yeah
but.
B
B
No
because
I
can
attach
stuff
anywhere,
I
can
keep
stuff
alive
using
set
timeouts
and
stuff
like
that.
I
might
have
data
intentionally
loaded,
even
small
amounts
of
data
intentionally
loaded
waiting
on
the
results
of
whatever
comes
next
in
the
chain.
So
while
it's
possible,
I
believe
both
bleak
memory.
If
you
allocate
a
ton
and
hold
on
to
it,
you
would
need
to
reap
the
whole
function.
Scope.
C
I'm
thinking
in
the
loop
scenario
it's
much
much
less
likely
like
you
would
have
to
try,
but
in
the
sort
of
like
inception,
recursion
types
of
scenario,
you
could
quite,
I
would
say,
innocently.
C
Let's
say
I'm
getting
get
source
on
well,
let's
say:
first,
I
load
over
https
some
string
or
somewhat
some
some
data.
Then
it
turns
out
that
that
data
is
typescript
typescript.
I
have
the
raw
typescript.
I
need
to
pass
that
to
a
typescript
loader.
Then
the
typescript
loader
is
gonna.
Do
some
stuff
internally,
let's
say
for
instance,
for
some
reason:
it
is
using
a
bevel,
a
babble
to
do
some
trans
transpiling
stuff
and
then
her
typescript
is
also
going
to
do
the
conversion.
B
Can't
do
it
out
of
order
you're
trying
to
do
it
in
reverse
order.
You
need
to
get
the
source
at
the
default
level.
Somehow
that
has
to
pass
through,
probably
babel.
First,
it
sounds
like
and
then
it
passes
down
to
typescript,
and
so,
if
f
is
the
default,
it
holds
onto
the
string,
it
passes
it
to
babel
e,
it
does
its
processing
and
stops,
and
so
it
drops,
then
it
passes
it
back
to
typescript.
Does
its
processing
drops
so
I'm
trying
to
understand?
B
C
Yes,
where's
the
coffeescript
one
so,
for
instance,
result
here
is
this
is
basically
like
the
raw
result.
So
this
is
the
the
string
of
the
coffeescript
file.
C
Then
source
here
is
passing
that
raw
coffeescript
file
to
the
coffeescript
compiler
and
then
that's
gonna
return,
the
transpiled
source.
So
that's
true
for
both
effectively
yeah,
for
which.
B
C
Well,
let's
say
there
are
multiple
levels
here,
though
so,
let's
say
a
coffee
script.
The
result
of
coffeescript
subsequently
needs
to
be
transpiled
by
babel.
That
would
need
to
happen
after
the
coffeescript
stuff
gets
compiled
so
there
that
would
be
sort
of
this
interim
thing
here.
So.
B
C
C
Yeah
but
then
you
still
have
the
raw
source
of
this.
The
file,
okay,
plus
something
else.
C
C
B
C
B
Next
is
not
gonna
call
babel
ever
ever
next
is,
is
going
to
call
the
default
loader
of
some
kind
or
some
https
loader
you're
you're,
trying
to
conflate
next
with
calling
an
operation
that
works
on
javascript
here.
This
is
the
coffeescript
loader
takes
coffeescript
and
does
an
operation
on
it
and
results
in
javascript,
which
babel
can
work
on.
B
C
B
No
in
the
next
recursive
form
you're
you're,
just
returning
results.
You
only
operate
when
you
are
called
and
you
return
results.
You're
not
saying,
there's
more
work
to
be
done.
You're
saying
you
need
the
results
of
something
else.
C
C
Here
this
result
would
be
like
the.
A
C
C
Yeah,
but
in
in
the
bible
babel
scenario,
this
result
would
have
been
the
result
of
that
default,
loader
and
then
also
coffeescript.
So
now
this
is
just
the
coffee
script.
B
B
D
C
B
A
Cli
argument
well
sure,
but
then
you
can
but
we're
not
going
to
offer
left
we're
only
going
to
offer
right.
You
know
so
it's
like
that's
fine
right
so
like
next
is
like
say
it's
dash,
loader
coffeescript
loader
battle,
and
then
that's
it
and
there's.
So
then
there's
three
loaders
in
the
chain:
it's
the
those
two
and
then
the
default,
the
node
one.
So.
A
A
C
A
A
A
Let's
look:
where
do
we
go
from
here?
Do
you
want
to?
Maybe
I
would
suggest
if
you
don't
mind,
maybe
let's
close
the
issue
on
the
main
node
repo
and
start
like,
say
a
new
issue
or
pr
on
the
loader's
repo
with
like
a
revised
design,
maybe
a
pr,
and
then
we
can
just
iterate
on
that
off
sync,
and
that
way
we
can
include
everybody
else.
C
A
Don't
we
maybe
write
it?
Why
don't
we
make
two
files
so
like
we
can
make
one?
We
should
come
up
with
names
for
the
two
of
them,
the
like
ones,
whatever.
A
And
iterative,
or
something
like
that
and
then
like.
Maybe
that
could
be
a
quick
pr.
We
land
just
rename
this
one
to
like
recursive
design
and
then
you
can
create
a
pr
to
add
iterative
design
as
a
separate
markdown
file,
and
then
in
that
pr
we
can
iterate
and
do
lots
of
nodes
and
you
could
keep
revising
it
until
it's
the
best
it
can
be.
And
then
you
know
it
eventually
goes
in
and
we
can,
you
know,
choose
one
and
then
delete
the
other
file
as
a
final
pr
or
something
like
that.
A
C
A
C
A
These
both
have
pros
and
cons
like
the
I
feel
like
there's
a
lot
of.
I
understand
what
you're
trying
to
do
with
like
trying
to
eliminate
the
you
know:
failure
to
call
the
thing
to
short
circuit,
but
at
the
same
time,
like
the
new
design,
just
adds
a
lot.
You
know,
there's
a
lot,
there's
more
inputs
to
the
function
and
there's
more
potential
outputs
to
the
function.
So
it
just
feels
a
lot
more
complex
to
me.
So
I
don't
know
I
mean,
maybe
that
complexity
is
better
because
you
have
to
there's
more
opportunities
for
explicitness.
A
So
I
don't
really
know
what's
what's
better,
but
I
feel
like
both
of
them
could
be.
Both
of
them
could
be
improved
to
get
to
their
better
versions
of
themselves.
So
maybe
we
should
kind
of
develop
both
of
them
and
and
then
kind
of
see
from
there
and
get
feedback
from
people
and
like
what
use
cases
would
be
missing
from
each
one.
B
One
thing
we
could
do
is
we
can
combine
them,
it
would
be
gross,
but
it's
doable.
Basically,
if
you
take
the
recursive
form
and
have
you,
you
must
call
either
next
or
kind
of
a
skip
function
whatever
or
short
circuit
function
kind
of
like
how
done
is
in
the
iterative
form.
B
C
Yeah,
my
my
main
concern
was
only
that
it
was.
It
seemed
quite
easy
to
accidentally
do
something
that
you
did
not
want
to
do
well,.
A
Minor
change,
the
original
design
that
achieves
that,
maybe
not,
but
I
feel
like
there
probably
could
be
now.
I
feel
like
that's
not
all
you
had
in
mind
if
you
came
up
with
a
whole
new
design,
like
you
probably
wanted
some
of
these
other
ideas
for
certain
things,
and
so
I
think
that
and
that's
worth
while
I'm
not
saying
that
those
are
that's
bad
or
anything
so,
but
I
think
we
should
call
that
out
like
what
are
all
the
advantages
of
the
new
proposal.
B
B
A
Well,
oh,
as
so
in
the
in
a
current
node
code
base,
because
they're,
because,
like
even
our
example
loaders,
some
of
them
don't
like.
If
you
look
at
the
current
https
loader,
it
never
calls
default
load
because
that
wouldn't
make
sense.
You
know
like
this
one
here
is
unchanged,
whether
it's
chained
or
not,
because
this
one
is
always
the
end
of
the
line.
D
A
Yeah,
it
would
just
be
like
there
would
be
some
other
parameter
in
there
like
next
comma
short
circuit
or
something
or
skip
or
whatever
you
want
to
call
it,
and
then
it's
like
the
function
has
to
call
one
or
the
other
if
it
calls
short
circuit
or
skip
whatever
we
call
it,
then
that's
a
way
of
just
swallowing
the
error.
It
would
be
like
a
no
off
to.
B
A
A
C
A
All
right
we
should
get
going,
but
I
look,
let
me
know
I
I
can
open
like
the
precursor
pr,
just
like
renaming
the
file
on
the
record
or
something
and
then
let
me
know,
and
we
can
coordinate
that
stuff
and
then
get
it
up
there,
and
I
will
and
then
so
I'll
assume
we'll
meet
two
weeks
from
today.
A
At
the
same
time,
I'm
trying
to
get
access,
I
asked
for
access
to
the
calendar,
remove
the
meeting
officially
and
then
then
we
can
like
move
it
ad
hoc
as
needed
for
the
other
people
who
are
occasional
visitors.