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

React ChildContextProvider #64

Closed
jakubknejzlik opened this issue Mar 22, 2018 · 4 comments
Closed

React ChildContextProvider #64

jakubknejzlik opened this issue Mar 22, 2018 · 4 comments

Comments

@jakubknejzlik
Copy link

jakubknejzlik commented Mar 22, 2018

I've been struggling with contextTypes in React 16.2.0 and found this solution:

import * as React from 'react';
import * as PropTypes from 'prop-types';

interface ProviderChildContext {
  blah: string;
}

export class Provider extends React.Component<void, void>
  implements React.ChildContextProvider<ProviderChildContext> {

  static childContextTypes = {
    blah: PropTypes.string
  };

  getChildContext() {
    return {
      blah: 'foo'
    };
  }
}

Do you think that something like this could be also part of this guide?

@piotrwitek
Copy link
Owner

Hi @jakubknejzlik
Thanks for sharing.
Looks like a quite clean solution, have you tested it in some big project, have you run into any downsides?

@jakubknejzlik
Copy link
Author

jakubknejzlik commented Mar 22, 2018

Hello @piotrwitek yes I tested it, but I must admit that I switched to mobx in the end. Not that it doesn't work, but I went through redux -> context -> mobx and mobx seems to be the best fit for the current state. So the project is just starting and I would classify it as really small :-).

We can at least leave it open for reference so I (or any volunteer) can test it in larger scale. On the other hand the newer approach will be here soon so the question is if it's not better to focus on it.

Also the only downside that I've found is that you have to duplicate the interface and static childContextTypes.

@piotrwitek
Copy link
Owner

piotrwitek commented Mar 23, 2018

Thanks for your thoughts, I agree about a new approach for context coming soon, but still it would be nice to have for other people sitting on the older versions of React.

Regarding downsides, static childContextTypes is a requirement of React so it's not really a downside from this perspective :), and ProviderChildContext interface can be exported and imported by consumers.

The real problem is found for the consumers, because React types doesn't consider context type as a type argument and is failing to any type, which in the end doesn't give us any type-safety for consumers.

I found below pattern to work but not sure what are the downsides as I didn't tested them in real world project yet.

// context consumer component
import { ProviderChildContext } from './Provider';

export class ContextConsumer extends React.Component<{}> {
  static contextTypes = {
    blah: PropTypes.string,
  };

  context: ProviderChildContext = { blah: '' };

  render() {
    const { blah } = this.context; // context has correct type ProviderChildContext 
    return <div>{blah}</div>;
  }
}

export const ContextConsumer2 = (props: {}, context: ProviderChildContext) => (
  <div>{context.blah}</div> // context has correct type ProviderChildContext 
);

ContextConsumer.contextTypes = {
  blah: PropTypes.string,
};

Have you found a decent type-safe solution for consumers case (without failing to type-assertion)? @jakubknejzlik

@piotrwitek
Copy link
Owner

Closing as this is now deprecated API, will add something about new context API soon.

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

2 participants