“The Little Hidden Secret to Amazing Nuxt

3 Apps!”
Hey, thank you for downloading this secret! I’m so glad you decided to. What I’m
about to show you is a secret that so many software engineers don’t know. I work
for a software development company, and I recently revealed this little secret to
the team that I work with.
This secret is the best way to build your Nuxt 3 apps and any app for that matter.

I built our church app, which you can see at https://coy.vercel.app . That’s where I
do my testing of our app.
That app is built with Nuxt 3. When I started working on this app, I was writing my
code like most developers do. But when I discovered this secret, I immediately
stopped and redid all the work I had done, just so I could utilize this secret.
Look I’m telling you the truth!
If you use this secret to build your Nuxt 3 app, your app will be:
 Well-structured – a well-structured app is easy to read and follow. It’s also
easy for other developers who will work with you to read and follow. A
well-structured app can be understood in 10 seconds or less of just staring
at the code.
 Easier to debug – look this is big! Bugs almost always occur in software no
matter how good a developer you are or how experienced you are. Bugs
happen! If you follow this secret, your app will be easier to debug. One of
most frustrating things I have come across as a developer is code that is
hard to debug! Ah, I hate it!
 Easier to change - software changes. New updates may be required. You
might want something to look a different way and that means the software
must change. If you use this secret, changing your software becomes so
much easier. Another frustrating thing I’ve run into as a developer is code
that is hard to change! Ah, so frustrating!
 Less coupled – this is probably my favorite benefit of this secret. Your code
will be less coupled. That means that your code won’t be so dependent on
other code such that it can’t easily be moved around.
Oh, I just love this secret and I totally want you to know it and use it!
So, what’s the secret?
Drum roll….
The secret is:
Chances are you’ve never heard of this, but I’m going to break it down for you.
Component-driven methodology pretty much says that you componentize your
app from the smallest (most basic) all the way up to the most complex (pages).
When you do this, each component is well-tested and well-written therefore
leading to a well-tested and well-written app.
The components in your app will be broken down into three categories.
Pages Complex Basic
This is your highest-level This is a component with This is your smallest
component. This is the other components in it. component. For
level that we get to talk Most of your example: button, avatar,
to the API at and send components will fit this input
data to all other category. For example: a
components. form, navigation bar, a
list

So, when you build your app, you start from the right and make your way to the
left.
Does this sound too complex? Please let me know.
Here’s a web site that explains this quite well:
https://www.componentdriven.org/
Here’s a graphic from https://whatjackhasmade.co.uk/component-driven-
development/ that should help explain things better:
Do you see how atoms would be the basic components, molecules to templates
would be complex components, and then pages would be the highest-level
components?
They are going from left to right in this graphic, and I was going from right to left. I
also combined the molecules through templates and called them all complex
components.
Look, I understand that you may not understand this completely yet, but if you
follow me, as Yahweh (God) wills, then I’ll help you build well-structured,
component-driven apps.
I’m telling you if you get this right, your app will look much better and be easier
for you to work with.

Coding vs Engineering
Look, anyone can code. It doesn’t take that much to learn how to write JavaScript.
It doesn’t take that much to learn how to write code that works in a framework
like Vue.JS or Nuxt.
Just about anyone can learn to write JavaScript syntax.
But engineering is different! Engineering requires that you think about your code,
that you plan for how your code will look 5 or even 10 years from now. Yes, you
may have to rewrite your app or even change the language, but if you engineer
your code right, trust me, you’ll be glad you did when it comes time to rewrite it
or change it!
Engineering works to make sure your app is stable, it’s easy to read, it easy to
debug, easy to restructure, and even easy to rewrite – even if you’ll be writing it
in a different programming language.
My goal here is to help you not just build Nuxt 3 apps but build amazing Nuxt 3
apps. Building anything amazing takes more time and thought than just quickly
putting something together. You can’t just be sloppy with your code.
You want to build something you’re proud of and component-driven
methodology/development helps you get there.
It may take time, but the end is well worth it! Trust me you’ll be thankful for it!
Does this make sense, or is it too complex? Please let me know.
So, let’s break down component-driven methodology.

Breaking Down Component-Driven Methodology

Here’s a breakdown of component-driven methodology.
1. Build one component at a time
Traditional web development and web application development built and
continues to build web sites and apps page by page. This is how it’s been
done for decades.
Page by page means that as long as what you put on the page looks fine
and works fine, then all is good.
This is how web apps are built in traditional web app building software like
Wordpress. Most developers also build their apps by going page by page.
But I’m telling you, if you build your Nuxt app that way, you’ll be sorry
when it gets complex! If you plan on building any worthwhile Nuxt app, it’s
going to get complex.
 A complex app that is unstructured is terrible to work in. It’s hard to read
