Помимо того, что автор, похоже, не знает понятий «передача по ссылке» и «передача по значению» – и делает это поводом для того, чтобы ругать const – он ещё и не знает, как работают дефолтные значения в деструктурировании.
Это:
let userName = eventRecord.user.userName || 'Unknown';
ни разу не эквивалентно этому:
let { name: userName = "Unknown" } = user
Потому что первый случай вернёт 'Unknown' для любого falsy значения, а второй – только и исключительно для undefined.
Эти высосанные из пальца статьи о том, что «если писать плохой код, то код получается плохим» раздражают с каждым разом всё больше, ей-богу.
Занятно, что кого-то в этой игре «цепляет сюжет» и радует «хорошая внутренняя логика».
Сюжет, по которому -20 считается апокалипсисом и надо бросать обжитый город и бежать в пустыню жить палатках.
Сюжет, в котором люди, которые, видимо, тоже осознали предыдущий пункт и хотят вернуться обратно в Лондон, не предлагают сначала отправить туда разведчиков, а устраивают бунты и диверсии, стремясь разрушить город, в котором они сами живут.
Сюжет, где один из сценариев повествует тебе о том, что какие-то высокомерные лорды хотели в «новом мире» сделать из вас рабов и пытались вас физически уничтожить – а когда вы выжили и основали новый город, они пришли к вам греться; после чего на полном серьёзе игра предлагает их впустить и принять, а если вы отказываетесь, они снова раскручивают войну и в конечном итоге вам приходится всех их уничтожить – после чего игра сообщает, какое же вы чудовище, нелюдь и убийца. Действительно, да как ты посмел защищать себя вообще.
Внутренняя логика, по которой самое тёплое по определению здание в городе – теплица – со всеми апгрейдами на утепление и обогреватели, обслуживаемая автоматоном, во время бури перестаёт работать, потому что «так надо». По сюжету, кстати, да. В то время как игровой индикатор температуры здания продолжает показывать, что внутри даже не прохладно.
Логика, по которой ввод удлинённой рабочей смены на угольной шахте, в городе, находящемся на грани выживания, является основанием для роста недовольства и может привести к вашей отставке. Ну в самом деле, мы тут хотим просто попинать балду, а не выжить и вот это вот всё.
Логика, которая в конце сообщает тебе, что ты перешёл черту и стал чудовищем, вне зависимости от твоих действий. Принял ты финальный, самый суровый закон, устанавливающий абсолютную военную/религиозную диктатуру, или не принял (я вот не принял, не было необходимости) – без разницы.
Логика, по которой выполнение «обещаний» даёт крошечный прирост преданности, а провал обещания – несоизмеримо огромный рост недовольства. Так что быстро становится понятно, что обещаний лучше вообще не давать. Тем более, они повторяются снова и снова, одни и те же.
Ну и так далее.
Я не знаю… Игра очень красивая… и всё. В какой-то момент накапливается критическая масса вот этих вот глупостей, и вся «атмосфера» испаряется, оставляя от игры голую градостроительную механику. Люди – такой же ресурс, как уголь и дерево, и все эти моральные выборы превращаются в «детей, калек и преступников – на мороз, остальных – в упряжку». Баланс преданности/недовольства сводится к «запусти удлинённую смену, получи рост недовольства, потом запусти обход города стражниками, нейтрализуй рост недовольства», и так по кругу.
Механика – ну нормальная. Игра как игра. Но сюжет, мораль, «атмосфера»… нету здесь этого.
Выглядит как наичернейшая магия. КАК это всё работает? Где хранится? Как трекается?
И получается, каждый вызов функции – читай «каждый рендер» – приводит к вызовам всех этих хуков? На каждый рендер мы будем порождать целые охапки новых функций (хотя одного раза более чем достаточно)?
Я не владею в должной мере этой информацией – но даже если это никак не влияет на производительность (расскажите, кто разбирается) – неужели вот чисто концептуально это хорошо и правильно? Никогда этого не понимал. Я мирюсь с инлайновыми функциями для function-as-children и для map – но вот это:
это же попросту ужасно выглядит, это очень плохо читается, и это НЕ_НУЖНО™. Очевидно же, что эти коллбеки делают одно и то же. На кой ляд их пересоздавать?
Зато, безусловно, любая обезьянка, едва усвоившая синтаксис стрелочных функций, но ниасилившая этот чудовищно сложный this и жуткие классы, сможет написать рабочий компонент, это да… А потом Фейсбук сочинит какой-нибудь очередной Fiber 19.0, который в очередной раз позволит всему этому хозяйству не лагать.
Полностью поддерживаю. Фронтенд полнится всевозможными библиотеками самого разного уровня качества. И часто действительно приходится самому их патчить – потому что либо исправление их автором либо займёт слишком много времени, а вам надо вотпрямщас; либо вы даже сами пуллреквест сделали, но их там уже 50 штук висит и автору принять их некогда; либо репозиторий вообще заброшен, а форк сделать не вариант, потому что эта библиотека находится в зависимостях ещё нескольких используемых вами пакетов… и так далее.
Простой и доступный синтаксис для приватных полей приведёт только к тому, что сообщество начнёт его пихать куда надо и не надо (а оно начнёт, это же js-сообщество, в котором, ну будем честны – средний уровень компетенции довольно-таки посредственный). И этим катастрофически осложнит жизнь всем, кто будет плодами этого творчества пользоваться.
Объясните мне про Svelte. «Магически исчезающий фреймворк».
Раз он «исчезает», стало быть, он встраивает в код какие-то инлайновые хелперы, которые будут делать его работу. Как babel без плагина transform-runtime.
Раз он их встраивает, то вопрос: как скоро размер этого встраиваемого кода превысит исходный размер фреймворка? Очевидно же, что на крупном проекте это рано или поздно случится. Это происходит скорее рано, или скорее поздно?
А если он не инлайном вставляет, а генерирует какой-нибудь модуль с реюзабельным инструментарием, то какой же он, к чёрту, «исчезающий»?
Я вот никак этого не пойму. Выглядит как полный пшик.
Кто пробовал, поделитесь впечатлениями, пожалуйста.
You may call setState() immediately in componentDidMount(). It will trigger an extra rendering, but it will happen before the browser updates the screen. This guarantees that even though the render() will be called twice in this case, the user won’t see the intermediate state. Use this pattern with caution because it often causes performance issues. In most cases, you should be able to assign the initial state in the constructor() instead. It can, however, be necessary for cases like modals and tooltips when you need to measure a DOM node before rendering something that depends on its size or position.
«Use with caution», но «it can be necessary».
Не вводите людей в заблуждение почём зря.
Всё хорошо в этой статье, но вот говорить о том, что FrostPunk – это «прекрасный релиз» и «вполне себе стратегия» попросту недопустимо. В ней потрясающий визуал, и… всё.
В ней нет ни капли какого-то вызова или сложности (просто сообрази, какие технологии изучать первыми, а какие не нужны вообще).
В ней нет ни грамма, ни грамма вообще атмосферы выживания («Поработать 10 часов вместо восьми, когда от этого зависит жизнь всей колонии? БУНД, БЛ**Ь!!™»; про ставший уже притчей во языцех суп я вообще молчу).
В ней нет даже элементарной внутренней логики и следования собственным правилам (игра сказала «во время бури так холодно, что даже нельзя еду добывать» – и ваши теплицы перестают функционировать, хотя они отапливаются лучше всего в городе, и минимум половину бури игровой индикатор температуры показывает, что в них тепло).
Про бездну сценарного провала не буду даже начинать – просто откройте негативные отзывы в Steam с 1000+ лайков и почитайте, какой «логикой» тут пытаются пичкать нас странные люди, почему-то называющиеся сценаристами.
Да и тот самый визуал, на самом-то деле, настолько паршиво оптимизирован и жрёт столько ресурсов, что где-то с середины игры я уже играл в слайд-шоу, тратя по 20 секунд на просто прокладку дороги. На макбуке про, на секундочку.
FrostPunk – это, к сожалению, большой-пребольшой провал, а ни разу не достойная стратегия.
Нет, нет и нет. Валидация форм не должна быть привязана к html вообще никак.
Почему вообще каждое решение пытается привязать валидаторы к компонентам? Написать десяток компонент, которые каким-то там замороченным образом трансформируют пропсы для потомков, кладут чего-нибудь в локальный стейт, и пытаются реализовать мало-мальски адекватное поведение и реагирование на события, опираясь на лайфхуки Реакта? А потом обрастают вот этими «onModelChange», «onSubmitErrors» (который внезапно не то же, что onSubmit, и вешается не на форму, а куда-то там ещё), и прочим не пойми чем, которого становится тем больше, чем дольше автор пользуется этим решением, понимая, что оно не решает какую-то очередную проблему. И при этом почему-то заявляется, что всё это дело не «задаёт модель управления» и не «требует дополнительные данные».
Форма – это состояние. Это просто кусок данных, который нужно прогнать через функцию-валидатор. Точка. Ни данные, ни валидаторы не имеют к Реакту и компонентам вообще никакого отношения. Валидация отдельно, рендеринг ошибок – отдельно. И будет вам и декларативность, и композиция, и реюзабельность, и даже юнит-тестирование можно делать.
Для валидации требуются:
набор предикатов (типа isEmail)
тексты ошибок (задаваемые вами, а не чем-то сторонним – потому что i18n)
механизм соединения предиката и текста ошибки в функцию-валидатор
механизм соединения валидаторов в функции с более сложной логикой типа «validateScheme»
Это:
ни разу не эквивалентно этому:
Потому что первый случай вернёт 'Unknown' для любого falsy значения, а второй – только и исключительно для undefined.
Эти высосанные из пальца статьи о том, что «если писать плохой код, то код получается плохим» раздражают с каждым разом всё больше, ей-богу.
Сюжет, по которому -20 считается апокалипсисом и надо бросать обжитый город и бежать в пустыню жить палатках.
Сюжет, в котором люди, которые, видимо, тоже осознали предыдущий пункт и хотят вернуться обратно в Лондон, не предлагают сначала отправить туда разведчиков, а устраивают бунты и диверсии, стремясь разрушить город, в котором они сами живут.
Сюжет, где один из сценариев повествует тебе о том, что какие-то высокомерные лорды хотели в «новом мире» сделать из вас рабов и пытались вас физически уничтожить – а когда вы выжили и основали новый город, они пришли к вам греться; после чего на полном серьёзе игра предлагает их впустить и принять, а если вы отказываетесь, они снова раскручивают войну и в конечном итоге вам приходится всех их уничтожить – после чего игра сообщает, какое же вы чудовище, нелюдь и убийца. Действительно, да как ты посмел защищать себя вообще.
Внутренняя логика, по которой самое тёплое по определению здание в городе – теплица – со всеми апгрейдами на утепление и обогреватели, обслуживаемая автоматоном, во время бури перестаёт работать, потому что «так надо». По сюжету, кстати, да. В то время как игровой индикатор температуры здания продолжает показывать, что внутри даже не прохладно.
Логика, по которой ввод удлинённой рабочей смены на угольной шахте, в городе, находящемся на грани выживания, является основанием для роста недовольства и может привести к вашей отставке. Ну в самом деле, мы тут хотим просто попинать балду, а не выжить и вот это вот всё.
Логика, которая в конце сообщает тебе, что ты перешёл черту и стал чудовищем, вне зависимости от твоих действий. Принял ты финальный, самый суровый закон, устанавливающий абсолютную военную/религиозную диктатуру, или не принял (я вот не принял, не было необходимости) – без разницы.
Логика, по которой выполнение «обещаний» даёт крошечный прирост преданности, а провал обещания – несоизмеримо огромный рост недовольства. Так что быстро становится понятно, что обещаний лучше вообще не давать. Тем более, они повторяются снова и снова, одни и те же.
Ну и так далее.
Я не знаю… Игра очень красивая… и всё. В какой-то момент накапливается критическая масса вот этих вот глупостей, и вся «атмосфера» испаряется, оставляя от игры голую градостроительную механику. Люди – такой же ресурс, как уголь и дерево, и все эти моральные выборы превращаются в «детей, калек и преступников – на мороз, остальных – в упряжку». Баланс преданности/недовольства сводится к «запусти удлинённую смену, получи рост недовольства, потом запусти обход города стражниками, нейтрализуй рост недовольства», и так по кругу.
Механика – ну нормальная. Игра как игра. Но сюжет, мораль, «атмосфера»… нету здесь этого.
И получается, каждый вызов функции – читай «каждый рендер» – приводит к вызовам всех этих хуков? На каждый рендер мы будем порождать целые охапки новых функций (хотя одного раза более чем достаточно)?
Я не владею в должной мере этой информацией – но даже если это никак не влияет на производительность (расскажите, кто разбирается) – неужели вот чисто концептуально это хорошо и правильно? Никогда этого не понимал. Я мирюсь с инлайновыми функциями для function-as-children и для map – но вот это:
это же попросту ужасно выглядит, это очень плохо читается, и это НЕ_НУЖНО™. Очевидно же, что эти коллбеки делают одно и то же. На кой ляд их пересоздавать?
Зато, безусловно, любая обезьянка, едва усвоившая синтаксис стрелочных функций, но ниасилившая этот чудовищно сложный this и жуткие классы, сможет написать рабочий компонент, это да… А потом Фейсбук сочинит какой-нибудь очередной Fiber 19.0, который в очередной раз позволит всему этому хозяйству не лагать.
Простой и доступный синтаксис для приватных полей приведёт только к тому, что сообщество начнёт его пихать куда надо и не надо (а оно начнёт, это же js-сообщество, в котором, ну будем честны – средний уровень компетенции довольно-таки посредственный). И этим катастрофически осложнит жизнь всем, кто будет плодами этого творчества пользоваться.
#js_is_public
Раз он «исчезает», стало быть, он встраивает в код какие-то инлайновые хелперы, которые будут делать его работу. Как babel без плагина transform-runtime.
Раз он их встраивает, то вопрос: как скоро размер этого встраиваемого кода превысит исходный размер фреймворка? Очевидно же, что на крупном проекте это рано или поздно случится. Это происходит скорее рано, или скорее поздно?
А если он не инлайном вставляет, а генерирует какой-нибудь модуль с реюзабельным инструментарием, то какой же он, к чёрту, «исчезающий»?
Я вот никак этого не пойму. Выглядит как полный пшик.
Кто пробовал, поделитесь впечатлениями, пожалуйста.
Чего-чего? Я что, пропустил какой-то свежий апдейт Реакта?
Давайте вместе проверим:
reactjs.org/docs/react-component.html#componentdidmount
«Use with caution», но «it can be necessary».
Не вводите людей в заблуждение почём зря.
В ней нет ни капли какого-то вызова или сложности (просто сообрази, какие технологии изучать первыми, а какие не нужны вообще).
В ней нет ни грамма, ни грамма вообще атмосферы выживания («Поработать 10 часов вместо восьми, когда от этого зависит жизнь всей колонии? БУНД, БЛ**Ь!!™»; про ставший уже притчей во языцех суп я вообще молчу).
В ней нет даже элементарной внутренней логики и следования собственным правилам (игра сказала «во время бури так холодно, что даже нельзя еду добывать» – и ваши теплицы перестают функционировать, хотя они отапливаются лучше всего в городе, и минимум половину бури игровой индикатор температуры показывает, что в них тепло).
Про бездну сценарного провала не буду даже начинать – просто откройте негативные отзывы в Steam с 1000+ лайков и почитайте, какой «логикой» тут пытаются пичкать нас странные люди, почему-то называющиеся сценаристами.
Да и тот самый визуал, на самом-то деле, настолько паршиво оптимизирован и жрёт столько ресурсов, что где-то с середины игры я уже играл в слайд-шоу, тратя по 20 секунд на просто прокладку дороги. На макбуке про, на секундочку.
FrostPunk – это, к сожалению, большой-пребольшой провал, а ни разу не достойная стратегия.
Почему вообще каждое решение пытается привязать валидаторы к компонентам? Написать десяток компонент, которые каким-то там замороченным образом трансформируют пропсы для потомков, кладут чего-нибудь в локальный стейт, и пытаются реализовать мало-мальски адекватное поведение и реагирование на события, опираясь на лайфхуки Реакта? А потом обрастают вот этими «onModelChange», «onSubmitErrors» (который внезапно не то же, что onSubmit, и вешается не на форму, а куда-то там ещё), и прочим не пойми чем, которого становится тем больше, чем дольше автор пользуется этим решением, понимая, что оно не решает какую-то очередную проблему. И при этом почему-то заявляется, что всё это дело не «задаёт модель управления» и не «требует дополнительные данные».
Форма – это состояние. Это просто кусок данных, который нужно прогнать через функцию-валидатор. Точка. Ни данные, ни валидаторы не имеют к Реакту и компонентам вообще никакого отношения. Валидация отдельно, рендеринг ошибок – отдельно. И будет вам и декларативность, и композиция, и реюзабельность, и даже юнит-тестирование можно делать.
Для валидации требуются:
И вот где и зачем здесь Реакт и компоненты?
Вот пример того, как надо правильно и декларативно делать валидацию: medium.com/javascript-inside/form-validation-as-a-higher-order-component-pt-1-83ac8fd6c1f0
Правда, автор немного чересчур угорел по функциональщине) Можно было попроще. Но саму суть подхода показывает предельно верно.