Devlog 5
You're viewing a Gemini article on the web
It's much better to view it on Gemini!
Today it's an early devlog. I've been awake for a few hours now applying for jobs and I realized that I've been massively overcomplicating a core feature of this app.
Today's work
This morning I've mostly been thinking about data structures to get away from writing handler code. I've also done a little bit of research into unit testing and creating mocked information for my handlers so I can check my logic. Having discussed this with my friend previously, I suspect that writing too many unit tests isn't going to be that helpful and that end-to-end testing is going to be more important, but it never hurts to read!
The realization I've come to relates to columns. I've been thinking about these data structures somewhat spatially, conceptualizing items in lists and boards. As part of this I've structured the database around boards, lists, items, and list <-> item pairings. The idea is that an item represents a film, and it can be included in multiple lists/have multiple reviews. Each board, then, represents a kanban board containing a list of films. Where my thinking was a bit diseased was in how the columns would function. I had initially conceived the mechanism of items being picked up and moved between lists, but this is entirely the wrong way to think about it. Instead, a column should represent only a "status" with a user-assigned label. When the user picks up the film and moves it to a new column, they're simply changing the status and having the frontend reflect this.
This may seem obvious, but it's a fundamental mistake in my thinking that's already led to me spending too much time writing complex SQL queries. Understanding this mechanism better is going to make things a lot easier. Fortunately, the SQL work isn't a total waste. The linked list logic is still correct for moving items inside a list.
The thing I need to consider now is relative positioning. After all, an item has an absolute position in a list. We can consider this its "list position". This is the initial order it appears in within the default column/list view. However, there needs to be a "meta position" that determines the item's position within a specific status. If two items have the same status e.g. "Watching this week", the user needs to be able to rearrange the items within the "Watching this week" column. This requires there to be a meta_position column in the database to store the information. I think this can be achieved by checking for other items with the same status/list_id and using the same linked list movement logic.
What's next
I'm going to finish adding the status/item handlers first, then think more about this meta-positioning logic. If I'm right, it shouldn't be that difficult to implement. Once I've got that working, it's on to frontend dev to try and create some sort of minimal interface for the kanban/list logic.
I've also been looking into data sources for adding film items. I don't really have a great range of options. I wanted to use Wikidata originally but it doesn't look like I can query their API for "film" items in particular. Most likely, I'm going to need to use the TMDb API and require that hosts provide an API key. As far as I can see, the keys are free so it shouldn't be that big a blocker. If anyone knows a better open dataset or a way to query Wikidata (not with SPARQL, it's too slow), send an email to the mailing list.
Tell me what you think.