Since my last post, I kept working on this new project, and made quite a good progress.
So let’s welcome Treesque ! Go take a look, and give it a try. And if you like it, let me know on Twitter or by email. It is very basic at this point, missing a lot of functionalities, but it is a start, and I am happy to just have something out.
It took a long time to get where it is today, because I had a lot to learn on the way, and I made some bad decisions along the way.
Lessons learned 🔗
The first big mistake that I did was to absolutely want to use GraphQL for the API of this application while I had an already working RESTy API. Going from a RESTy API to a GraphQL API may help in the future, but it really was not necessary at this point. I did it because I wanted to have a schema in my API, and now I do. But it came at the price of flexibility, limitations imposed by the GraphQL specification (No recursion and no maps) and difficulty of implementation.
Rewriting most of the already working code, backend and frontend, was the greatest price timewise. And since no recursivity was possible in the response, I had to rethink completely the way data are parsed back in the front-end. But while it take me a long time, it was a very rich learning experience.
The most important thing I learned is that it is probably always a good idea to serve your data flat. So instead of returning
[
{
"id": 1,
"children": [
{
"id": 2,
"children": [
{
"id": 3,
"children": [...]
}
]
}
]
}
]
it is better to return
[
{
"id": 1,
"children": [2]
},
{
"id": 2,
"children": [3]
},
{
"id": 3,
"children": [...]
}
]
The second way makes it much easier to work with single elements in the list, and probably provides more advantages than just this. If you know the pros and cons of each of these approaches, I’d be delighted to read about it.
Managing state in VueJS was also hard. I had something working quite well with pure VueJS, but found myself limited for developing further. The main limitation was that since I have quite a lot of recursive data, I had to pass it up and down the components, which was a mess. Migrating to Vuex helped solve the problem, until I tried to use it for everything, and it became too much of a hassle. Keeping only the data and backend calls in Vuex and having the state of the page elements managed with Vanilla VueJS helped solve this problem. This allowed me to keep the simple things straightforward, and keep the complexity of the recursivity as low as possible. Now, my stack looks like this:
Vuejs <-> Vuex <-> GraphQL <-> Backend
I find myself quite satisfied with this stack, and I’ll continue developing it this way.
Before tackling this project, I did not really understand why a lot of people think that recursivity is hard. I stand corrected, since I ran into so many troubles working with it. I learned a lot during those first months, and I probably had to make the mistakes that I made so that I could improve.
New ideas 🔗
Tag everything ! 🔗
I am a SRE by day (and entrepreneur by night), and my job entails working with Kubernetes daily. One of the core concepts of Kubernetes is to use tags to filter, schedule, and flag for action for about everything.
My first idea with Treesque was to create a todo tree. I know, quite boring right ? As would say DHH, “It’s an other fucking todo list”.
So following the Kubernetes way, why not use tags to do all the things a todolist can do, like:
Write a blog post #status:in-progress
|- Find a topic #status:done
|- Find a title #status:in-progress
| |- Get 3 ideas #status:done
| |- Choose 1 idea #status:todo
|- Write post #status:todo
With the proper functionality, every tag can be displayed differently, or not at all, to hide or strikethrough those tasks that are done.
And why not do more with those tags ? Like decomposing an idea for learning, or a project into smaller parts, with research items and action items, as described in other terms in Shape Up.
With some tree filtering, you can also tags according to categories then filter on those categories, hiding the tasks that are not part of it. You end up with a lighter view of the tree, of a specific part of a project you’re working on.
That’s the first idea that I want to develop, because it can make it so flexible that I can really use it, as I explained in my previous post, as a working space, in which I can easily filter in and out what I want.
Feedback popup 🔗
This is not really my idea (I think I saw it from Ryan Hoover, but I’m probably wrong). The idea is to have an always visible button that allows to send feedback quickly directly from within the interface.
This is good because the only way I’ll know if people like what I did is by having them try it out, and see what they like, what they don’t like and what they feel is missing.
Let’s get moving ! 🔗
I just released the very first, ugly, probably buggy version, and I’ll be using it for myself. Just to tell you how pre-pre-pre-alpha it is, there is no user management yet, but more important, no way to recover your workspaces if you clear your cache.
And while I have a lot of ideas to improve it (and that I need a much better design), I will start with the much less sexy part of user management, to have an application you can access from anywhere, consistently.
By using it, I’ll see what I can improve, and it will become better with time.