Комментарии 57
Так, раз уж это туториал, и вы показываете, как делать правильно, давайте разбираться, почему так неправильно. Во-первых, где TypeScript?
export default class Checkbox
Не надо ничего export default, вы потом даже переименовать его не сможете. Подробнее тут, но в гугле есть и больше.
&-yellow svg rect
А без svg не подойдёт rect? А rect внутри svg внутри rect внутри svg точно подходит? У вас с такими селекторами потом полный проект soft-important'ов будет, чтобы проблемы с specificity побороть. БЭМ.
return newState;
Редюсер обязан возвращать оригинальный стейт, если он не поменялся. В обработке экшена SET у вас та же ошибка.
import './scss/index.scss';
А если будем переписывать на какой-нибудь postcss, то заведём ещё папку postcss, и будем потом переключаться между тремя папками каждые 10 секунд, да? Почему компоненты не изолированы в одной папке?
import App from './App';
У разработчиков бывают разные операционные системы, у которых разные файловые системы, которые по-разному обрабатывают верхний регистр. Чтобы не получилось фиаско, когда разработчики не могут из гита проект даже счекаутить, в Node (и в целом во фронтэнде) приняли за стандарт именовать файлы в kebab-case. К сожалению, разработчики CRA, которым вы, скорее всего, сделали шаблон этого кода, были не в курсе, но на них не нужно равняться.
import store from '../redux/store.js';
Не надо в глобальную область видимости класть никакое состояние, в том числе store. Вы когда SSR делать будете, потом весь код переписывать. У вас connect для этого есть (а по-хорошему должен был быть useDispatch).
class Checkbox extends React.Component {
Ну, не Component, а PureComponent, и вообще Legacy API в примерах показывать не комильфо. Где хуки?
constructor() { store.dispatch(...) }
А вы сможете рассказать, когда именно здесь вызывается конструктор, что произойдёт, если в это время диспетчеризовать экшены, и как от одного неудачно проставленного key потенциально зависнет вся страница?
this.props.redux[this.props.id]
В JS есть destructuring.
принести данные с сервера (это про axios)
Не нужен. 2022 год на дворе, есть fetch. У кого fetch нет, есть полифилл.
почистить данные (prop-types в компонентах или что-то кастомное ещё на выходе axios)
Сейчас популярен zod для этих целей.
Не нужен (axios - прим. ред.). 2022 год на дворе, есть fetch. У кого fetch нет, есть полифилл.
Из README.md в описании тестового:
Написать приложение "Круги и квадраты" с использованием React+Redux+Axios.
______________________
При этом ни разу не умаляю ваших познаний. Зашла к вам в профиль, за статьями такой же насыщенности как ваш комментарий. Но их нет. У вас просто нет статей вообще. Это не дело.
Когда вам есть, что сказать, надо писать статьи, от себя. А не чужие статьи критиковать, вне связи с их темой. Критикуя, вы разгоняетесь, пишете, что axios не нужен в тестовом, где он есть в требованиях открытым текстом, и... и потом не можете этот ваш ляп исправить, поскольку на исправление комментариев тут только полчаса.
Статьи, напротив, можно править сколько угодно.
Насчет axios'a согласен с вами, но вот остальное... Простой вопрос: для чего нужны комментарии к статям?
В принципе @maerisправ и не просто так докопался.
И к вам тоже зашла в профайл в поисках ваших статей. Потрясена глубочайше: ваш аккаунт не просто новый. В нём этот ваш комментарий - первый. Ну и пока единственный.
Это существенно затрудняет мне лично обсуждение с вами простого, на ваш взгляд, вопроса о ценности комментариев под статьями.
По-моему, это как раз очень сложный вопрос. Разноплановый. И каждый раз есть уйма деталей: какая статья, о чём, насколько с ней комментарий тематически связан, можно ли быть уверенным, что комментатор статью прочёл полностью до конца, а не только название...
Это, конечно, оффтопик категорически. Этот вопрос. Но ладно, давайте ещё немного посравниваем:
А если будем переписывать на какой-нибудь postcss, то заведём ещё папку postcss, и будем потом переключаться между тремя папками каждые 10 секунд, да? Почему компоненты не изолированы в одной папке?
В статье (под катом, под файлом index.js, поскольку тема, имхо, скорее побочная, даже в квадрате побочная):
Если вам интересно, что делает одинокий импорт стилей из index.scss тут вверху: весь scss можно складывать в одну папку scss отдельными файлами, по разным темам. Дальше мы импортируем их внутри папки scss в этот тамошний индекс scss-импортами. Ну а в js используем уже только только scss/index.scss.
Если бы приложение было побольше, я бы иначе организовала файлы. Были бы отдельные модули по разным темам, и в каждом модуле по отдельности и свои компоненты реакт, и свои стили. И подключала бы стили внутри компонентов.
Коротко говоря, по-моему,
ув. критик статью не читал вообще, или так вскользь пробежал, в поисках тем, к которым бы прицепиться,
пришёл звездить, как он обычно делает в комментариях - см. в его профиле комментарии к другим статьям,
печалька в том, что у хабравчан это вот вызывает большую радость, поскольку очередному выскочке (автору очередной статьи) надрали уши.
И... и совершеннейше удивительно, между прочим, что карма у юзера в данный момент аж 70, но статей нет. Ээээто как? Без публикаций не может быть кармы 5 или выше.
То есть... То есть, возможно, там публикации были, но юзер их вынес в черновики. Статья была, под статьёй насовали в панамку любезные комментаторы, и юзер статью убрал. А карма осталась.
Не баг ли это?
@Boomburum, посмотрите, пожалуйста, это немного странно. Карма у человека 70, а статей нет. Так можно было?
То есть, возможно, там публикации были, но юзер их вынес в черновики.
Так и было. Потеряли актуальность.
Почему-то вот всегда карма больше всего в комментариях волнует людей, у которых с ней проблемы, и почему-то всегда это заканчивается тем, что эти проблемы у них обостряются. :)
Мария, статьи автор скрыл в черновики. Он имеет на это полное право, т.к. они могли устареть или, например, оказаться неудобными для работы и т.д. Причин много, статьи были качественные, карма заслуженная.
В принципе, это уже не особенно актуально (я уже выявила для себя тему, реально меня зацепившую тут, и уже написала о ней в других комментариях), но всё таки.
Мне кажется, это - плохая - традиция хабра: писать много букв комментариями к чужим статьям. Особенно если фокус статьи не на этом. Вернее, фокус статьи на чём-то одном, но его размывают деталями в комментариях. Дальше, естественно, этот размыв кому-то ещё полезен. Но ведь не всем. И чаще всего - ни разу не ЦА статьи.
При этом статья устроена так, что читает больше ЦА. В итоге имеем сразу аж две побочки:
ЦА не рискует соваться в каменты, ибо растопчут,
а комментаторы пыл свой растрачивают на срач вместо новых статей.
У меня никаких оснований верить вам на слово, что человек, вот так вот не видящий, что именно он комментирует, что-то сам написал читабельное - читабельное для меня лично. Есть в психологии такая штука, "контактная функция", это когда ты не можешь подойти к группе, беседующей в кругу, и вступить в разговор просто так. Надо сначала как-то немного контакт создать. Постоять около этой группы. Прислушаться. Уместно хмыкнуть. Только минут через пять или десять (и то не факт) можно реально вступить в разговор, никого не задев.
В каментах хабра контактная функция сдохла.
Здесь абсолютно нормально прийти под статью про А, написать про Б или С, что Б или С существенно лучше (и это ведь спорно - вот @Marcelinkaпишет сейчас про Vue 2, потому что у них Vue 2, а не 3, а у кого-то в хедхантере требуется Laravel 5, хотя на сегодня уже основная - девятка), и... ну нельзя так. Нельзя вот так обращаться друг с другом.
Может быть, у вас есть психолог, способный качественно написать про контактную функцию? Почему это не хорошо - не читать, но высказываться, причём не по теме и сразу? Какие издержки есть у такого подхода?
Любой психолог из института психоанализа справится... Может быть. Собственно да, "контактная функция" - это понятие из группового психоанализа.
К сожалению, написать что-то достойное внимания людей довольно тяжело. Для этого нужно, по меньшей мере, знать что-то лучше, чем свои читатели. Это тяжело сделать, если вы не перфекционист или с трудом воспринимаете критику.
Это тяжело сделать, если вы не перфекционист или с трудом воспринимаете критику.
Это вообще тяжело.
Скажем, у этой моей статьи было штук двадцать черновиков. В смысле я начинала её раз двадцать. Несколько раз дописывала почти совсем - но мне не нравилось. Вернее, я полагала, что недостаточно чётко выделила основные шаги, ну и рассказываю о тех, что выделила то чересчур подробно, то чересчур поверхностно.
В целом это, возможно, часов сорок времени, в течение месяца. Если не больше.
На момент выпуска в публикацию вот этой версии у меня в личке было ещё пять-шесть черновиков практически с тем же названием, с немного разными текстами. Я удалила их, только опубликовав эту.
Дальше кто-то пришёл с первым каментом. Статья для джунов, про то, как аккуратно написать мелкое тестовое. Как не запутаться, не попутать синий с зелёным (вы же прочли исходник - статью, в которой тестовое предложено? Или нет?) Какой нахрен БЭМ, когда надо краткое тестовое написать?
И да, уберите "не", если у вас ещё доступ есть на редактирование комментария. Вы же имели в виду как раз "если вы именно да перфекционист".
Психологи - это туда. Их время довольно дорого стоит - у тех, которые вот с этим вот умеют работать. В этих деньгах зашита ещё оплата за вредность, токсичность.
И чисто на бытовом уровне попробуйте разделять
перфекционизм и ответственность (я писала эту статью целый месяц не потому, что я перфекционистка - хотя я перфекционистка. Я писала месяц, поскольку у меня была цель: сделать доступное объяснялово по выполнению тестовых. На чём угодно),
звездёж и конструктивную критику (ни один пункт вашего первого комментария не учитывает, что статья - про тестовое задание для джунов. В котором задании ни о каком TypeScript не упоминается - но вы его требуете в первой же фразе. При этом в задании открытым текстом упоминается Axios, но вы орёте, что аксиос уже не носят)
Один из способов справиться с внутренним критиком - начать с себя. Перестать полоскать собственный перфекционизм под чужими статьями. Попробовать по возможности с чужим результатом обращаться ответственно и конструктивно. Т.е., сначала читать, откуда вообще растёт тема. Потом обдумывать, реально ли по итогу в статье эта тема раскрыта. И др. И перед тем, как писать комментарий, взвешивать: это ваш комментарий к статье, он чем-то поможет ЦА статьи (допустим, джунам, пишущим краткое тестовое), или он больше о том, что вы - самый умный в садике?
Комментарии людей, которые что-то знают, всегда полезны для читателя статьи. Вам, как автору, может не нравиться критика, но для меня она оказалась полезной. Я могу соединить вашу статью и замечания к ней и получить лучшее приложение, чем я сделал бы без этих замечаний
Вопрос-то ещё и в том, полезна ли эта статья.
Я, её автор, чувствую омерзение. Вот прямо сейчас. Досаду. От, например, того, что так и не сделала личный блог, и выложила статью, которую писала долго (осмысленно долго) на хабр. Дав повод кому-то выпендриться за мой счёт.
Скажем, я могу эту статью сейчас скрыть. Просто убрать её снова в черновики. Статья в закладках уже у дюжины человек... ну и что? Эти прекрасные люди не удосужились нажать плюсик, только в закладки добавили. И я в общем-то не против.
Но в совокупности с высокой оценкой за комментарий, который вы сочли критикой, а я - ленивым душным паразитизмом, я уже не особо рада, что всем этим занималась.
Так что... такое дело. Если вы дальше хотите статьи, извольте уважать авторов в первую очередь. А во вторую - обдумывать не только суть комментариев, но и их тон. Вопросы типа "Почему не...?" в комментарии - это окрик. Окрик автору-идиоту.
ЗЫ добавлю, что мне тоже в чём-то тот камент был вполне полезен. Я не знала про, например, соглашение про именование файлов в нижнем регистре - просто не сталкивалась с этим ни разу (да и не факт, что столкнусь). И я огорчилась, что у него нет статей в аккаунте.
Но всё это ну никак, ни разу не отменяет всю ситуацию в целом:
автор потратил/а на статью часов сорок,
эту статью быстренько добавляют в закладки, но автору ни оценку, ни карму пока не выращивают (ещё как бы не слили),
за комментарий, написанный минут за пять-десять, оценка сейчас уже почти 10 баллов.
Зачем мне писать мою следующую статью сюда? Если единственное, что реально поощряется тут сообществом - хлёсткая отповедь такой неумёхе от гуру?
Зачем Вы пишете статьи если не готовы к замечаниям/комментариям/...?
Зачем мне писать мою следующую статью сюда?
Никто вроде не заставляет. Особенно с таким отношением, всё же просто
P.S. Раз уж Вы занялись аналитикой профилей, то можете и мой глянуть, одна статья, с минусами. Надеюсь, я заслужил право писать комментарии к чужим статьям?
P.P.S.
за комментарий, написанный минут за пять-десять, оценка сейчас уже почти 10 баллов.
Повод задуматься
Нет. Это не повод задуматься. Это лишь подтверждение тому факту, что хабр поощряет скоростной выпендрёж на фоне чужой хорошей работы.
Поскольку комментарий комментарию рознь. Можно сказать "вот тут ещё я предложил бы так, а тут эдак". А можно орать "почему тут так?" Особенно "почему аксиос", если он в тестовом. Как же вы в этом не видите противоречия.
Никто вроде не заставляет. Особенно с таким отношением
С таким отношением хабра к авторам? Ну, мне сейчас слили карму уже почти на 10 баллов. С утра было почти 40, сейчас почти 30.
А моё отношение... Ну, моё отношение-то было к ЦА статьи. ЦА в этой вот статье - джуны, которых может заинтересовать аккуратное написание такого тестового. С ненавязчивой рефлексией отдельных шагов написания тестовых вообще.
Причём этот факт (что тут про тестовые) вынесен и в подзаголовок, и в описание статьи в ленте.
Можете прояснить, как вы лично тут оказались? Зачем вы лично зашли прочитать статью, в которой в подзаголовок вынесено "это статья джунам"?
Нет. Это не повод задуматься. Это лишь подтверждение тому факту, что хабр поощряет скоростной выпендрёж на фоне чужой хорошей работы.
Первый комментарий был предметный и по делу. И плюсы ему поставили отнюдь не за скорость.
Ответов на замечания, кстати, так и не было, были какие то нелепые полупереходы на личности. Зато успели посмотреть (и поделиться) кто сколько статей опубликовал.
С таким отношением хабра к авторам? Ну, мне сейчас слили карму уже почти на 10 баллов. С утра было почти 40, сейчас почти 30.
Слили не за статью, а за реакцию и комментарии. "Вы кто такие, я статьи пишу, а вы нет, сейчас вообще уйду и не буду больше писать"
А я просто читаю статьи, особенно с названием "чистый фронтенд" в надежде научиться чему то новому. И я, кстати, не увидел, что статья для джунов.
А в итоге, и в статье ничего чистого, и в комментариях автор всех грязью поливает в ответ на конструктивную критику.
И да, первый комментатор ошибся насчёт axios, а Вы за это зацепились проигнорировав другие комментарии по делу
А я просто читаю статьи, особенно с названием "чистый фронтенд" в надежде научиться чему то новому.
А описание статьи вы читаете? А первые строчки?
В этой статье ни описание, ни первые строчки не изменялись уже почти сутки. Давайте напомню:
Допустим, у вас есть тестовое задание.
Что вы с ним делаете?
В каком порядке что выполняете?
(и так далее)
Это начало статьи. Её первые строчки.
И возмущение моё имеет ровно единственный смысл: вы для чего, люди с опытом в годы и годы, вы для чего статью для джунов заваливаете лишней - джунам - инфой?
Понимаете, из 40 (я не уверена в цифре, может быть - 30, а может быть, 50) часов, потраченных на эту статью, я 90% потратила на... вычёркивание. Целью было найти, что именно тут оставить, чтобы, при минимальных усилиях, джун с опорой на этот текст смог бы упорядочить свою работу с тестовыми. Причём не только в реакте, чисто теоретически.
Собственно, был вариант даже "одна статья общая + реализация на ванилле + на вью + на реакте". Отброшен был по итогу именно за избыточную насыщенность. Джун нуждается в годной эвристике и взгляде дальше своего носа - они же на курсах проходят что-то, и сразу реализуют. Потом на первой работе Начальник говорит "тут сделай так и такими буквами", и джун делает. Общий вид сверху вообще наглухо непонятен. Вот он и был в фокусе.
АПД добавлю, что я даже списывалась в личке с @mSnusпо ходу работы, чтобы узнать у него в деталях, правда ли те проблемы, которые он описал, таковые и были. Или, допустим, в статье он добавил гротеска. Ну и других подробностей попросила, которые в его статью не доехали.
Читать статью только из-за того, что в названии есть слова "чистый фронтенд", это как колбасу покупать только из-за названия. Не обращая внимания на этикетку с составом. А там, допустим, ваш основной аллерген. И завтра вы померли. Причём страдая.
Джун не может отличить плохое от хорошего и такими статьями и примерами делаете только хуже.
Если считаете, что джунам можно показывать плохой код "чтоб их не нагружать" - Ваше право. Если код тут не важен - нужно было его убрать. Оправдания "я и так все вычеркнула" не убедительны - мы ж на результат смотрим.
Если статья не зашла, имхо, нет смысла обвинять всех и вся, стоит сделать выводы и адекватно ответить на замечания. Понятно, что ресурсы на статью затрачены, но сама по себе ценность работы не в затраченных ресурсах, а в пользе. Ваши же примеры могут стать плохим примером для джунов, которых учите
Если статья не зашла
Менее чем за сутки в закладки её добавили более двадцати человек.
При этом ни один джун с ответами на вопросы в статье сюда в комментарии уже не сунется - побоится.
Открою секрет, в мобильной версии очень легко случайно добавить статью в закладки при пролистывании. Это первое. А второе - статью могут добавить в закладки, чтоб потом почитать, а не потому что статья понравилась
Я знаю этот секрет. Однако попробуйте рассмотреть и ещё варианты. Кто-то начал читать, понял, что ему надо подробнее вчитываться, и добавил в закладки. Такое возможно? Кто-то прочёл подробно и запланировал сделать-покодить. Добавил в закладки. Такое возможно?
Вы почему-то выносите скопом за скобки всех тех, кому это может быть надо. Кому это правда надо. Всех тех, кому вы с коллегами уже зарубили вариант "прийти потусить обсудить свои разные тестовые".
Уверены ли вы, что этих людей ровно ноль? Что я - единственная, кого это всё задело?
Что я - единственная, кого это всё задело
Судя по комментариям и реакции комментаторов - да
Судя по реакциям, которые вы (вы лично и несколько других человек) решили оставить. Другие, кого, возможно, это тоже задело, просто решили не ввязываться. Себе дороже.
Я для себя пока что просто решение приняла больше ни слова на хабр не писать по делу, пока тут не сменится климат. Ну там, покомментировать там-сям иногда, это святое. Но вот статьи... статьи теперь будут у меня в блоге в другом ресурсе. В смысле что я уже блог создала, статью туда перенесла... тут не стёрла пока. Но не уверена, что завтра её не сотру.
Опять же, если сообщество хабра меня отхабрит, эта статья пропадёт тут сама собой.
Если считаете, что джунам можно показывать плохой код "чтоб их не нагружать" - Ваше право. Если код тут не важен - нужно было его убрать. Оправдания "я и так все вычеркнула" не убедительны - мы ж на результат смотрим.
Я считаю, что джунов надо сфокусировать. Именно в этом был мой педагогический интерес - продумать, как на мой нынешний взгляд грамотно преподнести тему самоорганизации при написании тестового.
Код при этом имеет чисто иллюстративную функцию. Он должен быть. Но его должно быть по минимуму.
Подробности должны быть. Но по минимуму, и под катом по теме.
Мои примеры без TypeScript в тестовом, где его не просили - это всего лишь пример выполнения тестового близко к тексту, а не манкирование правилами профессии. Просто тестовое. Просто пошагово. Только затем, чтобы пройти на работу к данному работодателю (или похожему).
Дальше они будут читать уже ваши статьи - вы же ещё напишете что-то? С хорошим кодом. С подробными описаниями хороших практик.
И я сейчас ни разу не ёрничаю - я совершенно серьёзно. Вы же не ожидаете от закуски сытости, даже если оно называется "салат сытный". Не ожидаете, что "финский сервелат" сделан в Финляндии.
Что же вы от статьи для джунов ждёте детализации техники. Какое бы там название у неё не было. Если конфета называется "муму", вы не пытаетесь её доить. Потому что при этом названии она - конфета, а не корова.
Любая статья по делу имеет специализацию. Тут специализация - как научить джунов писать тестовые пошагово, мирно и сравнительно быстро. И это сказано открытым текстом как в описании статьи в ленте, так и в начале статьи.
Какие ко мне претензии после этого? И почему у вас настолько отсутствует цеховая солидарность? Собственно да. Меня таращит от того, какому количеству потенциально заинтересованных людей вы зарубили возможность тут в комментариях потусовать по делу. Какое количество джунов распугали.
Я совершенно не так себе представляла дискуссию: я себе представляла джунов, обсуждающих, как они что попробовали и на чём сломались. И как вообще они делают свои тестовые. Блин. Вот сейчас формулирую наконец, что меня беспокоит реально - и... какие же вы эгоисты-то, вашу мать.
Я совершенно не так себе представляла дискуссию
наши ожидания – наши проблемы
Проблема ли наша вера в людей? Наше предположение, что люди будут вести себя предупредительно? Будут предполагать, что нечто, самим им не очень нужное, нужно кому-то ещё?
наши ожидания - наши проблемы
Это бульварная психология. Из той же серии, что обидеть можно только обидчивого. Почему-то никто ни разу не утверждал, что можно синяк поставить только тому, кто сам в синяках виноват. А если двинуть кому-то, кто в синяках разбирается, то у него не будет никаких синяков, даже если двинуть с ноги.
Л - логика.
Заглянула к вам в профиль, нашла статью, написанную вами на хабр практически год назад, как раз про React. Добавила к себе в закладки, на вас подписалась. Но.
Если на хабре мало статей для уже продолжающих, вот как вы, это - отдельная тема.
И эта тема может быть связана, в частности, именно с тем, как, точнее - насколько слабо, обычные комментарии связаны именно со статьёй, под которой написаны. Насколько, тем самым, здешний контекст демотивирует авторов.
Вам, уже год назад написавшему тут про тот самый реакт, вам приходится черпать сведения в комментариях под статьями для джунов про тестовые. Потому что тот комментатор, чей камент вас обогатил, не написал свою развёрнутую статью в том же хабе. Он только прокомментировал тут.
Но почему он её там не написал? Почему он достаточно мотивирован лишь для того, чтобы распылять на детали кода тему под статьёй для джунов о самоорганизации при написании тестового на примере реакта? Почему он не мотивирован на собственную статью про всё это?
@Free_Mic_RSпопробую вам показать это вот всё обсуждение. На мой взгляд, фантастиш категорически. Люди в целом бегут ровно в обратную сторону от того, куда им хотелось бы каждому по отдельности.
Вдруг у вас в блоге вырастет про это статья? "Как нам обустроить хабр для жизни, а не для драки", не знаю.
а загляните в мой еще тогда!
Заглянула, спасибо. Неплохо.
Но тот же вопрос, что и к коллеге выше: как вы зашли на статью, в которой и в описание в ленте, и в подзаголовок вынесено "это статья для джунов"? У вас уже 10 лет опыта. Зачем это вам?
И поучаствовали ли вы сегодня в сливе моей кармы? Кто-то же должен был это сделать, если с утра было 40 почти, сейчас почти 30. Что-то кто-то за это время нажал. Не вы ли?
(это сейчас было не обвинение - мне именно любопытно. Мне интересно, кто именно сливает карму)
Для этого Хабр и придуман :-)
Но как насчёт специализации статей?
Я только что в другом комментарии сформулировала, наконец, что же меня выматывало тут так сильно. В каких именно ожиданиях я обломалась. И я в упор не понимаю, что с ними делать, с этими ожиданиями - были ли они оправданы.
В статье, и в описании статьи в ленте я абсолютно развёрнуто и с порога поясняю, что это статья для джунов. Про тестовые. И я рассчитывала, что в комментариях будут джуны как раз. И будут они обсуждать, как именно что попробовали, и что получилось.
Было бы совершенно логично дальше увидеть, как все эти прекрасные люди, только что здесь уже предъявившие свои знания, этого момента дождутся молча, и дальше помогут. Помогут джунам, понимаете?.. Ну потому что эти прекрасные люди ещё заодно наниматели. Им же самим, казалось бы, выгодно иметь джунов сфокусированных, аккуратных и вдумчивых.
Там, в комментариях этим джунам, можно и техник добавить, и подсказать, что axios уже не айс и есть fetch, и что в хорошей жизни нужен ещё TypeScript...
Но вот такое вот моментальное заполнение эфира тяжёлой техникой - это... это не кажется вам абсолютно эгоистичным занятием? Абсолютно эгоистичным занятием толпы народу. Причём под статьёй, в дискуссии под которой они бы могли быть полезны - только в другом формате. Подождать этих самых джунов, посмотреть, что те напишут, и подсказать им по месту. В ответ на конкретный вопрос.
Ваш подход называется credentialism, при том если чаще для оценки чужой авторитетности используют какие-то формальные регалии, то вы выбрали свой собственный критерий - наличие статей на эту тему. Да не просто выбрали (хрен бы с этим, вы этим только себе хуже делаете, выбрасывая из рассмотрения то, что совершенно осмысленно, но при этом не удовлетворяет вашему критерию "авторитетности"), а ещё и ходите и всем на это указываете. Так дело не пойдет (уже не пошло, вы свой лимит нейтрального отношения исчерпали).
Спасибо за коммент. Тот случай, когда прочитав первый коммент и ответ автора, становится ясно, что на статью лучше времени не тратить.
Остался один вопрос, являетесь ли вы джуном-фронтендером в поисках джобы.
Потому что если вы им не являетесь, уже по описанию статьи в ленте можно было понять, что вы вне ЦА статьи. Т.е., времени не пришлось бы тратить даже на комментарии.
(буду рада, если уточните - джун вы или не джун, в поисках или нет)
На мобилке превью нет. Только заголовок статьи.
Гм. Но тогда это повод для обращения насчёт UI хабра? Я работаю дома и только в компе читаю. Как-то не приходило в голову, что на мобилке отдельно совсем. Как же так можно-то, без описания?
Не порядок.
@Boomburumпосмотрите, пожалуйста, на это тоже - как же так, нет описания к статьям в мобильнике? Уйма народу в транспорте читают с мобильного.
Если там места мало, можно сделать отдельное описание для мобильника, укороченное. Но оно же должно же быть.
20 лет назад в каком-нибудь Delphi этот интерфейс с логикой делался за полчаса, хм…
Ага, я писал масштабирование такого интерфейса по Ctrl++, и это было больно. А адаптивную вёрстку как в Delphi сделать? И так, чтобы у всех пользователей работало? Причём на букридере.
Delphi предлагал удобный дизайнер (хотя у нас был свой, а его запускали для дебага), но он хорошо подходил только для одного типа приложений - десктопа. Жизнь, увы изменилась. Хотя object pascal мне нравился.
Давайте погадаем по тестовому заданию, стоит и идти работать в эту компанию..
По технологиям:
Axios: используется библиотека на 10 кб, чтобы просто делать хттп-запросы. Это означает, что техлид тянет в проект первые попавшиеся либы, совершенно не думая о его полезности. И не способен написать простейшую обёртку на 10 строк.
Redux: централизованное хранение данных свидетельствует о плохой декомпозиции проекта. Это означает, что архитектор не работал с проектами сложнее hello world, и не понимает, что глобальная шина событий очень плохо масштабируется.
React: используется популярное решение с непродуманной архитектурой. Это означает, что техдир навязывает технологии ориентируясь на рынок труда, а не на техническую целесообразность, что влечёт трату большого количества времени разработчика на борьбу с фреймворком и постоянное разрастание команды.
По макету:
Семантически однородные фильтры расположены в совершенно разных местах и выполнены разными типами контролов. Это означает, что UX-ер лепит интерфейсы от балды, не ориентируясь на информационную архитектуру.
Число колонок задаётся в конфиге, а не выставляется автоматически для оптимального заполнения экрана. Это означает, что верстальщик не умеет в адаптивную вёрстку.
Макет нарисован в виде мобильного экрана в портретном режиме. Это означает, что дизайнер практикует рисование по отдельному макету на каждый типоразмер экрана, что крайне не эффективно тратит его время.
Резюмируя: ни чему хорошему вы у дилетантов не научитесь.
Просто отмечу для джуна-читателя: это был комментарий от автора фреймворка $mol .
Что означает, как минимум, что статья... зацепила такого автора. Я в растерянности. Единственное, в чём я почти уверена, что комментария Эвана Ю не будет - он не читает по-русски, а до перевода этой моей статьи пока не дошло. Наверное.
Если серьёзно, мне кажется, у начинающих свои потребности, которые мы забываем, когда растём. Скажем, миддлу и выше важно знать, что уже устарело, какие есть нововведения. Но это не для того, чтобы "писать на новом". А для того, чтобы "писать на новом всегда". Т.е., это вообще совершенно отдельный навык, "умение менять / обновлять стек".
У джунов такого умения нет. Джуну и менять-то нечего: надо что-то одно (да хоть джиквери) освоить качественно. Тем более, что на чём угодно есть дофига сайтов (на том же джиквери есть). Надо сначала вообще освоиться с темами: что мы в принципе можем куда добавить в плане функционала. Дальше уже реально пойти изучать, как это сделать удобнее, проще и качественнее.
Ну и ещё: на рынке не миллион нанимателей. Сейчас у джунов не то, чтобы богатый выбор. Те, кого кто-то счёл дилетантами, могут вполне удобно сойтись с соискателями попроще. А, например, у знающего нанимателя можно выгореть намертво именно из-за масштабов пропасти между вами.
дизайнер практикует рисование по отдельному макету на каждый типоразмер экрана
Простите моё возможное невежество, но как нынче принято рисовать подобные штуки?
Я когда-то пробовал смотреть модную нынче Figma — но то ли я чего-то не понял, то ли там тоже все рисуют по отдельному макету на каждый типоразмер. В фигме есть constraints и это круто, но в общем случае недостаточно
По этой же статье: вы написали кучу кода, но бизнес задачу так и не выполнили. Понимаю, вы устали писать бойлерплейт. Но раз уж взялись показывать, как делать чистый фронтенд, то показывайте уж законченное решение, а не заготовку в духе "как нарисовать сову".
Вот, смотрите, я выполнил это задание на $mol пока завтракал...
Сперва делаем карточку фигуры, которая умеет показывать квадраты, круги и даже треугольники, которые есть в данных:
my/shapes/shape/card/card.view.tree
$my_shapes_shape_card $mol_view
attr *
^
my_shapes_shape_card_form <= form \circle
my_shapes_shape_card_bright <= bright \light
style *
^
backgroundColor <= color \grey
minimal_width 80
minimal_height 80my/shapes/shape/card/card.view.css.ts
$mol_style_define( $my_shapes_shape_card, {
flex: {
basis: rem(5),
grow: 1,
shrink: 1,
},
aspectRatio: '1/1',
maxWidth: vh(50),
'@': {
my_shapes_shape_card_form: {
circle: {
border: {
radius: per(50),
},
},
triangle: {
clipPath: `polygon( 50% 0, 100% 100%, 0 100% )`,
},
},
my_shapes_shape_card_bright: {
dark: {
filter: 'brightness(.5)',
},
},
},
} )Теперь реализуем схему загружаемых данных:
/my/shapes/catalog/catalog.view.ts
enum DataForms {
circle = 'circle',
square = 'square',
triangle = 'triangle',
}
const DataShape = $mol_data_record({
form: $mol_data_enum( 'Form', DataForms ),
color: $mol_data_string,
dark: $mol_data_boolean,
})
const Data = $mol_data_array( DataShape )Затем запилим страницу вывода карточек для заданных фильтров, который загружает данные, валидирует их, нормализует, фильтрует, и выводит в виде сбалансированной галереи:
/my/shapes/catalog/catalog.view.tree
$my_shapes_catalog $mol_page
title @ \Shapes
form*? true
color*? true
bright*? true
body /
<= Items $mol_gallery
items <= items /
<= Item*0 $my_shapes_shape_card
form <= item_form* \circle
color <= item_color* \grey
bright <= item_bright* \light/my/shapes/catalog/catalog.view.ts
enum Bright {
dark = 'dark',
light = 'light',
}
export class $my_shapes_catalog extends $.$my_shapes_catalog {
@ $mol_mem
data() {
const data = $mol_fetch.json( '/my/shapes/data/shapes.json' ) as any
return Data( data ).map( ({ form, color, dark }) => ({
form,
color,
bright: dark ? Bright.dark : Bright.light,
}) )
}
@ $mol_mem
data_filtered() {
return this.data().filter(
shape => this.form( shape.form ) && this.color( shape.color ) && this.bright( shape.bright )
)
}
@ $mol_mem
items() {
return this.data_filtered().map( ( _, index )=> this.Item( index ) )
}
item_form( index: number ) {
return this.data_filtered()[ index ].form
}
item_color( index: number ) {
return this.data_filtered()[ index ].color
}
item_bright( index: number ) {
return this.data_filtered()[ index ].bright
}
}/my/shapes/catalog/catalog.view.css.ts
$mol_style_define( $my_shapes_catalog, {
flex: {
basis: rem(40),
grow: 1,
},
Items: {
padding: $mol_gap.block,
},
Item: {
margin: $mol_gap.block,
},
} )Потом реализуем панельку с фильтрами:
/my/shapes/config/config.view.tree
$my_shapes_config $mol_page
title @ \Config
body /
<= Filters $mol_list rows /
<= Forms_labeler $mol_form_field
name @ \Form
control <= Forms $mol_check_list
options *
circle @ \Circle
square @ \Square
triangle @ \Triangle
option_checked*? <=> form*? true
<= Colors_labeler $mol_form_field
name @ \Color
control <= Colors $mol_check_list
options *
red @ \Red
green @ \Green
blue @ \Blue
yellow @ \Yellow
option_checked*? <=> color*? true
<= Brights_labeler $mol_form_field
name @ \Bright
control <= Brights $mol_check_list
options *
dark @ \Dark
light @ \Light
option_checked*? <=> bright*? true
И, наконец, соединим панели друг с другом, получив законченное приложение:
/my/shapes/app/app.view.tree
$my_shapes_app $mol_book2
title @ \Shape Store
pages /
<= Config $my_shapes_config
form* => form*
color* => color*
bright* => bright*
<= Catalog $my_shapes_catalog
form* <= form*
color* <= color*
bright* <= bright*
Placeholder null/my/shapes/app/index.html
<!DOCTYPE html>
<html mol_view_root>
<head>
<meta name="viewport" content="width=device-width, height=device-height, initial-scale=1">
</head>
<body mol_view_root="$my_shapes_app">
<script src="web.js"></script>
</body>
</html>Результаты:
На мобилке
На планшете
На десктопе
Во-первых, хотела бы вас попросить, если у вас ещё есть возможность отредактировать комментарий, убрать и код, и картинки под кат.
Во-вторых, эта статья - не про готовый проект. А про "как писать тестовое - спокойно, пошагово". Поэтому там повторяется тема про кнопку-радио, в двух разных параграфах: сначала её надо сделать, потом прикрутить к редаксу. И, наконец, там задача на самооценку: прикиньте, какое время понадобится на блаблабла, потом ещё прикиньте время на блаблабла в других условиях, и, наконец, выполните на практике и сверьте с предположениями.
ЗЫ ну и ещё. Я не сомневаюсь, что вы способны на вашем фреймворке работать быстро. Но неужели вы сами не видите, как рекламируетесь сейчас под статьёй о реакте с редаксом в тестовом для джунов? Неужели у вас так плохо идут дела? Неужели вот вам нужна вот такая реклама?
Я в шоке, серьёзно.
Туториал о том, как не надо писать код React приложений и какие технологии лучше не брать.
Не использовать Typescript? - Категорически нельзя.
Redux в качестве стейт менеджера? - Категорически нельзя. Ведь есть MobX, который разумеется на порядки лучше по всем пунктам. Отмазка о том, что это условие ТЗ не канает, ибо использование Redux на проекте это автоматическая скорая смерть этого проекта.
Использовать просто SCSS без Css Modules? Зачем? Почему? SCSS + Css modules это то, что доктор прописал. Но спасибо что хотя бы не упали до уровня CSS in JS.
export default lalala- Категорически нельзя! Только named export, без вариантов.
onClick={() => store.dispatch({ type: 'TOGGLE', id: this.props.id })}Что? Зачем? Почему?
onClick={this.toggle}Как бы вот.
Использовать везде длинные цепочки this.props.lalal.tata и т .п. - Зачем?
const { someParam, someOtherParam } = this.props;Я тут тоже пять копеек вставлю
Redux в качестве стейт менеджера? - Категорически нельзя
Конечно, нельзя, авторы как будто постарались сделать максимально неудобно и бойлерплейтно, но когда дело доходит до SSR или, не дай боже, undo, с mobx проблем всё-таки больше. Я экспериментировал с тем, чтобы redux починить (может, даже пост напишу, раз просят), чтобы там типы сходились, селекторы не были нужны, изменения в коде были локальными, обновления массивов занимали логарифмическое время и так далее, но наткнулся на крайне неприятные баги в typescript, которые испортили всю малину. Честно говоря, "хорошего" стейт менеджера я ни разу не видел, и даже смутно представляю, как он должен выглядеть.
onClick={this.toggle}
Тут, кстати, не так и важно. Если пользоваться, например, хуками, у вас будет два варианта:
useCallback, который внутри будет проверять, что dependencies не поменялись, что занимает время, и
вот как у автора написано. Так как висит обработчик не на компоненте, будет обновлено только поле в Set на новый метод, потому что у React синтетические события и слушатель на самом деле вешается один на root. Никаких дорогих вызовов в DOM при этом нет.
В общем, даже без такой оптимизации это дёшево (хоть и небезопасно, потому что кто-нибудь на компонент может отрефакторить и не вынести), и даже с хуками дешевле обычно не сделать. Если бы dispatch пробрасывался правильно, то пришлось бы this.toggle.bind(this) в render делать, и всё равно бы ссылка менялась каждый раз. В Legacy API корректное решение только одно: mapDispatchToProps у connect.
Не использовать Typescript? - Категорически нельзя.
SCSS без Css Modules
спасибо что хотя бы не упали до уровня CSS in JS.
Жаль, нельзя три раза плюсануть.
Честно говоря, "хорошего" стейт менеджера я ни разу не видел, и даже смутно представляю, как он должен выглядеть.
Я не знаю, что написали в двух комментариях выше - я уже обоих забанила (недавно сделала себе хабраклинер. Просто из вашего комментария примерно понятно, что они написали. Что ни редакс, ни вьюекс, ни пиния, ни ещё сто тысяч чертей им не подходят. Что ж вы, наивный, рассчитываете, что подойдёт ваш? Людям просто не нравится ни че го.
Что касается рекламы - вопрос, а есть ли у вас песочница, с вашим фреймворком? Что-то с примерами кода, с которым можно немножечко поиграться, не парясь загрузкой чего бы то ни было и общим дизайном? Подумала об этом, прикидывая, стоит ли вчитываться в ваши примеры кода тут выше.
Скажем так. Я очень люблю изучать что-то новое. Но время моё не резиновое, и браться за изучение вещи, которую я не встречала пока ни в одной вакансии, я бы решилась только в максимально удобных условиях. Подозреваю, что так же думает абсолютное большинство ваших возможных последователей.
Один из вариантов создания комфортных условий - песочница, с отрисовкой на месте в браузере, с готовыми примерами проектов, причём сначала простых, а не вот это вот всё, как здесь.
(здесь, если что, проект, исходно мне приглянувшийся как раз навороченностью. И для начала я его сделала на ванилле - просто так, по приколу. Даже ещё и в мыслях не было ни про какую статью - просто хотелось вот это вот написать и оптимизировать)
Ссылка на песочницу тут. Примеры некоторых приложений можно найти там в директории /mol/app.
(разбанила, посмотрела ваш комментарий, забанила снова)
Коллега.
Это статья - по тестовому. Тестовое - из другой статьи, и на неё в моей статье есть ссылка. Вы ту статью прочли, на которую ссылка?
Многие люди (другие, не вы) ищут работу. У джунов сейчас сложности, устроиться джуном трудно. Поэтому джуны пишут те тестовые, которые выдали наниматели, а не "как надо лучше". А наниматели выдали то, что их лично интересует.
Скажем, я пишу на Laravel. Сейчас уже есть 9-ая версия. Но до сих пор на хедхантере бывает в требованиях Laravel 5. Это категорически устаревший вариант - но там у них монолиты. Которые себе дороже распиливать и переписывать... на питон. Или ещё на что-то, что более лучше, чем Лара, по вашему, например, мнению.
Собственно, да, это важнейший вывод из обсуждения: умные люди не видят темы "тестовое по требованиям". Вынести, что-ли, в подзаголовок статьи?.. Обдумаю этот момент.
Девушку не слышат, очень жаль.
Хабр не торт
Вопрос в следующем, а о чем именно слышать девушку (женщину?) с таким отношением к статье?
Ниже обсудим, как это тестовое выполнить аккуратно, пошагово. Ну и - побочный эффект - относительно быстро.
Тестовое выполнено? Нет. Только лёгкая поверхностная подготовка без решения требуемой бизнес-логики, что можно притянуть к "относительно быстро", но это не итог, а окончание "вступительной части", а где "кульминация", "развязка", "заключение"?
В данном ключе, статья похожа на подобный пример.
Заголовок: Как быстро научиться делать правильно?
Текст статьи: Делать. Оставляйте ваши лайки, комментарии, подписывайтесь на канал
Спрячь и покажи: чистый фронтенд
Чистый фронтенд? Нет. Нагромоздили всё в кучу без аргументации, отсылок, ссылок, сохранения code-style и тд. Пойди, мистер Юниор, разберись с этим сам...
Основной посыл, если судить по первым абзацам, был в том, чтобы выполнить поставленное задание с полным разложением по полочкам всех этапов со всеми затратами по времени, ссылками на используемый материал и так далее и тому подобное. А итог, который приведён здесь, это не половина и даже не одна третья всей выполненной работы, но это уже считается за полностью выполненную работу?
И, множество других, не затронутых вопросов, которые можно затронуть, но стоит ли оно того, если даже базово ничего не раскрыто?..
Вопрос, читаете ли вы Боба Мартина ради того, чтобы что-то там посмотреть досконально. Как делать отдельный конкретный проект.
Я - нет. Я от его книжек жду только помощи в оттачивании моих привычек. У меня есть примерно всё, что на русском вышло - от "Чистого кода" с "Чистой архитектурой" до даже "Рефакторинга" на Джаве от Фаулера, который я не могла не купить, ведь Роберт Мартин Фаулера так любит. Я не пишу на Джаве, я ни один проект не делала такого типа, как Фаулер рассматривает. И между тем эти книги - в моих любимых.
Основной посыл, если судить по первым абзацам, был в том, чтобы выполнить поставленное задание с полным разложением по полочкам всех этапов со всеми затратами по времени, ссылками на используемый материал и так далее и тому подобное.
Основной посыл был в том, чтобы помочь заинтересованному читателю на частном примере данного симпатичного тестового (задание там симпатичное, на мой взгляд) подумать над тем, как он вообще подходит к своим разным тестовым. С чего начинает. Что делает дальше. Где какой выбор.
Я за неинвазивную педагогику, без вталкивания в мозги по максимуму. Правильная педагогика - это подсказки по минимуму, и по возможности только в ответ на вопросы.
На JS не пишу, но иногда бывает.
ИМХО, заголовок статьи не удачный. Внимание цепляет, но содержанию не совсем соответствует. Разбираем тестовое задание для джуна - вот это более в тему. Начало мне понравилось, когда пошел код не совсем.
Захождение в профиль для просмотра статей выглядит как попытка надавить авторитетом.
Спрячь и покажи: чистый фронтенд