А еще приложение погоды! Где все можно было увидеть на одном экране, а теперь огромные карточки как для телевизора! Чтобы что-то посмотреть, нужно скролить и искать!
То есть изменение явно для того, чтобы увеличить время проведения в приложении.. пользователям оно нахер не упало
Не приходят, потому что есть еще понятие кодовой базы! Всякие UI либрари, взаимодействия с формами, стейт менеджерами, все это написано и работает в реакте. Поэтому просто отказаться в пользу голого HTML проблематично достаточно, потому что разработка будет явно замедлена!
Но есть же SSG! На выходе те же html страницы, такой же быстрый рендер! А под капотом тот же реакт со всеми плюшками. Так что я не понимаю в чем в принципе особая проблема..
Что это за правильный код ТС, где вы используете кастинг, возвращаете в match пустой массив, и чтобы это пофиксить следующей строкой дефолтите его на 0px..
А что если вместо браузера изобретут что-то, что позволит открывать прям бинарники например! Так если призадуматься браузер здесь, как костыль. Все равно взаимодействие с ним писать на JS. Но такую систему никто не придумал вместо браузеров. Так что эта технология будет там использоваться где она реально нужна… для дорогих расчетов! Хотя это не факт. Условная figma так написана, если я не путаю. И последнее время она тормозит, как любое веб приложение, и жрет памяти, как не в себя….
Ну хрен его знает! Раньше у вас было четкое разделение слоев логики и вью. В RQ это все намешано… Раньше вы вообще могли все в эпих редакс обсервабл описывать, например работы с фильтрами и т.д. там при помощи withLatestStore забирать данные и кидать запросы на сервер! Сейчас запросы будут кидаться из компонента, и в случае например с фильтрами вам придется тащить туда 100500 селекторов, чтобы сделать один запрос… И при этом от редакса вы никуда не уходите, вам все равно придется где-то это хранить.. например, вот фильтры те же. То есть как бы бойлер плейт не уменьшается, только для запросов на сервер и все.
И еще много много вопросов! По сути ради того, чтобы не писать лишних много строк вы решили мешать логику и вью ради кеширования и меньшего количества строк.. вот и все! Интересно будет посмотреть как вы FSD туда прикрутили, где есть сегмент модель, который как раз отвечает за логику..
Да, именно это я имею ввиду! Никто еще не додумался.. эффектор вот там farfetched написали и atomic-router, которые прям привязаны к effector! Но это все энтузиасты, а хотелось бы от самих разрабов…
То есть это свой урезанный mobx? С тем же публичным API. Вопрос: зачем?
Где сравнение, чем это удобнее, например effector, mobx, redux, reatom. Хоть что-то…
Хотя бы про производительность бы. Ну хотя б одно преимущество…
Почему я должен взять и перейти на это даже с хуков? Потому что это красивее пишется?
Про что вообще статья?
А еще предлагаю порассуждать об инфраструктуре вокруг стейт-менеджеров. Сам стейт менеджер написать не сложно, п вот какие-нибудь удобные библиотеки для него уже сложнее! Например, роутер, форм library, fetching? Потому что стейт менеджер в реакт должен решать только одну проблему: разделение логики и ui на разные слои! И как только мы все это выносим в стейт менеджер, мы сразу начинаем думать о формах, роутере и остальном, что взаимодействует с этим стейт менеджером.
Поэтому, раз тут про удобство! Было бы удобно, если бы был стейт менеджер, которыц покрывает весь спектр задач, а не только кусочек!
Как у вас микрофронтенды общаются друг с другом? Потому что на бумаге оно все хорошо, что логика независимая, но по факту она становится зависимой часто! Берем примеры!
У вас есть какой-нибудь баланс, который нужно обновить после того, как что-то произошло на странице в другом МФ.
У вас есть куча лендингов, которые классно выносятся в МФ. А потом приходит бизнес и говорит хотим интерактивную форму на одном лендинге такую же, как в каком-нибудь МФе, чтобы пользователь мог прям тут на лендинге что-то поискать. Что будем с этим делать?
И это ты сейчас попробовал. А год назад у них код комплишн вообще буквально не работал. Работал только после перехода на другую строку и ожидания 7 секунд! И за это они просят 100 баксов в год… я вообще их не понимаю
Я понимаю, что лодаш создает проблемы с тришейкингом, но писать свои утилиты это огромная проблема! Своя утилита должна обрабатывать все кейсы, которые разработчик вряд ли покроет. Это первое! А второе, типы, граждане вывод типов. Все ваши собственные утилиты никогда нормально не умели в сужение типов. Сколько я этого насмотрелся в проектах! Я не понимаю почему все резко стали против библиотек. Я использую ramda, и не вижу ничего плохого. Она полность тришейкабл и может отлично работать с типами.
А еще приложение погоды! Где все можно было увидеть на одном экране, а теперь огромные карточки как для телевизора! Чтобы что-то посмотреть, нужно скролить и искать!
То есть изменение явно для того, чтобы увеличить время проведения в приложении.. пользователям оно нахер не упало
Это только когда размеры точно определены
Не приходят, потому что есть еще понятие кодовой базы! Всякие UI либрари, взаимодействия с формами, стейт менеджерами, все это написано и работает в реакте. Поэтому просто отказаться в пользу голого HTML проблематично достаточно, потому что разработка будет явно замедлена!
Но есть же SSG! На выходе те же html страницы, такой же быстрый рендер! А под капотом тот же реакт со всеми плюшками. Так что я не понимаю в чем в принципе особая проблема..
Что это за правильный код ТС, где вы используете кастинг, возвращаете в match пустой массив, и чтобы это пофиксить следующей строкой дефолтите его на 0px..
Перед тем, как писать что ответила нейросеть, нужно сначала было промпт прикрепить… а то может ты там сформулировал с горе пополам свой запрос
Reatom еще есть и effector для тех кому интересно что-то новое пощупать
А что если вместо браузера изобретут что-то, что позволит открывать прям бинарники например! Так если призадуматься браузер здесь, как костыль. Все равно взаимодействие с ним писать на JS. Но такую систему никто не придумал вместо браузеров. Так что эта технология будет там использоваться где она реально нужна… для дорогих расчетов! Хотя это не факт. Условная figma так написана, если я не путаю. И последнее время она тормозит, как любое веб приложение, и жрет памяти, как не в себя….
Звучит, как реклама! А еще если это на массмаркет то почему здесь Formik и yup вместо hook form и zod?
все, как я понимаю нужно использовать в компоненте… события есть? aboutRouter.opened например..
А зачем вам SSR в закрытом под авторизацией личном кабинете?
А здесь у автора что? Не тоже самое ли?
И если уж на то пошло, это не просто структура папок, это слои с правилами взаимодействия друг с другом! Что еще в твоем понимании архитектура?
Ну хрен его знает! Раньше у вас было четкое разделение слоев логики и вью. В RQ это все намешано… Раньше вы вообще могли все в эпих редакс обсервабл описывать, например работы с фильтрами и т.д. там при помощи withLatestStore забирать данные и кидать запросы на сервер! Сейчас запросы будут кидаться из компонента, и в случае например с фильтрами вам придется тащить туда 100500 селекторов, чтобы сделать один запрос… И при этом от редакса вы никуда не уходите, вам все равно придется где-то это хранить.. например, вот фильтры те же. То есть как бы бойлер плейт не уменьшается, только для запросов на сервер и все.
И еще много много вопросов! По сути ради того, чтобы не писать лишних много строк вы решили мешать логику и вью ради кеширования и меньшего количества строк.. вот и все! Интересно будет посмотреть как вы FSD туда прикрутили, где есть сегмент модель, который как раз отвечает за логику..
Да, именно это я имею ввиду! Никто еще не додумался.. эффектор вот там farfetched написали и atomic-router, которые прям привязаны к effector! Но это все энтузиасты, а хотелось бы от самих разрабов…
То есть это свой урезанный mobx? С тем же публичным API. Вопрос: зачем?
Где сравнение, чем это удобнее, например effector, mobx, redux, reatom. Хоть что-то…
Хотя бы про производительность бы. Ну хотя б одно преимущество…
Почему я должен взять и перейти на это даже с хуков? Потому что это красивее пишется?
Про что вообще статья?
А еще предлагаю порассуждать об инфраструктуре вокруг стейт-менеджеров. Сам стейт менеджер написать не сложно, п вот какие-нибудь удобные библиотеки для него уже сложнее! Например, роутер, форм library, fetching? Потому что стейт менеджер в реакт должен решать только одну проблему: разделение логики и ui на разные слои! И как только мы все это выносим в стейт менеджер, мы сразу начинаем думать о формах, роутере и остальном, что взаимодействует с этим стейт менеджером.
Поэтому, раз тут про удобство! Было бы удобно, если бы был стейт менеджер, которыц покрывает весь спектр задач, а не только кусочек!
Мне нравится как веб ходит по кругу! Рендерим на сервере, потом на клиенте. Теперь снова на сервере 😀 очередной виток, который мы уже проходили!
Как у вас микрофронтенды общаются друг с другом? Потому что на бумаге оно все хорошо, что логика независимая, но по факту она становится зависимой часто! Берем примеры!
У вас есть какой-нибудь баланс, который нужно обновить после того, как что-то произошло на странице в другом МФ.
У вас есть куча лендингов, которые классно выносятся в МФ. А потом приходит бизнес и говорит хотим интерактивную форму на одном лендинге такую же, как в каком-нибудь МФе, чтобы пользователь мог прям тут на лендинге что-то поискать. Что будем с этим делать?
И это ты сейчас попробовал. А год назад у них код комплишн вообще буквально не работал. Работал только после перехода на другую строку и ожидания 7 секунд! И за это они просят 100 баксов в год… я вообще их не понимаю
О чем эта статья вообще? Где реальный сравнительный анализ. NextJs быстрее, чем SPA. Дайте нам метрики с LCP например.
Seo, seo, seo. Почему nextjs, а не prerender например, который решает вопросы seo? Слишком поверхностная статья
Я понимаю, что лодаш создает проблемы с тришейкингом, но писать свои утилиты это огромная проблема! Своя утилита должна обрабатывать все кейсы, которые разработчик вряд ли покроет. Это первое! А второе, типы, граждане вывод типов. Все ваши собственные утилиты никогда нормально не умели в сужение типов. Сколько я этого насмотрелся в проектах! Я не понимаю почему все резко стали против библиотек. Я использую ramda, и не вижу ничего плохого. Она полность тришейкабл и может отлично работать с типами.
А где rive в этом списке?