о, через hash наверное сделаю ) не уверен, что на хостинге можно что-то настроить, он бичесвкий совсем. спасибо

Для SEO какую либу сечас юзают повсеместно?

react-helmet

react-helmet

спасибо

:(

Во во ? Я к тому моменту уже успел обнадёжиться, мол щас как упрощу всё) Ичсх, там есть refine, позволяющий "вывести" тип, но он оказывается полностью бесполезен ? Шаг влево шаг вправо — расстрел

Зря только к нему тайпинги для флоу сделал)

Камрады, использующие стайлед, что юзаете для сеток?

Или проще самому сделать?..

парни, что быстрее работает и есть ли в них разница? ids.map(id => <Item id={id} />) vs ids.map(id => <div><SomeComponent id={id} /></div>)

интересует ререндер при изменении ids, будет ли разница если выставление ключей будет одинаковым?

в первом случае в Item такое же содержание, как в div

но в первом реальный компонент, а во втором просто div из лупа

парни, что быстрее работает и есть ли в них разница? ids.map(id => <Item id={id} />) vs ids.map(id => <div><SomeComponent id={id} /></div>)

одно с враппером в <div>, а другое нет?

одно с враппером в <div>, а другое нет?

Item внутри такой же, как div во втором случае

я так понимаю сравнение идет все равно по key и разницы вроде нет

ты кстати им key не передал

кстати

второй вариант не сработает

будет варн

нужно ставить key на <div>

ты кстати им key не передал

забыл упомянуть, что key будет и в обоих случаях одинаков

ну и в первом случае key нужен

с мобх меньше бойлерплейта?

Дело не в самом болерплейте, мобикс в отличии от редакса предлагает уникальные фичи при работе с состоянием - возможность создавать ссылки между объектами а если вкратце то а это позволяет удобно работать с состоянием приложения как с бизнес-сущностями. Например есть такая бизнес-логика обычного приложения менеджера задач - у юзера может быть много папок, у каждой папки может быть много проектов, у каждого проекта может быть много тасков и у каждого таска может быть много комментариев и каждый комментарий также может иметь много реплаев (получается дерево комментариев) и соотвественно каждую сущность можно создать, отредактировать или удалить. С мобиксом как мы описали бизнес-сущности и связи one-to-many или many-to-many, так мы и и храним - объект юзера хранит массив объектов-папок, внутри папки будем хранить массив объектов-проектов, внутри проекта будем хранить массив объектов-тасков а в объекте таска будем хранить массив объектов комментариев и внутри каждого объекта комментария храним также массив других комменатриев-реплаев. Создавать редактировать или удалять сущности очень просто - для создания просто создаем объект и пушим в массив, для удаления делаем сплайс из массива для редактирования просто изменяем одно свойство и вот таким одинаковым образом работаем как с папками так с проектами так и с более глубокими сущностями И самое главное эти сущности могут быть связаны между собой что упрощает логику в обработчиках. Например когда рендерим таски в компоненте проекта <div>{project.tasks.map(task=><Task task={task}/>)}</div> то получив в компоненте Task через пропсы только нужный объект состояния (в данном случае task) часто бывает нужно обратиться к свойству какой-то родительской сущности например project (чтобы например проверить тип или какой-то свойство перед редактированием). И тут конечно можем выдумывать различные костыли передавая через пропсы также объект project и другие родительские сущности (а это может повлечь за собой изменение других родительских компонентов) а можем просто при создании таска добавить свойство project и записать в него ссылку на проект и обратится к свойству просто через task.project.someprop. В итоге взяв за правило при создании любой сущности записывать в свойство объекта ссылку на родительскую сущность можно очень удобно обращаться ко всему состоянию независимо от уровня вложенности например получив через пропсы комментарий можно обратится к папке в котором находится комментарий - comment.task.project.folder.name и это не потребует изменения всех вышестоящих компонентов. А теперь попробуйте ответить на вопрос как бы вы разрабатывали такое приложение используя редакс? Сколько редюсеров бы вам понадобилось? Как работали бы со связями one-to-many? Особенно интересует момент с добавлением и обновлением вложенных сущностей и особенно с деревом реплаев к таску и также интересен момент когда нужно обратится к родительским сущностям в компоненте получив через пропсы только свой объект.

