Чем руководствоваться при создании компонента в react? Его функциональностью и изменяемостью
или логической структурой приложения?
Допустим, имеется главная страница
Блок 1 и блок 3, как понимаю, однозначно должны описываться как компоненты, потому
что представляют собой функциональные блоки.
Блоки 2 - входят в навбар и тоже описываются как компоненты.
Блок 3 - отдельный компонент, содержит дудл, строку поиска и кнопки поиска. Строка
поиска и кнопки это отдельные компоненты? А нужно ли выделять дудл в отдельный компонент
(допустим он никогда не меняется)?
Блок 4 - футер. Описывать его отдельным компонентом, если он всегда неизменен? Или
его включать в компонент, который описывает целиком главную страницу?
Ответы
Ответ 1
Контейнер (container или умный компонент) - это компонент унаследованный от Component
и содержащий логику и/или изменяющий свое состояние. Используется для порождения и
инициализации других компонентов. Его так же можно назвать statefull.
Презентационный (presentational или глупый компонент) - это компонент унаследованный
от Component не имеющий логики и не изменяющий свое состояние. Может иметь собственные
стили. Так же его называют еще stateless. Применяется для отображения данных, как правило
полученных через props. Сейчас его использовать нет смысла, так как для его замены
был создан новый вид компонентов описываемый ниже.
Функциональные (или глупые компоненты так же являющиеся презентационными) - это компоненты-функции
которые не имеют логики и не хранят состояние и имеют собственные стили. Так же называются
stateless. В их обязанность входит отображать данные полученные через props.
Чистый (pure) - компонент унаследованный от PureComponent, может относится как к
первой категории так и второй и третей. В его задачу входит производить неглубокое
сравнение состояния компонента чтобы избежать лишнего рендера и избавить программиста
от написания лишней проверки.
Этого должно хватить для понимания где что и когда использовать, но все равно добавлю,
что лучше писать как можно меньше компонентов-контейнеров.
Что касается понимания когда использовать компонента, а когда элемент, то проще объяснить
на простом примере -
// так можно, но лучше не делать
// так будет более правильно
const ButtonGroup = ({children}) =>
(
{children}
);
И раз уж зашел разговор о компонентах, то не могу не упомянуть о такой важной составляющей,
как стиль компонентной композиции. Очень часто я вижу подобное -
Но лично я предпочитаю и поэтому советую писать вот так -
Ведь очень часто бывает так, что из головы вылетают детали собственного приложения
и очень важно суметь освежить его в памяти одним охватом. А для людей которые впервые
знакомятся с кодом второй вариант вообще подарок, так как очень сложно воссоздать в
голове приложение не по дереву, а по классам из файлов. Но есть исключения, когда кода
будет действительно много, то придется делать как в первом варианте, но все равно стараться
как можно больше уместить в одном компоненте. Просто очень часто вижу как пишут App
=> Header + Footer. Идешь в Header, а там только один компонент, как например ButtonGroup.
Потом идешь в этот ButtonGroup а там ещё один компонент. И так пока дойдешь до последнего
уже забываешь откуда пришел и зачем.
А что качается конкретно Вашего случая, то минимум мог бы выглядеть так -
Ответ 2
Разделение компонента
Чтобы компонент не делал слишком много. Общепринято делить его на два компонента,
каждый из которых будет играть различную роль. Эти два типа компонентов называются
компоненты-контейнеры и презентационные компоненты, также их называют “умными” и “глупыми”
компонентами соответственно.
Говоря кратко, компоненты-контейнеры содержат исходные данные и работают с состоянием.
Состояние передается презентационным компонентам как свойство и затем рендерится в
представление.
Термины “умные” и “глупые” компоненты постепенно уходят из употребления в сообществе.
Презентационные компоненты
var UserList = React.createClass({
render: function() {
return (
{this.props.users.map(function(user) {
return (
{user.name}
);
})}
);
}
});
Презентационные компоненты “глупые” в том смысле, что они не имеют понятия о том,
откуда взялись свойства, которыми они оперируют. Состояние? Нет, не слышали.
Презентационные компоненты никогда не должны менять данные в свойствах самостоятельно.
Фактически, любой компонент, принимающий свойства должен считать, что данные неизменны
и принадлежат его родителю. В то же время никак не влияя на значимость данных в свойстве,
он свободен в форматировании данных для вывода в представлении (например, конвертируя
Unix timestamp во что-то более читаемое).
Компоненты-контейнеры
Компоненты-контейнеры практически всегда являются родительскими для презентационных
компонентов. В определенной степени они служат посредниками между презентационными
компонентами и остальным приложением. Они также называются “умными” компонентами, так
как они в курсе всего приложения в целом.
var React = require('react');
var axios = require('axios');
var UserList = require('../views/list-user');
var UserListContainer = React.createClass({
getInitialState: function() {
return {
users: []
}
},
componentDidMount: function() {
var _this = this;
axios.get('/path/to/user-api').then(function(response) {
_this.setState({users: response.data})
});
},
render: function() {
return ();
}
});
module.exports = UserListContainer;
Компоненты-контейнеры могут создаваться точно также, как и любой другой компонент
React. У них также, как у остальных компонентов, есть метод render, но они ничего не
создают для своего рендеринга, а вместо этого возвращают результат в виде презентационного
компонента.
Ссылка на оригинальную статью
Комментариев нет:
Отправить комментарий