Хабр Курсы для фронтендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Фронтенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 28
Спасибо, что делитесь своими разработками:)
опять одна библиотека с одним маленьким решением
Это путь в никуда, нужна полноценная система где у разработчика не будет возможности сделать "плохой" или "неправильный" выбор
Желательно вообще не делать выбор, что бы в фреймворки это было уже настолько продумано, что бы внешнее решение не требовалось
Это путь в никуда
Нет. Это может быть путь в никуда именно для вас, а для настоящих разработчиков это путь вперед и вверх!
нужна полноценная система где у разработчика не будет возможности сделать "плохой" или "неправильный" выбор
Получается вы не можете(и не хотите) сделать шаг влево шаг вправо без указки начальника/хозяина/и т.п. Ну как бы к такой жизненной философии не надо людей привлекать, человечество не так давно от нее освободилось) Кто-то предпочитает свободу, а кто-то рабство. Я например отношусь к тем, кто принципиально предпочитает свободу.
Желательно вообще не делать выбор, что бы в фреймворки это было уже настолько продумано, что бы внешнее решение не требовалось
Мда, это конечно очень удручающе) Боюсь вы не ту профессию выбрали)
опять одна библиотека с одним маленьким решением
Так это прекрасно, одно маленькое, но качественное решение, чем большой уродливый монстр.
Все берут эти "хорошие маленькие решёния" а получают глючное приложение на реакте
странно от Go разработчика слышать хейт в сторону небольших библиотек
Все берут эти "хорошие маленькие решёния" а получают глючное приложение на реакте
Кто всё? 100% разработчиков? Или под "все" вы имеете ввиду только плохих разработчиков? Почему то у меня все прекрасно получается когда я беру хорошие маленькие решения и много у кого все прекрасно получается.
Большинство
На самом деле конечно чаще берут то что уже знают, это самая верная эвристика
Здорово что у вас получается, правда
Я аппелирую только не совсем к этому. Да из маленьких либ можно собрать хорошее приложение, но это сложнее как при постройке так и в поддержке, лучше когда флоу продуманы, cookbookи написаны
Но ещё лучше когда остаётся написать только бизнес логику, а всё остальное берёт на себя фрейморк, при этом никак не ограничивая закопаться вглубь
Чем "настоящий" разработчик отличается от "ненастоящего" ? Я вот код пишу, даже зачастую руками, я разработчик , по вашему ?
Незнаю что вы там навыдумывали про свободу какие то бредни
Хз реально чем вы кичетесь, не понимаю. Лучше конечно инструмент решает много задач, а не приходится под каждую задачу подбирать отдельный инструмент, особенно во фронтенде, так как это полностью формализованная область знаний
Чем "настоящий" разработчик отличается от "ненастоящего" ? Я вот код пишу, даже зачастую руками, я разработчик , по вашему ?
Настоящий - не тот, кто пишет код руками, а тот кто любит это делать, любит разбираться досконально всё устроено, как всё работает и т.п. И т.к. априори настоящий разработчик уже знает что и как устроено и что и как работает, то понятное дело он хочет делать все максимально удобно для себя, без ограничений и т.п. Потому что он знает, как сделать лучше. И если его не устраивает монструозный фреймворк all-in-one, то это не потому что разработчик плохой, а потому что фреймворк плохой.
Незнаю что вы там навыдумывали про свободу какие то бредни
Это не выдумки, вы прямо говорите что свобода плохо, надо зажимать в тиски разработчика что нельзя было ступить шаг влево шаг вправо.
под каждую задачу подбирать отдельный инструмент
У меня основа Typescript + React + MobX, все остальные задачи я решаю сам, и не подбираю под каждую задачу библиотеку, более того за много лет у меня давно есть решения почти на все случаи жизни) У меня и свой роутер которому уже лет 8 и инструменты для работы с формами/валидации, всякие хэлперы для асинхронного кода, плагины для Vite и т.д. и т.п.
если его не устраивает монструозный фреймворк all-in-one, то это не потому что разработчик плохой, а потому что фреймворк плохой.
Логически неверный аргумент
Про свободу. Где свободнее, в строго типизированных языках или динамических ? Где свободнее, в языках с прямым доступом к памяти или в языках где есть GC ?
Вся история программирования - про искусственные ограничения. Но при этом должна оставаться гибкость в использовании, как раз для решений разработчика.
За mobx like, хороший инструмент
Для себя я выбрал $mol, по скорости как mobx, только не нужно следить за состояниями, реактивностью, он сам под капотом всё делает хорошо
Для себя я выбрал $mol
Это всё объясняет))))
Вся история программирования - про искусственные ограничения. Но при этом должна оставаться гибкость в использовании, как раз для решений разработчика.
Да?)) Понятно) Нужно чтобы машина не разгонялась больше 20км/ч, но при этом нужно чтобы она разгонялась до 300км/ч)
вы считаете что языки с динамической типизацией лучше чем со статической ? врядли, вы используете typescript
но по вашему типы - это же ограничение, почему не избавитесь от него ?
давайте по существу, без пространных аналогий ( которые не работают )
вы считаете что языки с динамической типизацией лучше чем со статической ?
Всё хорошо в меру, TS меня более чем устраивает)
но по вашему типы - это же ограничение, почему не избавитесь от него ?
В Typescript это опциональное ограничение и это ключевой фактор. И мне в 95% случаев типизация ничем не мешает и не ограничивает. А для всего остального есть any)
опциональное ограничение
ура, мы пришли к общему знаменателю, я говорю ровно о том же самом
ограничения + гибкость
ура, мы пришли к общему знаменателю, я говорю ровно о том же самомограничения + гибкость
Однако вот ваши слова:
Это путь в никуда, нужна полноценная система где у разработчика не будет возможности сделать "плохой" или "неправильный" выбор
Желательно вообще не делать выбор, что бы в фреймворки это было уже настолько продумано, что бы внешнее решение не требовалось
Т.е. гибкости не должно быть согласно им)
Вот есть в фреймворке Х дерьмовый стейт менеджмет - пользуйся, он же уже есть, да он работает, но он просто дерьмовый, но это никого не волнует, он же уже есть и выбирать не надо и даже думать об этом не надо. И т.д. и т.п.
А это уже не похоже на ограничения + гибкость, это исключительно ограничения)
Выбор из хороших решений же есть...
В этом случае нужно фрейморк менять. Фронтенд полностью формализованная область, можно взять лучшее в своём классе и не задумывать о внутренностях
Выбор из хороших решений же есть...
Не существует ни одного фреймворка в мире в котором есть решения на все случаи жизни и при этом все они классные, работают быстро, код писать приятно и т.п.
В этом случае нужно фрейморк менять
Или лучше собрать свой из кирпичиков, которые тебя устраивают, а те что не устраивают реализовать самому)
Свой будет хуже продуманного
Frontend - это почти полностью формализованная область, то есть описанная с понятными задачами. Если упростить то это задача отобразить интерфейс с данными, и не глючит.
В этом плане $mol как раз очень близко к идеалу. В нём, в большинстве случаев, вам не нужны внешние библиотеки, всё продумано заранее.
Рендеринг полностью виртуальный, для любого компонента.
Что бы любое приложение сделать offline first - нужна 1 строка кода.
Кода получается меньше чем на других фрейморках, и он стабильнее, так как приведен к синхронному поведению. Даже fetch
Локализация из коробки
DSL для описания интерфейса вместо убого html, который даёт те плюсы что я выше описал ( кроме офлайна )
Темизация продума сразу. Отступы в интерфейсе. Адаптивность под все экраны.
Это даже не упоминая гипер базу , которая позволяет писать такие приложения без бекенда но с поведением как с бэком, с авторизацией, шифрованием по дефолту, на crdt ( бесконфликтных типах данных )
Свой будет хуже продуманного
Ясно понятно) В вашем случае может быть, в остальных зависит от уровня. В моём случае свой всегда будет лучше "продуманного", потому что я знаю как именно устроены те или иные вещи и как именно я хочу чтобы они работали и как должен в итоге выглядеть код.
В этом плане $mol как раз очень близко к идеалу.
:D :D
Это, конечно, решает частную боль автора этой либы, но их всегда будут писать, как минимум по той причине, что что-то большое иногда происходить от чего-то маленького, так что в этом нет ничего плохого
"ведь к более качественному закрытому коду доступа нет"
Объясните пожалуйста, а чего это он более качественный?
Статистики именно по "качеству" нигде нет, исхожу только из личного опыта и открытой статистики. Например, в прошлом году на Гитхабе 81% коммитов были именно в приватных рабочих репо, и процессы там как правило строже - с ревью, тестами, постоянной production-доработкой и адаптацией к новым технологиям.
А в публичных репо большая часть - пет-проекты или библиотеки даже без базовых тестов / эксперименты, которые в проде никто и не использовал. Да и из оставшихся репо многие устарели или заброшены с много лет висящими issues, потому что OSS очень непросто монетизировать, а на энтузиазме далеко не уедешь. Поэтому мысль "ИИ в основном обучается на менее качественном коде, не готовом к продакшену и стабильной предсказательной генерации", думаю, валидна.
Конечно, есть OSS авторы с шикарными библиотеками, но как правило они их писали как раз для продакшена и после нескольких лет доработок и обкатки выложили в публичные репо. Есть и компании, у которых бизнес-модель построена на OSS и они могут нанимать большие команды, чтобы делать качественно. Но это капля в море
я только ближайший аналог знаю Nano Stores Router (да знаю подход другой, но там проще). В теории это намного лучше чем vue-router. Но поддерживать это будет больно из-за обилия адаптеров. Тут ведь не только на чистом vite делают, тут есть метафреймворки вроде nuxt/next/remix/astro. И под каждого нужен свой адаптер. Хорошо если подхватит комьюнити, но я не думаю. Кстати я не нашел как использовать metadata и локализацию
Метафреймворки на то и есть, чтобы под них не писали адаптеры, а вся экосистема была "из коробки" - туда независимым разработчикам очень сложно интегрироваться, да и не нужно.
По поводу metadata (title, description, social теги) - это хотя и можно сделать через роутер (внутри beforeEnter), лучше все-таки использовать компоненты страниц. То есть проставлять их при рендере на onMount или другими способами конкретной UI-библиотеки, так сохранится поддержка SSR и MPA.
Под локализацией не понял, что имеется в виду, так как есть разные схемы. Например, заводят поддомены вида lang.mydomain , тогда в конфигурации роутера никаких изменений делать не нужно. Либо если через params - можно к каждому path добавлять параметр /:lang/home , либо через query: { lang: (v) => ['en', 'ru'].includes(v) } . Я бы рекомендовал вариант с поддоменами - поисковики с этим лучше работают, да и код не нужно подстраивать.
Вопрос такой, что произойдет в случае, если мы предотвратим навигацию, когда источник ее изменения будет popstate. Как я понимаю будет рассинхрон между url и состоянием роутера?
К сожалению или к счастью, сайты не могут блокировать браузерные кнопки вперед-назад и popstate соответственно) Поэтому нельзя “предотвратить переход, если нажал Назад в браузере”. Вот как сделано в роутере:
listener() {
void this.redirect({ ...this.urlToState(location.href), replace: true });
},
historySyncStart() {
win?.addEventListener('popstate', this.listener);
},То есть жмешь “Назад”, запускается стандартный redirect, то есть сработает beforeEnter соответствующего конфига. И в нем можно проверить - откуда пришел
dashboard: {
path: '/dashboard',
loader: () => import('./pages/dashboard'),
async beforeEnter({ redirect, currentState }) {
// Пользователь находился на странице авторизации,
// нажал кнопку "назад" и оказался на странице дашборда.
// запретить браузеру менять свой URL мы не можем,
// но можем явно проверить этот кейс и вернуть обратно на авторизацию
if (currentState?.name === 'login') {
return redirect(currentState);
}
}
}Рассинхрон будет в любом случае, каким бы роутером ни пользовались - браузер меняет URL (из js это не достать), посылает событие popstate (js это уже может поймать, вытянуть location.href и запустить цикл валидации и редиректов), затем в данном случае роутер заредиректит обратно. Но на состоянии приложения это не скажется - оно будет консистентным и источником правды для рендеринга.
Если говорить другими словами - каждая вкладка браузера это безопасный sandbox без root-доступа к API браузера из js. И popstate для роутера - полноценный заход на сайт как если бы было по прямой ссылке, но с доступом к предыдущему состоянию currentState, которое можно восстановить (эмуляция доступа к истории браузера).
Может быть я неправильно понял вопрос и не на то ответил - я говорил как “вернуть состояние назад” в beforeEnter, но возможно имелось в виду именно предотвращение в beforeLeave. Это пока не стабилизированный функционал, к сожалению:
браузер поменял URL, вызвался redirect+lifecycle
beforeLeave говорит preventRedirect(), state остается старым, URL в браузере - новым (что неправильно)
Сделаю доработку в библиотеке и добавлю тестов на эти кейсы, чтобы URL менялся обратно, вроде такого механизма
if (reason === ‘unmodified’) {
if (source === ‘popstate’ && actualUrl !== currentUrl) {
win?.history.replaceState(null, ‘’, currentUrl);
}
}Подумаю над этим. Довольно мало внимания уделил синхронизации с браузерными асинхронными переходами, больше стабильности состояния и пайплайну мульти-редиректов. Причем в коммерческих версиях роутера это было, сам не знаю зачем удалил)
P.S. Скорее всего из-за ограниченного доступа к History браузера - что нет полной манипуляции стеком истории, а только push в конец и replace текущего. Поэтому стабильного preventRedirect с "пост-фактум popstate" не получалось, и оставил половинчатое решение на будущее.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Reactive Route — новый роутер для разных фреймворков и реактивных систем в 2 КБ