Если заменить сотни на десятки репозиториев, то у нас всё так и есть на работе, — банковский сектор.
Сотни репозиториев наберётся будет, если посчитать ещё другие проекты в компании, а не конкретно наш)
Есть состояние запросов - RTK, SWR и т.п. Есть состояние приложения - Redux, MobX и т.п.
Когда в проекте начинаются различаться эти вещи, избавиться от Redux и заменить его на React.useState, если ненадо шарить между компонентами запро с и React.Context или zustan (или другой stm) становится легче.
Раньше на проектах часто сваливави все состояния запросов в Redux и он становился ещё большей помойкой)
У меня по legacy такие мысли с точки зрения фронтендера. Любой код превращается в legacy c течением времени из-за развития проекта и изменение технологического стека / подходов к разработке. И нужно стремиться к уменьшению количества самого кода.
Пример развития проекта с работы. 1. NX Монорпеозиторий У нас было 3 хостовых приложения и 50 модулей (отдельные страницы) к ним в отдельных репозиториях. Мы приняли решение перейти на NX монорепозиторий и объединить модули и хосты. После объединения сразу появился лишний legacy код (в виде регистрации модулей и т.п.), который мы методично убрали. Ушли лишние webpack.config.js в модулях и т.п. Меньше файлов - меньше legacy.
2. Наш любимый React Redux Мы приняли решение отказаться от redux в пользу локальных State по возможности и заменой его на легковесный zustand и React Context. Каждый модуль уменьшился процентов на 30-50 legacy кода, который был из-за Redux boilerplate. Модули сами по себе остались legacy без изменения бизнес логики.
Не получится полностью избавится от legacy, но можно существенно сократить его объём.
А в итоге данные с сервера на клиент передаются в формате JSON и проходят JSON.parse()? Или с бэка на фронт тоже бинарные данные, как в последних разделах статьи? Смотрели в сторону других форматов передачи данных от серверка к клиенту? Возможно, это могло бы ещё сократить время обработки фронта
Недавно на комьюните общались на эту тему. Краткий вывод: в команде нужны разного уровня программистов, как идеальные, так и неидеальные. Они уровновешивают процессы друг друга и сохраняют баланс.
Конечно, если в команде 1 или 2 человека, то лучше, чтобы они были идеальными)
Делали лендинг на самых простых технологиях, которые хорошего индексировались и показывали отличные WebVitals. Они были
А сам личный кабинет и приложение были уже на субдомене, где индексация и СЕО не нужны, т.к. и так уже пришли через лендинг. Все оставались довольным
В статье расматревался вопрос от тимлида к веб-разработчику и вебсайт являлись для обоих источником доходов, а не всякой ерундой.
Не могу ответить на твой вопрос "Что дальше?", т.к. не понял кто ответил тимлиду. Вроде как по комменатрию явно не веб-разработчик. А может у нас разные тимлиды попадались
Спасибо. Это моя реальная история - мне такой вопрос (в чём проблема?) задалл тимлид и направил думать в этом русле. У нас на работе был следующий механизм "как его наказать" - кто накосячил, тот и должен исправить. Даже если уже прошло несколько релизов. Это было больно, но отрезвляюще
Если заменить сотни на десятки репозиториев, то у нас всё так и есть на работе, — банковский сектор.
Сотни репозиториев наберётся будет, если посчитать ещё другие проекты в компании, а не конкретно наш)
Есть состояние запросов - RTK, SWR и т.п.
Есть состояние приложения - Redux, MobX и т.п.
Когда в проекте начинаются различаться эти вещи, избавиться от Redux и заменить его на React.useState, если ненадо шарить между компонентами запро с и React.Context или zustan (или другой stm) становится легче.
Раньше на проектах часто сваливави все состояния запросов в Redux и он становился ещё большей помойкой)
p.s. не везде всё клали в Redux)
У меня по legacy такие мысли с точки зрения фронтендера.
Любой код превращается в legacy c течением времени из-за развития проекта и изменение технологического стека / подходов к разработке.
И нужно стремиться к уменьшению количества самого кода.
Пример развития проекта с работы.
1. NX Монорпеозиторий
У нас было 3 хостовых приложения и 50 модулей (отдельные страницы) к ним в отдельных репозиториях.
Мы приняли решение перейти на NX монорепозиторий и объединить модули и хосты.
После объединения сразу появился лишний legacy код (в виде регистрации модулей и т.п.), который мы методично убрали. Ушли лишние webpack.config.js в модулях и т.п. Меньше файлов - меньше legacy.
2. Наш любимый React Redux
Мы приняли решение отказаться от redux в пользу локальных State по возможности и заменой его на легковесный zustand и React Context.
Каждый модуль уменьшился процентов на 30-50 legacy кода, который был из-за Redux boilerplate.
Модули сами по себе остались legacy без изменения бизнес логики.
Не получится полностью избавится от legacy, но можно существенно сократить его объём.
Ещё сюда можно добавить Fediverse и Mastadon, которые хотят по своему повлиять на данную ситуацию.
https://www.youtube.com/watch?v=is_q7CFUdTI&list=PLeDR6lYFEHWGE-kI9ChrIaPsB0iPbQIVQ&ab_channel=Теплицасоциальныхтехнологий
Джуна из бутылки, хех
(никак, если это не ломает CI/CD)
А в итоге данные с сервера на клиент передаются в формате JSON и проходят JSON.parse()? Или с бэка на фронт тоже бинарные данные, как в последних разделах статьи?
Смотрели в сторону других форматов передачи данных от серверка к клиенту?
Возможно, это могло бы ещё сократить время обработки фронта
Сейчас можно создавать музыку / картинки через нейросети.
Видел видео, где китай уже делает визуальные новеллы через GPT.
Вот хочется, чтобы нейронка могла создавать "Квесты", "Карточки умений", "Оружие" и т.п. в рамках самой игры)
Хочу бесконечную игру-рогалик с использованием нейросетки)
С пет проектами похожая ситуация.
Вроде бы раньше хотел сделать все и сразу… И выгарал, пока доводил страницу/код до идеального состояния.
А теперь просто думаю, зачем что-то делать самому/своё, если можно взять готовое и накидать контента и получится то, что хотел.
Недавно на комьюните общались на эту тему.
Краткий вывод: в команде нужны разного уровня программистов, как идеальные, так и неидеальные. Они уровновешивают процессы друг друга и сохраняют баланс.
Конечно, если в команде 1 или 2 человека, то лучше, чтобы они были идеальными)
Перешли в компании на этот подход, избавились от develop. Стало проще делать релизы.
Наконец-то у TikTok появился достойный конкурент
Однажды дизайнер сам сделал лендинг на https://elementor.com/ и остался очень доволен своей работой)
А мы уже к нему прикрутили личный кабинет, хех
Вот ещё пару хороших:
https://codeium.com/vscode_tutorial - бесплатный чатгпт, хорошо справляется
https://marketplace.visualstudio.com/items?itemName=DominicVonk.parameter-hints - подсветка парметров. Мастхев для ФПников
Code Spell Checker + Russian - Code Spell Checker - проверка русской орфографии. В настройках переключить на Hints уровень, чтобы не надоедало
https://marketplace.visualstudio.com/items?itemName=oderwat.indent-rainbow - подсветка отступов
Да.
Делали лендинг на самых простых технологиях, которые хорошего индексировались и показывали отличные WebVitals. Они были
А сам личный кабинет и приложение были уже на субдомене, где индексация и СЕО не нужны, т.к. и так уже пришли через лендинг. Все оставались довольным
А, понятно.
Наверное, я просто в другой ситуации находился
Согласен, это из минусов одностраничников SPA, которую в идеале бы решить. Она частично была решена, но пока не на уровне Next.js.
Вроде у чистого React SPA есть похожие проблемы с индексацией
В статье расматревался вопрос от тимлида к веб-разработчику и вебсайт являлись для обоих источником доходов, а не всякой ерундой.
Не могу ответить на твой вопрос "Что дальше?", т.к. не понял кто ответил тимлиду. Вроде как по комменатрию явно не веб-разработчик.
А может у нас разные тимлиды попадались
Спасибо.
Это моя реальная история - мне такой вопрос (в чём проблема?) задалл тимлид и направил думать в этом русле.
У нас на работе был следующий механизм "как его наказать" - кто накосячил, тот и должен исправить. Даже если уже прошло несколько релизов.
Это было больно, но отрезвляюще