Nuxt is a beautiful framework, based on Vue and Vite, for building complex applications quickly. It gives you just enough structure to ensure you don't make too much of a mess, while at the same time it provides you with a lot of easily accessible tools that speed up your development process. I've been building with either Vue or Nuxt since 2018 and if you haven't checked them out, I highly recommend them.

About Composables

Composables are a way to bundle similar sets of functionality into a single file. You export the functions and the refs, and then you can use them throughout your app. This reduces code duplication and ensures that when you make updates to the composable, the core functionality of your app is all updated at once. It's a clean, sensible pattern.

The question then is, "how do I group functionality into composables?"

I think that this is an interesting question that comes down to how you think about development and how you structure your code. For Vewrite, I've been building composables and have generally broken them down by object type. By this I mean that my composables/ folder has a set of files like:

• useAction.ts
• useClient.ts
• useDeliverable.ts
• useState.ts
• useWorkflow.ts
• etc.

These composables reflect the concepts in my app, and this gives me an easy to remember, sensible mental model for when I'm actually doing the work of building out functionality.

For example, if I'm building a new feature that involves a client, I know that I can go to useClient.ts and find all the functions and refs that I need to build out that feature. I'll be able to create a new client, update an existing one, delete it, list all of the clients, find a client by project, etc. It's all in there.

Composables First

One of the things I've been doing lately is building with composables first, before I build any templates or solve front-end issues. From a product perspective, this allows me to start by blocking out big chunks of functionality at the concept level before I have to worry about how it works, or how it looks.

It reminds me a lot of building with Ruby on Rails (or really, any other MVC framework), where you work from the back-end to the front-end. With Rails, you typically define your model first (i.e., how your object is defined, and how it is reflected in the database), then your controller which houses all of your actions. Lastly, you'll define your views which rely on the functionality that you have built up.

When I first started using Nuxt and Vue, since I was actually building a front-end, I started from the front-end and worked backwards towards the back-end when I needed to.

Some of the problems that I encountered with working this way