Since most of my previous works have been either too simple or too customized (for personal use), I’m starting this project with a wider audience in mind. The goal is to create an interactive to-do list app. Users will be able to see “tasks”, set times, and add, edit, and delete tasks and so on. You know the type.
This is still simplistic and driven by personal needs. And it’s too common an idea. But it’s better to start with something easy than losing motivation halfway, before anything significant is done.
Technologies
I’m calling this app “Mantle”. It’ll be built with Laravel and Vue.
The complete list, as of now, is this:
-
Laravel (for the back-end API)
-
Vue.js (for data binding and manipulation on the front-end)
-
laravel-websockets (for sending real-time updates to the front-end)
-
Laravel Echo (for receiving the real-time data)
-
Bulma (CSS framework)
Laravel is there only for the API. I’ll probably never use more than a handful of routes. I’ll be using whatever comes by default with Laravel 8. Don’t think I’ll need the famous Debugbar even. The database will be MySQL.
I’ll be using Vue 2. The “vue-loader” package will be needed because of Single-File Components. But no “vue-router” or “vuex”. For now, Mantle will be done with just plain, old data binding.
“laravel-websockets” will be replacing Pusher. (It’s always seemed a little ridiculous to me to send data somewhere else to get it to the user. It’s like if you want to go from A to B, you need to go from A to C first and then from C to B. But things often seem obvious only in retrospect.)
I’m new to using WebSockets. For those who don’t know what it does: It’s used to keep a permanent connection with the server open, as opposed to HTTP requests that can only be sent from the client. This is great, because until the client (a browser, for example) has sent a request to the server, it won’t know even if the server’s been blown up. So, in case of real-time update, for example, you’d have to send requests to the server either continuously or at a specific interval. Both of these have their own problems. But in a WebSockets connection, the server can send data to the client on its own! The two most common uses of WebSockets probably are chatting apps and notifications.
And while a WebSockets server can send data to the client, the client needs to receive it. Echo is a JS library that does just that. Echo listens to messages from the WebSockets server and receives the broadcast data.
I’m using Bulma just because I’ve never used it before and I don’t trust myself with Tailwind yet.
Features
Mantle’s features will be simple. A user will be able to:
-
see a list of “tasks”, along with their due times,
-
edit task names,
-
edit and remove due times,
-
add and remove tasks,
-
mark tasks as “done” or “not done”.
Currently, for the UI, I’m thinking card-like containers showing tasks. There will be a hierarchy where tasks will be assinged to something from a higher tier, and they’ll be assigned to another upper tier in turn. Kind of like: board -> card -> task.
Mantle’s UI will resemble Slack (or other similar apps) a lot. In fact, I’ll try not to make it an outright Slack clone. There will be similarities in features, but my personal preferences will have influence too.
The due time feature is a good example of this. For some time now, I’ve been using a makeshift “task list”, using only JS for some of my daily errands. It was made just for that reason: to list the things I’m going to do over a day, and to set timers accordingly. So, I’d create a task and set a time, which would start ticking and show a timer in “hh-mm” format.
That was the seed of Mantle, I think.
Anyway, more features will be added slowly. Mantle will always look like a Slack clone, and it will always have features I personally like. My aim here is to practice building something for common use, with emphasis on “practice”.
Note
These posts won’t be regular. I’m writing these mainly to record my thought process during the development. I started Mantle without much planning and I intend to improvise all the way. Since writing things down often requires organizing your thoughts, these will help me look at the things I’ve done and maybe think ahead a bit too.
The ulterior motive is to look back, some years later, at how I built things and what I thought while building them.
Disclaimer: I won’t explain all the steps of building Mantle. So, don’t expect too much code and technical explanations. (There’s loads like that (and better) out there.) In fact, most code snippets I include are likely to be incomplete. And even the writing might not be all that coherent. (You’ll often think I forgot to write something in the middle.)
But Mantle will be open-source, and all the code will be available on GitHub . So, feel free to check it out there.
Suggestions are always welcome.