Если через 5 лет вы еще останетесь во frontend - разработке, придите, и перечитайте свой комментарий.
и хендлингом кеша!
Шта???) Вы о чём вообще?)
Именно так. Недостаточно просто получить данные, и надеяться, что этого достаточно.
Что будет, если 2 компонента вызовут fetch?
Что будет, если компонент часто монтируется? Каждый раз дергать fetch?
Как выполнять оптимистичное обновления стейта (например при сабмите формы) и отменять его при ошибке запроса?
Как инвалидировать данные, если пользователь долго не меняет стейт приложения (долго держит вкладку открытой)?
Как делать повторную попытку запроса, если произошла ошибка?
Как обрабатывать ошибки? А как обрабатывать ошибки при инвалидации данных?
Как отменять запрос (`AbortController`), если компонент размонтировался, или просто хочется сделать это глобально?
Если ваш механизм получения данных не покрывает хотя бы один из этих пунктов, то ваше приложение не отвечает современным требованиям по работе с данными, и не пройдет ни одну техническую экспертизу.
В тоже самое время, куда больший функционал покрывает Tanstack Query или SWR - оба с безупречной репутацией и многолетней поддержкой.
Но я к $mol отношусь нормально. Не вижу проблем в инструменте, который решает проблему и приносит деньги. Совсем другой вопрос в другом - стоит ли продолжать инвестировать собственное время в инструмент, который так и не получил широкого распространения.
Пожалуй, для новых проектов сейчас идет выбор следующего порядка: HTMX или React/NG/Vue. В этом ряду нет ни Svelte, ни Solid и прочих крутых быстрых фреймворков. Когда действительно нужна скорость и легковесность, то лучше сразу делать на HTMX. Компании с приличной экспертизой не выберут промежуточное решение - либо полный хардкор, либо классический SPA на понятном стеке с миллионами разработчиков на рыке.
Я имел ввиду action из Remix. Next.js решает аналогичную задачу иным путем - через onSubmit. Обработка форм через action позволит стандартизировать хендлинг форм и на клиенте, и на сервере.
Серьезно? Т.е. использовать встроенный в реакт стейт менеджмент это нормально? :D У меня для вас очень плохие новости.
Весь во внимании, какие такие плохие новости у вас есть для меня.
MobX - 17kb gzip это много
Я не упоминал о размере тех или иных библиотек. Будем честны - это последнее, что забодит, если речь идет о SPA.
противовес максимальному удобству и качеству для кода
Качество кода можно сохранять без использования MobX. MobX - ненужна, переусложненная абстракция, которая не дает ни одного явного преимущества в реальных React-приложениях.
Какой Redux? Какой MobX? Какой 2023э4 год? Оба инструмента не нужны в современном React, и больше вредят проектам, чем несут пользы.
MobX был от части способ реализовать быстрый рендеринг в React, и только поэтому получил хоть какое-то распространение. Сегодня он просто слишком большой и сложный по дизайну, чтобы тащить это чудо в новый проект.
Redux ужасен сам по себе, и просто делает разработку большого проекта - пыткой.
Был фанатом Некста много лет, но с появлением HTMX у меня теперь большие сомнения в целесообразности использования React для рендеринга страниц целиком. Свой будущий проект я бы предпочел делать на Astro + HTMX. Хотя HTMX подойдёт для любого бэка.
Мы столкнулись с аналогичными проблемами, при развитии своего продукта. Попытка расширить собственные компоненты, которые были написаны разными руками в разное время - оказалось бессмысленной. За месяц мигрировали все приложение на MUI. Все разногласия с дизайнерами заканчиваются там, где нет компонента из MUI для Figma. Любые кастомные контролы мы теперь просто реджектим.
Идея в том, что если разработчики, следуя строгим правилам того фреймворка, в котором работают могут двигать продукт, то почему дизайнеры не могут работать в оговоренных рамках? Почему разработчики должны обслуживать любое "opinioned meaning" дизайнеров, просто по их желанию? Если вы двигаете продукт, то ограничения - благо. Для всех.
Ничего не мешает. Общепринятые конвенции нужны для простоты онбординга новых разработчиков. Гораздо проще пояснить, что "используем Trunk-Based c Feature Toggles", и дать ссылки, чем пытаться придумать собственный подход и правильно его задокументировать.
Я не предлагаю вам просто использовать метод A или B, и не задавать вопросов. Наоборот, ищите тот флоу который больше подходит вашей команде.
master | main - не священная корова. Мы используем Trunk Based в рутинном режиме разработки, и переключаемся на Git Flow, когда работаем над разными версиями пакета одновременно.
Скажем так, если вы не знаете зачем все это нужно - значит у вас нет проблем, которые решают различные флоу. Возможно, вы интуитивно выбрали один из подходов, и даже сами об этом не догадываетесь.
Меня прямо иногда удивляет безапелляционность подобных заявлений.
Чем по вашему глобально отличается компонент реакта от любой другой функции? Я с таким же успехом могу и домены построить на компонентах, и бизнес логика там будет уместна.
Обычным бетоном никто не печатает, он не позволяет класть слой за слоем так, чтобы ничего не растекалось. Опять же, между стен засыпается теплоизоляция.
Если через 5 лет вы еще останетесь во frontend - разработке, придите, и перечитайте свой комментарий.
Именно так. Недостаточно просто получить данные, и надеяться, что этого достаточно.
Что будет, если 2 компонента вызовут fetch?
Что будет, если компонент часто монтируется? Каждый раз дергать fetch?
Как выполнять оптимистичное обновления стейта (например при сабмите формы) и отменять его при ошибке запроса?
Как инвалидировать данные, если пользователь долго не меняет стейт приложения (долго держит вкладку открытой)?
Как делать повторную попытку запроса, если произошла ошибка?
Как обрабатывать ошибки? А как обрабатывать ошибки при инвалидации данных?
Как отменять запрос (`AbortController`), если компонент размонтировался, или просто хочется сделать это глобально?
Если ваш механизм получения данных не покрывает хотя бы один из этих пунктов, то ваше приложение не отвечает современным требованиям по работе с данными, и не пройдет ни одну техническую экспертизу.
В тоже самое время, куда больший функционал покрывает Tanstack Query или SWR - оба с безупречной репутацией и многолетней поддержкой.
Такая ламповая статья, узнаю себя лет этак 10 назад. Хороший пример правильного использования backbone.
Удачи с дебагом и хендлингом кеша! Ваш код выглядит великолепно, и эффективно!
Да, подловил он меня в пылу, что тут скажешь.
Но я к $mol отношусь нормально. Не вижу проблем в инструменте, который решает проблему и приносит деньги. Совсем другой вопрос в другом - стоит ли продолжать инвестировать собственное время в инструмент, который так и не получил широкого распространения.
Пожалуй, для новых проектов сейчас идет выбор следующего порядка: HTMX или React/NG/Vue. В этом ряду нет ни Svelte, ни Solid и прочих крутых быстрых фреймворков. Когда действительно нужна скорость и легковесность, то лучше сразу делать на HTMX. Компании с приличной экспертизой не выберут промежуточное решение - либо полный хардкор, либо классический SPA на понятном стеке с миллионами разработчиков на рыке.
Я имел ввиду action из Remix. Next.js решает аналогичную задачу иным путем - через onSubmit. Обработка форм через
actionпозволит стандартизировать хендлинг форм и на клиенте, и на сервере.Позвольте я угадаю, что это за мифический инструмент? MobX?
Думаю как стандартизация конвенционального подхода. SSC фреймворк уже используют action.
Все 3 кейса ловятся элементарными линтерами. Вы же не самостоятельно за зависимостями в хуках следите.
Весь во внимании, какие такие плохие новости у вас есть для меня.
Я не упоминал о размере тех или иных библиотек. Будем честны - это последнее, что забодит, если речь идет о SPA.
Качество кода можно сохранять без использования MobX. MobX - ненужна, переусложненная абстракция, которая не дает ни одного явного преимущества в реальных React-приложениях.
В современном React принято использовать
useSyncExternalStore()иuseTransition(). Вам какие примеры нужны? Больших приложений без MobX и Redux?Какой Redux? Какой MobX? Какой 2023э4 год? Оба инструмента не нужны в современном React, и больше вредят проектам, чем несут пользы.
MobX был от части способ реализовать быстрый рендеринг в React, и только поэтому получил хоть какое-то распространение. Сегодня он просто слишком большой и сложный по дизайну, чтобы тащить это чудо в новый проект.
Redux ужасен сам по себе, и просто делает разработку большого проекта - пыткой.
Был фанатом Некста много лет, но с появлением HTMX у меня теперь большие сомнения в целесообразности использования React для рендеринга страниц целиком. Свой будущий проект я бы предпочел делать на Astro + HTMX. Хотя HTMX подойдёт для любого бэка.
Я бы тогда предложил вам выбрать GitHub Flow - простой и интуитивно понятный.
Как же я понимаю вас.
Мы столкнулись с аналогичными проблемами, при развитии своего продукта. Попытка расширить собственные компоненты, которые были написаны разными руками в разное время - оказалось бессмысленной. За месяц мигрировали все приложение на MUI. Все разногласия с дизайнерами заканчиваются там, где нет компонента из MUI для Figma. Любые кастомные контролы мы теперь просто реджектим.
Идея в том, что если разработчики, следуя строгим правилам того фреймворка, в котором работают могут двигать продукт, то почему дизайнеры не могут работать в оговоренных рамках? Почему разработчики должны обслуживать любое "opinioned meaning" дизайнеров, просто по их желанию? Если вы двигаете продукт, то ограничения - благо. Для всех.
Ничего не мешает. Общепринятые конвенции нужны для простоты онбординга новых разработчиков. Гораздо проще пояснить, что "используем Trunk-Based c Feature Toggles", и дать ссылки, чем пытаться придумать собственный подход и правильно его задокументировать.
Я не предлагаю вам просто использовать метод A или B, и не задавать вопросов. Наоборот, ищите тот флоу который больше подходит вашей команде.
master | main- не священная корова. Мы используем Trunk Based в рутинном режиме разработки, и переключаемся на Git Flow, когда работаем над разными версиями пакета одновременно.Скажем так, если вы не знаете зачем все это нужно - значит у вас нет проблем, которые решают различные флоу. Возможно, вы интуитивно выбрали один из подходов, и даже сами об этом не догадываетесь.
Я бы также посоветовал приглядеться к сервисам авторизации на вроде Clerk. Интеграция за 5 минут, админка в комплекте.
Меня прямо иногда удивляет безапелляционность подобных заявлений.
Чем по вашему глобально отличается компонент реакта от любой другой функции? Я с таким же успехом могу и домены построить на компонентах, и бизнес логика там будет уместна.
А до этого на TypeScript, ага.
Обычным бетоном никто не печатает, он не позволяет класть слой за слоем так, чтобы ничего не растекалось. Опять же, между стен засыпается теплоизоляция.