Skip to content
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

option to modify/process props while passing down to component from HOC(container) ? #407

Closed
chandu0101 opened this issue Oct 1, 2015 · 6 comments

Comments

@chandu0101
Copy link
Contributor

is it good idea to support this feature ?

UseCase : I am using relay in scala.js app , i want to pass type safe classes to the component ( instead of manually deserializing json to scala classes every time i call props).

Pseudo code :

var finalStateProps =  {...this.state.queryData}

 if(spec.processProps)  {
   finalProps = spec.processProps( {...this.state.queryData})
 }

<Component {...this.props}
          {...finalStateProps}
          {...prepareRelayContainerProps(relayProps, this)}
          ref="component" />

or process all pieces ({this.props,this.state.queryData,ref,relayprops})

@xsistens
Copy link

xsistens commented Oct 1, 2015

👍

@Globegitter
Copy link
Contributor

Something that would be useful for us as well in certain use-cases. E.g. we query the same data all over our app, but in a few parts we need to prepare the data, e.g. to display it in our select-component.

@chandu0101
Copy link
Contributor Author

any objections for this proposal ? please let me know if none i'll send a PR!

@josephsavona
Copy link
Contributor

I'm a bit wary of adding more complexity to RelayContainer. What are you doing as a workaround?

@Globegitter
Copy link
Contributor

Globegitter commented May 10, 2016

The current workaround that we are using is modifying the data in the render function (e.g. before we pass it down into a generic component).

@kassens
Copy link
Member

kassens commented May 10, 2016

It appears to me that this is a fine workaround and doesn't add much boilerplate to your app and if common in your case could be moved into a higher order component or some other abstraction.

I'm with @josephsavona on this one that we should try to keep the API small.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants