Ещё будем рады, если портируешь реализацию на фреймворк $mol - это много времени не займёт. Дизайн сохранится твоим ) Мы с радостью поможем это сделать, дадим обратную связь, поделимся экспертизой и побудем тестирами) Поможем сделать приложение гиппер эффективным во всех смыслах
Хороший пет проект - unix way. Есть пару предложений, которые сделают сайт лучше. В погоне за красивым дизайном, забывается об эффективности приложение. Цель - сократить кол-во пустых действий 1. Поле ввода сразу открыто 2. Отправлять поиск сразу при вводе слова (убрать enter). Можно добавить debounce 1 сек 3. Не скрывать строку поиска после ввода текста 4. Добавить в url значение слова. Так можно будет скинуть ссылку и сохранится поле ввода.
По оптимизациям: - svg не оптимизированы, можно уменьшить размер ~ в 2 раза
Работа оффлайн: Сколько весит сейчас словарик? Если до 10-20 мб, то можно её 1 раз скачать и сохранить в localStorage и сайт (как и приложение) сможет работать полностью офлайн. А чтобы не тратить серверные ресурсы, можно её сохранить на github в виде файлика json. 0 затрат - 100% профит
Термин "Финансовая подушка безопасности" разбивается об скалы реальности.
Взял на днях ипотеку в новостройке в черновом ремонте.
1млн первоначальный взнос + оставшиеся деньги на ремонт.
Как верно заметили в комментариях ниже.
Если ты уйдешь с аккредитованной компании, то будет очень плохо.
Хорошо, когда пет проект имеет законченную форму. Лучше выпустить без "кучи" фич, поставить точку и двигаться дальше, чем взяться за 10 проектов и перегареть на каждом. Делайте маленькие пет проекты)
Если заменить сотни на десятки репозиториев, то у нас всё так и есть на работе, — банковский сектор.
Сотни репозиториев наберётся будет, если посчитать ещё другие проекты в компании, а не конкретно наш)
Есть состояние запросов - 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.
Можно посмотреть тут: https://lyumih.github.io/hyper/
Исходники: https://github.com/Lyumih/hyper
Как будет готово, создам следующую статью
В статье на мой взгляд не хватает иллюстраций к пунктам и плохая / хорошая реализация с примером.
Ещё будем рады, если портируешь реализацию на фреймворк $mol - это много времени не займёт. Дизайн сохранится твоим )
Мы с радостью поможем это сделать, дадим обратную связь, поделимся экспертизой и побудем тестирами)
Поможем сделать приложение гиппер эффективным во всех смыслах
Хороший пет проект - unix way.
Есть пару предложений, которые сделают сайт лучше.
В погоне за красивым дизайном, забывается об эффективности приложение.
Цель - сократить кол-во пустых действий
1. Поле ввода сразу открыто
2. Отправлять поиск сразу при вводе слова (убрать enter). Можно добавить debounce 1 сек
3. Не скрывать строку поиска после ввода текста
4. Добавить в url значение слова. Так можно будет скинуть ссылку и сохранится поле ввода.
По оптимизациям:
- svg не оптимизированы, можно уменьшить размер ~ в 2 раза
Работа оффлайн:
Сколько весит сейчас словарик?
Если до 10-20 мб, то можно её 1 раз скачать и сохранить в localStorage и сайт (как и приложение) сможет работать полностью офлайн.
А чтобы не тратить серверные ресурсы, можно её сохранить на github в виде файлика json. 0 затрат - 100% профит
Ответ - онлайн
А потом через пару лет статья: "Turbo 12 переписали на TypeScript"
Термин "Финансовая подушка безопасности" разбивается об скалы реальности.
Взял на днях ипотеку в новостройке в черновом ремонте.
1млн первоначальный взнос + оставшиеся деньги на ремонт.
Как верно заметили в комментариях ниже.
Если ты уйдешь с аккредитованной компании, то будет очень плохо.
Супер!
У нас похожая ситуация с Material UI, но дизайнеры пока всё ещё норовят свою красивую кнопочку сделать)
Квартал без работы - впечатления на всю последующую жизнь.
Хорошо, когда пет проект имеет законченную форму.
Лучше выпустить без "кучи" фич, поставить точку и двигаться дальше, чем взяться за 10 проектов и перегареть на каждом.
Делайте маленькие пет проекты)
Если заменить сотни на десятки репозиториев, то у нас всё так и есть на работе, — банковский сектор.
Сотни репозиториев наберётся будет, если посчитать ещё другие проекты в компании, а не конкретно наш)
Есть состояние запросов - 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.
Вот хочется, чтобы нейронка могла создавать "Квесты", "Карточки умений", "Оружие" и т.п. в рамках самой игры)
Хочу бесконечную игру-рогалик с использованием нейросетки)
С пет проектами похожая ситуация.
Вроде бы раньше хотел сделать все и сразу… И выгарал, пока доводил страницу/код до идеального состояния.
А теперь просто думаю, зачем что-то делать самому/своё, если можно взять готовое и накидать контента и получится то, что хотел.