а зачем запросы делать вверху по стеку когда каждый компонент может для себя самого доставать данные, таким образом образуя вместе с бэком единое целое, и таким образом устраняя проблему собирания запроса вообще?
@@yahorsinkevich4451 это не очень удобно, когда компонентам надо заниматься транспортом данных: Компоненты становятся от этого сложнее. Компоненты должны зависеть только от состояния, а вот уже приложение должно заботиться о транспорте. Так, например, если разным компонентам нужны одни и те же данные, при этом друг о друге эти компоненты знать ничего не должны, то обоим компонентам достаточно просто читать данные из состояния, не заботясь о том, как они туда попали. Или второй пример, данные нужны разные, но они могут быть получены от сервера одним запросом, приложение может объединить подзапросы в один. Это может быть гораздо эффективнее, чем посылать два отдельных запроса (особенно если нужны просто разные наборы данных об одной сущности)
@@dimitro.cardellini не вижу в чём неудобно, с моей точки зрения всё ровно наабарот. Компонент становится полностью изолированным, его максимально просто использовать
@@yahorsinkevich4451 пока такой "Умный компонент" один и используется в одном проекте, то да -- все проще. Но, как только возникает второй компонент, которому нужны те же данные, то сразу возникает вопрос: что делать с двумя запросами? И вот здесь надо вспомнить о concern separation принципе. Есть еще важный кейс -- это расширение приложения. Например, сначала у Вас был компонент, который показывает список, пусть будет, книжек. А потом бизнес говорит: а сделай так, чтобы если книжка у пользователя одна, то надо сразу сделать переход на страницу этой книжки. Ваш подход: дописать логику внутри компонента, но на самом деле -- это плохо. Зачем нам трогать компонент со списком книжек -- у нас ведь ничего не меняется в способе их отображения. А меняется логика самого приложения. И вот, здесь Ваш подход серьезно все осложняет. Никто кроме умного компонента "Список Книг" ничего об этом списке не знает, вот и придется: 1) либо выносить логику на уровень выше, 2) либо менять сам компонент. С п. 2) будут другие проблемы -- сам компонент сможет принять решение о том, надо себя рендерить или нет, а вот что делать с соседними элементами. Пока "Список Книг" будет грузить свои данные и показывать какой-нибудь спиннер, соседние уже отрендеряться. В итоге, вместо плавной смены урла в адресной строке у нас будет "блинкать" интерфейс -- вряд ли это то, что заказывал бизнес. Так, что, ... SOLID Вам в помощь.
Отличный доклад. Единственное, я не соглашусь с замечанием по Редаксу. Да -- редакс "многословный", много писать надо. Это красивый идеоматический подход к управлению состоянием, который обязательно надо освоить (на самом деле нечто в роде редакса лежит в ядре большинства функциональных языков программирования, которые работают с иммутабельными данными (т.е. там нет возможности работать с состоянием, кроме как передать обновленное состояние ядру языка). Вот пример: codesandbox.io/s/redux-counter-phvwv (там нет кучи редакс-файлов. один домен -- один файл). Просто в отличие от других библиотек, Дэн Абрамов показал, что внутри, без использования магических оберток. Вероятно, это стало ошибкой судя по тому, что привело к большому числу проектов, которые жестко следовали туториалу и клепали action-types.js, actions.js, reducers.js, middlewares.js централизованно на уровне проекта.
По поводу волосатости, ради справидливости надо уточнить что по сути что произошло - запросы к по сути базе данных переехали на фронт, нельзя сказать что это решило кучу проблемм фронтендера если у него был хороший апи
@Gonza это никак не связано с производительностью вообще, опять же если апи был нормальный, а учитывая HTTP2 и мультиплексирование так и вообще становится под вопрос
@Gonza Почитайте про OData, там один эндпоинт. Да и с большим количеством эндпоинтов проблем никаких нету. Клиент просто весь генерируется из сваггер спецификации и ты забываешь про урлы и эндпоинты
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
Презентация: nodkz.github.io/conf-talks/talks/2019.05.24-holyjs-piter/index.html#/
Apollo: github.com/nodkz/example-fragments-apollo
Relay: github.com/nodkz/example-fragments-relay
а зачем запросы делать вверху по стеку когда каждый компонент может для себя самого доставать данные, таким образом образуя вместе с бэком единое целое, и таким образом устраняя проблему собирания запроса вообще?
@@yahorsinkevich4451 это не очень удобно, когда компонентам надо заниматься транспортом данных: Компоненты становятся от этого сложнее.
Компоненты должны зависеть только от состояния, а вот уже приложение должно заботиться о транспорте.
Так, например, если разным компонентам нужны одни и те же данные, при этом друг о друге эти компоненты знать ничего не должны, то обоим компонентам достаточно просто читать данные из состояния, не заботясь о том, как они туда попали.
Или второй пример, данные нужны разные, но они могут быть получены от сервера одним запросом, приложение может объединить подзапросы в один. Это может быть гораздо эффективнее, чем посылать два отдельных запроса (особенно если нужны просто разные наборы данных об одной сущности)
@@dimitro.cardellini не вижу в чём неудобно, с моей точки зрения всё ровно наабарот. Компонент становится полностью изолированным, его максимально просто использовать
@@yahorsinkevich4451 пока такой "Умный компонент" один и используется в одном проекте, то да -- все проще. Но, как только возникает второй компонент, которому нужны те же данные, то сразу возникает вопрос: что делать с двумя запросами?
И вот здесь надо вспомнить о concern separation принципе.
Есть еще важный кейс -- это расширение приложения. Например, сначала у Вас был компонент, который показывает список, пусть будет, книжек. А потом бизнес говорит: а сделай так, чтобы если книжка у пользователя одна, то надо сразу сделать переход на страницу этой книжки.
Ваш подход: дописать логику внутри компонента, но на самом деле -- это плохо. Зачем нам трогать компонент со списком книжек -- у нас ведь ничего не меняется в способе их отображения. А меняется логика самого приложения.
И вот, здесь Ваш подход серьезно все осложняет. Никто кроме умного компонента "Список Книг" ничего об этом списке не знает, вот и придется: 1) либо выносить логику на уровень выше, 2) либо менять сам компонент.
С п. 2) будут другие проблемы -- сам компонент сможет принять решение о том, надо себя рендерить или нет, а вот что делать с соседними элементами. Пока "Список Книг" будет грузить свои данные и показывать какой-нибудь спиннер, соседние уже отрендеряться. В итоге, вместо плавной смены урла в адресной строке у нас будет "блинкать" интерфейс -- вряд ли это то, что заказывал бизнес.
Так, что, ... SOLID Вам в помощь.
Очень хорошая лекция. Разве что не хватает ссылок из презентации.
Класс, как раз Relay в проде буду делать
Дико крутая презентация. Спасибо!
Отличный доклад.
Единственное, я не соглашусь с замечанием по Редаксу.
Да -- редакс "многословный", много писать надо. Это красивый идеоматический подход к управлению состоянием, который обязательно надо освоить (на самом деле нечто в роде редакса лежит в ядре большинства функциональных языков программирования, которые работают с иммутабельными данными (т.е. там нет возможности работать с состоянием, кроме как передать обновленное состояние ядру языка).
Вот пример: codesandbox.io/s/redux-counter-phvwv (там нет кучи редакс-файлов. один домен -- один файл). Просто в отличие от других библиотек, Дэн Абрамов показал, что внутри, без использования магических оберток. Вероятно, это стало ошибкой судя по тому, что привело к большому числу проектов, которые жестко следовали туториалу и клепали action-types.js, actions.js, reducers.js, middlewares.js централизованно на уровне проекта.
Очень крутой доклад
По поводу волосатости, ради справидливости надо уточнить что по сути что произошло - запросы к по сути базе данных переехали на фронт, нельзя сказать что это решило кучу проблемм фронтендера если у него был хороший апи
@Gonza это никак не связано с производительностью вообще, опять же если апи был нормальный, а учитывая HTTP2 и мультиплексирование так и вообще становится под вопрос
@Gonza А что мешает сделать это в рест? В запросе указать что именно возвращать? Посмотри OData - это рест протокол в котором решены эти проблемы
@Gonza Почитайте про OData, там один эндпоинт. Да и с большим количеством эндпоинтов проблем никаких нету. Клиент просто весь генерируется из сваггер спецификации и ты забываешь про урлы и эндпоинты
огонь!
Первые пять минут думал , а почему о апалло не говорит