Да, у редукса когда вложенный стейт все усложняется

А аналог middleware для сайд эффектов какое то есть?

Max в редуксе довольно удобно экшенами декларативно описывать сайд эффекты, которые и тестируются хорошо и модулизируются.

Max в редуксе довольно удобно экшенами декларативно описывать сайд эффекты, которые и тестируются хорошо и модулизируются.

Редукс... Бля

Редукс... Бля

Ридакс

Ридакс

от слова "ридакция"

Это для него axios обычно используют?

от слова "ридакция"

Да нет, так оно и произносится

Хм, в русском языке 2 способа заимствований по буквам и звукам. Вечный холивар)

Ридакс

ору

кто-нибудь пользовался перевождем?

Дело не в самом болерплейте, мобикс в отличии от редакса предлагает уникальные фичи при работе с состоянием - возможность создавать ссылки между объектами а если вкратце то а это позволяет удобно работать с состоянием приложения как с бизнес-сущностями. Например есть такая бизнес-логика обычного приложения менеджера задач - у юзера может быть много папок, у каждой папки может быть много проектов, у каждого проекта может быть много тасков и у каждого таска может быть много комментариев и каждый комментарий также может иметь много реплаев (получается дерево комментариев) и соотвественно каждую сущность можно создать, отредактировать или удалить. С мобиксом как мы описали бизнес-сущности и связи one-to-many или many-to-many, так мы и и храним - объект юзера хранит массив объектов-папок, внутри папки будем хранить массив объектов-проектов, внутри проекта будем хранить массив объектов-тасков а в объекте таска будем хранить массив объектов комментариев и внутри каждого объекта комментария храним также массив других комменатриев-реплаев. Создавать редактировать или удалять сущности очень просто - для создания просто создаем объект и пушим в массив, для удаления делаем сплайс из массива для редактирования просто изменяем одно свойство и вот таким одинаковым образом работаем как с папками так с проектами так и с более глубокими сущностями И самое главное эти сущности могут быть связаны между собой что упрощает логику в обработчиках. Например когда рендерим таски в компоненте проекта <div>{project.tasks.map(task=><Task task={task}/>)}</div> то получив в компоненте Task через пропсы только нужный объект состояния (в данном случае task) часто бывает нужно обратиться к свойству какой-то родительской сущности например project (чтобы например проверить тип или какой-то свойство перед редактированием). И тут конечно можем выдумывать различные костыли передавая через пропсы также объект project и другие родительские сущности (а это может повлечь за собой изменение других родительских компонентов) а можем просто при создании таска добавить свойство project и записать в него ссылку на проект и обратится к свойству просто через task.project.someprop. В итоге взяв за правило при создании любой сущности записывать в свойство объекта ссылку на родительскую сущность можно очень удобно обращаться ко всему состоянию независимо от уровня вложенности например получив через пропсы комментарий можно обратится к папке в котором находится комментарий - comment.task.project.folder.name и это не потребует изменения всех вышестоящих компонентов. А теперь попробуйте ответить на вопрос как бы вы разрабатывали такое приложение используя редакс? Сколько редюсеров бы вам понадобилось? Как работали бы со связями one-to-many? Особенно интересует момент с добавлением и обновлением вложенных сущностей и особенно с деревом реплаев к таску и также интересен момент когда нужно обратится к родительским сущностям в компоненте получив через пропсы только свой объект.

так же как и в реляционных базах делаются связи, через поле, например с id

что-то подзаебал redux, кажется пора попробовать mobx

вокруг redux надо прыгать с бубном, чтобы он на каждый чих не вызывал функцию рендера

