-
Notifications
You must be signed in to change notification settings - Fork 65
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
Encoding optional props with ReactPropFields #151
Comments
Out of curiosity, which version or commit was this working on? @natefaubion any thoughts? |
I'm currently trying to upgrade doolse/purescript-reactnative which uses the |
The type of |
If that's the case, how should I define
|
PureScript doesn’t have optional fields, so what you’d do is use Record.merge with some set of default props before passing it in. Otherwise I would import fooClass as |
Hm, I guess I've been wanting Option 1 as discussed in #147. This has worked nicely in purescript-reactnative with purescript-react 5.1.0. My problem with the default props is that the defaults are not always known esp for foreign react components. I'll probably just try out unsafeCoerce for now. Alternatively, why not have two row types for |
* Have to use createElement with unsafeCoerce due to purescript-contrib/purescript-react#151 * Change createNoChild to use createLeafElement
What do you mean by this? Do you mean something like pass-through props? You can construct a
This is an orthogonal issue to what the constraints are trying to accomplish. Right now it's impossible to use createElement to construct something with a |
Default props - when integrating third party components, with lots of optional props (say https://facebook.github.io/react-native/docs/view.html#props), it is: 1 - tedious to find out which default each prop should take As such a Union based API is just much more friendly to work with. I understand that ReactPropFields is used just to introduce -- If we want to embrace optional fields though, and we're open to change the
See gist for full example. Imo, this definition would mirror how most JS defined react components are used. When working with purescript react components, we can maybe change getProps to emit a record containing all required props and wrapping all optional props with Maybe. I can work on this if this is an acceptable approach. |
Regarding integrating with third-party components, I think I prefer the implementation mentioned in Option 2 - Builder in #147, albeit more time consuming to write. The main reason is that I think it is handy for defining props where you might want a more complex data type for the prop value. In the React Native View example, if you wanted |
I don't know how to do this without significant overhead. A single type for props reflects the actual React interface. As far as implementation goes |
I'll continue to experiment approaches for this, but for now, the unsafe variants on createElement that's part of #149 should do. Thanks! |
* Have to use createElement with unsafeCoerce due to purescript-contrib/purescript-react#151 * Change createNoChild to use createLeafElement
* Have to use createElementUnsafe, createLeafElementUnsafe due to purescript-contrib/purescript-react#151 * Change createNoChild to use createLeafElementUnsafe * Change from Eff eff to Effect * Fix imports * Change unsafe components to require record props
* Upgrade bower deps for 0.12 * Upgrade to purescript-react 6.0.0 * Replace purescript-eff with purescript-effect * Replace purescript-maps with purescript-foreign-object * Add purescript-avar dev dependency * Upgrade to purescript 0.12, purescript-react 6.0.0 * Have to use createElementUnsafe, createLeafElementUnsafe due to purescript-contrib/purescript-react#151 * Change createNoChild to use createLeafElementUnsafe * Change from Eff eff to Effect * Fix imports * Change unsafe components to require record props * Upgrade test to 0.12 * Upgrade travis, package.json, package-lock.json to 0.12
On the current master,
createLeafElement
has the signature:I used to be able to use
Union
for encoding react classes with optional prop fields defined such as:Wherein I can call
foo {}
orfoo {title: "hello"}
. But it seems the newReactPropFields
constraint now prevents me from doing this. Any suggested way getting around this?The text was updated successfully, but these errors were encountered: