Post demystifying IndexByType
#81
Conversation
|
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/statelyai/blog/CHAk3GywDHPi3wpeY3eSuMqnDGv5 [Deployment for c2ce9d4 failed] |
There was a problem hiding this comment.
I think the structure is fine as a long read like this will really appeal to folks who like to know the details, which is really the point of the post!
A few more headings might help give some navigational landmarks which will also appear in the Table of contents sidebar. I’ve noted where I think we might need them, but you know best.
Most of my suggestions are minor grammatical fixes, some typography and occasionally trying to make it clearer what you’re referring to when you say “it”, “this”, or “that.” Please feel free to dismiss or ignore any you disagree with, and let me know if you want a re-review at any point.
Let me know when you’ve confirmed the title and I’ll make a matching open graph image so it looks pretty on social media.
| }; | ||
| ``` | ||
|
|
||
| It's also worth noting that our check isn't literally checking if `T[K]["type"]` is exactly the same as `K`. It's checking if it is a subtype of `K`. But we are working on a very strong, practical, assumption that each member of the union has a literal type as its type (or a union of those) and none of them is using `{ type: string }`. |
There was a problem hiding this comment.
| It's also worth noting that our check isn't literally checking if `T[K]["type"]` is exactly the same as `K`. It's checking if it is a subtype of `K`. But we are working on a very strong, practical, assumption that each member of the union has a literal type as its type (or a union of those) and none of them is using `{ type: string }`. | |
| It’s also worth noting our check isn’t literally checking if `T[K]["type"]` is exactly the same as `K`. Instead, it’s checking if `T[K]["type"]` is a subtype of `K`. But we’re working on a very strong practical assumption that each member of the union has a literal type, as its type (or a union of those) and none of them is using `{ type: string }` |
There was a problem hiding this comment.
Perhaps we could finish off with a short conclusion/summary?
There was a problem hiding this comment.
Ye, I was thinking about adding some closing thoughts. What do you think about "please don't do it at home"? 🤣
There was a problem hiding this comment.
“I did this so you don’t have to” 😂
Co-authored-by: Laura Kalbag <[email protected]>
|
|
||
| Honestly, I’ve not reached for the showcased implementation so far. I’ve just shared it as a comparison to the “JavaScript implementation” and for fun 😉 | ||
|
|
||
| In XState right now, we are using the following implementation: |
There was a problem hiding this comment.
Laura has suggested adding a subheading here: #81 (comment)
This is a strong draft of the post - it needs to be polished before we can publish it.
I think it has the potential of splitting into two parts:
IndexByTypedemystified (the big part from the "indexing" header)We could make this whole thing a series of blog posts about the typegen's internal machinery. Not every blog post has to be as long as this one - some tricks used in there are much simpler, or at least they can be described much quicker. And I think that each blog post should be its own thing, it's not worth squeezing two different tricks into a single post or something like that.
I would be very grateful for some initial feedback and help with the structure, language, etc