consider a component with props defined as follows ```external interface UserProps : Props { var ...

# react

[andylamax]

consider a component with props defined as follows

external interface UserProps : Props {
   var name: String
   var photo: String?
}

In Typescript, Rendering a component (say User) with these kind of props would behave like this


✅ Compilation

<User name="John Doe"/>

❌ Compilation (prop name is required)

<User photo="<https://some.url>"/>

While in kotlin

✅ Compilation

User { name="John Doe" }

✅ Compilation, ❌ Runtime

User { photo="<https://some.url>" }

Now (@turansky), Isn't there a way to provide compile time safety for kotlin-react similar to how Typescript provides it for jsx?? I feel like this is so hugely required especially for large projects

[spand]

You can get some of the way by making the props a real kotlin class ie. class UserProps(val name: String, val photo: String? = null)

[andylamax]

And with the current API, how does the user of my react components use this UserProp class??

[spand]

Not sure. I did it for an old version by looking at how the existing functions work and hacked something together. Not sure if there is anything standard now

[andylamax]

The current API can't enforce the use of those classes right now

[turansky]

Isn’t there a way to provide compile time safety for kotlin-react similar to how Typescript provides it for jsx?

It’s common problem of DSL with required options/properties

[andylamax]

For now I am resorting to extending ChildrenBuilder. Despite it not being a true react component, it does work for most (Not all) our use case

Something like this if any one asks

private val User = FC<UserProps> {}

inline ChildrenBuilder.User(name: String, photo: String?=null) = User { 
  this.name=name
  this.photo = photo
}

[turansky]

We can’t say “goodbye extensions” 😞

[andylamax]

Looks like we can't hence we need a compiler plugin for this 😀

[turansky]

Or sugar for DSL builders

[Mike Dawson]

Maybe it would be possible to make a Lint check for it? I still see a need for end-to-end tests (using Cypress for this at the moment), so anything that doesn't get caught at compilation will be caught in the end

[andylamax]

How would DSL sugar look like in this case? syntactically I mean