https://kotlinlang.org logo
Join Slack
Powered by
Is there a good way to implement a default prop fo...
# javascript
b
Is there a good way to implement a default prop for a component? (Or is that an anti-pattern?)
I tried using a data class with a default value for the props type, but that doesn't seem to work (the value ends up as undefined)
I was hoping to avoid having to do something like 
val someKey = props.key ?: defaultProps.key
and just use a kotlin-style default value.
m
There’s no nice way apart from hiding props altogether by creating a lot of 
RBuilder
extension functions which in turn have default parameter values and create the props internally. That’s one reason I’ve created https://github.com/fluidsonic/fluid-react as an alternative. Doesn’t support kotlin-styled though.
b
m
Nice. You still can’t use 
data class
not 
class
though. Only 
external interface
for props.
b
yeah
And with this I still have to do 
props.someKey ?: defaultProps?.someKey
But using that method to fill out defaultProps and then doing 
props.someKey ?: defaultProps?.someKey
does seem to work as expected
m
I don’t think that’s necessary if you use that 
RStatics
approach
b
Hm, I checked and 
props.someKey
was still undefined, but 
defaultProps.someKey
was set.
m
“in your class components” mhh, only works with class components
b
What's the distinction there? I don't think I know.
I'm using 
MyClass : RComponent<...>
m
If it doesn’t work then maybe it’s broken 😕
b
Oops, I take that back...
props.someKey
is showing it. Maybe the local rebuild hadn't deployed yet.
m
Incremental builds are quite unreliable unfortunately 😅
b
Ha, oops...you're right because it's not showing up in `props.someKey`: I had changed my log to 
console.log(props.someKey ?: defaultProps?.someKey)
and then changed it back to just 
console.log(props.someKey)
and thought it worked...but it just hadn't updated yet
I just waited and did a force refresh and 
props.someKey
does not show the value, but 
defaultProps?.someKey
does.
m
That’s weird. How does the companion object look now?
b
Pretty nice that your helper lib allows 
Class
for props.
I have it as:
Copy code
companion object : RStatics<GraphSelectionProps, RState, GraphSelection, Nothing>(GraphSelection::class) {
        init {
            defaultProps = GraphSelectionProps().apply {
                allKeys = listOf("1", "2", "3")
            }
        }
    }
With
Copy code
external interface GraphSelectionProps : RProps {
    var allKeys: List<String>
    // An optional property which can contain stored data to be graphed
    var data: List<dynamic>?
}

fun GraphSelectionProps(): GraphSelectionProps = js("{}").unsafeCast<GraphSelectionProps>()
m
Looks right 🤔
b
So, even in vanilla react, it will inject values from 
defaultProps
into 
props
? You don't have to check both?
m
yes
b
Hm
Maybe worth a bug then.
Oh, but that's not using kotlin react I don't think(?)
m
no, that’s IDE tooling for normal React
b
m
b
Oh, damn...I even scrolled up in #javascript to find a prior bug someone had mentioned to check which project 🤦
👍 1
Hm, I was trying to define a property delegate to check both, but with 
thisRef: RComponent<P, *>
, 
thisRef
has access to 
props
but doesn't have access to 
defaultProps
(even though inside my 
RComponent
subclass I do)--I dunno if there's something weird with the hierarchy there.
m
defaultProps
is set on the component class, 
props
only on the instance of the class
You should never see both properties in the same JS object
b
Ah
6 Views
Open in Slack
PreviousNext
Powered by