From fe76a9d4286cf86d977a60419ca8f6ab20346739 Mon Sep 17 00:00:00 2001 From: Adam Rackis Date: Sat, 27 Jul 2024 10:38:21 -0500 Subject: [PATCH 1/3] feedback --- book-content/chapters/10-deriving-types.md | 1 + 1 file changed, 1 insertion(+) diff --git a/book-content/chapters/10-deriving-types.md b/book-content/chapters/10-deriving-types.md index 925c279..77827ec 100644 --- a/book-content/chapters/10-deriving-types.md +++ b/book-content/chapters/10-deriving-types.md @@ -850,6 +850,7 @@ Instead, we can use the `number` type as the argument to the indexed access type ```typescript type AllPrograms = (typeof programModes)[number]; +// that's a new one from me - I did't know you could index tuple types with number. I'd urge you to cover that in the main content of the chapter, and, as I've said before, re-think whether you need these exercises in the book ``` Now new items can be added to the `programModes` array without needing to update the `AllPrograms` type manually. This solution makes the test pass as expected, and is a great pattern to apply in your own projects. From fafc69fa65e5817a6491402d71915a1998299d56 Mon Sep 17 00:00:00 2001 From: Adam Rackis Date: Sat, 27 Jul 2024 12:28:07 -0500 Subject: [PATCH 2/3] more notes --- book-content/chapters/10-deriving-types.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/book-content/chapters/10-deriving-types.md b/book-content/chapters/10-deriving-types.md index 77827ec..c1c50d0 100644 --- a/book-content/chapters/10-deriving-types.md +++ b/book-content/chapters/10-deriving-types.md @@ -1418,6 +1418,8 @@ What can make decoupling a difficult decision is that deriving can make you feel Deriving makes most sense when the code you're coupling shares a common concern. The examples in this chapter are good examples of this. Our `as const` object, for instance: +I think this discussion is missing a crucial component: sometimes you WANT coupling. If the AvatarImageProps from above doesn't just happen to contain some common properties from the User type, but is in fact, conceptually and in practice, a true subset of the User type, then you WANT tight coupling. If the imageUrl prop on the User type changes from a string to, say, a union of a string (url) or an object containing some inline preview for the image, then you want that change automatically propagated to the dervied type. Coupling is good and desirable sometimes. When it is, you should derive. When you just happen to have a type that shares some structure with another type, duplicate, don't derive. + ```typescript const albumTypes = { CD: "cd", From b37304cf9fffb3911f8acf5345b0632de84f500d Mon Sep 17 00:00:00 2001 From: Adam Rackis Date: Sat, 27 Jul 2024 12:30:40 -0500 Subject: [PATCH 3/3] tweak --- book-content/chapters/10-deriving-types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book-content/chapters/10-deriving-types.md b/book-content/chapters/10-deriving-types.md index c1c50d0..76a7426 100644 --- a/book-content/chapters/10-deriving-types.md +++ b/book-content/chapters/10-deriving-types.md @@ -850,7 +850,7 @@ Instead, we can use the `number` type as the argument to the indexed access type ```typescript type AllPrograms = (typeof programModes)[number]; -// that's a new one from me - I did't know you could index tuple types with number. I'd urge you to cover that in the main content of the chapter, and, as I've said before, re-think whether you need these exercises in the book +// that's a new one for me - I did't know you could index tuple types with number. I'd urge you to cover that in the main content of the chapter, and, as I've said before, re-think whether you need these exercises in the book ``` Now new items can be added to the `programModes` array without needing to update the `AllPrograms` type manually. This solution makes the test pass as expected, and is a great pattern to apply in your own projects.