Closed apaleslimghost closed 5 years ago
the approach i'm going to go with is: handlers for things like PRs will specify that they operate on a single item in an array (something like input = 'repos[].branch' ; output = 'repos[].pr'
. then i'll add checking for an existing PR for that branch (see #65) and similar for each operation.
input | output | what goes on with handler |
---|---|---|
scalar | scalar | same as current |
scalar | array | adds return value to each item in array |
array | scalar | parallel, return values saved as array to output |
array | array | parallel, each return value saved to item in output |
with input/output types, the check needs to become "is this input type a subset of the union of all the previous types"
this approach is far too complex 🙃 instead, i'm going to decouple the input/output types from the actual state data, and make them abstract. this way, handlers get passed the entire state and can do whatever they want to it.
currently, if you undo creating 20 PRs, add a filter so there are now 15 repos, and redo the PRs, you get 20 closed PRs and 15 new PRs. ideal would be 5 closed and 15 reopened/force-pushed. this isn't possible with the current data architecture, where we don't keep track of undone steps and there's no link between say a repo object, its branch, and its PR.
i don't know how to do this. here are some thoughts:
repos
array. ie makerepos
sort of a first-class concept. this addresses linking between repos/branches/PRs and facilitates not creating PRs for branches with no changes but doesn't handle reopening PRs because there's no way to keep track of PRs when you undo that step48 would make undo/redo/replay self-healing
data
in the state file if you're doing #48halp