Reckoner Update May 2025
I wasted so much time this month chasing dead ends. May this be a cautionary tale in the allure of sweeping refactors.
🚢 Attempted Refactor
I tried to do several different refactors this month. They all failed, but I had a few learnings and a good dose of failure due to a repeated pattern of mine.
🚣 Drift
I tried to enable a Drift change to have drift generate the custom data class to SQL mapping using the write_to_columns_mixins. However, I uncovered very late into the month that there is an issue with the mapper it generates. Namely, that nullable fields are indistinguishable from unchanged (absent) data. I created an issue for this, but it means that I did waste some time on a dead end.
🥶 Immutable Data
I have been hearing for some time that freezed is the way to handle client data. Looking at it, it makes the route code of serialization and equality checks easy to implement. If you take a look at my code, I devote a good portion of it t handling equality, serialization, and copying of data.
I tried actually using freezed, but found that it wouldn’t work with the way I’ve structured my data. In particular, I make heavy use of inheritance which freezed doesn’t support. Thus I found the package data_mappable which supports inheritance. I made several changed to make the data immutable and support editing of immutable data classes.
Ultimately, I ended up abandoning this change due to the issues discussed in the next section.
🚝 Large Monolithic Refactor
The other piece that made this take the whole month is that I didn’t discover the drift issue until late in the month when I monolithically applied the immutable data changes to both the data classes and the editing widgets. This was a fairly extensive change which had me refactor several of the edit widgets along with the data classes.
I really did like how concise the change made my data classes. Unfortunately, there were several regressions in the editing functionality. Then I discovered the drift generator issue. Seeing the number of regressions I was experiencing with the code, I opted to abandon this work and instead try to incorporate the widget refactors.
📤 Current Work
I am working on a minor refactor based on some poor design earlier in how the UI is constructed. For convenience, I was using functions to generate Widgets to structure the code in a DRY (Do Not Repeat) fashion. However, this can actually cause performance issues in Flutter as I was reminded here. I am working on a smaller refactor to eliminate the use of functions which generate Widgets and should have that
🧑🏫 Lessons
While structures like Freezed help to create durable and simple UIs, it does not appear worth the effort to retrofit it into an existing codebase. I had already incorporated several changes in the codebase to make sure editing widgets made copies of the data class under edit from the DataCache. I should continue to follow the pattern I’ve developed and just incorporate the widget refactor.
Finally, I should focus on getting new enhancements out for Reckoner. I still have the synchronization change I need to implement. Then I need to figure out and create a cloud service for device synchronization.