Refactor to speedup resource implementation #13

Merged

antman merged 4 commits from try-with-children into resource-refactor

2026-08-17 08:38:39 +00:00

antman commented

2026-08-17 08:21:51 +00:00

Owner

Motivation

There are 12 resource implementations to write and maintain, that we know of so far. We want to minimize code duplicated amongst them as this will incur obvious maintenance burden, and it was already getting difficult to keep things consistent with just 2 implementations. The boilerplate code was getting quiet tedious when writing resource implementations, and it's likely that there will be more resource types to implement.

Solution

I tried creating a higher order function that would take in another function that would be the resource creation function which the HOF would enhance. This turned out to be an inversion of what was required. Instead, the resource instance creation function (e.g. defineFileResource) calls a getImplementers function which takes a handful of arguments and returns a set of common properties and higher order functions that must wrap the CRUDD methods of a resource.

The downside of this approach is that anyone implementing a resource gets a little less guidance from the type system, but the upside is we don't have bidirectional data that they must flow between the higher order function and the concrete implementation, which gets very messy and confusing in a way outweighs the benefit of slightly better type hinting.

### Motivation There are 12 resource implementations to write and maintain, that we know of so far. We want to minimize code duplicated amongst them as this will incur obvious maintenance burden, and it was already getting difficult to keep things consistent with just 2 implementations. The boilerplate code was getting quiet tedious when writing resource implementations, and it's likely that there will be more resource types to implement. ### Solution I tried creating a higher order function that would take in another function that would be the resource creation function which the HOF would enhance. This turned out to be an inversion of what was required. Instead, the resource instance creation function (e.g. `defineFileResource`) calls a `getImplementers` function which takes a handful of arguments and returns a set of common properties and higher order functions that must wrap the CRUDD methods of a resource. The downside of this approach is that anyone implementing a resource gets a little less guidance from the type system, but the upside is we don't have bidirectional data that they must flow between the higher order function and the concrete implementation, which gets very messy and confusing in a way outweighs the benefit of slightly better type hinting.

antman added 2 commits

2026-08-17 08:21:51 +00:00