and understand the code, hard to fix, hard to add components to, and hard
on other developers who may have to work on it.
But if you build your Nuxt app, or any other web app, using component-
driven methodology, you will save yourself headaches in the future.
So, instead of building your app, page-by-page, build it component-by-
component. So, a button could be a component, a tooltip, or an avatar too,
for example.
This doesn’t mean every single HTML element should be a component, no,
that would be insane. What I’m saying is that any Nuxt code with HTML
that can be logically isolated (makes sense by itself) should be a
component.
When you build your component, you make sure it is well-written and
stable (doesn’t cause other code to break). This is the beginning of
component-driven methodology.
2. Combine components to make complex components

The next step is to combine your components to make complex

components. This is actually not that hard. It’s self-explanatory.

Combine the basic components into complex components. Now you don’t
just do this any kind of way. You need to combine them in a way that
makes logical sense.

That means if you have basic components called <NavigationButtons>, then

a logical complex component would be <NavigationMenu> or
<NavigationBar>. That means the <NavigationButtons> are part of
<NavigationMenu>

This also brings another point I like to call semantic componentization or

naming your components in a meaningful way (Ha! That’s easier, less big
words!)
Semantic componentization means that the names of your components
should accurately describe what they do in the fewest words possible.

<NavigationButtons> is more semantic than <Buttons>. The name

“Navigation Buttons” tells me exactly what that component is about. It
holds navigation buttons, not just any buttons.

<Buttons> is not semantic. Now if your app is really small and there are no
other components that have buttons, then that may be fine. But apps tend
to grow and so giving a component a more semantic name like
<SideBarButtons> or <FormButton> is almost always better.

A good way to know if your components are semantic enough is to ask a

non-developer to read your code and try to tell you what your code does in
10 seconds or less!
For example, this is code you’ve probably never seen before. But I bet you
can tell me what this code is about right?
What do you think these components are about? These components are in
Nuxt 3.

I asked my wife, who is a non-developer, to tell me what she thinks these

components are about in less than 10 seconds. And guess what? She got it
right, they are about sermons, displaying sermons or searching about
sermons.

The reason why I ask that you test this on a non-developer is because if a
non-developer can get it right in 10 seconds or less, then a developer
should be able to as well, in probably less time, and that means it would be
easier for the developer to understand the code.

That developer may be you! If you write your code well, and you come back
6 months later to work on it, you’ll be able to understand it. But if your
 code is not componentized and semantic, it could be a headache reading
your own code!

3. Combine complex components to make a page / highest-level component

The next step is to combine these complex components into pages. Pages
are the highest-level components, and this is where incoming data gets.

You see, Nuxt.JS, https://nuxtjs.org/, is based on Vue.JS, https://vuejs.org/,

and the preferred way of passing data in your Vue components is props
down (parent components pass data to children) and events up (child
components pass data up to parents.)

I’m assuming you now about Vue.JS and props here. If not, I believe you can
still understand the point I’m trying to make.

If your app is connected to an API and received data from it, the page
component is the component that the data should enter your app through.
Then after that, the data should flow down from the page to the complex
components and then down to the basic components.

Doing it this way makes for a well-structured app and you’ll know where all
your API calls are being done.

One of the things that can complicate an app is having any component call
an API directly. In that case, your app would be structured like this:
Those little colored circles are your components. That’s a mess! But if you
followed the way I’m talking about instead, your app could look like this:
 In the picture above, the page components are the highest-level
components. They are represented by the black ovals (long circles). They
call the API and data comes back to the pages, and then it is sent whatever
components need it.

This also makes sense because if you’ve been following component-driven

methodology, any data that flows from an API call to a page, and then to
the pages’ complex components, and down to the basic components will be
related data.

So, for example, if you have a user page, the page would grab all the users
from an API, then the components that are expected to be on that page
should only be components that have to do with users, and nothing else.
This is called cohesion. Cohesion is good!

This make sure your app is semantic and less coupled.

If you follow my tutorials, I desire to build all my apps this way and I
recommend you do too.

4. Combine your pages to make your project

This is the final step. Your pages now make up your project. Page doesn’t have
to be a Nuxt page, just any highest-level component.
When you get to this level, you’ll have a well-structured, semantic, easy-to-
understand, easy-to-debug app. In other words, you’ll have an amazing app!
I hope you got something from this.

Conclusion
Component-driven methodology builds apps one component at a time. We start
with the most basic components that do not have any other Nuxt components in
them.
Then we combine the basic components to create complex components, which
are components that have other components. Then we combine those complex
components to create pages or highest-level components. These are the
components responsible for communicating with an API, and they pass data down
to other components.
The benefits of using component-driven methodology to build your app includes:
 Creating a well-structured app
 Creating an app that is easier to debug
 Creating an app that is easier to change
 Creating an app that is less coupled
 Creating an app that is cohesive
We also talked about semantic componentization, which means naming your
components in such a way that accurately described what they do, or what they
are about, in the fewest possible words.
An app following semantic componentization will be easy to read and understand.
Hey, that’s it! I hope this wasn’t too complex! Make sure to follow the tutorials on
my YouTube channel where you’ll see component-driven methodology in action.
My goal is to help you build amazing Nuxt apps! Check it out now!