вокруг redux надо прыгать с бубном, чтобы он на каждый чих не вызывал функцию рендера

recompose жиесть.

рекомпоз нихера не может

Ой всё.

попробуйте продебажить а ну тупо пихать куда попало рекомпоз хелперы

Редукс... Бля

Редуктор.

попробуйте продебажить а ну тупо пихать куда попало рекомпоз хелперы

Зачем дебажить?

И ваще я не понял предложение.

Редуктор.

Убивать

в рекомпоз еще такая вложенность, что пиздец покажется добрым словом когда увидишь цепочку вызовов в каком-нибудь сложном контейнере, которого есть штук 200 на странице

это все компоненты и хреновы анмаунты когда начинаешь перемещаться между страницами/списками

попробуйте продебажить а ну тупо пихать куда попало рекомпоз хелперы

Ну, сунул в композицию withProps(console.log), если очень хочется.

Ну, сунул в композицию withProps(console.log), если очень хочется.

дебажь рендер

в рекомпоз еще такая вложенность, что пиздец покажется добрым словом когда увидишь цепочку вызовов в каком-нибудь сложном контейнере, которого есть штук 200 на странице

Это скоро пофиксят в реакт дев тулс.

это все компоненты и хреновы анмаунты когда начинаешь перемещаться между страницами/списками

Это ты про быстродействие?

Это ты про быстродействие?

да, это cost

иногда дешевле is-hidden убрать/добавить чем делать маунт/анмаунт

Пруф, что это существенно.

иногда дешевле is-hidden убрать/добавить чем делать маунт/анмаунт

Это всегда дешевле, чем операции с ДОМ.

это все компоненты и хреновы анмаунты когда начинаешь перемещаться между страницами/списками

позволь поинтересоваться, ты вот сегодня весь день про перфоманс говоришь, вы что там такого разрабатываете? правда интересно

в рекомпоз еще такая вложенность, что пиздец покажется добрым словом когда увидишь цепочку вызовов в каком-нибудь сложном контейнере, которого есть штук 200 на странице

Если контейнеров много на странице, то это дерьмо

Если контейнеров много на странице, то это дерьмо

Или много контейнеров, или компоненты, как дикообразы, утыканные пропсами.

позволь поинтересоваться, ты вот сегодня весь день про перфоманс говоришь, вы что там такого разрабатываете? правда интересно

котировки, меняющиеся каждые несколько секунд и длинные списки

котировки, меняющиеся каждые несколько секунд и длинные списки

Юзайте сишечку и васм, как в IQ Option.

Юзайте сишечку и васм, как в IQ Option.

не хайпово)

Или много контейнеров, или компоненты, как дикообразы, утыканные пропсами.

Значит у вас все плохо с проектированием

Или много контейнеров, или компоненты, как дикообразы, утыканные пропсами.

Я лучше буду юзать контейнеры.

котировки, меняющиеся каждые несколько секунд и длинные списки

несколько секунд это же много

Значит у вас все плохо с проектированием

Т.е. когда много данных — это плохо с проектированием?

Т.е. когда много данных — это плохо с проектированием?

Нет

Сова, ты стал слишком горазд на быстрые (дешёвые по перфомансу) умозаключения. Так мозги могут и подзастыть. =)

Когда куча пропс

Когда куча пропс

Придётся выбирать: либо куча пропсов, либо куча контейнеров.

Не, ну код-сплиттинг никто не отменял, но это же совсем про другое.

Придётся выбирать: либо куча пропсов, либо куча контейнеров.

Каждый компонент должен делать что-то одно

пропсов как можно меньше ставим, дело не в них, а в больших массивах данных

Каждый компонент должен делать что-то одно

Согласен. Например, Root компонент.

Согласен. Например, Root компонент.

А потом люди ноют что ридакс это плохо

А потом люди ноют что ридакс это плохо

Root не контейнер же.

У меня кнопка логаут может быть завёрнута в контейнер.