Как стать автором
Обновить

Комментарии 26

Если нужны ajax запросы и не хочется самому делать XmlHttpRequest, всегда можно воспользоваться window.fetch. А если нужно заполифилить, то https://github.com/github/fetch :-) А то в react приложении видеть jQuery — «так себе идея» (с)

По статье хочется, чтобы была для начинающих пометка, что React компоненты — это View слой, в нем не должно находиться места бизнес-логики вашего приложения. В Вашем случае — это, например, ajax запросы на сервер. Для того, чтобы унести бизнес логику придумали как раз такие штуки как flux, redux, которые отлично применяются с react =)

ajax запросы в данном случае не являются бизнес-логикой приложения, приложение просит компонент отобразить комментарии и компонент их отображает. Приложение не знает ничего о комментариях, они не входят в его состояние. Подобный подход — это не чистый MVC, а что-то вроде HMVC, где каждое V представляет собой полноценную триаду, но верхние слои об этом не знают.
jQuery? Вы серьезно?
Кажется я начинаю стареть, совсем не поспеваю…
Пожалуйста скажите чем плох jQuery? или он плох именно в данном конкретном примере с ReactJS?

не серчайте, спрашиваю для общего развития…

В данном конкретном. Тащить весь jquery только ради $.ajax плохо. Ещё хуже, что это в официальном туториале. Типичный фейсбук.

Дабы быть справедливым, это перевод реакт туториала, и да, там jquery.
«Узнайте почему необходимо использовать React ...» — звучит очень категорично и безальтернативно. Посмотрел оригинал там, действительно, такого агрессивного продвижения в тексте нет.
«Learn more about why to use React» — наверняка было бы правильнее перевести как «Узнайте больше о том зачем использовать React».
Спасибо, поправил.
Допустим у комментария должны быть контролы для админа, кнопки удаления, редактирования и т.д. Что-бы удалить комментарий мне нужно изменить state.data у CommentBox. Что бы это сделать я должен пробросить метод для удаления от CommentBox через CommentList в Comment?
С использованием Redux разбиение на контейнеры и презентеры делается невероятно легко.
CommentBox передает функцию удаления комментария (например, removeComment(id)) CommentList, а оттуда, в свою очередь, снова же атрибутом передается эта же функция, но уже в сам Comment.

В React есть два типа компонент – презентационные и контейнеры. Так вот CommentBox – контейнер, а CommentList и Comment – презентационные компоненты.

Больше можно почитать в отличном посте от Dan Abramov: https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0, в котором объясняются их отличия. :)
Не «есть», а «рекомендуется разбивать». Любой компонент может содержать как состояние с логикой, так и не посредственное его представление. Но при смешивании это спагетти очень быстро становится не поддерживаемым.
Я правильно понимаю, что в приведенном примере сервер всегда возвращает все комментарии в ответ на запрос? То есть, если их будет сотня, то каждые две секунды будут гоняться десятки килобайт трафика?
И второй вопрос: как вообще происходит перерисовка компонента react-а при изменении состояния: даже не изменившиеся объекты заново перерисуются?
Отрендерятся только те компоненты, у которых state/props изменились. Остальные же будут не тронуты, в этом одна из главных концепции react-a, на ровне с shadow dom
В данном случае каждые 2 секунды state/props приходят новые, да и нет обработчика shouldComponentUpdate или миксина PureRenderMixin. Так что в любом случае виртуальный DOM всякий раз пересчитывается, но реальный не меняется.
Взяли пример из оф документации да еще старье.
Кому сейчас нужны примеры не на es6? Кого вы обучать собрались устаревшими методами интересно?
Хороший туториал.
Я к коментариям выше относительно потоков Flux и Redux добавил бы, что хорошей практикой является описанный полный жизненный цикл компонента.

Если есть
componentDidMount: function() {
    this.interval = setInterval(this.loadCommentsFromServer, this.props.pollInterval);
}

то должно быть и
componentWillUnmount: function() {
    clearInterval(this.interval);
}

И также для любого асинхронного кода
Иначе, если компонент планируется использовать в дальнейшем как составную часть приложения, то при свертывании будут ошибки и утечки.
Ой как все плохо. А как же es6, как же наследование компонентов через extend. Зачем каждый раз в представлении писать this.state…. и вытаскивать данные, если красивее вытащить их в начале рендера, а на es6 еще красивее через let. Можите заминусить но сделать этот функционал на react-starter-kit будет намного приятней
success: function(data) {
        this.setState({data: data});
      }.bind(this)

Понимаю, что нужно, но расскажите зачем здесь bind?
Чтобы изменить контекст функции success на контекст компонента.
Если bind не будет, то this будет ссылкой на объект Ajax request
Тогда на месте this.setState будет ошибка, т.к. Ajax request не знает о setState.
Тут все очень любят es6, с ним можно так:
success = data => this.setState({data});
Я не знаю кто ошибся в статье автор или переводчик, но, React JS — это не фреймворк, а библиотека (A JavaScript library for building user interfaces )
Может автор имел ввиду, то в сборе с другими модулями это уже что то похожее на фрейм.

React is all about modular, composable components. Фреймворк — это моя отсебятина.
Компоненты React модульные и компонуемые. Можно так перевести.
Если предложите лучше вариант, я заменю.

В тексте есть опечатка hendleCommentSubmit вместо handleCommentSubmit, раздел «Обратные вызовы как параметры»
И еще раз спасибо за перевод.

спасибо, поправил.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории