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.

TypeScript definition render() problem

See original GitHub issue

https://github.com/developit/preact/blob/0dea3b77ee0677987815347c1e6bd23821728aa2/src/preact.d.ts#L66

So, this definition doesn’t seem to work. I have to do something like this to make it work:

interface Props {
  item: any;
}

class Item extends Component<Props, any> {
  render({ item }: Props) {
    return <div class="item">
      {item.title}
    </div>;
  }
}

Issue Analytics

  • State:open
  • Created 6 years ago
  • Reactions:5
  • Comments:13 (8 by maintainers)

github_iconTop GitHub Comments

3reactions
leebensoncommented, Feb 17, 2018

Yeah, this is a Typescript issue. Consider this minimal example in the TS playground:

screen shot 2018-02-17 at 05 42 09

In the above, this.props is correctly inferred to be of type Person.

Yet, the argument passed into the function - despite being part of the overridden function signature (TS will balk if you pass into a non-Person instance) - is incorrectly inferred as any:

screen shot 2018-02-17 at 05 45 13

Preact is doing the right thing in its type definitions; if/when TS fix it, it should just work.

Until then, your options are:

  1. Explicitly define the type in the render() args list, or…
  2. Use this.props.

FWIW, I do the latter. It means I define the types in one place and screw up less often, whilst also cleaning up the render() call (I never understood the point of explicitly passing in props, when they’re already set on this.props anyway.)

1reaction
mindplay-dkcommented, May 14, 2019

Yeah, then you need the extra type-hint.

I’ve been bothered by this before - it’s been a minor annoyance, nothing too grievous for me.

And it’s just an annotation with no effect on bundle size, so… I just add it and move on.

(Incidentally, constructors also can’t be abstracted and can’t inherit anything - so you’ll duplicate the type-hint for the props argument in constructors as well. It’s not perfect.)

Read more comments on GitHub >

github_iconTop Results From Across the Web

Problems with Rendering Component in React + Typescript
Here is where I write the conditional to render a certain content. renderContent = (): Content => { this.props.contents.forEach( ...
Read more >
Documentation - JSX - TypeScript
element instance type => { render: () => void }. The element instance type is interesting because it must be assignable to JSX....
Read more >
Deciphering TypeScript's React errors | by Fiona Hopkins |
ReactNode is anything that React knows how to render: strings, components, and so on. The ? means that this property is optional—you don't...
Read more >
Resolving Error: "Objects are not valid as a React child"
As the error message states, React cannot render objects as children directly. If you are seeing this error, there is a good chance...
Read more >
Useful Patterns by Use Case - React TypeScript Cheatsheets
items={["a", "b"]} // Error: Type 'string' is not assignable to type 'number'. renderItem={(item) => ...
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