Комментарии 47
Что думаете насчет redux-thunk? Хватает ли вам его и не рассматриваете ли альтернативы для управления сайд-эффектами?
Мы рассматривали в качестве альтернативы redux-saga. Было рассмотрено множество критериев: тестирование, архитектура, поддержка, связность и другие. Счет плюсов и минусов по каждому критерию оказался равным. Выбрали thunk, потому что уже работали с ним, когда писали на react native. А saga — слишком мощный и более своеобразный инструмент.
Redux-thunk хорошо справляется со своими задачами, нам его хватает.
Redux-thunk хорошо справляется со своими задачами, нам его хватает.
Все жизненные истории по переходу с одной парадигмы кода на другую всегда такие одинаково-меланхолические :-)
Это всё не зависит от переносов между фреймворками. Разве что при переносе что-то просто таки придётся выпрямлять, в то время как без переносов оно может жить годами без модификаций (а может и не жить, если есть кому бороться за улучшение кода).
И в силу вышесказанного, не понимать вот тут — это как раз нормально. Не надо изучать первый ангуляр, если переезд всё равно будет только на второй. С принципами ознакомиться — да, стоит. Изучать? Ну такое.
Переносы сами по себе имеют вполне выразимую стоимость (стоимость всех человеко-часов программистов, стоимость повторного QA, и так далее), и не всегда она как-то даже рядом стоит с выигрышами от улучшения кода, особенно с учётом того, что улучшение кода можно отлично проводить и без переносов.
Но когда потенциальные выигрыши таки значительны — там да, взяли и понесли.
Оказалось, что когда переводишь проект с одного фреймворка на другой, ты не просто переносишь код. Приходится анализировать и улучшать архитектуру приложения, выпрямлять логику, рефакторить.
Это всё не зависит от переносов между фреймворками. Разве что при переносе что-то просто таки придётся выпрямлять, в то время как без переносов оно может жить годами без модификаций (а может и не жить, если есть кому бороться за улучшение кода).
Не понимала, зачем изучать первый Angular, чтобы завтра забыть о нем и изучать второй. Не понимала, зачем менять jQuery.Ajax на Fetch, чтобы заменить потом Fetch на Axios.
И в силу вышесказанного, не понимать вот тут — это как раз нормально. Не надо изучать первый ангуляр, если переезд всё равно будет только на второй. С принципами ознакомиться — да, стоит. Изучать? Ну такое.
Переносы сами по себе имеют вполне выразимую стоимость (стоимость всех человеко-часов программистов, стоимость повторного QA, и так далее), и не всегда она как-то даже рядом стоит с выигрышами от улучшения кода, особенно с учётом того, что улучшение кода можно отлично проводить и без переносов.
Но когда потенциальные выигрыши таки значительны — там да, взяли и понесли.
Я вот весьма косвенно отношусь к веб-разработке (пилю всякое на php+jquery в свободное время), но прям чувствую боль, когда пытаюсь понять, а чем же новым пользоваться, чтобы быстрее, лучше и без рефреша.
Профессионалы — понятно, они целыми отделами заранее знают технологию. А с любителями вопрос «изучить, забыть, изучить снова» встает очень остро.
Расскажите, как быть?
Профессионалы — понятно, они целыми отделами заранее знают технологию. А с любителями вопрос «изучить, забыть, изучить снова» встает очень остро.
Расскажите, как быть?
но прям чувствую боль, когда пытаюсь понять, а чем же новым пользоваться, чтобы быстрее, лучше и без рефреша
Ну, добро пожаловать в наш мир. Чувствовать боль в таких случаях — это как раз нормально.
На моей практике вообще никогда не существовало ситуаций, когда можно было откинуться в кресле, ткнуть пальцем в технологию из некоего заготовленного списка максимально подходящих, и не поиметь проблем, сразу или же (еще больнее) потом.
Это уж не говоря про то, что еще и при самом составлении списка происходит огромное количество страданий.
Пока что максимально великое откровение, которое я тут знаю — это «Никто в мире не знает, как решать конкретно твои проблемы. Даже если они довольно типичные. А уж если нетипичные, то тем более». Поэтому без боли и необходимости думать самому по каждому конкретному случаю — не выходит.
ЗЫ: Ну а если сказать более практично, то с php+jquery можно нынче куда угодно двигаться. Можно уменьшать серверную часть. Можно съехать с jquery в сторону уменьшения императивности. Можно и не делать этого (мне, например, императивный js очень нравится, и от попыток присобачить туда декларативности побольше я всегда вижу больше проблем, чем пользы). Можно смотреть в направлении модульности — даже я бы сказал нужно, если вдруг вы пока этим не озадачивались. Модульность из js уже точно никуда не денется, возможно она будет не совсем такая, как нынешние RequireJS, CommonJS, итд, но какая-то подобная будет в любом случае. Можно смотреть на разделение функциональных стилей и look&feel — этого вообще до сих пор в мире никто не смог сделать так, чтоб всем понравилось (спасибо примитивности css). Короче, тысячи путей, и это помимо предложений «изучите фреймворк Х, авось вам понравится».
Распечатаю, и в рамку, настолько хорошо :)
Ладно, вот тогда вопрос дня: какой фреймворк в первую очередь изучить человеку, который умеет в php+jquery, но хочет зарабатывать как все остальные фронтендеры, а не веками пилить сайт своего завода?
Ладно, вот тогда вопрос дня: какой фреймворк в первую очередь изучить человеку, который умеет в php+jquery, но хочет зарабатывать как все остальные фронтендеры, а не веками пилить сайт своего завода?
Тот, который хочет работодатель, ищущий фронтэндеров за хорошие деньги, разумеется.
Если говорить про вотпрямщас, то это скорее всего будет один из троицы Vue, Angular2 (то есть 2+), React. Но важно понимать, что через годик эта троица может уже выглядеть как-то иначе, а через пару лет — почти наверняка.
Если говорить про вотпрямщас, то это скорее всего будет один из троицы Vue, Angular2 (то есть 2+), React. Но важно понимать, что через годик эта троица может уже выглядеть как-то иначе, а через пару лет — почти наверняка.
Пока обдумывал ваш ответ, вспомнил прекрасное
— Слушай, это легко. Пиши весь код в TypeScript. Все модули, использующие Fetch компилируй в ES6, транспайль их с Babel с stage-3, и загружай с SystemJS. Если у тебя нет Fetch, используй polyfill, или Bluebird, Request или Axios, и обрабатывай промисы с await.
— У нас очень разные определения «легко».
— Слушай, это легко. Пиши весь код в TypeScript. Все модули, использующие Fetch компилируй в ES6, транспайль их с Babel с stage-3, и загружай с SystemJS. Если у тебя нет Fetch, используй polyfill, или Bluebird, Request или Axios, и обрабатывай промисы с await.
— У нас очень разные определения «легко».
Это вы еще не слышали, на каком языке геймеры разговаривают :-)
Но да, в той статье всё хорошо написано. И, на самом деле, этот микс из фреймворков, пакетов, фич, и прочей лабуды — он не настолько страшен, как издалека кажется. Умных слов много, а принципов работы этого куда меньше. С некоторыми вещами можно разбираться и подольше, как с теми же модулями, но во многие — нет необходимости погружаться дальше одного предложения. То есть, например, «транспайлер — это то, что переделывает не работающий в браузере JS (или TS, не суть) в работающий». Всё. Научно там разжевывать можно долго, но это всё будет про шашечки, а не про ехать.
Но да, в той статье всё хорошо написано. И, на самом деле, этот микс из фреймворков, пакетов, фич, и прочей лабуды — он не настолько страшен, как издалека кажется. Умных слов много, а принципов работы этого куда меньше. С некоторыми вещами можно разбираться и подольше, как с теми же модулями, но во многие — нет необходимости погружаться дальше одного предложения. То есть, например, «транспайлер — это то, что переделывает не работающий в браузере JS (или TS, не суть) в работающий». Всё. Научно там разжевывать можно долго, но это всё будет про шашечки, а не про ехать.
Это как раз легко, так как каждый пункт тут сводится к «открой гитхаб и выполни шаги из ридми». С этим даже обезьяна справится при условии владения командной строкой, линуксом и английским. А вот отладить все это, чтобы не было багов, чтобы удобно было разрабатывать, чтобы работало под виндоуз, чтобы в результате не получалось 2 мегабайта яваскрипта, чтобы работало в ИЕ — это действительно другое определение слова «легко».
Упс, написал ниже большой коммент, а вы оказывается не просто любитель, ваяющий что-то для себя или какого-то своего сообщества, а, как минимум, видящий себя профессионалом в будущем, да и сейчас уже возможно деньги за веб-разработку получающий, то есть формально к профессионалам уже относящийся.
Тут критерии другие, если среднесрочная цель выйти на достойный уровень оплаты в веб-разработке. Прежде всего анализ требований рынка, как по уровню оплаты на позициях типа миддл/регуляр, так и количеству вакансий. Ну и сравнение своих актуальных знаний и навыков с требуемыми. Сначала просто по «чек-листу» вакансии, потом с помощью попыток прохождения собеседований по всем более-менее адекватным вакансиям с активным требованием фидбэка в случае отказа.
Навсидку на вашем месте я бы смотрел в сторону Angular или Vue на фронте и Laravel на бэке (сам по дефолту выберу React+MobX и Symfony :) ). И вообще определился бы, что интересней, фронт или бэк, и основные усилия прилагать к выбранному пока до полноценного миддла не дорастёте. А уж потом смотреть интересно ли становиться фулстэк разработчиком или нет.
Тут критерии другие, если среднесрочная цель выйти на достойный уровень оплаты в веб-разработке. Прежде всего анализ требований рынка, как по уровню оплаты на позициях типа миддл/регуляр, так и количеству вакансий. Ну и сравнение своих актуальных знаний и навыков с требуемыми. Сначала просто по «чек-листу» вакансии, потом с помощью попыток прохождения собеседований по всем более-менее адекватным вакансиям с активным требованием фидбэка в случае отказа.
Навсидку на вашем месте я бы смотрел в сторону Angular или Vue на фронте и Laravel на бэке (сам по дефолту выберу React+MobX и Symfony :) ). И вообще определился бы, что интересней, фронт или бэк, и основные усилия прилагать к выбранному пока до полноценного миддла не дорастёте. А уж потом смотреть интересно ли становиться фулстэк разработчиком или нет.
Если относитесь весьма косвенно, то просто посмотрите туториалы, демки, конкурсы и т. п. и посмотрите, что вам ближе, понятней. Если ещё затрудняетесь с выбором, то попробуйте какие-то простые задачи (можно уже решенные, можно новые, но которые вам абсолютно понятно как решать на привычном стэке технологий, в общем чтобы не приходилось думать а как вообще задачу решать, а только как решение перенести на новый стэк) решить одновременно на оставшихся кандидатах. Ну и где-то раз в год-два можно повторять, если боитесь, что упустите что-то новое, что кардинально упростит вам жизнь. А может по результатам анализа в целом окажется, что и ваш текущий стэк вполне себе приемлем, что проблем, которые решают новые или значительно обновленные технологии, у вас просто нет. Ну, например, в ваших любительских проектах крайне редки изменения существующей функциональности, добавления бывают, но переделывать то, что уже сделали вам не интересно. Или у вас нет проблемы входа новичка в проект. Или не сталкиваетесь постоянно с багами, связанными с неявными сайд-эффектами, когда сделали что-то новое или починили старое, а тут внезапно вылазят ошибки, казалось бы никак не связанные с тем, что делали.
Главным критерием, по-моему, для люителей должна быть простота и скорость разработки, за милисекундами отклика или рендеринга вам, по-моему, смысла нет гнаться, если оптимизация сама по себе вам удовольствия не доставляет.
Ну и хорошо бы проанализировать что вы чаще делаете — пишите что-то новое, реализуете какие-то идеи типа «а не запилить ли мне...» или изменяете существующее, реализуете идеи типа «вот я это уже сделал, а теперь вижу, что это можно по другому и спать теперь не могу». Вряд ли вы найдёте стэк, который удовлетворят обеим подребностям, одинаково хорошо подходящий для быстрой разработки или прототипирования идей (RAD есть такой термин) и для долгосрочной поддержки с постоянными изменениями (ближе к «кровавому ентерпрайзу»)
Не думаю, что вам нужно фокусироваться на таких критериях как скорость работы стэка или время сборки — всё сколь-нибудь популярное имеет приемлимые метрики.
Главным критерием, по-моему, для люителей должна быть простота и скорость разработки, за милисекундами отклика или рендеринга вам, по-моему, смысла нет гнаться, если оптимизация сама по себе вам удовольствия не доставляет.
Ну и хорошо бы проанализировать что вы чаще делаете — пишите что-то новое, реализуете какие-то идеи типа «а не запилить ли мне...» или изменяете существующее, реализуете идеи типа «вот я это уже сделал, а теперь вижу, что это можно по другому и спать теперь не могу». Вряд ли вы найдёте стэк, который удовлетворят обеим подребностям, одинаково хорошо подходящий для быстрой разработки или прототипирования идей (RAD есть такой термин) и для долгосрочной поддержки с постоянными изменениями (ближе к «кровавому ентерпрайзу»)
Не думаю, что вам нужно фокусироваться на таких критериях как скорость работы стэка или время сборки — всё сколь-нибудь популярное имеет приемлимые метрики.
В начале статьи думал, что будет история про react-bem-core :)
Спасибо.
З.ы. Не придираюсь, но почему "реактивный фронтенд"? От слова React?
Опередили, спасибо :)
React не имеет никакого отношения к реактивному программированию. Название статьи вводит в заблуждение, потому что ни о каком РП в статье речи не идет.
Неужели к вот такому
И это ещё простой селектор.
&__toggler{
...
}И это ещё простой селектор.
Яндекс знатные почитатели NIH синдрома. create-react-app — не, сделаем своё. Nightwatch? Не, сделаем своё. Фреймворк? Не, своё. Потом, правда, выкинем, и будем пользоваться React.
А где-то можно потыкать в сайтик сделанных на этих всех описанных модных-молодёжных плюшках?
Можно: money.yandex.ru
Потыкал минут пять. Вот скажите, как так происходит? Почему в современном вебе несмотря на реакты-редуксы и прочую хрень на выходе получаются кривые, косые и ЧУДОВИЩНО тормозные сайты?
У вас в мобильной версии адово тормозит анимация выезжающего слева меню. В этом же меню некомфортно мелкие невидимые области в которые надо попасть чтобы перейти по ссылке. На странице создания кошелька нельзя вернуться назад.
На главной бэкграунд с теткой неприятно дёргается в конце анимации выезжания текста. Там же, чтобы проявился текст после «Кошелек защищает покупателя» надо очень сильно проскроллить страницу вниз, наблюдая до трёх четвертей экрана белой пустоты.
Кнопки «других способов пополнения» со страницы пополнения кошелька ведут на десктопную версию сайта (всего два клика с главной и упс, мобильная версия кончилась).
Я провёо всего 5 минут на вашем сайте и абсолютно не являюсь профессиональным тестировщиком и проигнорировал проблемы вёрстки.
Как так происходит? Грош цена всем этим БЭМам если на выходе сайт, создающий впечатление кривой поделки.
Дело не конкретно в вас, весь веб сейчас такой. Просто вы тут пытаетесь учить других как делать его хорошо и правильно, но то что вы делаете не хорошо и не правильно.
У вас в мобильной версии адово тормозит анимация выезжающего слева меню. В этом же меню некомфортно мелкие невидимые области в которые надо попасть чтобы перейти по ссылке. На странице создания кошелька нельзя вернуться назад.
На главной бэкграунд с теткой неприятно дёргается в конце анимации выезжания текста. Там же, чтобы проявился текст после «Кошелек защищает покупателя» надо очень сильно проскроллить страницу вниз, наблюдая до трёх четвертей экрана белой пустоты.
Кнопки «других способов пополнения» со страницы пополнения кошелька ведут на десктопную версию сайта (всего два клика с главной и упс, мобильная версия кончилась).
Я провёо всего 5 минут на вашем сайте и абсолютно не являюсь профессиональным тестировщиком и проигнорировал проблемы вёрстки.
Как так происходит? Грош цена всем этим БЭМам если на выходе сайт, создающий впечатление кривой поделки.
Дело не конкретно в вас, весь веб сейчас такой. Просто вы тут пытаетесь учить других как делать его хорошо и правильно, но то что вы делаете не хорошо и не правильно.
Нисколько не в защиту Яндекса, ибо сам эту контору не люблю, но…
Ну вы уже должны были сами всё понять.
Мобильная версия сама по себе не взлетит. Не взлетит она и с реактами-редуксами и прочими умными словами. Мобильная версия — это по прежнему такое особое чудо, которое надо допиливать и тестировать отдельно.
И не смотря на всё это — это лучше, чем было раньше, когда мобиловерсия сайта сжирала столько же, или даже больше сил, чем обычная.
У вас в мобильной версии
Ну вы уже должны были сами всё понять.
Мобильная версия сама по себе не взлетит. Не взлетит она и с реактами-редуксами и прочими умными словами. Мобильная версия — это по прежнему такое особое чудо, которое надо допиливать и тестировать отдельно.
И не смотря на всё это — это лучше, чем было раньше, когда мобиловерсия сайта сжирала столько же, или даже больше сил, чем обычная.
У них тормоза скорее всего не от яваскрипта или БЭМ, а от злоупотребления анимациями. То есть арт-директор видимо в мечтах видит какие-то футуристичные интерфейсы, где все выезжает, трансформируется, подмигивает и подпрыгивает в векторе, но реальные браузеры на обычных устройствах, особенно если недоступно аппаратное 3D ускорение, или элементы DOM неудачно выстроились в дереве, просто не могут это нормально отображать и перерисовывать страницу по 60 раз в секунду.
У меня например, 100% сайтов, на которых есть эффекты при прокрутке страницы, дергаются и притормаживают, а если не притормаживают, то анимации смотрятся как-то неестественно и отвлекают внимание.
Я кстати крайне не люблю эти анимации. Белая страница с сухой таблицей с аккуратно подобранными отступами и шрифтами в 10 раз лучше всех этих гигантских современных блоков с 40-пиксельными шрифтами.
У меня например, 100% сайтов, на которых есть эффекты при прокрутке страницы, дергаются и притормаживают, а если не притормаживают, то анимации смотрятся как-то неестественно и отвлекают внимание.
Я кстати крайне не люблю эти анимации. Белая страница с сухой таблицей с аккуратно подобранными отступами и шрифтами в 10 раз лучше всех этих гигантских современных блоков с 40-пиксельными шрифтами.
Океей, десктоп. С текстом на главной такая же фигня: cloud.mail.ru/public/5kkt/ST6WpV8d9
Правда тётка уже не дергается.
При переходах в левом меню на «Как собирать деньги» и обратно в этом самом меню колбасит шрифт. Как, почему??? Почему именно эта страница? Что такого надо было нареактить вместо «просто указать шрифт текста» чтобы это происходило?
Страница «Оплата->Налоги». Сначала загружается всё, потом с паузой до секунды догружается поле ИНН. Да, яндекс, вы клёвые, вы умеете апдейтить на ходу куски страницы. Но начерта это здесь? Кому нахрен сдалась форма в её промежуточном виде, без единственного значимого поля?
В «Помощи» попадаешь в другую вселенную.
Со страницы создания кошелька опять почти никуда не выбраться.
Ищо:
cloud.mail.ru/public/NHvF/CKqVQcwx1
cloud.mail.ru/public/FBV1/naXJFFYm8
Десерт: cloud.mail.ru/public/EnWQ/c4b2LPTUp
P.S. Хабр, гори в аду. Мискликнул в кнопку «написать комментарий» внизу страницы и весь набранный текст пропал.
P.P.S. Повторю, сайт ЯД не как-то особенно плох на фоне других сайтов. И вообще я потенциально не являюсь целевой аудиторией и мои претензии можно проигнорировать.
Правда тётка уже не дергается.
При переходах в левом меню на «Как собирать деньги» и обратно в этом самом меню колбасит шрифт. Как, почему??? Почему именно эта страница? Что такого надо было нареактить вместо «просто указать шрифт текста» чтобы это происходило?
Страница «Оплата->Налоги». Сначала загружается всё, потом с паузой до секунды догружается поле ИНН. Да, яндекс, вы клёвые, вы умеете апдейтить на ходу куски страницы. Но начерта это здесь? Кому нахрен сдалась форма в её промежуточном виде, без единственного значимого поля?
В «Помощи» попадаешь в другую вселенную.
Со страницы создания кошелька опять почти никуда не выбраться.
Ищо:
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') (подозреваю, там какая-то магия, но все равно выглядит странно).
Функции в такой записи, на мой взгляд, плохо читаются:
Больше напоминает результат обфускации. По моему, так export function xyz() было бы куда читабельнее.
Когда вы разрываете куски названий классов
То они перестают искаться. То есть, если в таком коде сделать поиск по title__toggler, то ничего не найдется. Это, по моему, минус.
Насчет «уровней переопределения» — по моему, тут есть риск, что два уровня могут переопределять одно и то же свойство (или задействовать один и тот же псевдоэлемент) или конфликтующие друг с другом свойства (один уровень ставит overflow: hidden, а другой добавляет выходящий наружу элемент).
Также, по моему, это выглядит довольно странно:
tag()('button')Так как непонятно, почему не просто tag('button') (подозреваю, там какая-то магия, но все равно выглядит странно).
Функции в такой записи, на мой взгляд, плохо читаются:
export const addPhone = (params) => () => axios.что-то.тамБольше напоминает результат обфускации. По моему, так export function xyz() было бы куда читабельнее.
Когда вы разрываете куски названий классов
.title {
&__toggler {
То они перестают искаться. То есть, если в таком коде сделать поиск по title__toggler, то ничего не найдется. Это, по моему, минус.
Оно лежит в понятных местах на ФС и в полнотекстовом поиске по всему проекту нет необходимости.
BEM — хороший пример Соглашения по конфигурации, когда js/css/шаблоны находятся в предсказуемых местах. Соглашение позволяют легко войти в другой проект, созданный по таким же соглашением с минимальным количеством «WAT».
Тело шаблона — это отдельный вызов функции, которая ожидает аргумент.
Можно использовать сокращенный синтаксис, который выглядит привычнее:
Посмотрите пример
Также, по моему, это выглядит довольно странно:
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?
1. Большинство наших фронтендеров используют плагины, перечисленные в официальной документации — www.styled-components.com/docs/tooling#syntax-highlighting.
2. При адекватном форматировании код легко читается, а много кода это повод разбить его на несколько компонент. Мы не испытываем проблем с читаемостью.
2. При адекватном форматировании код легко читается, а много кода это повод разбить его на несколько компонент. Мы не испытываем проблем с читаемостью.
Пример с ChangePhoneForm на реакте, это настоящая реализация в проекте?
зачем байндить метод в рендере? Вы же в компонент Form будете передавать каждый раз новую ф-цию. Почему не сделать метод, как arrow function или не забайндить в конструкторе? Или я чего-то не понимаю?
зачем байндить метод в рендере? Вы же в компонент 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 };
})Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реактивный фронтенд. История о том, как мы снова всё переписали