PropTypes — это некий конспект того, что должно приходить в компонент и в каком виде. В процессе разработки и поддержки — это очень удобно. Конечно, игнорирование предупреждений или внезапное изменение чего-то от бэкэнда, приведет к проблемам в production версии.
чтобы компонент самостоятельно мог выдавать ошибки или мог принудительно генерировать дефолтные значения для props, если ничего не было передано (или конвертировать входные значения в подходщий формат, если они имеют неправильный)
Здесь +1, но не согласен, что делать это «лучше, вместо описывания PT».
p.s. вместе с flow, propTypes становятся еще более удобными в режиме разработки и поддержки.
Вас понял. Я не делал анонса на хабре, так как не знаю как это здесь подать. У меня платного аккаунта нет, а анонс больше подходит под рекламу. В противовес этому, в разборе уже без ссылок (только на github), без призывов к переходу в паблики, разобраны ошибки, которые в отрыве от всей движухи в целом тянут на отдельную заметку, полезную для начинающих.
p.s. надо подумать, как можно сделать анонс и не разгневать публику. Аккаунт с карточкой подписи, в которой можно указать vk/telegram и тд на 3 месяца стоит дорого (14 тысяч), и тоже не особо позволяет постить ссылки в самой статье, а корпоративный аккаунт стоит и того дороже (было 70).
Спасибо за развернутый комментарий. По макету/примеру хорошее замечание, возможно, будут добавлены в будущем.
Про детали и лень — хороший пример. Если делаешь — делай хорошо. Фронтенд, это не только про «вау как здорово и классно, и платят много», это так же про не любимые «доработки/допиливания» мелких деталей, особенно возня с формами и ошибками как раз. Мы на видео этого коснулись. На трансляции некоторые ребята ответили — да, было лень. С ленью надо работать. Заодно они увидели реальные примеры того, что им могут отправить на доработку после code-review. Поэтому, я считаю, что это «несет реальную информацию».
p.s. хабр взрастил какой-то пласт обидчивых авторов и комментаторов?) Конструктивная критика всегда хорошо, никаких обид. Для меня junior react — начинающий разработчик (фронтендер), который пишет на стэке react. Это отчасти и начинающий javascript разработчик, или не начинающий js разрабочтик, но начинающий в react, или наоборот ничего не знающий в javascript, но так же тот, кто начал свой путь с react.
Зависит от бэкэнда. Если бэк сразу выдает «читаемую» ошибку — то можно сразу ее и выводить. Если нет — то нужно «переопределить». В задании, бэкэнд не умел выдавать красивую ошибку, а присылал: wrong_email_or_password
Хабр — это площадка, где люди делятся знаниями. 21 человек добавил статью в закладки, значит как минимум им это оказалось полезно. Так же люди по-прежнему, голосуют за посты, но с этим сложнее, так как требуется карма. Однако, и тут выплыли в плюс (с трудом, кхе-кхе). Для часового перевода по React Native был сделан конспект. Здесь конспект делать неуместно.
Никакой пользы именно для хабра не имеющая
Плюсы за статью и закладки — говорят о том, что кому-то все же польза была. Поэтому, я продолжу работать для этих людей, пока динамика будет положительной.
эм… там не удобно, вот посмотрите на пример. Если вы не против помочь сделать из сабов статью с абзацами, то напишите в личку, я вышлю вам полный файл и укажу вас (по желанию) в статье.
Про усвоение — это на любителя. Согласен, это не так удобно, чем если бы был голосовой перевод. Но в целом, определенным группам людей (кто чаще учится по видео) это нравится, поэтому такую аудиторию терять не хочется. К тому же, кто-то включает субтитры только в определенных местах и это так же повышает лояльность к нашему делу.
Переводы текстовые делаем, но обычно уже не выкладываем на хабр.
В заголовке написано (субтитры). Они были созданы человеком, подогнаны по времени для удобного чтения и добавлены к видео. Оригинальное видео не содержит даже англ. субтитров сделанных человеком. В публикациях есть и другие подобные посты, там к счастью, нет такого недовольства.
Внятно, конечно, но не на русском языке. Поэтому тут сабы либо для тех, кто вообще не знает языка автора, либо для тех, кто хочет уточнить какой-то момент, даже если по коду все понятно.
Вы имеете в виду, когда проблема была на стадии переписки [1] или когда уже началась реальная консультация [2]?
Для начала, как это происходит: «ученик» пишет запрос, «Добрый день, хочу получить консультацию». Если в письме нет уточнения о чем именно, я прошу дополнить вопрос. Таким образом у меня в распоряжении оказывается письмо с темами/кодом для обсуждения. Смотреть код — тоже работа, поэтому я беру такой заказ, если проблема цепляет настолько, что можно посмотреть код, или потому что знаю наверняка, что просмотрев код — быстро выясню могу/не могу провести консультацию. Однако, многие ценят чужое время и описывают проблему словами, а код демонстрируют уже на этапе консультации.
[1] Если я понимаю на стадии переписки, что не смогу решить проблему, то сообщаю об этом. Невозможно быть экспертом во всем, даже в такой небольшой (относительно) теме как реакт. Например, с выходом четвертого роутера, я долгое время продолжал работу с третьим и мне было некогда разбираться с новой версией. На этом этапе я написал немало отказов, к сожалению.
[2] Проблема на стадии консультации может возникнуть, если клиент о чем-то умолчал (обычно по незнанию), либо мы недопоняли друг друга на стадии переписки. Такое решить легко, мы просто обсуждаем как быть дальше. Если же, проблема со стороны клиента была описана как нужно, но решить ее не получается, то предлагаю следующие варианты:
а) (если думаю, что решить можно быстро) мы вместе гуглим/смотрим документацию, и это время поисков вычитается из итогового времени. Тут бонус для обучающегося — он смотрит, как ищет проблему человек с квалификацией (то есть, я переключаюсь на свой экран)
б) сообщаю, что сейчас проблему решить не выйдет, но есть следующие мысли (перечисляю) и мы прощаемся без оплаты за эту часть, либо если это был единственный вопрос — без оплаты вообще.
Я все жду, когда случится консультация, после которой не будет оплаты. Тогда мне придется брать предоплату, но пока такого не было, пришедшие ни чем не рискуют. В конце каждой консультации, мы подсчитываем затраченное время (из которого можно что-то вычесть или выдать скидку) и дело в шляпе.
Недовольные консультациями, думаю были. Но открыто мне об этом никто не говорил. Однако, если человек пришел «заряженный» позаниматься несколько раз (о чем он говорит), а потом пропадает, то я это принимаю на личный счет. На моей памяти таких было 2 случая, вроде бы. Один, как мне кажется недавно, думаю мой промах был в том, что за отведенный час не успел выдать все, что ожидал ученик. Другой не помню уже, но «засечку в личном деле» нарисовал.
p.s. корп.клиенты как правило берут пробный сеанс (на 1 час), а потом присылают документы на оказание услуг наперед. С этим пока проблем не было, поэтому обошлось без возвратов.
PropTypes — это некий конспект того, что должно приходить в компонент и в каком виде. В процессе разработки и поддержки — это очень удобно. Конечно, игнорирование предупреждений или внезапное изменение чего-то от бэкэнда, приведет к проблемам в production версии.
Здесь +1, но не согласен, что делать это «лучше, вместо описывания PT».
p.s. вместе с flow, propTypes становятся еще более удобными в режиме разработки и поддержки.
1) диспатчнуть два экшена (например, SET_ICONS_FOR_COMP_A и SET_ICONS_FOR_COMP_B)
2) делать это в компоненте
В зависимости от частоты перерисовок компонента и каких-то еще условиий задачи, можно выбрать то, что больше подойдет. Мне пока импонирует вариант 1.
Так или иначе, в задаче хотелось показать, что если вам с бэкэнда пришли не угодные данные, то на мой взгляд, лучше их «перевернуть» в редьюсере.
p.s. надо подумать, как можно сделать анонс и не разгневать публику. Аккаунт с карточкой подписи, в которой можно указать vk/telegram и тд на 3 месяца стоит дорого (14 тысяч), и тоже не особо позволяет постить ссылки в самой статье, а корпоративный аккаунт стоит и того дороже (было 70).
Про детали и лень — хороший пример. Если делаешь — делай хорошо. Фронтенд, это не только про «вау как здорово и классно, и платят много», это так же про не любимые «доработки/допиливания» мелких деталей, особенно возня с формами и ошибками как раз. Мы на видео этого коснулись. На трансляции некоторые ребята ответили — да, было лень. С ленью надо работать. Заодно они увидели реальные примеры того, что им могут отправить на доработку после code-review. Поэтому, я считаю, что это «несет реальную информацию».
p.s. хабр взрастил какой-то пласт обидчивых авторов и комментаторов?) Конструктивная критика всегда хорошо, никаких обид. Для меня junior react — начинающий разработчик (фронтендер), который пишет на стэке react. Это отчасти и начинающий javascript разработчик, или не начинающий js разрабочтик, но начинающий в react, или наоборот ничего не знающий в javascript, но так же тот, кто начал свой путь с react.
Плюсы за статью и закладки — говорят о том, что кому-то все же польза была. Поэтому, я продолжу работать для этих людей, пока динамика будет положительной.
p.s. спасибо за обратную связь
Переводы текстовые делаем, но обычно уже не выкладываем на хабр.
p.s. большую часть видео идет речь только про getDerivedStateFromProps. Само видео короткое (9 мин)
Для начала, как это происходит: «ученик» пишет запрос, «Добрый день, хочу получить консультацию». Если в письме нет уточнения о чем именно, я прошу дополнить вопрос. Таким образом у меня в распоряжении оказывается письмо с темами/кодом для обсуждения. Смотреть код — тоже работа, поэтому я беру такой заказ, если проблема цепляет настолько, что можно посмотреть код, или потому что знаю наверняка, что просмотрев код — быстро выясню могу/не могу провести консультацию. Однако, многие ценят чужое время и описывают проблему словами, а код демонстрируют уже на этапе консультации.
[1] Если я понимаю на стадии переписки, что не смогу решить проблему, то сообщаю об этом. Невозможно быть экспертом во всем, даже в такой небольшой (относительно) теме как реакт. Например, с выходом четвертого роутера, я долгое время продолжал работу с третьим и мне было некогда разбираться с новой версией. На этом этапе я написал немало отказов, к сожалению.
[2] Проблема на стадии консультации может возникнуть, если клиент о чем-то умолчал (обычно по незнанию), либо мы недопоняли друг друга на стадии переписки. Такое решить легко, мы просто обсуждаем как быть дальше. Если же, проблема со стороны клиента была описана как нужно, но решить ее не получается, то предлагаю следующие варианты:
а) (если думаю, что решить можно быстро) мы вместе гуглим/смотрим документацию, и это время поисков вычитается из итогового времени. Тут бонус для обучающегося — он смотрит, как ищет проблему человек с квалификацией (то есть, я переключаюсь на свой экран)
б) сообщаю, что сейчас проблему решить не выйдет, но есть следующие мысли (перечисляю) и мы прощаемся без оплаты за эту часть, либо если это был единственный вопрос — без оплаты вообще.
Я все жду, когда случится консультация, после которой не будет оплаты. Тогда мне придется брать предоплату, но пока такого не было, пришедшие ни чем не рискуют. В конце каждой консультации, мы подсчитываем затраченное время (из которого можно что-то вычесть или выдать скидку) и дело в шляпе.
Недовольные консультациями, думаю были. Но открыто мне об этом никто не говорил. Однако, если человек пришел «заряженный» позаниматься несколько раз (о чем он говорит), а потом пропадает, то я это принимаю на личный счет. На моей памяти таких было 2 случая, вроде бы. Один, как мне кажется недавно, думаю мой промах был в том, что за отведенный час не успел выдать все, что ожидал ученик. Другой не помню уже, но «засечку в личном деле» нарисовал.
p.s. корп.клиенты как правило берут пробный сеанс (на 1 час), а потом присылают документы на оказание услуг наперед. С этим пока проблем не было, поэтому обошлось без возвратов.