This week I effectively continued where I left off in week 18, meaning I worked on the API. But this time, my focus was on API use for the new UI again rather than use by external consumers.
In particular, the API was still missing a few authentication and authorization features that are in place for regular pages, like loading permissions that are “game world local” or allowing an admin to impersonate an account (which is often required to troubleshoot issues). When the API is used to fetch data for UI components across all pages, these things obviously need to be in place. For once, this was a rather satisfying development experience because the effort that went into “Spring Cleanings” in the past is really starting to pay dividends now. Re-using the same logic across different parts of the application was relatively painless and with every change, I was able to get rid of a few more pieces of legacy code. So…yes…very satisfying if your brain’s wired like mine ![]()
With this out of the way, I turned my attention to the actual UI again. Obviously, this was a lot less satisfying (regular readers will be aware of my aversion to anything frontend- or design-related), but it was productive nonetheless. With the footer already converted to gen-3, the logical next step is converting the header. That’s also the reason for the API-work I described above…it wouldn’t make a lot of sense to show my own company’s cash balance in the header - a value that will be delivered through the API - while I was impersonating another user. But as it’s often (almost always?) the case, there’s always “one more thing to take care of”.
This time, I had to make a call concerning how I want to manage the transition from the current UI to what I am aiming for with the new UI. The current UI allows picking one of three themes - dark, light and classic. This is a fairly static setting: If the user picks a different theme, the setting is stored in their local account and only once a new page is opened, the change becomes effective. Going forward, there will two main changes:
- The “classic” theme will eventually be removed and only a light and a dark mode will remain.
- Dark and light mode will behave in the way people expect these days, meaning the mode will be selected automatically based on the preference communicated by the operating system/browser, while giving users the option to override this manually if they prefer one or the other.
Especially the latter bit is a lot more dynamic than what we have right now. To that end, I made some technical preparations to allow “more dynamic theme switches” that happen primarily on the client-side. While at it, I got rid of a few legacy UI options that make no more sense nowadays and/or would hinder the migration to the new UI. These changes are already live in Paine.