►
Description
Rejon @maximumcrash joins us for a superadmin architecture walkthrough of the Community Development Portal.
Community Development Portal:
https://community-development.makerdao.com/
A
Let
me
share
my
screen
with
you
and
start
the
typical
rigmarole,
hello,
everybody
everybody
on
youtube.
My
name
is
rajon
and
I
also
go
by
maximum
crash
in
the
community,
but
essentially
to
put
it
the
perfect
way,
I've
been
the
lead
developer
on
the
portal
project
since
april
of
2020.
We
are
here,
we've
made
it
one
whole
year
since
we
started
development
and
I'm
kind
of
just
going
to
fly
through
these
slides.
They
are
available
for
a
much
longer
call
at
this.
This
youtube
video,
this
youtube
community
call.
A
Let
me
throw
this
in
the
chat:
real
quick
for
y'all
chat
boom.
So
if
you
want
to
see
the
rest
of
these
slides,
you
can
definitely
go
through
it,
but
essentially
to
start
off
with
our
agenda.
The
first
is
really
just
talking
about
where
we
started
and
why
we
made
some
of
the
decisions
that
we
made
for
the
project
when
we
started.
A
Initially,
there
was
the
stakeholders
for
the
portal,
were
tim,
amy
and
rich,
who
is
no
longer
with
the
community,
but
he's
still
around
in
his
ghostly
ways,
and
essentially
the
the
cry
for
help
was
that
the
initial
portal
that
they
had
previously,
I
believe,
was
running,
get
books
on
github
and
it
was
very
crunchy
to
work
with.
It.
Didn't
really
do
everything
that
everybody
wanted.
A
So
some
of
the
mission
objectives
initially
was
to
leverage
a
framework
if
one
existed,
that
essentially
enables
folks
to
create
content
to
write
to
design
new
elements,
make
videos
and
then
have
a
collective
place.
To
then
share
that,
given
that
the
maker
dial
community
is
global,
we
also
need
to
be
able
to
solve
for
localization
and
also
making
the
platform
accessible
for
our
localizers
as
well.
A
The
directory
of
content
needed
to
be
decoupled.
This
was
a
very
big
request
from
rich.
Initially,
they
hated
the
folder
structure
for
git
books.
It
was
very
unintuitive
and
my
approach
is
essentially
to
kind
of
lessen
the
amount
of
time
it
takes
to
solve
a
typo
right,
like
the
amount
of
time
from
somebody
seeing
a
typo
on
our
website
and
going
oh
crap,
somebody
spelled
the
word
worm
wrong,
and
now
we
have
to
fix
it.
All
of
our
developers
are
asleep
because
it
is,
I
don't
know,
probably
like
10
a.m.
A
Here
in
south
africa,
everybody
is
asleep.
How
do
I
fix
this?
How
do
I
have
the
agency
to
be
able
to
solve
a
problem
when
I
see
it
so
that
really
was
a
very,
very
big
ask
for
this
kind
of
project,
but
the
next
big
one
was.
We
need
to
be
able
to
allow
our
writers
to
have
access
to
any
tools
that
they
want.
Any.
A
That
means
any
components
if
they
want
to
put
a
heat
map
on
the
website,
they
should
be
able
to
without
any
really
strict
limitations
other
than
the
tediousness
of
implementing
something
like
that,
and
then
the
last
one
was
transferring.
The
old
content
should
be
a
snap
right
like
we
don't
want
to
lose
any
of
the
content
that
folks
have
already
written,
because
there's
a
lot
of
pages,
hundreds
of
pages
already
existing
on
the
skip
books.
A
A
So
we
kind
of
started
off
kind
of
designing
what
a
dream
cms
would
look
like,
essentially
giving
our
writers
the
agency
to
create
the
content
they
want
without
the
need
to
really
reach
out
to
any
developer.
Like
hey,
I
wrote
this
thing
wrong.
How
do
I
do
it
right?
Because
not
everybody's
going
to
be
available
all
the
time?
We
also
wanted
to
make
sure
that
there
was.
A
You
know
solving
for
that
amount
of
time
to
fix
a
typo
situation
where
the
barrier
of
entry
for
new
folks
joining
our
community
was
extremely
low,
but
also
making
sure
that
we
could
make
the
new
system
adoptable
by
the
existing
writers
was
very
important.
So,
with
that
in
mind,
get
books
was
written
mostly
using
markdown,
which
was
a
really
really
big.
I
want
to
say
advantage
for
us
moving
forward
because
right
around
the
same
time,
we
were
doing
a
little
bit
of
research
and
development
for
this
dream.
A
Cms,
we
came
to
discover
a
number
of
really
good
technologies
that
just
happened
to
work
really
really
well
together.
If
we
could
make
them
work
well
together
and
then
using
these
technologies
to
essentially
establish
a
philosophy
for
how
folks
will
work
together
in
our
community,
so
some
of
those
our
stack
looks
like
this
github
acts
as
the
source
of
truth
kind
of
where
everything
will
start
and
end.
Then
we
have
gatsby
js
as
our
underlying
react
framework.
A
The
beautiful
thing
for
me
with
gatsby
is
that
it
has
really
really
good
document
querying
using
their
graphql
engine.
I
think
which
is
might
be
built
off
as
sift.
I
could
be
wrong,
but
as
at
the
time
of
this
conversation
here,
youtube
gatsby
has
launched
version
three
of
their
framework
and
our
current
stack
is
built
using
gatsby
version
two,
so
I'm
not
entirely
sure
what
the
upgrade
process
will
look
like
for
that.
It
might
be
a
little
bit
crunchy,
but
lo
and
behold,
if
they
made
it.
A
A
Next
is
the
bread
and
butter
of
the
whole
markdown
conversion
conversation
which
is
mdx.js
or
mdxjs,
and
it's
kind
of
the
heart
of
our
engine.
It
essentially
enables
us
to
write
our
website
using
markdown,
but
the
beautiful
part
of
it
is
that
it
allows
us
to
interweave
markdown
with
react
components,
and
when
we
start
talking
about
being
able
to
enable
our
writers
to
write
code,
we
start
to
dip
into
the
biggest
philosophy
behind
the
portal
moving
forward.
But
that's
the
next
step.
I
don't
wanna,
I'm
just
teasing
you
off
a
little
bit.
A
Some
of
the
boring
stuff
here,
which
is
also
equally
exciting,
is
we
are
using
lunar.js
for
our
static
search
indexing.
Typically,
you
could
use
something
like
algolia,
but
in
this
case
we
got
to
keep
in
mind.
We
want
things
to
stay
free,
and
that
means
having
our
search
index
also
be
part
of
the
build
process
for
the
website.
A
And
lastly,
I
built
a
custom
translation
module
to
kind
of
support
the
flexibility
needed
by
the
localization
teams
here
at
the
community,
and
you
might
think,
I'm
crazy
for
building
my
own
translation
module,
given
that
there
are
many
many
solutions
to
this
and
I
may
have
reinvented
the
wheel,
but
essentially
by
building
our
own
translation
module.
We
are
given
the
flexibility
to
change
it
to
meet
our
needs,
rather
than
changing
our
content
to
meet
its
needs
so
yeah,
it
solves
for
a
lot
of
things
right
this.
This
stack
in
particular.
A
A
So,
if
anybody's
like,
I
need
this
file
from
this
page,
you
can
look
at
the
url
and
the
url
will
directly
match
the
directory
structure
that
we
would
see
in
your
code
editor
or
any
editor
that
you're
using
comfortably
github
serving
as
the
source
of
truth
solves.
You
know,
naturally
not
only
source
control
for
the
project,
but
it
also
enables
communication-
and
we
have
a
couple
of
things
designed
on
the
community
portal
in
particular
to
enable
these
conversations
around
the
work
that's
being
done
in
particular.
A
Personally,
I
don't
really
like
when
folks
will
just
write
code
and
submit
it,
and
then
I
may
not
know
I
may
not
notice,
and
nobody
on
the
team
knows
and
the
folk
the
person
who
did
it
will
forget.
So
essentially,
we
have
a
little
bit
of
devops
more
of
a
get
ops
process
for
enabling
these
conversations,
where
we
have
certain
branch
permissions.
A
Naturally
combined
with
pr
reviews.
At
least
one
human
must
see
it.
And
then
we
have
a
couple
of
apps
added.
We
have
the
good
old
dependabot.
We
are
using
kodiak
for
pr
cues
and
we
are
also
using
excuse
me
a
little
github
action
called
pool
party
deploy,
which
is
just
another
custom
script
that
I
put
together
for
essentially
stopping
pool
parties
from
happening
in
your
code
and
your
content,
and
you
might,
you
might
see
it
on
our
repo
called
a
lifeguard,
but
essentially
they're
the
same
thing.
A
And
then
you
know
we
had
our
own
designers
here
in
the
community,
designing
for
the
portal
and
designing
for
other
projects,
but
essentially
dye
ui
is
meant
to
solve
those
communication
issues
and
making
sure
that
we're
everybody
knows
what
our
design
philosophies
are
from
a
technical
standpoint,
not
an
actual
design
standpoint
and
then
finally
mdx.
I
can't
really.
I
can't
really
gloat
about
it
enough.
It's
a
wonderful
technology
and
I
believe
it
may
be
the
future
of
writing
websites
in
the
future.
A
But
the
most
important
part
about
mdx
is
that
it
enables
a
specific
kind
of
practice
or
an
underlying
little
secret
thing.
I
was
kind
of
enabling
and
pushing
on
to
our
writers,
where
you
know
everybody
wants
more
control,
but
not
everybody
wants
to
maintain
the
systems
that
require
that
control
using
mdx
js
enables
us
to
kind
of
push
this
philosophy
of
architecture
for
the
website
versus
how
it's
executed
and
the
tldr
there
is.
I
would
essentially
tell
the
team
all
summer
that
I'm
not
writing
the
website.
A
You
are
because
we
would.
We
would
essentially
create
this
stack
the
developers
at
the
time.
It
was
me,
isaac,
pearl
and
elijah,
and
you
know
I
was
probably
june
or
july
in
august.
I
want
to
save
during
our
first
phase,
but
we
were
more
so
tools
developers
that
we
were
just
front-end
developers,
and
I
think
that
distinction
is
super
important,
because
what
ends
up
happening
is
your
content.
Creators
and
your
writers
and
your
designers
become
engineers
over
time
through
the
means
of
creating
content
for
the
website.
A
However,
naturally,
with
any
stack,
no
stack
is
forever.
Gatsby
is
not
forever
right.
They
came
out
with
a
new
version
just
as
we're
getting
ready
to
sign
off,
and
we
had
to
essentially
make
sure
that
by
using
mdx
combined
with
the
react
interlacing
with
markdown,
we
can
sort
of
kind
of
almost
ensure
that
our
content
doesn't
become
locked
into
any
hard
framework.
A
That
means
almost
every
single
person
that
has
actually
worked
on
our
website
that
has
contributed
to
our
website
is
also
a
junior
front-end
engineer.
To
some
extent,
the
more
a
writer
would
want
out
of
the
mdx
system,
the
more
knowledge
they
gained
with
react
or
with
javascript.
It's
like.
Oh,
I
want
this
component
to
do
x,
y
and
z.
Well,
you
can
make
it
the
same.
The
same
code
you've
been
writing
for
the
website.
A
Is
the
same
code,
we
would
use
to
create
your
components
give
or
take,
and
you
know
I
think,
that
this
philosophy
was
proven
super
heavily
when
our
designer
shay
was
able
to
go
into
our
system
and
change
some
of
the
css
parameters
and
make
a
commit
and
everything
went
through
clean.
So
if
that
doesn't
really,
you
know,
prove
the
chef's
kiss,
and
you
know
it
doesn't
it
doesn't
if
it
doesn't
prove
that
we've
got
a
really
good
secret
sauce
to
put
in
here
with
this
system.
A
A
I
can
talk
about
this
for
hours,
at
least
in
our
philosophy,
but
I
think
we
should
definitely
start
moving
on
to
some
of
the
more
super
admin
related
stuff
get
a
little
bit
more
technical.
But
my
final
final
words,
especially
in
regards
to
gatsby
being
upgraded
from
version
to
the
version
three,
is
that
I
believe
they're
starting
to
address
some
of
the
issues
that
I
address
on
this
slide,
where
everything
sounds
fantastic,
but
naturally
that
lift
has
to
go
somewhere
because
we
built
a
lot
of
the
systems.
A
They're
all
documented
in
a
separate
repo
called
community
dash
portal,
where
there's
probably
200
or
so
pr's
with
charles
dickens
worth
sleuth
of
information.
But
the
lift
is
that
gatsby
is
has
been
notoriously
known
for
having
really
bloated
build
times.
That
means,
if
you're,
using
a
cicd
process
like
netlify,
it
will
cost
you
more
as
you
use
it
more.
The
more
content
you
add,
the
slower
the
build
times.
Are
it's
an
unfortunate
fact,
but
at
the
end
of
the
day
the
website
is
free,
so
the
cost
has
to
go
somewhere.
A
A
Let's,
let's
just
look
at
the
folder
structure
here,
because
it's
a
lot
more
beautiful,
so
prior
we
had
a
separate
repo
that
this
project
was
initialized
and
called
community
dash
portal.
It
didn't
contain
certain
files
that
are
here.
We
ended
up
merging
that
repo
into
the
main
community
repo
at
large.
So
it's
a
little
bit
of
a
mono
repo.
A
It
solves
multiple
problems,
but
its
structure
is
still
having
our
gatsby
project
at
the
top,
and
then
there
are
a
couple
of
other
really
required
directories
that
are
used
by
other
projects
in
the
community.
Specifically
things
like,
if
you
see
like
contributing
faqs
content,
oh
not
content,
governance
grants
hackathons,
meetups
onboarding.
A
lot
of
these
directories
are
managed
by
long
for
wisdom
and
the
data
that
go
inside
of
them.
They're
also
markdown
files
from
what
I've
noticed
are
used
by
certain
procedures
in
our
community
and
on
the
chain
as
well.
A
So
those
are
dangerous
files.
We
don't
touch
those
we
don't
have
to
be
concerned
about
those.
A
lot
of
our
project
is
kind
of
contained
within
a
vacuum,
which
is
the
beauty
of
the
graphql
system.
That
gatsby
enables
us
to
use,
but
let
me
open
up
a
couple
of
links,
starting
with
source
and
content,
so
source
directory.
If
you're
not
a
developer,
don't
be
afraid.
This
is
kind
of
where
all
of
our
code
for
the
project
lives.
A
But
we
also
have
a
components.js
file,
which
you'll
see
has
something
called
an
md
override
the
beautiful
thing
about
mdxjs.
Is
that
not
only
does
it
allow
you?
Well,
we
already
know
I've
said
this
hundred
times,
but
the
interlacing
of
markdown
and
react,
but
it
also
enables
us
to
create
our
own
components,
and
this
is
where
they
get
defined.
A
So
you'll
see
things
like
we'll
have
like
basic
definitions
like
an
anchor
link
or
we'll
have
a
custom
link
component
for
that
or
something
like
a
table
or
a
divider
will
have
custom
components
because
we
have
custom
styles.
What
else
do
we
have
right?
We
actually
have
custom
components
that
go
outside
of
the
scope
and
limits
of
just
the
markdown
elements,
because
all
of
these,
like
a
link,
an
image,
h1
h2,
these
are
all
comparable.
A
So
if
you're
working
specifically
with
authors,
you
would
look
in
the
author's
module
and
that
will
have
its
own
piece
of
information,
and
god
bless
antonio
for
helping
to
clean
this
up.
For
me,
where
we
now
have
our
components,
we
have
data
functions
and
methods
and
any
transformers
to
existing
data
kind
of
situated
in
our
own
contextual
directories
as
well.
This
is
you
know.
This
is
all
design
stuff.
A
A
We
need
to
get
things
done,
I'm
very
much
a
let's
just
get
the
job
done,
first
kind
of
developer
because
there
won't
be
any
code
to
refactor
or
clean
if
the
project
isn't
finished.
So
that's
why
we're
doing
all
the
nice
typing
stuff
now,
but
naturally,
all
these
other
modules
they're
very
specifically
tied
to
things
that
we
would
want
to
focus
on
and
before
I
dive
deeper
into
these
modules,
we
have
the
pages
directory,
which
is
a
directory
expected
by
gatsby
for
the
different
pages
of
our
site.
A
A
This
is
the
page
that
you
will
land
on,
but
you
won't
actually
see
it
and
to
show
you
that
let's
go
just
the
slash
right.
Let's
so
you
see
a
little
blank
page
and
then
it
drops
you
into
en
that's
a
little
bit
of
an
example
of
our
translation
module
at
work,
and
that's
because
oh
wait,
I
gotta
go
to
that's
because
this
page
serves
solely
to
redirect
our
users
based
on
the
locale
of
their
browser.
A
A
So
yeah,
that's
just
a
just
a
navigate
to
our
initial
locale
and
another
thing
about
initial
locales
is
that
the
project
has
a
default
locale,
and
in
that
case,
in
the
case
of
our
portal,
that
default
locale
is
en
for
english.
Excuse
me
that
default
locale
is
english
and
it's
important
to
have
that
default
locale,
because
it
acts
as
a
fallback
in
the
case
that
other
languages
don't
exist
and
we'll
dive
much
deeper
into
that.
A
Once
we
start
talking
about
some
of
the
auto
magic
that
is
happening
to
generate
our
site,
but
you've
probably
heard
me
say
a
lot
of
things
like.
Oh,
what
you
see
is
what
you
get
and
the
content
creator
essentially
control
the
website.
That
means
every
single
page
is
home
page.
This
learn
page
all
of
it
is
written
in
mdx,
and
these
pages
exist
inside
of
the
content
directory.
A
So,
at
the
top
level
of
our
project
we
have
a
content
directory
and
inside
of
that
you'll
see
you
can
ignore
the
all
contributors.json.
That's
a
little
bit
more
extra,
we'll
get
to
that
at
the
end.
Possibly
but
you'll
see
that
we
have
en
and
then
you'll
see
that
we
have
an
index
that
mdx,
let's
go
into
that
and
we'll
see.
A
Let
me
look
at
the
raw
for
this
you'll
see
that
we
have
markdown
a
couple
of
front
matter
parameters,
but
this
is
the
markdown
and
react
being
interwoven
to
create
the
page
that
we
have
here
on
the
home
page
like.
If
we
were
to
look
for
this
welcome
to
community
development,
we
can
find
that
here
it's
just
an
h2
and
markdown,
but
it
is
surrounded
by
a
component.
A
This
h3
will
then
render
just
below
this
piece
of
information
here
if
I
was
running
this
locally,
so
that's
all
well
and
good.
However,
you'll
notice
that
the
organization
of
this
directivity
looks
a
little
funky
and
that's
because
of
the
because
of
two
things.
First,
I
want
to
ensure
that
the
content
directory
solves
one
of
our
mission
objectives
of
being
obvious.
When
you
look
at
it,
so
the
slugs
should
match
the
directory.
A
We
are
using
plugin
page
creator
and
what
this
plugin
does
for
us
is.
It
looks
for
a
path
in
this
case.
It's
looking
for
the
content
directory
at
the
top
level
of
our
project,
and
we
have
a
couple
of
ignore
patterns
to
make
sure
that
if
anybody
puts
anything
that
they
shouldn't
be
putting
in
this
directory,
they
just
it
just
gets
ignored
like
don't,
don't
create
a
powerpoint
page.
Please,
like
you
know,
I'm
I
wouldn't
do
that.
I'm
sure
you
wouldn't
do
that,
but
you
never
know
you
know.
A
Folks
may
not
be
as
versed
yet,
especially
if
they're
just
joining
the
community
and
adding
content
they
won't
know
like.
Oh,
where
do
I
put
images
or
oh?
Where
do
I
put
this
powerpoint?
I
want
to
link
to
right,
like
they
just
won't
know
these
things
so
making
sure
that
we
can
prepare
for
those
cases
ahead
of
time
is
super
important,
but
this
little
thing
is
the
thing
that
creates
all
of
our
pages,
based
on
the
mdx
pages
that
exist.
A
However,
we
also
are
using
plugin
we're
using
gatsby
plugin
mdx,
which
enables
us
to
use
mdx
with
gatsby.
It
looks
for
two
extensions,
mdx
and
regular.md
files
so
like
if
somebody
has
an
existing
markdown
file
somewhere,
and
they
just
want
to
slap
it
in
and
not
use
any
of
our
components,
they
totally
can
do
that
and
it
will
render
just
fine
and
we
have
a
couple
of
default
layouts.
A
You
could
ignore
the
blog
post
one
because
that's
a
little
bit
more
newer
and
I
probably
won't
cover
that
for
this
call,
but
the
default
layout
they're,
essentially
kind
of
the
same
they
act
as
the
layout
wrapper
for
the
page.
So,
let's,
let's
go
to
that.
Let's
go
to
default.
Layout.Js
real,
quick
you'll,
see
a
couple
of
really
scary.
Looking
objects
wrapped
in
quotes.
These
are
our
graphql
queries.
A
Specifically,
we
are
running
this
really
disgusting
regex
call
to
ensure
that
we
are
getting
all
of
the
file
absolute
paths
for
all
the
mdx
files
in
our
projects
out
of
the
content
directory
and
this
little
slash
slash
w.
The
two
is
ensuring
that
we
are
getting
all
the
files
out
of
the
little
cale
that
we
need,
and
all
of
these
is
just
ignore-
ignore
all
these
kinds
of
files
right
like
we're,
just
making
sure
that
another
double
check
just
making
sure
nobody's
putting
anything
they
shouldn't
be
putting
in
this
directory.
A
I
know
we're
getting
a
couple
of
pieces
of
data
out
of
that,
though,
right
we're
getting
the
node
which
will
contain
our
headings.
We
get
the
the
first
h1
we
get
its
absolute
path,
so
the
actual
path
it
has
on
our
directory
locally
to
the
file
itself.
So
if
I
was
to
output,
this
you'll
see
something
like
rageon,
slash,
community,
slash
content,
slash
en
slash
whatever
on
our
web
server
or
anywhere
you
may
deploy.
A
This
it'll
essentially
follow
that
path,
depending
on
wherever
it's
being
used,
then
we're
also
pulling
out
some
front
matters
specifically
the
title
and
the
order-
and
this
is
where
I'll
get
into
this
a
little
bit
after.
I
explained
this
page
more
because
that's
when
we
start
digging
deeper
into
the
more
advanced
concepts
of
this
project
and
the
auto
magic
of
it
all.
A
So,
let's
skip
some
of
this
code,
but
a
lot
of
this
code
is
essentially
just
rendering
a
fragment
and
it
renders
a
side
nav
based
on
some
rules
that
we
have
it
render.
It
provides
the
seo
from
the
from
the
page
that
the
important
part
about
this
default
layout
and
the
fact
that
it's
being
used
here
from
the
gatsby
plugin
mdx
is
that
whenever
the
page
creator
plug-in
says
okay,
I've
got
this
mdx
page
from
the
content
directory.
A
I'm
going
to
take
that
page
and
then
I'm
going
to
pass
it
to
the
gatsby
plug-in
mdx
and
the
gatsby
plug-in
mdx
is
going
to
be
like
okay.
What
what?
What
kind
of
what
kind
of
file
are
we
dealing
with?
Where
is
this
file
located?
It's
located
inside
of
def?
It's
it's!
It's
not
defined.
Okay,
go
with
the
default,
and
the
default
in
this
case
is
default.
Layout
blog
posts
matches
the
directory
name
for
where
our
blog
posts
are
located.
So
those
things
are
super
important.
This
is
how
it
knows
that.
A
A
This
front
matter
is
really
just
like
extraneous
details
and
information
about
a
page
that
you
would
want
to
be
recognized
whether
that
be
through
seo
or
if
you
want
to
have
more
modular
control
over
the
elements
that
show
up
in
the
layout
you'll
see
things
like
here,
like
oh
hide,
the
breadcrumbs
component
or
hide
the
scroll
cta.
You
can
even
do
things
like
hide
the
sidenav.
A
If
you
didn't
want
to
sign
that
on
your
page,
this
kind
of
granular
control
essentially
means
that
a
writer
or
anybody
adding
content
to
the
site
could
say.
Oh
I
on
my
page
specifically,
I
don't
want
to
show
this
element.
How
could
I
hide
this
element?
Well,
if
it's
part
of
the
default
layout,
which
it
most
likely
will
be,
you
can
just
add
a
new
boolean
parameter
to
your
front
matter,
we'll
take
that
recognize
it
and
hide
that
thing
from
the
ui.
A
However,
where
does
the
actual
mdx
go
right
like?
Where
does
where
does
all
of
this
below
actually
go?
And
that
goes
inside
this
thing
here
where
it
says
children,
because
the
children
prop
of
the
default
layout
is
the
mdx
that
has
been
converted
into
react
code
that
then
gets
displayed
on
our
website.
That's
actually
really.
The
coolest
part
about
mdx
for
me
is
that
they
take
the
markdown
and
the
react,
and
then
they,
just
at
the
end
of
the
day,
turn
it
into
react
code
that
then
gets
displayed
on
our
user
interfaces.
A
A
That's
about
it,
save
that
push
it
boom.
You
go
to
slash
hello,
slash
en
slash
hello,
you'll,
see
hello,
youtube
and
that's
that
is
like
the
shortest
path
to
creating
a
page
on
our
site.
No
matter
what
page
that
may
be,
it
could
be
a
blog
post,
it
could
be
a
content
post,
it
could
be
the
home
page,
it
could
be
any
page,
and
that
is
how
the
sausage
is
made
all
right.
A
A
A
A
The
other
important
thing
about
the
header,
though,
is
that
all
of
these
pages
have
been
kind
of
designed
by
our
content
creators
to
exist
in
a
header,
so
you'll
see
things
like
if
we
go
to.
Let's
go
to
the
learn
index
page
real,
quick,
you'll,
see
this
parameter
here
called
header,
true
and
you'll,
see
its
header
order
position
with
zero.
Being
first
in
line
left
to
right
is
zero.
You
can
set
this
parameter
on
any
page
of
our
website.
A
A
You
would
see
your
header
updated
with
that
page
that
you
wanted
that's
as
easy
as
it
is
for
a
writer
to
update
the
header
of
the
website
without
having
to
figure
out
where
the
component
is
figure
out
where
the
links
are
and
how
to
copy
and
paste
things.
It's
as
simple
as
adding
this.
Now
it's
simple
to
do
but
executing
it
is
a
completely
different
story
from
a
technical
standpoint,
because
we
have
multiple
concerns.
A
The
first
is
that
we
have
to
kind
of
assume
everybody's
going
to
make
a
mistake.
The
second
is
that
our
entire
website
is
localized
freely
like
as
in.
If
you
wanted
to
create
a
fake
language
and
have
that
be
the
language
you
use
for
all
the
content
on
the
website,
you
totally
can
without
restriction,
and
the
third
is
that
between
locales
there
will
be
files
that
do
exist
and
files
that
don't
exist.
A
You
can't
expect
the
spanish
community
development
website,
for
example,
to
have
all
of
the
pages
that
the
english
one
does,
especially
since
there
are.
There
may
be
different
kinds
of
articles
that
that
community
specifically
want
to
talk
about
or
want
to
solve.
For
so
with
that
in
mind,
how
do
we?
How
do
we
solve
kind
of
it's
an
algorithms
problem,
essentially
where
we
have
to
figure
out?
A
So
in
this
specific
case,
any
pages
outside
of
the
locale
aren't
considered
for
the
side
nav
and
for
the
header.
If
you
wanted
this,
it's
as
easy
as
just
get
rid
of
that
then
boom
you're,
getting
all
the
data
for
all
your
pages
in
the
content
directory,
but
because
we
are
localization
focused
and
we
kind
of
make
sure
that
locale
solving
for
locales
and
solving
for
internationalization,
especially
from
an
accessibility
standpoint,
is
always
solved
first.
That
means
there
isn't
a
consideration
being
made
by
stakeholders
at
oh.
A
We
think
it
might
be
too
hard
to
add
germany
or
it
might
be
hard
to
add
arabic
and
it's
like.
No,
no,
no,
you
can
you
just
need
somebody
to
create
the
content
for
you,
so
there
is
no
limitations
in
regards
to
your
localization.
That's
always
has
to
come
first
and
I'm
a
very
big
accessibility
advocate
in
that
regard.
A
A
A
So
I've
written
a
ton
of
documentation
here
and
I'm
probably
just
going
to
read
it
back.
It
takes
and-
and
it
takes
the
mdx
edge
data
constructs
a
usable
sidenav
object
that
we
will
use
throughout
the
site
code
and
it
creates
sidenav
objects
specifically
for
our
default
language
and
our
current
locale.
This
is
a
very
important
thing
to
notice
about
this
algorithm
it
would.
It
would
be
much
simpler
if
we
could
just
be
like
for
our
current
language
process
everything,
but
there
was
a
design
requirement
raised
during
the
summer
where
we
were
like
okay.
A
Well,
if
this
page
doesn't
exist
in
spanish,
but
it
exists
in
english,
should
we
have?
The
english
page
exist
in
its
place
kind
of
like
a
fallback
page
of
sorts,
and
the
answer
was
yes,
so
we
ensure
we
have
to
take
both
the
english
or
our
default
locale,
and
we
also
have
to
take
whatever
our
current
language
is
and
combine
those
two
into
a
usable
data
package.
A
In
the
case
that,
if
I
was
on
es,
for
example-
and
I
were
to
get
rid
of
dye,
this
page
would
exist
in
english
in
this
side
navbar
and
then
we
also
make
sure
that
we
merge
some
of
the
overlaps.
So
we
take
all
the
pages
for
spanish
and
all
the
pages
for
english,
and
then
we
merge
those
and
get
rid
of
anything
if
we're.
A
If,
if
spanish
is
our
be
our
local,
we
get
rid
of
anything
from
the
english
directory
and
sort
that
out
keep
anything
that
does
exist
from
the
english
directory,
just
to
make
sure
that
we're
doing
that
little
merge
and
making
sure
that
we
still
have
the
fallback
languages
and
pages
part
of
this
solution.
I
actually
borrowed
from
hasura's
gatsby
getbook
starter,
ironically
we're
using
a
git
book
solution
to
kind
of
solve
for
this.
A
They
wrote
a
side,
nav
reducer,
and
let
me
link
this
in
the
chat
for
folks,
but
it's
almost
it's
a
little
bit
of
a
carbon
copy
of
what
they
created
except
I've,
tweaked
it
to
kind
of
meet
our
needs,
especially
given
that
our
data
is
different
and
well.
The
data
input
is
different
and
the
data
output
needs
to
be
different
as
well,
because
this
algorithm
doesn't
just
solve
for
the
side
and
half.
A
So
let's
walk
through
this
a
little
bit
we
are
taking
in
our
edges.
So
that's
the
thing
we're
getting
from
that
graphql
call
it's
just
an
array
of
objects
that
contain
our
blog
posts
or
our
content,
page
posts.
We
have
a
current
top
section
and
that
is
at
least
based
on
the
design
of
our
content
by
ryan
past
summer.
It's
based
on
the
top
sections
of
your
header.
So,
like
things
like
learn,
contribute
funding.
It's
any
directory
that
sits
at
the
top
of
your
en
folder.
A
So
if
contribute
is
a
directory,
faq
directory
funding,
learn
and
resources,
these
are
all
current
top
sections.
It's
only
designed
this
way
to
really
solve
for
the
need
of
each
of
these
top
sections
has
their
own
side
nav,
it's
not
like.
Oh,
we
have
one
entire
content
directory.
We
have
one
side
nav
if
I
were
to
go
to
contribute,
you'll
see
that
this
has
a
completely
different
side,
nav
and
it's.
This
is
a
very
unique
approach.
I
think,
to
our
content
solution
for
the
portal.
A
It's
not
really
something,
I
think,
would
be
used
more
at
large,
but
in
the
case
that
you
have
a
giant
collection
of
data
and
a
giant
collection
of
knowledge
that
you
wanted
to,
then
each
have
their
own
side
nav
with
their
own
breadcrumb
data
as
well.
This
is
how
we
had
to
kind
of
do
it
where
the
contribute
page
goes
to
the
default
layout
right
just
to
run
it
from
the
top.
We
come
to
this
contribute
page.
We
land
on
this
bit
of
code.
Here
it
runs
the
query.
A
A
We
also
make
sure
that
we
are
passing
in
the
top
section
and
the
way
that
we
grab,
that
is
by
taking
the
current
pages
path,
replacing
all
the
garbage
splitting
it
by
its
slashes
and
taking
and
then
slicing
it
by
one,
so
we're
taking
kind
of
the
second
index
of
this
url
like
if
we
were
to
take
this,
we
know
that
we're
going
to
have
a
local
get
rid
of
the
locale.
Take
this
contribute.
A
That
is
your
top
section
and
because
of
our
rule,
of
what
you
see
is
what
you
get
with
the
file
content,
that
structure
and
the
way
that
the
gatsby
plugin
page
creator
works
by
using
the
names
of
the
files
and
the
names
of
the
folder.
We
can
100
ensure
guaranteed
that
the
name
of
the
file
will
always
match
the
name
in
the
slug
and
that's
why
we
pull
out
file
absolute
path.
A
Next,
we
pass
in
our
default
volcano,
which
goes
into
the
localization
and
translation
module,
but
I'll
I'll
cover
that
a
little
bit
later
take
our
current
locale
and
the
pathers,
which
is
just
every
single
part
of
your
string
after
en
gets
chopped
and
put
into
an
array.
So
if
I
was
on,
let's
go
deep.
If
I
was
on
guide
to
hacking,
we
will
take
every
single,
we'll
take
guide
to
hacking,
we'll
take
hackathons
we'll
take
contribute
and
those
are
our
path
directories.
A
All
of
that
gets
passed
into
the
calculate
tree.
Data
algorithm
and
the
first
thing
we
do
is
filter
through
our
edges
to
make
sure
that
we're
getting
only
the
current
top
section.
So
if
I'm
in,
if
I'm
in
contribute,
I
don't
need
the
data
from
learn.
I
don't
need
the
data
from
funding.
I
don't
need
the
data
from
anywhere
else.
A
Just
just
get
me
the
top
section,
so
we
filter
that
all
out,
and
we
also
have
to
make
sure
that
we're
getting
the
the
base
file
too,
because
that's
another
complication
of
our
content
structure,
where,
if
I
were
to
click
on
content,
there
is
a
chance
that
the
directory
for
content
will
have
an
index.mdx
which
acts
as
its
home
page
and
some
of
them
won't.
So
just
another
thing
we
have
to
solve
for
like
another
edge
case
where
it's
like
somebody
may
create
a
folder.
A
Let
me
see
where
my
where's,
my
content
like
if
I
were
to
create
a
new
folder
called
cool
things
to
do,
and
then
I
immediately
created
a
page
called
skateboarding,
mdx
or
yeah
I'll,
just
leave
that
for
now.
But
if
I
were
to
create
this
page,
this
directory
would
exist
in
well.
If
I
were
like
thrown
in
faqs,
this
directory
would
exist
as
a
part
of
the
side
nav,
because
we
have
a
little
title
system
to
ensure
that
we
always
have
a
really
clean
string
for
our
side
nav.
A
A
However,
we
also
have
to
make
sure
that
we
can
code
and
solve
our
algorithms
should
be
able
to
kind
of
solve
for
both
of
these
cases,
so
ensuring
that
we
are
have
the
current
top
section
and
that
the
file
absolute
path
of
that
of
this
page
isn't
well.
Let
me
see
yeah
making
sure
that
it's
it
has
the
current
top
section
and
that
it
has
an
index.nbx.
A
I
take
all
of
that
and
I
flatten
that
map
I'm
using
a
flat
map
here.
What
that
does
is
it
just
takes,
because
these
are
just
all
objects?
We
need
to
be
able
to
kind
of
pull
out
just
the
things
we
need
from
it
and
we,
I
make
sure,
to
simplify
our
object
to
meet
our
needs.
So
the
first
thing
I
do
is
I'm
building
out
the
slug
for
this
page.
So
that
way,
when
you
click
a
link,
it's
just
like
give
me
the
slug
for
this
page.
A
A
A
Then
we
replace
the
mdx
with
nothing.
We
just
drop
the
ndx
in
the
case
that
we're
using
an
index
page
like
index.mdx.
We
just
dropped
this
because
we
know
that
you're
in
the
browser
slash
is
the
index
and
then
we
make
sure
to
get
rid
of
any
other
garbage,
so
any
spaces
or
anything
like
that
and
our
raw
slug
is
going
to
take
that
and
it's
going
to
drop
the
it's
going
to
drop
the
local.
So
in
the
case
of
this
slug,
which
contains
en
slash.
A
Whatever
the
raw
slug
just
drops,
the
drops,
the
en
so
it'll
just
be
faqs,
slash
whatever,
and
the
reason
why
we
do
this
is
because
we
need
to
be
able
to
compare.
There
are
certain
situations
where
we
will
need
to
be
able
to
compare
pages
based
on
their
existence
in
the
local
if
a
page
exists,
and
they
both
share
the
same
name.
A
Our
we
have
a
component
called
a
language
selector
that
can
show
up
on
any
page
and
if
you
click
that
it
will
show
you
a
list
of
all
the
other
locales
that
this
page
exists
for.
This
is
just
another
means
of
solving
for
that.
Finally,
we
have
a
little
something
called
the
title
rule
where
we
will
take
a
page,
and
it's
title,
or
rather
you
know
the
title
that
shows
up
here.
A
The
title
that
shows
up
in
the
side,
nav
title
that
shows
up
in
seo
or
anywhere
else
is
based
on
a
few
rules.
The
first
is
that
if
a
writer
has
determined
the
title
of
a
page
inside
of
front
matters,
so
that
little
up
here
this
this
title
here,
for
example,
is
the
title
of
this.
This
page,
we
take
it
first
that
is
the
title
the
net.
Then
we
spill
down.
We
check
if
the
data
for
this
page
we
get
its
headings.
Does
it
have
any
headings?
It
does.
A
Okay,
get
the
first
heading
and
we
only
check
the
h1.
If
you
remember
our
graphql
query
here,
we
only
get
a
depth
of
h1.
The
first
h1
is
the
next
kind
of
spill
down
for
the
title.
If
that
doesn't
exist,
then
just
just
take
the
slug
part,
which
in
this
case
is
just
the
file
name
of
the
file.
So
if
we
were
looking
at
cool
things,
to
do,
skateboarding
would
be
the
slug
part
here.
A
Then
the
title
of
your
page
and
the
title
on
your
seo
will
be
cool
things
tony
hawk
if
this
skateboarding
doesn't
exist.
So
if
this
front
matters
skateboarding
doesn't
exist,
then
it's
going
to
be
cool
things.
Tony
hawk
now
cool
things
tony
hawk
doesn't
exist.
Then
we
just
take
the
file
name
and
use
that
as
a
title
we
just
constantly
spill
down
until
we
get
to
like
the
final
denominator
of
a
page
existing
and
thankfully,
because
every
single
page
should
have
a
file
name.
A
This
was
a
big
request
during
the
middle
of
the
summer,
where
certain
pages
initially
were
being
categorized
by
alphabetical
order,
but
sometimes
that's
not
always
the
case
that
you
want
based
on
the
design
of
the
content
you're
presenting
you
may
want.
What's
a
good
example
yeah,
you
may
want
something
like
your
learn.
Page
to
first
show
the
name
of
your
company
and
if
it
starts
with
a
z-
and
it's
all
the
way
at
the
bottom
of
your
sidenav,
then
it's
not
exactly
going
to
solve
for
anything.
You
need
to
do.
A
A
Index
here
we
go.
We
see
here
that
it
has
an
order
of
negative
five.
It
is
probably
the
lowest
order,
based
on
its
title.
It'll
show
up
at
the
top
another
important
thing,
and
the
reason
why
this
this
giant
calculate
tree
is
so
giant
is
that
we
also
have
to
be
able
to
solve
for
situations
where
we
have
files
inside
of
directories
and
directories
inside
of
directories
and
with
files
inside
of
directories.
A
We
kind
of
have
to
be
able
to
support
the
flexibility
of
the
file
directory,
regardless
of
whatever
the
structure
of
it
may
be.
So
in
the
case
of
something
complicated
like
dot
like.
If
I
were
to
go
to
this
borrow
die
page,
then
we
see
that
the
slug
is
learn.
Slash
die,
slash,
get
to
hide
how
the
way
the
order
prop
works
is
based
on
the
context
in
which
the
level
it
exists
in
the
side,
nav
is
so
in
the
case
of
this
buy
die,
earned
I
borrowed
I.
A
However,
you
will
never
be
able
to
take
borrow
die
and
put
it
at
the
top
of
the
side
nav
here,
that's
not
something
you
can
do,
because
that
goes
against
our.
What
you
see
is
what
you
get
philosophy.
That
means
that
a
file
that
is
actually
one
two
three
four
levels
deep
in
your
directory
is
at
the
top,
and
now
when
somebody
has
to
go
look
for
that
file,
they
won't
exactly
know
where
to
look.
The
other
is
just
that
from
an
engineering
perspective.
A
It
would
be
way
too
much
work
to
support
that
and
all
of
the
other
stuff
we're
supporting
already
so
you
kind
of
have
to
compromise
and
say:
okay,
you
can
only
contextually
handle
order
based
on
the
location
or
the
depth
that
it
exists
at.
You
can't
take
a
file
from
here
and
throw
it
at
the
top
of
the
side.
Now,
that's
just
not
something
we
will
support,
however,
to
continue
talking
about
this
algorithm
a
little
bit
more.
We
make
all
the
side.
A
Then
we
create
an
array
based
on
our
current
locale,
but
only
if,
like,
if
your
default
locate
is
your
current
lookout
and
we
don't
run
this
twice
like
that-
would
just
be
unnecessary,
just
pass
an
empty
array
and
then
finally,
we
say:
okay,
our
editable
local
files,
which
is
kind
of
just
this
stretched
out,
currently
fails
five.
This
is
probably
extraneous,
but
it
works
for
now
we
take
that
and
we
merge.
A
We
merge
those
files,
we
say:
okay,
if
current
local
files
has
a
length
of
zero
and
in
our
case
that
means
our
default
location
is
our
current
local.
Then
just
our
merge
l5
is
just
default.
We
ain't
got
to
do
a
merge
right,
that's
fine!
If
it
is
emerged
and
we
take
the
default
locales
files,
we
map
through
all
of
them-
and
we
say:
okay,
find
the
localized
file
from
our
current
locale
files.
A
We're
going
to
find
we
look
for
the
file
match
based
on
the
raw
slug,
because
it's
more
consistent
without
having
to
do
like.
Oh,
is
it
this
little
kill
or
this
okay
like
if
you
have
10
little
kills
or
20
locals,
nobody
wants
to
search
through
20
little
tails.
Just
give
me
the
rough
slug
and
if
those
match,
if
those
slugs
match
without
their
locales,
then
we're
good
to
go.
We
found
a
merge.
A
Finally,
outside
of
this
font,
well,
that's
just
defined
oops,
that's
just
defined
outside
of
that.
We
then
say:
okay,
if
we
found
a
localized
file
to
merge,
overlap,
then
return
that
file
return.
The
mer
return
the
file
from
the
locale
that
we
need
right
like
this
is
how
we're
doing
the
merge.
We
say.
Okay,
we
found
the
localized
file
for
our
current
local.
Take
that
and
swap
it
out
with
the
default
locator
just
get
rid
of
it,
and
then
we
concatenate
all
those
files
together,
which
is
great.
A
The
next
part
we
have
is
in
regards
to
breadcrumb
data,
which
you
think
would
be
really
easy,
considering
there's
even
a
plugin
to
solve
for
this
there's
a
gatsby
breadcrumb
plugin,
but
it
wasn't
as
extensible
for
our
needs
that
we
needed
so
instead,
I
just
decided
to
combine
the
concerns
into
one
algorithm
where
we
just
say:
okay,
we
have
a
current
top
section.
Then
we
we
got
breadcrumb
data.
A
Breadcrumbs
we
don't.
We
don't
have
to
worry
about
that
right.
We
don't
have
to
go
to
a
learn
page
like
all
the
top
level
index
files
for
like
contribute
and
funding.
None
of
them
have
breadcrumbs
and
that's
by
design.
So
our
algorithm
does
not
support
it,
but
you
do
have
a
current
top
section
and
you're,
not
the
index
file
of
that
current
top
section
and
boom.
We
have
an
array
here
we
take
this.
We
say
your
part
is
your
current
top
section.
A
Your
title
is
using
the
title
rule
where
we
take
your
current
top
section
return
that
well.
This
is
really
just
like
initializing
the
object
right
we
say.
Oh,
you
have
a
current
top
section.
Then
your
first
index
after
home
will
always
be
the
top
section.
It
will
always
be
learned
like
if
we
go
in
here
we
say:
okay.
The
first
instance
will
always
be
learned.
A
We
don't
have
to
worry
about
that,
and
that
url,
for
this
link
specifically,
will
always
be
the
current
top
section
index
page,
because
we
know
that
has
to
exist
based
on
the
design
of
the
content.
Then
we
have
a
reducer
that
essentially
takes
our
merged
locale
files
and
reduces
them
and
goes
through.
It
says
okay
based
on,
and
this
is
kind
of
where
we
start
to
dive
into
the
territory
of
hasura's
algorithm.
A
A
Same
we
take
that
we
slice
it
by
its
first
and
it's
last
so
negative.
One
for
slice
is
always
going
to
be
the
last
element.
At
the
end
of
the
array.
We
have
our
sliced
parts,
fantastic,
we
loop
through
those
sliced
parts
and
we
say
our
tnp
or
like
temporary,
is
if
we
have
previous
items
from
our
accumulator
we
use,
which
should
be
an
array
right
items
previous
previous
items.
A
A
A
We
don't
know
if
a
writer
or
an
editor
is
going
to
make
a
folder
with
20
folders
and
the
depth
is
infinity
to
be
able
to
support
that
we
essentially
slice
each
part
or
each
file
name.
We
take
that
and
we
say:
okay
is
this
a
header.
Does
it
have
children
it
maker
down
in
this
case?
Has
children,
so
we
say:
okay,
you
got
children,
we're
gonna,
go
through
we're
gonna,
go
through
your
children
and
handle
their
deaths.
A
So
in
this
case
let's
go
to
die
and
get
die,
die
has
children
get
die,
has
children,
so
we
say:
okay,
once
we
reach
get
die
in
the
slug
part
for
our
reducer.
We
say:
okay,
we're
going
to
handle
your
children
and
if
those
children
have
children,
then
we're
going
to
handle
those
children.
It's
kind
of
like
a
mafia
contract
of
sorts
we're
going
through
and
running
through
each
page
and
handling.
It's
we're
handling
its
routing.
A
It
runs
through
it
sorts
everything
by
the
order.
If
the
order
exists,
if
not,
then
we
do
it.
We
do
a
local
compare,
and
this
is
very
important
instead
of
like
an
actual
string.
Compare
because
string
compares
do
it
based
on
latin
characters,
but
in
the
case
that
we
have
arabic
or
russian
for
any
of
our
languages
using
local
compare
is
better
supported
for
whether
a
title
is
closer
to
a
than
z
kind
of
situation,
and
that's
how
order
is
handled,
and
we
return
that
as
sidenav
data
and
breadcrumb
data.
B
A
B
A
A
Thank
you,
chi.
That
means
a
lot.
I'm
really
happy.
It's
working
out,
it's
it's!
It's
a
beast
and
a
lot
of
folks
would
be
like
well.
This
package
does
this
this
package.
Does
that
right
like
oh,
why
don't
you
just
install
imt
nl
for
your
localization
and
stuff
like
that
right,
and
it
was
very
much
like
the
problem
with
the
practice
of
using
packages
like
that
right
like
if
it
solves
your
case.
B
B
On
mobile
navigation
for
documentation
sites
in
particular,
it's
really
useful
to
have
next
and
previous
buttons
at
the
bottom
of
a
page,
because
currently
on
on
mobile,
you
will
need
to
go
back
into
the
hamburger
menu.
Remember
where
you
are
remember
what
depth
it
is
and
it
gets
difficult
to
navigate
on
mobile,
whereas
if
you
have
next
and
previous
buttons
that
navigate
from
one
page
to
the
next,
based
on
the
order
specified
in
the
front
matter
that
makes
mobile
navi
in
particular,
significantly
easier.
A
A
A
So
we
have
sidenav
data,
we
pass
that
into
a
sidenav
component,
because
this
sidenav
data
is
just
an
array
of
objects
with
slugs
and
titles
and
those
get
mapped
through
in
the
order
they're
provided
your
use
case
on
mobile
would
be
that
for
inside
your
default
layout.
Let's
say
you
have.
Let
me
just
make
a
quick
thing
right.
Let's
say
you
have
a
div
and
let's
say
actually
you
know,
let's,
let's
go
inside
the
side
map,
because
I
think
I
actually
do
some
of
that
here.
Node.
A
A
A
Items
index,
that's
one
and
of
course
you
have
to
make
sure
that
you're
supporting
the
edge
cases
of
whether
you're
at
the
beginning
or
end
of
an
array.
But
let's
say
like
my
next:
my
next
sibling
is
this
item.
I
can
pass
that
in
knowing
full
well
what
my
next
sibling
is,
but
the
complication,
I
think
for
your
use
case,
will
come
from
the
depth
of
the
pages.
A
So
in
the
case
where
we
have
something,
like
borrow
die,
if
I
hit
or
even
even
better,
let's
say
I'm
on
baidai
and
I
hit
previous,
I
would
expect
that
to
take
me
to
get
die.
However,
because
it's
a
parent
and
not
a
sibling,
it
may
not
know
about
its
parent,
so
you
you
have
a
little
bit
of
tweaking.
You
need
to
do
to
the
algorithm
to
kind
of
support
that,
like
let's
say
we
wanted
to
do.
A
B
A
And
then,
based
on
this
index,
you
could
you
would
essentially
want
to
check
like
if
you
have
a
sibling,
if,
if
not
get
to
get
the
next
from
the
previous
data
slide,
at
least
that's
what
my
approach
would
be.
My
approach
would
definitely
be
to
like
update
the
sidenav
data
objects
to
support
next
and
previous.
A
So
that
way
you
have
those
pages
as
part
of
your
current
page's
sidenav
data,
and
then,
when
you
click
next,
the
only
thing
you
need
to
see
is
like
oh
get
me
the
slog
give
me
the
slug
from
my
next
sibling
object,
and
then
it
would
take
me
to
that
page,
because
you
can't
really
always
predict
what
page.
That
would
be,
at
least
that's
what
my
initial
off
the
top
of
my
head
approach
would
be
especially
given.
A
When
we
actually
perform
the
sort,
there's
there's
multiple
ways
to
really
skin
this
cat,
but
I
do
think
you
also
propose
a
really
good
question
in
regards
to
how
we're
handling
mobile
navigation,
because
mobile
is
also
its
own
kind
of
side
nav
that
has
unique
design
constraints
yet
so
we
have
a
mobile
nav.
It
also
takes
this
ipad
data.
If
we
were
to
look
at
that
mobile
nav
we're
doing
some
minor
algorithmic
things
to
really
just
handle
the
ui
states,
but
really
just
checking.
A
This
is
like
a
hack
for
blog
data,
but
like
checking
like
oh
do
I
have
items.
What
is
my
current
slug
part,
because
some
of
the
design
constraints
was
like.
Oh,
if
I'm
on
the
learn
page,
then
when
I
open
the
mobile
nav,
I
should
be
here.
I
should
be
on
this
learn.
I
should
see
the
side
nav
open,
as
I
would
see
it
on
desktop,
and
then
I
should
be
able
to
click
this
back
menu,
and
I
should
see
that
learn
is
bold.
A
B
But
spaced
repetition
requires
a
database,
and
I
see
in
the
top
level
structure
that
there
is
a
gatsby
ssr
file,
but
you're,
not
using
that
at
the
moment
correctly,
because
this
is
for
static
sites.
How
much
work
do
you
think
it
would
be
to
implement
a
very,
very
simple
database,
just
literally
for
email
notifications
using
that
ssr
file.
A
It's
complicated
because,
depending
on
the
library
you
choose
will
kind
of
determine
like
there's
kind
of
two
issues
here.
Right
like
the
first
is
that
gatsby
has
kind
of
its
own
enclosed
library
of
plugins.
That
work
really
well
with
its
build
processes
that
touch
the
ssr
files
and
touch
the
node
files
and
kind
of
does
all
these
things
automatically
for
you,
I'm
not
entirely
sure
if
they
have
one
for
web3.
A
I
honestly,
I
don't
really
have
a
hard
answer
on
that
only
because
it
definitely
comes
down
to
the
library
you
choose
to
handle
that
connection,
and
I
guess
my
chara.
My
next
question
for
you
is
like
would
would
you
want
gatsby
to
be
your
database
like?
Do
you
imagine
that
your
content
is
the
database
that
they'll
be
pulling
from,
or
is
the
data
base
going
to
be
somewhere
else.
B
B
It
is
with
flash
cards
that
present
questions
and
answers
and
are
done
in
a
spaced,
repetitive
manner
in
order
to
handle
that
when
requires
a
database
which
people
would
sign
up
to
and
give
their
email
address,
so
that
they
can
be
notified
to
come
back
to
the
site
in
a
week
and
then
in
two
weeks
and
then
in
the
month
and
then
in
two
months
in
order
to
review
the
content.
So
the.
B
A
Like
I,
you
know,
I'm
not
suggesting
any
technologies,
but
you
know
if
you
want
to
use
something
like
mailchimp,
you
can
totally
integrate
mailchimp
on
your
gatsby
project.
They
actually
have
a
get
a
mailchimp
plug-in
specifically,
and
then
you
should
be
able
to
configure
that
in
your
config
file
to
meet
your
needs.
But
really
with
this
being
a
react
project,
I
would
say
sky
is
the
limit.
If
it
works
in
react,
you
can
use
anything.
B
B
I
was
refactoring
this
code
inside
modules,
blog
yeah
modules-
blog.
We
are
not
using
using
any
of
these.
I
don't
know
I
mean
yes,
we're
using
block
result
like
we're
using
the
components,
but
now
the
page
we
are
not
using
the
block
home
for
sure
because
the
block
home
now
I
just
want
to
make
sure
about
that.
B
A
Okay,
thanks
yeah,
the
main
like
home
for
ball
blog
is
the
blog
post
layout,
so
it's
being
used
here
or
it's
being
used
by
it
doesn't
really
matter
about
the
other,
because
we
have
like
two
pools
of
data.
We
have
the
content
that
handles
all
the
other
pages,
and
then
we
have
a
new
blog,
which
has
a
separated
bucket
of
data
here
on
the
outside.
Just
blog
posts
follows
the
same
locale
format,
but
these
pages
are
all
like
equally
living
in
a
vacuum.
A
So
these
absolutely
don't
really
matter
in
the
context
of
those
components.
Unless
there's
things
like,
I
would
say,
like
the
blog
post
layout,
is
using
every
single
component
from
that
module.
So
if
you
want
to
move
that
around,
I,
I've
got
no
problems
with
that.
I
think
the
only
other
place
for
probably
using
the
blog
results
is
in
search
results
because
they
have
blog
search
results
in
that
which
should
be
going
out
by
the
end
of
this
week
for
sure,
but
other
than
that
did
I
answer
your
question.