Giter VIP home page Giter VIP logo

Comments (14)

ferdaber avatar ferdaber commented on March 29, 2024 1

@eps1lon this actually doesn't work because when you construct <input value="0" /> the type of the resulting expression is just JSX.Element<any> so TypeScript won't actually check the constructor type of the child JSX expression, you can basically put any JSX expression you want inside.

from react.

deser avatar deser commented on March 29, 2024 1

Yep, that's kind of what I was alluding to in my first response. TypeScript will have no problems with simple interfaces, so the implementing component will just need to wrap it in a createElement call. It's an unfortunate limitation :/

@ferdaber , sorry I don't quite understand what does it mean to wrap it in a createElement call. Could you be so kind to show an example?

Thanks

from react.

swyxio avatar swyxio commented on March 29, 2024

this is potentially very useful for us! cc @ferdaber i wonder what problems you and Ryan Florence ran into that prevented him typing children - even if there are problems, we should definitely document them

from react.

ferdaber avatar ferdaber commented on March 29, 2024

Typing children as anything but JSX is generally safe for TypeScript. It only becomes a problem if you try typing them as specific JSX types.

So if you say "I want my children to be an array of objects with these properties" 👍🏼, but "I want my children to be an array of JSX elements that have this component as their type/constructor" 👎🏼

from react.

ferdaber avatar ferdaber commented on March 29, 2024

In the case above they are just simple interfaces, or objects, so they are able to be well-typed as children.

from react.

swyxio avatar swyxio commented on March 29, 2024

ah ok. honestly wouldnt have been a blocker for me adopting ts in Reach UI

from react.

deser avatar deser commented on March 29, 2024

In the case above they are just simple interfaces, or objects, so they are able to be well-typed as children.

Hm, seems I either misunderstood smth or that is not entirely correct. By default (without any explicit typings) typescript blames that child (which is React.Node) can't have any props:
image

Whatever I do with explicit typing doesn't help eventually.

from react.

deser avatar deser commented on March 29, 2024

Maybe this is an issue with @types/react or that I have React 15.6 installed but not 16.*

from react.

ferdaber avatar ferdaber commented on March 29, 2024

It's honestly a bit difficult for me to decipher what you want to achieve with the short example at the beginning of the issue. Can you elaborate on it?

from react.

eps1lon avatar eps1lon commented on March 29, 2024

Shouldn't this cover most use cases:

interface ParentProps {
  children: React.ReactElement<ChildProps>;
}

interface ChildProps {
  value: string;
}

function Parent(props: ParentProps) {
  return <div>My child has {props.children.props.value} value.</div>
}

// { children: string } is not assignable to ...
<Parent>1</Parent>; // $ExpectError
<Parent><input value="0" /></Parent>;

You could also allow only numbers or arrays. As long as it's assignable to React.ReactNode you shouldn't have any troubles. Probably helps with safe cloneElement but I would personally not use this anymore. This pattern creates a tight parent-child coupling that doesn't allow intermediate components (goes against reacts composition model). Context should cover most use cases.

from react.

eps1lon avatar eps1lon commented on March 29, 2024

@eps1lon [...] you can basically put any JSX expression you want inside.

😞 Well at least you could restrict it to primitives? Still has some DX improvements in the parent. For more usage safety you could add a prop-types validator e.g.

Parent.propTypes = {
  children: PropTypes.shape({
    props: PropTypes.shape({ // could share `propTypes` to the child
      value: PropTypes.string.isRequired
    })
  }).isRequired
};

from react.

ferdaber avatar ferdaber commented on March 29, 2024

Yep, that's kind of what I was alluding to in my first response. TypeScript will have no problems with simple interfaces, so the implementing component will just need to wrap it in a createElement call. It's an unfortunate limitation :/

from react.

stale avatar stale commented on March 29, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions!

from react.

swyxio avatar swyxio commented on March 29, 2024

cleaning up old issues - pls reopen if you still face this!

from react.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.