Project structure in Vue js
prophecy
Posted on August 13, 2020
Salam, I've been working with Vue js for quite some time now, around 2 years+. I've also used nuxt for few projects. While vue itself is a great framework, for me nuxt-js lacks the features and support I needed to call it the framework of choice. After all these projects, I've come up with my tiny ideas, arranged the components as I saw fit.
My current architecture looks like this
Looks nothing fancy, it isn't anything fancy either. But it supports and encourages to use a modular approach. We'll get back to the portion of the module later.
A walkthrough, the assets directory consists of static assets like images, the components directory hold global components, like a notifier maybe(?). Layouts directory is configured for layouting, similar to nuxt's layouting. Middleware, mixin are self-explanatory, nothing fancy.
Then we have pages, these are global pages or a page that is not specific to a module. Like maybe an error page.
pkg is new. We are planning to use module code, but this pkg directory is for scripts. For example, we have few scripts bundled together, acting as our gateway to consume REST API. It has no views or anything else, just plain old Javascript. We are packaging similar stuff in the pkg directory.
Plugins directory is connected with pkg, in a-way. If we have anything that needs to be modified of a default plugin, whether it be from pkg or from node_modules like you might want to setup timezone for moment-js. Or maybe for our REST-API consumer, you might want to define a function of how to find the access token if you are using it.
router and store, both are a common ground for registering all the routes (frontend) and states of modules. api_routes is for registering routes for the API end.
Bootstrap.js is for bootstrapping things, if you come from laravel backend, you can think it as setting up your drivers stuff. conf.js is configuration, again, similar to laravel's config/ directory but in a single file for the time being.
And finally global.js, it is for removal, will be deleted soon. But you can register your global functions.
Among this, plugins are being booted on startup. Makes sense, right?
The meat is the modules!
modules
We have a simple module, user. We think modules as a mini-vue app. With grouped responsibilities. Every store, every route, every page, every component, every API route will be defined in the specific modules directory. You can have anything else if you want to, and you can have close to nothing, like if your module does not talk to API route, it doesn't need to have api_routes.js or whatever you like to call it. If it doesn't have pages, it doesn't need to have a blank page directory.
Bindings
We have 3 bindings to be made,
If your module has client-side routing, it needs to be registered in /routes.js
if your module has API-routing, it needs to follow a pattern, for routing,
and register the UserAPIRoutes.js in /api_routes.js
and if your module has state management, register them for in /store/index.js
After these 3 bindings, I just like to work like
I don't have to deal with the shenanigan of 5 different states, routes and pages.
This is not perfect, but for me, it comforts me, lets me focus and work seamlessly.
The code can be found at https://github.com/thearyanahmed/baseplate
Posted on August 13, 2020
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.
Related
November 29, 2024