There is nothing wrong with a component accessing its own state. Write-only state wouldn't be terribly useful! However, you should be very careful when exposing component state or state-altering methods to other components. Component state is internal, and should only been touched from outside via a well-considered interface, to prevent your components from becoming an entangled mess.

In fact, there is an example that is similar to your Example #2 in the React documentation:

class Toggle extends React.Component {

  constructor(props) {

    super(props);

    this.state = {isToggleOn: true};



    // This binding is necessary to make `this` work in the callback

    this.handleClick = this.handleClick.bind(this);

  }



  handleClick() {

    this.setState(prevState => ({

      isToggleOn: !prevState.isToggleOn

    }));

  }



  render() {

    return (

      <button onClick={this.handleClick}>

        {this.state.isToggleOn ? 'ON' : 'OFF'}

      </button>

    );

  }

}



ReactDOM.render(

  <Toggle />,

  document.getElementById('root')

);

Note a difference from your example, however. The toggle method needs to be bound in the constructor, to ensure that this means what you're expecting it to mean.

If the wrapping component is the one keeping track of the visibility of the child ExternalComponent, then rather than passing the toggle method into the child component, I would expect the wrapper to render a hide/show affordance of some sort, and then either pass the current visibility into the child component as a prop or selectively render it (note that selective rendering will cause the entire child component to be remounted when it's enabled again, which may be expensive; you may be better off hiding it than tearing it down and recreating it). That makes the division of concerns clear: the wrapper knows about visibility, and the child component doesn't need to know how or why that decision was made, nor does it need to touch the wrapper's internal state.