Refactors state management code #5

antman · 2026-08-07T08:34:04Z

antman commented

2026-08-07 08:34:04 +00:00

Motivation

In the previous pull request, there was a fair amount of obvious boilerplate code that would be repeated. Plus a few variable names and function names that could be improved. The project is at a stage where fixing these are a quick win, which might not be the case in future.

Solution

I changed makeStateProperty from taking an arg list to taking an object. There were too many arguments and it was quite confusing to read without the names.

By splitting everything out into separate files, the state file is quite small now which is good because it's probably going to get quite large and quite repetitive, so we definitely don't want to mix up a lot of imperative code with a lot of declarative code.

I'm fairly confident that there will be a lot of properties that can make use of makeRefresher and makeSetter when creating state properties. The more declaratively these state properties can be defined, the better! These two functions make that much easier, as shown in this PR.

I also renamed the result functions to singular verbs. These functions are going to show up in a lot of places, and adding extra words to the function name will only marginally reduce the cognitive load when someone first encounters them, but significantly increase the cognitive load when someone is familiar with code base. It won't take them long to realise what succeeded and failed mean as past participle verbs. A very fair trade off in my opinion!

Since some managed properties will likely have very complicated setters and refreshers, I think it's reasonable to put them in a separate properties folder with each property in a separate file.

### Motivation In the previous pull request, there was a fair amount of obvious boilerplate code that would be repeated. Plus a few variable names and function names that could be improved. The project is at a stage where fixing these are a quick win, which might not be the case in future. ### Solution I changed makeStateProperty from taking an arg list to taking an object. There were too many arguments and it was quite confusing to read without the names. By splitting everything out into separate files, the state file is quite small now which is good because it's probably going to get quite large and quite repetitive, so we definitely don't want to mix up a lot of imperative code with a lot of declarative code. I'm fairly confident that there will be _a lot_ of properties that can make use of `makeRefresher` and `makeSetter` when creating state properties. The more declaratively these state properties can be defined, the better! These two functions make that much easier, as shown in this PR. I also renamed the result functions to singular verbs. These functions are going to show up in a lot of places, and adding extra words to the function name will only marginally reduce the cognitive load when someone first encounters them, but significantly increase the cognitive load when someone is familiar with code base. It won't take them long to realise what `succeeded` and `failed` mean as past participle verbs. A very fair trade off in my opinion! Since some managed properties will likely have very complicated setters and refreshers, I think it's reasonable to put them in a separate `properties` folder with each property in a separate file.

antman added 2 commits

2026-08-07 08:34:04 +00:00

refactor

/ test-and-lint (push) Successful in 50s

Details

839754354d

add doc strings

/ test-and-lint (push) Successful in 52s

Details

7781d81131

antman reviewed

2026-08-07 08:37:20 +00:00

src/logic/state/state.ts

					
				@ -0,0 +5,4 @@

				const state = {

				  hostname,

				} as const satisfies {

				  [key in keyof ServerConfig]: StateProperty<unknown, unknown>;

This ensures that ServerConfig and state do not fall out of sync in terms of their properties. This is the coupling/cohesion point between the translation layer and the logic layer.

This ensures that `ServerConfig` and `state` do not fall out of sync in terms of their properties. This is the coupling/cohesion point between the translation layer and the logic layer.

antman added 1 commit

2026-08-07 08:39:26 +00:00

update version number

/ test-and-lint (push) Successful in 52s

Details

09eb61d498

antman scheduled this pull request to auto merge when all checks succeed

2026-08-07 08:40:17 +00:00

antman merged commit c8ca112def into main

2026-08-07 08:40:18 +00:00

antman deleted branch cleanup

2026-08-07 08:40:19 +00:00