-
-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improvement: Use string union for Block Type instead of string #83
Comments
Note that this string union can also be used for the |
That's something I have faced. I was wondering if we can use existing types from notion SDK for this. |
Hi, I also looked into the official notion SDK for the types but unfortunately, there isn't any such types in their library. I guess, we'll have to do this by hand. |
Got done with most of it and should be fine for now. Feel free to add if you find some missing. Should be live in the patch release. |
So it seems like the IntelliSense is not working. Most probably because of the generic type |
Alright we are good to go ig. So I'll publish a new patch |
Hi, thanks for implementing this one, I thought I was going to do the PR stuff but I see you've already done it. Now that I think of it, allowing users to put any random string without any warning is a little risky and I think it's up to you if you want to allow this behaviour but I'm glad that people will get good intellisense thanks to you! |
I think we'll be fine and incase of any problem, always ready to fix 🧑🔧
Thanks to you :) |
Hi, I have noticed that the
setCustomTransformer
method takes the first argument as a string for the type of block to use the transformer function(the second argument) which can be anything arbitrary. However there can be spelling mistakes by the users of this library and in order leverage typescript's type safety and tsserver's intellisense, that we use a string union for the first argument of thesetCustomTransformer
so that the users can get good autocompletion.The code could look like this:
(I've added the last union as a string so that there is flexibility to use any arbitrary string at the risk of the user of this library while also providing intellisense to the users of the library who would otherwise have to guess what string to put here.)
and we could change the type definition for
setCustomTransformer
to:The text was updated successfully, but these errors were encountered: