Self-management

Hey all, hope you’ve been doing well!  

Before jumping into today’s topic, I wanted to announce that I’m close to rolling out the changes to the story list. I froze development of new features and the general scope about a week or two ago. This means that the rest of my dev time involves polishing up things, making sure there’s no breakage and optimizations. It may not sound like much, but the devil’s in the details and it’s still a fair amount of work! I don’t have a hard date for release but I’m aiming for the first or second week of September.  

With that out of the way, I’ll be talking about another part of the overhaul: managing story entries. If you’ve been paying attention to Discord, you may have noticed some time ago that I publicly shared a page that allows writers to enter their tripcode and add tags and synopses to their stories. The idea is to give the writers of THP more an active part in describing their stories and offloading some of the work that others would have to do in order to keep the story list up to date.  

This page uses some of the code and concepts from the rest of the story list overhaul to work: stories are fetched from a database after matching the tripcode, tag suggestions are offered on typing like on the story list itself, and any submissions go through a similar verification process to a search—making sure the submitted data is valid.  

Now, that said, there are a few design decisions that are unique to this page. First and foremost are the inputs themselves which are not traditionally submitted forms but instead asynchronously updated.  

Here’s a brief explanation: a form on a webpage usually submits data in its children inputs and the page is reloaded/user is redirected as data is processed server-side. The asynchronous solution, using javascript, means that the data is sent without reloading the page and instead the script awaits for a response from the server to tell the user whether or not the submission was successful. While the former is far simpler and standardized, it does have the disadvantage of requiring every entry being its own form and possibly complicating data processing when the users have input data in more than one story entry. Since I was already requiring javascript because of tags I figured it would be nice if users didn’t have to move away from the page when submitting as well.

Taking a step back, the way users are verified in the first place relies on initializing sessions. When a tripcode is valid, it creates a token that’s used to check against any other transactions. So, for example, when a user submits new info for a story, if the session data doesn’t match the tripcode for the story being modified, an error is produced and nothing is changed. Yes, tripcodes aren’t that secure to begin with, but this at least mitigates people doing funny business with the data they’re sending to the server.  

So with this additional sanity check, I felt comfortable enough to take things a step farther: not only can users modify existing stories but they will able to set new threads they’ve created as either new stories or part of existing stories. There’s a time delay before threads show up and can be added but for the most part it relies on users being reasonable enough to manage things for themselves. Ideally, I’d want to tie the fundamentally insecure tripcodes to user accounts but, for the time being, this will do.  

I don’t think it’s particularly interesting to describe the nut and bolts behind the submission process as it’s similar to the process I’ve described in other recent posts. It suffices to say that updating story tags or submitting a new thread/story makes the data go through various checks and sanitizing before it can be successfully inserted into the database. I’m fairly confident that there are no major oversights and the aforementioned testing by THP people helped catch a few corner cases in the code.  

Likewise, the appearance of the page itself also uses a lot of shiny new stuff under the hood to provide a comfortable experience on both phones and larger displays. For now, I’m limiting things to a pair of color schemes (light and dark) but, if I can figure out a sensible way of implementing user colors, that might be implemented down the line.  

That about covers it and the next time I have another technical post, I’ll hopefully have the story list changes live. I’ll also probably either talk about what’s next for the story list or some of the other work I’ve been doing in parallel in my spare time. Until then, take it easy!