Comments 47
Redux-thunk хорошо справляется со своими задачами, нам его хватает.
Оказалось, что когда переводишь проект с одного фреймворка на другой, ты не просто переносишь код. Приходится анализировать и улучшать архитектуру приложения, выпрямлять логику, рефакторить.
Это всё не зависит от переносов между фреймворками. Разве что при переносе что-то просто таки придётся выпрямлять, в то время как без переносов оно может жить годами без модификаций (а может и не жить, если есть кому бороться за улучшение кода).
Не понимала, зачем изучать первый Angular, чтобы завтра забыть о нем и изучать второй. Не понимала, зачем менять jQuery.Ajax на Fetch, чтобы заменить потом Fetch на Axios.
И в силу вышесказанного, не понимать вот тут — это как раз нормально. Не надо изучать первый ангуляр, если переезд всё равно будет только на второй. С принципами ознакомиться — да, стоит. Изучать? Ну такое.
Переносы сами по себе имеют вполне выразимую стоимость (стоимость всех человеко-часов программистов, стоимость повторного QA, и так далее), и не всегда она как-то даже рядом стоит с выигрышами от улучшения кода, особенно с учётом того, что улучшение кода можно отлично проводить и без переносов.
Но когда потенциальные выигрыши таки значительны — там да, взяли и понесли.
Профессионалы — понятно, они целыми отделами заранее знают технологию. А с любителями вопрос «изучить, забыть, изучить снова» встает очень остро.
Расскажите, как быть?
но прям чувствую боль, когда пытаюсь понять, а чем же новым пользоваться, чтобы быстрее, лучше и без рефреша
Ну, добро пожаловать в наш мир. Чувствовать боль в таких случаях — это как раз нормально.
На моей практике вообще никогда не существовало ситуаций, когда можно было откинуться в кресле, ткнуть пальцем в технологию из некоего заготовленного списка максимально подходящих, и не поиметь проблем, сразу или же (еще больнее) потом.
Это уж не говоря про то, что еще и при самом составлении списка происходит огромное количество страданий.
Пока что максимально великое откровение, которое я тут знаю — это «Никто в мире не знает, как решать конкретно твои проблемы. Даже если они довольно типичные. А уж если нетипичные, то тем более». Поэтому без боли и необходимости думать самому по каждому конкретному случаю — не выходит.
ЗЫ: Ну а если сказать более практично, то с php+jquery можно нынче куда угодно двигаться. Можно уменьшать серверную часть. Можно съехать с jquery в сторону уменьшения императивности. Можно и не делать этого (мне, например, императивный js очень нравится, и от попыток присобачить туда декларативности побольше я всегда вижу больше проблем, чем пользы). Можно смотреть в направлении модульности — даже я бы сказал нужно, если вдруг вы пока этим не озадачивались. Модульность из js уже точно никуда не денется, возможно она будет не совсем такая, как нынешние RequireJS, CommonJS, итд, но какая-то подобная будет в любом случае. Можно смотреть на разделение функциональных стилей и look&feel — этого вообще до сих пор в мире никто не смог сделать так, чтоб всем понравилось (спасибо примитивности css). Короче, тысячи путей, и это помимо предложений «изучите фреймворк Х, авось вам понравится».
Ладно, вот тогда вопрос дня: какой фреймворк в первую очередь изучить человеку, который умеет в php+jquery, но хочет зарабатывать как все остальные фронтендеры, а не веками пилить сайт своего завода?
Если говорить про вотпрямщас, то это скорее всего будет один из троицы Vue, Angular2 (то есть 2+), React. Но важно понимать, что через годик эта троица может уже выглядеть как-то иначе, а через пару лет — почти наверняка.
— Слушай, это легко. Пиши весь код в TypeScript. Все модули, использующие Fetch компилируй в ES6, транспайль их с Babel с stage-3, и загружай с SystemJS. Если у тебя нет Fetch, используй polyfill, или Bluebird, Request или Axios, и обрабатывай промисы с await.
— У нас очень разные определения «легко».
Но да, в той статье всё хорошо написано. И, на самом деле, этот микс из фреймворков, пакетов, фич, и прочей лабуды — он не настолько страшен, как издалека кажется. Умных слов много, а принципов работы этого куда меньше. С некоторыми вещами можно разбираться и подольше, как с теми же модулями, но во многие — нет необходимости погружаться дальше одного предложения. То есть, например, «транспайлер — это то, что переделывает не работающий в браузере JS (или TS, не суть) в работающий». Всё. Научно там разжевывать можно долго, но это всё будет про шашечки, а не про ехать.
Тут критерии другие, если среднесрочная цель выйти на достойный уровень оплаты в веб-разработке. Прежде всего анализ требований рынка, как по уровню оплаты на позициях типа миддл/регуляр, так и количеству вакансий. Ну и сравнение своих актуальных знаний и навыков с требуемыми. Сначала просто по «чек-листу» вакансии, потом с помощью попыток прохождения собеседований по всем более-менее адекватным вакансиям с активным требованием фидбэка в случае отказа.
Навсидку на вашем месте я бы смотрел в сторону Angular или Vue на фронте и Laravel на бэке (сам по дефолту выберу React+MobX и Symfony :) ). И вообще определился бы, что интересней, фронт или бэк, и основные усилия прилагать к выбранному пока до полноценного миддла не дорастёте. А уж потом смотреть интересно ли становиться фулстэк разработчиком или нет.
Главным критерием, по-моему, для люителей должна быть простота и скорость разработки, за милисекундами отклика или рендеринга вам, по-моему, смысла нет гнаться, если оптимизация сама по себе вам удовольствия не доставляет.
Ну и хорошо бы проанализировать что вы чаще делаете — пишите что-то новое, реализуете какие-то идеи типа «а не запилить ли мне...» или изменяете существующее, реализуете идеи типа «вот я это уже сделал, а теперь вижу, что это можно по другому и спать теперь не могу». Вряд ли вы найдёте стэк, который удовлетворят обеим подребностям, одинаково хорошо подходящий для быстрой разработки или прототипирования идей (RAD есть такой термин) и для долгосрочной поддержки с постоянными изменениями (ближе к «кровавому ентерпрайзу»)
Не думаю, что вам нужно фокусироваться на таких критериях как скорость работы стэка или время сборки — всё сколь-нибудь популярное имеет приемлимые метрики.
В начале статьи думал, что будет история про react-bem-core :)
Спасибо.
З.ы. Не придираюсь, но почему "реактивный фронтенд"? От слова React?
React не имеет никакого отношения к реактивному программированию. Название статьи вводит в заблуждение, потому что ни о каком РП в статье речи не идет.
Реактивное программирование можно довольно скромными усилиями хоть на голом JS поднять. Означает ли это, что JS имеет «кое-какое» отношение к реактивному программированию? Нет.
С такой логикой любой коллбек можно реактивным назвать.
&__toggler{
...
}
можно привыкнуть и даже чтобы было удобно?И это ещё простой селектор.
У вас в мобильной версии адово тормозит анимация выезжающего слева меню. В этом же меню некомфортно мелкие невидимые области в которые надо попасть чтобы перейти по ссылке. На странице создания кошелька нельзя вернуться назад.
На главной бэкграунд с теткой неприятно дёргается в конце анимации выезжания текста. Там же, чтобы проявился текст после «Кошелек защищает покупателя» надо очень сильно проскроллить страницу вниз, наблюдая до трёх четвертей экрана белой пустоты.
Кнопки «других способов пополнения» со страницы пополнения кошелька ведут на десктопную версию сайта (всего два клика с главной и упс, мобильная версия кончилась).
Я провёо всего 5 минут на вашем сайте и абсолютно не являюсь профессиональным тестировщиком и проигнорировал проблемы вёрстки.
Как так происходит? Грош цена всем этим БЭМам если на выходе сайт, создающий впечатление кривой поделки.
Дело не конкретно в вас, весь веб сейчас такой. Просто вы тут пытаетесь учить других как делать его хорошо и правильно, но то что вы делаете не хорошо и не правильно.
У вас в мобильной версии
Ну вы уже должны были сами всё понять.
Мобильная версия сама по себе не взлетит. Не взлетит она и с реактами-редуксами и прочими умными словами. Мобильная версия — это по прежнему такое особое чудо, которое надо допиливать и тестировать отдельно.
И не смотря на всё это — это лучше, чем было раньше, когда мобиловерсия сайта сжирала столько же, или даже больше сил, чем обычная.
У меня например, 100% сайтов, на которых есть эффекты при прокрутке страницы, дергаются и притормаживают, а если не притормаживают, то анимации смотрятся как-то неестественно и отвлекают внимание.
Я кстати крайне не люблю эти анимации. Белая страница с сухой таблицей с аккуратно подобранными отступами и шрифтами в 10 раз лучше всех этих гигантских современных блоков с 40-пиксельными шрифтами.
Правда тётка уже не дергается.
При переходах в левом меню на «Как собирать деньги» и обратно в этом самом меню колбасит шрифт. Как, почему??? Почему именно эта страница? Что такого надо было нареактить вместо «просто указать шрифт текста» чтобы это происходило?
Страница «Оплата->Налоги». Сначала загружается всё, потом с паузой до секунды догружается поле ИНН. Да, яндекс, вы клёвые, вы умеете апдейтить на ходу куски страницы. Но начерта это здесь? Кому нахрен сдалась форма в её промежуточном виде, без единственного значимого поля?
В «Помощи» попадаешь в другую вселенную.
Со страницы создания кошелька опять почти никуда не выбраться.
Ищо:
cloud.mail.ru/public/NHvF/CKqVQcwx1
cloud.mail.ru/public/FBV1/naXJFFYm8
Десерт: cloud.mail.ru/public/EnWQ/c4b2LPTUp
P.S. Хабр, гори в аду. Мискликнул в кнопку «написать комментарий» внизу страницы и весь набранный текст пропал.
P.P.S. Повторю, сайт ЯД не как-то особенно плох на фоне других сайтов. И вообще я потенциально не являюсь целевой аудиторией и мои претензии можно проигнорировать.
Насчет «уровней переопределения» — по моему, тут есть риск, что два уровня могут переопределять одно и то же свойство (или задействовать один и тот же псевдоэлемент) или конфликтующие друг с другом свойства (один уровень ставит overflow: hidden, а другой добавляет выходящий наружу элемент).
Также, по моему, это выглядит довольно странно:
tag()('button')
Так как непонятно, почему не просто tag('button') (подозреваю, там какая-то магия, но все равно выглядит странно).
Функции в такой записи, на мой взгляд, плохо читаются:
export const addPhone = (params) => () => axios.что-то.там
Больше напоминает результат обфускации. По моему, так export function xyz() было бы куда читабельнее.
Когда вы разрываете куски названий классов
.title {
&__toggler {
То они перестают искаться. То есть, если в таком коде сделать поиск по title__toggler, то ничего не найдется. Это, по моему, минус.
Оно лежит в понятных местах на ФС и в полнотекстовом поиске по всему проекту нет необходимости.
Также, по моему, это выглядит довольно странно:
tag()('button')
Тело шаблона — это отдельный вызов функции, которая ожидает аргумент.
Можно использовать сокращенный синтаксис, который выглядит привычнее:
block('link')({ tag: 'button' });
Посмотрите пример
Правда, по правилам БЭМ, придется разнести его аж по трем директориям
Не обязательно, этот код может быть записан в файле блока.
никто не читает теги
Вот зачем вы это пикабу сюда приносите?
А еще мы провели эксперимент — внедрили в одно из приложений диспетчер процессов, который упростил администрирование сервисов на Node.js. Он помог с кластеризацией, а еще избавил нас от одного старого bash-скрипта, который запускал приложения.
Хм… учитывая ваши масштабы, наверно вам нужно смотреть на n|solid platform (у него есть сертифицированные модули) или pm2.
Рассматривали ли MobX вместо Redux?
Спасибо, но тем, кто постит код картинками, готовят отдельный котёл в аду.
Попробуйте может объяснить, я даже готов понять.
Но мы не раскатываем на внешних пользователей код на Koa2: у фреймворка нет достаточной поддержки, зато есть открытые уязвимости.
- Какие уязвимости не позволили koa2 использовать в prod?
- Пробовали ли вы внести свой вклад в koa2?
Styled-components, я люблю тебя! СSS in JS – one love! Мой внутренний верстальщик ликует:
- Как решаете вопрос с поддержкой подсветки?
- Как с читаемостью когда CSS кода нужно много в JS?
2. При адекватном форматировании код легко читается, а много кода это повод разбить его на несколько компонент. Мы не испытываем проблем с читаемостью.
зачем байндить метод в рендере? Вы же в компонент Form будете передавать каждый раз новую ф-цию. Почему не сделать метод, как arrow function или не забайндить в конструкторе? Или я чего-то не понимаю?
Екатерина ayocommon, благодарю за статью, историю и примеры.
Жаль, что все примеры кода оформлены картинками, когда есть встроенная подсветка в редакторе статьи.
Куда-то пропало transform rotateZ
после преобразования CSS в Styled-components:
transform: rotateZ(180deg);
В примере про BEM-XJST в этом куске пахнет плохо
attrs()(function() {
const {type} = this.ctx;
return {type};
})
На мой взгляд так дышать лучше и выглядит читабельные
attrs()(function() {
return { type: this.ctx.type };
})
Реактивный фронтенд. История о том, как мы снова всё переписали