{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":235446990,"defaultBranch":"master","name":"redis-pipeline-segment","ownerLogin":"ethanresnick","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2020-01-21T21:39:53.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/471894?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1673107046.2776241","currentOid":""},"activityList":{"items":[{"before":"10499ed42ea688c45b8abc1f3eb892e9397fc286","after":"37e181fea62345d8280298758cfcd59af6a666df","ref":"refs/heads/master","pushedAt":"2023-09-11T20:32:33.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ethanresnick","name":"Ethan Resnick","path":"/ethanresnick","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/471894?s=80&v=4"},"commit":{"message":"refactor: total overhaul of types/implementation\n\n1. Before this, the type system tracked a type `A` for each Segment and\n   assumed that the result of the Segment (i.e., after getting the\n   command results from Redis and running them through `apply`) was an\n   `A[]`. If you joined two Segments together, your `A` would turn into\n   an `A | B` union type, but there was no tracking that, in the final\n   result array, the result(s) from the first segment came first. If the\n   first segment returned a fixed number of results -- e.g., a one-tuple\n   like `[A]` -- then destructuring the final results from the merged\n   segment would get needlessly messy, because the type system would\n   think that every destructured element could be an `A | B`, when\n   really the first element could only be A, and the subsequent elements\n   could only be `B`. Meanwhile, if the first segment returned a tuple\n   type with more than one element (e.g., `[X, Y, Z]`) this would also\n   get lost when working with the result, as the type system could only\n   track the segment's return type as an `(X | Y | Z)[]`. Now, though,\n   we leverage TS 4.0's variadic tuple types to make it so that every\n   segment can return a variable length array _or_ a tuple and, if it\n   returns a tuple, we'll track the type of the element at each position\n   _and_ we'll keep remembering those types when we append a subsequent\n   segment (which itself could add a fixed number of items, the\n   positions/types of which we'd track perfectly, or a variable array\n   which we'd use as a rest element in the final tuple used to represent\n   the merged segment's ultimate result).\n\n2. Before this, the type system tracked, as a parameter on Segment, the\n   return type of the underlying redis commands in a segment. (As with\n   the type used to track the final output value produced _after_\n   calling apply, this was a single [often union] type rather than a\n   tuple type representing the redis return data for each of the input\n   commands.) The issue was that making this a type parameter of\n   `Segment` is that it wasn't really necessary, and in some ways was a\n   negative: it exposed \"internal\" details and caused type unification\n   errors. I.e., from the outside world, the only thing that defines a\n   Segment -- i.e., the only values you can ever see out of it, whether\n   through `run` or `map` -- are the results after running `apply`. The\n   results of the commands themselves, before running `apply` are _only_\n   relevant in making sure that the type signature of apply itself is\n   valid, which we can still","shortMessageHtmlLink":"refactor: total overhaul of types/implementation"}},{"before":"f7e85de14d3a1a7548c89a8fb46f8a59d80905d8","after":"10499ed42ea688c45b8abc1f3eb892e9397fc286","ref":"refs/heads/master","pushedAt":"2023-09-11T04:02:59.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ethanresnick","name":"Ethan Resnick","path":"/ethanresnick","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/471894?s=80&v=4"},"commit":{"message":"refactor: total overhaul of types/implementation\n\n1. Before this, the type system tracked a type `A` for each Segment and\n   assumed that the result of the Segment (i.e., after getting the\n   command results from Redis and running them through `apply`) was an\n   `A[]`. If you joined two Segments together, your `A` would turn into\n   an `A | B` union type, but there was no tracking that, in the final\n   result array, the result(s) from the first segment came first. If the\n   first segment returned a fixed number of results -- e.g., a one-tuple\n   like `[A]` -- then destructuring the final results from the merged\n   segment would get needlessly messy, because the type system would\n   think that every destructured element could be an `A | B`, when\n   really the first element could only be A, and the subsequent elements\n   could only be `B`. Meanwhile, if the first segment returned a tuple\n   type with more than one element (e.g., `[X, Y, Z]`) this would also\n   get lost when working with the result, as the type system could only\n   track the segment's return type as an `(X | Y | Z)[]`. Now, though,\n   we leverage TS 4.0's variadic tuple types to make it so that every\n   segment can return a variable length array _or_ a tuple and, if it\n   returns a tuple, we'll track the type of the element at each position\n   _and_ we'll keep remembering those types when we append a subsequent\n   segment (which itself could add a fixed number of items, the\n   positions/types of which we'd track perfectly, or a variable array\n   which we'd use as a rest element in the final tuple used to represent\n   the merged segment's ultimate result).\n\n2. Before this, the type system tracked, as a parameter on Segment, the\n   return type of the underlying redis commands in a segment. (As with\n   the type used to track the final output value produced _after_\n   calling apply, this was a single [often union] type rather than a\n   tuple type representing the redis return data for each of the input\n   commands.) The issue was that making this a type parameter of\n   `Segment` is that it wasn't really necessary, and in some ways was a\n   negative: it exposed \"internal\" details and caused type unification\n   errors. I.e., from the outside world, the only thing that defines a\n   Segment -- i.e., the only values you can ever see out of it, whether\n   through `run` or `map` -- are the results after running `apply`. The\n   results of the commands themselves, before running `apply` are _only_\n   relevant in making sure that the type signature of apply itself is\n   valid, which we can still","shortMessageHtmlLink":"refactor: total overhaul of types/implementation"}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAADfjR0gAA","startCursor":null,"endCursor":null}},"title":"Activity · ethanresnick/redis-pipeline-segment"}