Skip to content
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

ref type broken for HTMLElement #951

Closed
mwerschy opened this issue Apr 12, 2020 · 2 comments · Fixed by #952
Closed

ref type broken for HTMLElement #951

mwerschy opened this issue Apr 12, 2020 · 2 comments · Fixed by #952
Assignees
Labels
🐞 bug Something isn't working

Comments

@mwerschy
Copy link

Version

3.0.0-alpha.12

Reproduction link

https://codesandbox.io/s/infallible-https-w248t?file=/src/index.ts

Steps to reproduce

Note the error on line 4 of index.ts.

What is expected?

ref<HTMLElement | null>(null) is assignable to a variable of type Ref<HTMLElement | null>.

What is actually happening?

Type 'Ref<{ accessKey: string; readonly accessKeyLabel: string; autocapitalize: string; dir: string; draggable: boolean; hidden: boolean; innerText: string; lang: string; readonly offsetHeight: number; ... 232 more ...; focus: (options?: FocusOptions) => void; }>' is not assignable to type 'Ref<HTMLElement>'.

Perhaps some issue with symbols in the UnwrapRef declaration? The full error includes the line Property '[Symbol.iterator]' is missing in type.

@jacekkarczmarczyk
Copy link
Contributor

see also

interface Foo1 { [Symbol.iterator]: any }
interface Foo2 { }
const foo1: Ref<Foo1|null> = ref<Foo1|null>(null);
const foo2: Ref<Foo2|null> = ref<Foo2|null>(null);
console.log(foo1, foo2);

@LinusBorg LinusBorg self-assigned this Apr 12, 2020
@LinusBorg LinusBorg added the 🐞 bug Something isn't working label Apr 12, 2020
@LinusBorg LinusBorg reopened this Apr 12, 2020
@LinusBorg
Copy link
Member

LinusBorg commented Apr 12, 2020

(Sorry for the close, mouse finger messed up ^^)

We can easily fix the problem with HTMLElement and similar Types (Window, Document) by adding them to the BaseTypes. That's correct as the properties of these types shouldn't be recursively walked by Unwrap anyways. I'll have a PR up for that in a second.

For the more general case about Symbol.Iterator that @jacekkarczmarczyk added, we should look at this PR from @pikaxas well as this comment from discord:

So I was bored and did some more digging. The issue is caused by this microsoft/TypeScript#24622. It's possible to work around it for general types by doing something like this:

type UnwrapTest<T> = {
  [P in keyof T]: T[P]
} & (T extends { [Symbol.iterator]: infer V } ? { [Symbol.iterator]: V } : {})

should be adaptable for our UnwrapRef implementation and seems to go in a similar direction as @pikax's PR.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
🐞 bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants