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

fix(info-context): InfoBox/InfoWindow children receive React context (addresses #258) #361

Merged
merged 2 commits into from
Oct 14, 2016

Conversation

benwiley4000
Copy link
Contributor

@benwiley4000 benwiley4000 commented Oct 12, 2016

Now in InfoWindow or InfoBox children you can use components like React Router's Link, which relies on React context for route matching information. Addresses #258.

ETA: For this to work all prop updater functions from a component's controlledPropUpdaterMap are called from enhanceElement with a supplied this (via Function.prototype.call). See here. This wasn't necessary before since none of the updaters required this, but we need this in order to get React context.

@benwiley4000
Copy link
Contributor Author

benwiley4000 commented Oct 12, 2016

This works fine for me but I noticed am getting an error when I click the Link to make a transition:

React.Children.only expected to receive a single React element child.

As far as I can tell this error isn't breaking anything, but I'm looking into the cause currently. If anyone else is/is not able to replicate the error I'd be interested to hear.

ETA: I've figured out the issue and I'm working on patching it.

@benwiley4000
Copy link
Contributor Author

Patched, errors gone. 😃

Copy link
Owner

@tomchentw tomchentw left a comment

Choose a reason for hiding this comment

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

wow, thanks for the fix @benwiley4000 ! This could definitely solve #258 .

Looks good in general, I just left two comments for some coding style changes. Also, could you try to split your code changes into two commits:

fix(InfoWindow): allow children to receive React's context
fix(addons/InfoBox): allow children to receive React's context

The first commit should contain changes of src/lib/InfoWindow.js and src/lib/enhanceElement.js. Reason for the changes is for the automatically changelog generation.

You can use git reset HEAD~ to amend your commits and do a force push afterwards, and I'll merge your branch locally to master (I'm hoping it'll mark this PR as merged).

Thanks!

@@ -72,7 +72,7 @@ const publicMethodMap = {

const controlledPropUpdaterMap = {
children(infoWindow, children) {
render(Children.only(children), infoWindow.getContent());
renderSubtreeIntoContainer(this, Children.only(children), infoWindow.getContent());
Copy link
Owner

Choose a reason for hiding this comment

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

I'd like to keep it just unstable_renderSubtreeIntoContainer to indicate we're using unstable APIs.

Copy link
Owner

Choose a reason for hiding this comment

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

Also change it to:

children(infoWindow, children, component) {
  unstable_renderSubtreeIntoContainer(component, Children.only(children), infoWindow.getContent());
}

@@ -135,7 +135,7 @@ export default _.flowRight(

componentDidMount() {
const infoWindow = getInstanceFromComponent(this);
controlledPropUpdaterMap.children(infoWindow, this.props.children);
controlledPropUpdaterMap.children.call(this, infoWindow, this.props.children);
Copy link
Owner

Choose a reason for hiding this comment

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

controlledPropUpdaterMap.children(infoWindow, this.props.children, this);

@@ -87,7 +87,7 @@ const enhanceWithPropTypes = _.curry((
_.forEach(controlledPropUpdaterMap, (fn, key) => {
const nextValue = this.props[key];
if (nextValue !== prevProps[key]) {
fn(getInstanceFromComponent(this), nextValue);
fn.call(this, getInstanceFromComponent(this), nextValue);
Copy link
Owner

Choose a reason for hiding this comment

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

I'm seeing this fn.call as a bad sign, and I would say, put it in the third argument:

fn(getInstanceFromComponent(this), nextValue, this);

@benwiley4000
Copy link
Contributor Author

@tomchentw thanks for the comments. You're actually putting me much closer to my original code, so go figure. I hesitated to make thisArg an actual argument to the prop updater since convention is to put that first or specify it via call, but your solution to just call it something else (component) makes perfect sense to me.

Also, no need to merge my branch locally. If I do a force push, I believe it should be reflected here and you can merge using GitHub. Don't quote me on that though - we'll find out in a few minutes.

@tomchentw
Copy link
Owner

@benwiley4000 the reason to merge locally is:

  • To keep contributor names (although it could be done in merge commit)
  • For auto changelog generation (because we made multiple changes to multiple subjects)

@benwiley4000
Copy link
Contributor Author

For what it's worth this post claims that should work.

Anyway, I've updated my fork.

Copy link
Owner

@tomchentw tomchentw left a comment

Choose a reason for hiding this comment

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

@benwiley4000 this is exactly what I'm looking for.

The changes look great!

@tomchentw tomchentw merged commit 5748a96 into tomchentw:master Oct 14, 2016
@tomchentw tomchentw deployed to github-pages October 14, 2016 06:22 Active
tomchentw added a commit that referenced this pull request Oct 14, 2016
@tomchentw
Copy link
Owner

Released v6.0.1 in the npm beta channel.

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

Successfully merging this pull request may close these issues.

2 participants