question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Please DON'T use `[key: string]: unknown`

See original GitHub issue

Reference 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:closed
  • Created 3 years ago
  • Reactions:8
  • Comments:20 (7 by maintainers)

github_iconTop GitHub Comments

3reactions
majelbstoatcommented, Jun 5, 2020

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.

3reactions
camerackercommented, May 8, 2020

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

This is useful for APIs that want to signal “this can be any value, so you must perform some type of checking before you use it”. This forces users to safely introspect returned values.

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 the Element or Text 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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

What's the difference between object and {[key: string]
{ [key: string]: unknown } refers to an object with string as indexable keys: this means that you cannot simply assign any arbitrary...
Read more >
How to check that an 'unknown' object has a specific key and ...
Hi, I am new to TypeScript. I have an object which I want to validate is the same structure/shape as some interface. I...
Read more >
When to use `never` and `unknown` in TypeScript
When you get down to a fundamental definition a type is a set of possible values, and nothing more. For example, the type...
Read more >
Objects - The Modern JavaScript Tutorial
A property is a “key: value” pair, where key is a string (also called a “property ... We mostly use null for “unknown”...
Read more >
Managing objects with unknown structures in TypeScript using ...
Consider using Record<string, unknown> instead, as it allows you to more easily inspect and use the keys. The issue with the object type...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found