weixin_39604189
2021-01-12 15:37 阅读 0

Document class contextType as the primary consuming mechanism

https://github.com/facebook/react/pull/13728

This documents the Class.contextType API.

The intention here is to document this as the primary way to consume a Context from a class, and since classes are still the mainstream component API, it's the primary way to consume a Context period.

The Consumer API is documented as the way to consume a Context from a function component.

As a result I could remove the following examples:

Accessing Context in Lifecycle Methods - Accessing context in life-cycles is now easy in since the primary way makes that the default. Technically this is still relevant for multiple context in a single class, but it's such an edge case that I feel like it belongs on Stack Overflow or some recipes section. Not the primary documentation.

Forwarding Refs to Context Consumers - While this is still something you might want to do, this is not different than forwarding refs in general. It used to be that this pattern was unique in that when you converted from a class to use Consumer + forwardRef, you would get into this awkward situation. However, if the primary API is to use .contextType on a class, then this situation doesn't happen so doesn't seem to add the confusion.

Consuming Context with a HOC - This pattern is possibly still relevant but it's only relevant because the render prop syntax is kind of a mess when you compose many of them. However, it looks like we're not going to be recommending this pattern and instead look to make it easier to consume context in other ways like the unstable_read proposal. Since this pattern isn't critical even before that's stable I think we should just remove it.

该提问来源于开源项目:reactjs/reactjs.org

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享

5条回答 默认 最新

  • weixin_39641738 weixin_39641738 2021-01-12 15:37

    Deploy preview for reactjs ready!

    Built with commit c9fe3768478d1533970ed73d1b62ce7438a99403

    https://deploy-preview-1265--reactjs.netlify.com

    点赞 评论 复制链接分享
  • weixin_39641738 weixin_39641738 2021-01-12 15:37

    Deploy preview for reactjs ready!

    Built with commit d7b724efc1a3054c8e5b39ba6cd26f186435bafd

    https://deploy-preview-1265--reactjs.netlify.com

    点赞 评论 复制链接分享
  • weixin_39576133 weixin_39576133 2021-01-12 15:37

    I think the HOC examples should be kept around. I'm not sure that consuming just a single context from a component is actually that common. The new API works well as a 1-1 replacement for some usages of legacy context, but most apps I've seen use a combination of HOCs and render props to inject data providers and there are usually more than one (for example react-intl injectIntl + Redux connect, plus some app-specific login context, navigation context, etc.).

    点赞 评论 复制链接分享
  • weixin_39628247 weixin_39628247 2021-01-12 15:37

    This looks great overall!

    Technically this is still relevant for multiple context in a single class, but it's such an edge case that I feel like it belongs on Stack Overflow

    I'm not sure this case is so edge, it was the first question that came to my mind when I knew about this

    or some recipes section

    Is it supported to access multiple contexts from this.context? If so, yes please add info about this somewhere from the beginning.

    I imagine something like this:

    
    static contextTypes = {
        myContext1: MyContext1,
        myContext2: MyContext2,
    }
    

    or

    
    static contextTypes = [MyContext1, MyContext2]
    

    EDIT: Just noticed this was already requested here: https://github.com/facebook/react/pull/13728#issuecomment-426007618

    点赞 评论 复制链接分享
  • weixin_39676930 weixin_39676930 2021-01-12 15:37

    You can still use render prop API for cases when you need that. This just attempts to cover the 80% case.

    点赞 评论 复制链接分享

相关推荐