Skip to content

Conversation

@johno
Copy link
Member

@johno johno commented Nov 22, 2018

No description provided.

@vercel
Copy link

vercel bot commented Nov 22, 2018

This pull request is automatically deployed with Now.
To access deployments, click Details below or on the icon next to each push.

@johno johno force-pushed the props-fix branch 2 times, most recently from 2d3b050 to d554d76 Compare November 22, 2018 09:14
Copy link
Member

@ChristopherBiscardi ChristopherBiscardi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just spent a bit following the commits over the last day or two that added/reverted the components changes, etc. This seems like it'll work as long as we pass everything into the createElement call. The other option I can think of would've been adding a conditional destructuring off this.props in the case of having an export.

constructor(props) {
super(props)
this.layout = ${layout}
this.layout = ${layout || 'null'}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could also remove the entire constructor instead if layout isn't defined.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is semantically cleaner than omitting the constructor entirely, because it's communicating that there is no user layout. null is semantically different than undefined.

}
render() {
const { components = {} } = this.props
const { components = {}, ...props } = this.props
Copy link
Member

@ChristopherBiscardi ChristopherBiscardi Nov 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

won't this need an equivalent change in the runtime to pass the props into createElement?

Previously, the runtime was just using the scoped names when passed in to defined the components and props variables. If we're standardizing the class to be this.props access always, then we need to pass everything into createElement in the runtime like

createElement(MDXContent, {components, ...props})

@ChristopherBiscardi
Copy link
Member

I can't push it up to this branch, but this additional change passes the tests for me.

diff --git a/packages/runtime/src/index.js b/packages/runtime/src/index.js
index 12f2bdd..0cd13de 100644
--- a/packages/runtime/src/index.js
+++ b/packages/runtime/src/index.js
@@ -37,7 +37,7 @@ export default ({
     ...keys,
     `${code}
 
-  return React.createElement(MDXContent, { components });`
+  return React.createElement(MDXContent, { components, ...props });`
   )
 
   return fn({}, React, ...values)

@johno
Copy link
Member Author

johno commented Nov 23, 2018

Thanks @ChristopherBiscardi, that diff was the ticket for runtime 👍

@johno johno merged commit 8978bb1 into master Nov 23, 2018
@johno johno deleted the props-fix branch November 23, 2018 16:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

4 participants