mletov, ну а второе. видимо у вас там правило стоит, которое запрещает тип any (вы там указали пустой объект, не знаю почему стало any.. флоу в вашем примере не вижу, может у вас там TS или еще чего)
mletov
> 1) В конструкторе идет обращение к this._columns и this.state, хотя таких свойств в классе не объявлено.
так вы их в конструкторе и создаете... this ссылается на конкретно этот элемент и вы туда просто пишите новые свойства, почему бы нет?
Никита Нескучаев, инфы по этому завались. Главное теорию с сайта Кантора понять и дальше уже выбрать любой из доступных инструментов с помощью гугления
eternalSt а может и добавить стоит) что когда запись идет в одну строку, и нужно вернуть объект, то его обязательно нужно взять в круглые скобки, иначе получается что запись "вместо" превращается в такую:
(function (state) {
entryText: state;
});
а запись "вот так попробуй" в:
(function (state) {
return { entryText: state };
});
frolldoll, в public кладите все что нужно, например css в директорию css, и подключайте так же:
//css/my_css.css
Но обычно css отдельно нет необходимости подключать. Либо берется сразу с CDN в индекс.хтмл (например стили бутстрапа), либо файлы стилей пишутся внутри приложения и просто импортируются. В create-react-app сразу есть пример подключения css
Nikolko, отлично! С уверенностью 100% могу сказать, что будет один из вебинаров посвящен такой теме, поэтому заглядывайте в паблик или на канал (ссылки есть в профиле).
Nikolko, на каждое изменение в роутере передавать событие. Изменения можно завязать на redux или на componentDidMount у примонтируемых страниц. То есть, все что нужно, это для каждой страницы (а она же представлена каким-то компонентам), на cdm вешать PAGE ивент сегмента.
Алексей Скляров полностью поддерживаю. По js-название_класса - легко и понятно, что это касается логики, и что если тут рефакторить, то нельзя просто взять и удалить этот класс.
Александр Виноградов, им не то чтобы на watermark пофиг, им пофиг даже если они вырезают / закрашивают, убивают красоту картинки... им вообще пофиг. Крутой вариант, если они не скачивают картинки, а тупо ссылки на ваш сайт вставляют как картинку, то можете заменить картинку по ссылке на что-нибудь не пристойное, только у себя убрать картинку по этой ссылке не забудьте ))
samegalt, вас понял. Главная мысль: код - это не про оптимизацию строчек, это про "поддержку". Весь кайф редакса в том, что если экшены были хорошо описаны (типы корректные) - то через 3 месяца вы сможете подкрутить код быстро. Согласитесь, есть разница:
- LOAD_USERS_FOR_TABLE_GAMERS (загрузить юзеров в таблицу для геймеров, например с их пк и ником на твиче)
- LOAD_USERS_FOR_PARTY_TONIGHT (загрузить юзеров в страницу встречи, где люди собираются на вечеринку).
Сразу понятно, будучи на экране "вечеринки" - что экшен приехал нужный и что юзеры скорее всего готовые "потусить".
Юзеры разные, страницы разные, цели разные - следовательно все разное (экшены и редьюсеры). Конечно, нужно использовать одинаковый код для запроса по сети, с парой параметров, можно как-то еще оптимизировать копи-пасту. Но вот в случае с редьюсерами и экшенами, обычно, копипаста не косяк, а удобство.
Тем не менее, обычно для таких целей используются разные api эндпоинты, то есть возможно, в вашей ситуации вы поступали не так уж и плохо, но нужно смотреть по ситуации. В остальном, как уже было сказано не только мной - на разные экраны, разные редьюсеры. При этом, есть вариант, загружать юзеров в свой отдельный редьюсер один раз (с пометками, кто обычный, а кто суперюзер), и на разных экранах их юзать из общего редьюсера, но при этом разделять по признаку? Тут опять же возникает вопрос о целесообразности: если вы уверены, что такая информация все равно будет загружена юзером - то ок, если же нет - то не надо грузить лишнего.
Как видите, тут много текста, много тонкостей, но я думаю общую суть передает.
Nikolko, redux-segment - мидллвейр, который просто смотрит, есть ли необходимое поле в экшене. Поэтому тут неважно какой роутер и все такое. Если важно "трекать" переходы между страницами, то тут нужно настроить отсылку нужных экшенов: в зависимости от роутера или от компонентов - зависит от задачи.
Yustas Alexu, Спасибо за ответ. Странно что в airbnb есть такое правило, ведь в этом вся соль: мы рисуем компонент с его начальным состоянием и потом начинаем делать различные манипуляции... я сначала тоже думал, что вроде бы логично делать сразу в componentWillMount, но где-то вычитал, что при таком подходе мы мешаем серверному рендерингу или что это просто не корректно, с точки зрения компонента, ведь он отрисовывается с каким-то начальным состоянием, которое мы как раз таки и хотим изменить! То есть, очевидно что раз "изменить", значит нужен рендер. Надеюсь, понятно написал ;)
