Please DON'T use `[key: string]: unknown`
See original GitHub issueReference merge request: https://github.com/ianstormtaylor/slate/pull/3566
Setting key type to unknown is a disaster for typescript users, now I have to write type cast (node as any)
or node.type as any
everywhere when accessing arbitrary properties, otherwise it will gives me an error and cannot be turned off by any typescript configurations. It makes me miss the old days when we are at 0.57.
Slate itself is a modular and extensive framework, so many users will assign self-defined properties to editor objects. an unknown
type will leads to many annoying and redundant type casts and type checks. Write type check code everywhere with if-else
block or (as any)
for simply access type
or bold
is silly.
unknown
type is evil, may be it fixes some trivial problems, but it will break the develop experience of typescript users, I have developed in typescript for three years, most of the typescript typings for open source projects don’t use unknown
type. I think it’s better if we have [key: string]: any
or other solutions.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:8
- Comments:20 (7 by maintainers)
Top GitHub Comments
It would be worth exploring whether we can do for example
createEditor<T = Text, E = Element>()
and have all the methods on the editor use that custom type, so it doesn’t have to be specified on every call. Harder for the Editor/Node interfaces because they’re static methods called individually, but worth looking into.Edit: Thanks for the feedback, we appreciate you bringing these concerns up
The goal behind this change is captured nicely here in this stack overflow answer https://stackoverflow.com/a/51441168
I have trouble believing that the intention of the API’s original use of
any
is to deprive the user of any typechecking when they bind arbitrary values to theElement
orText
objects. I hear you that the type checks are inconvenient, but type checking is part of the value typescript provides.If there’s something that can be done to make this easier to use while still providing stronger type checking than no type checking, that’d be cool. It’s certainly not a goal to make the API harder to consume. But the most helpful thing would be to provide some alternate suggestions on how to achieve the intended goal.