Alex Zeit: Это и есть jQuery way. Когда существующий сайт на jQuery, то сделать обращение к инстансу компонента из обработчика jQuery - это одна строка. React именно тем и хорош, что позволяет это делать легко. А применение EventEmitter в случаях синхронных обработчиков - это антипаттерн и overengineering.
Вообще, не вижу смысла продолжать этот флейм и пытаться что-то объяснить тому, у кого нет никакого желания это понять.
Alex Zeit: решение по ссылке довольно корявое. Redux очень далёк от серебряной пули. Получение инстанса и взаимодействие с ним - это нормально, когда сайт не является полностью приложением react.
Alex Zeit: setState не получает состояние, а изменяет его. Например, на этом сайте можно сделать компонент комментариев, а на существующую кнопку "отправить" добавить обработчик типа comments.setState({...comments.state, textarea.value})
Alex Zeit: зачем что? Доступ к состоянию компонента извне может быть нужен, например, если на реакте написан отдельный виджет на странице. new MyComponent() - просто демонстрация того, чем является MyComponent.
Максимка: Уже же ответили: с браузерными объектами работают в componentDidMount, он на сервере не выполняется. Если что-то нужно для рендера в строку, делают моки.
Не очень оптимально при каждом изменении при вычислении заново отыскивать все элементы и получать их значения. Лучше при изменении где-нибудь сохранять отдельные значения, и при вычислении брать сохраненные. Например так.
Faliah: с учетом того что var modal рядом с this.on... вряд ли это глобальная область видимости. В любом случае, инстанс можно сохранить и так и так. А вот сохранение в window изнутри компонента однозначно антипаттерн. Что если нужно будет сделать больше одного инстанса?
Изменение props это уже другой вопрос. Оно вообще работать не будет, потому что свойства props не перезаписываемые. Вообще props предназначены в первую очередь для передачи данных из вышестоящего компонента или при инициализации, а для собственных изменяемых данных больше подходит state. Я бы сделал примерно так.