Второй и третий пункты были изначально известны, так что они не могли быть причиной «разочарования».
По первому пункту, если автор горазд писать подобный код, то стоило бы тогда попробовать объявлять все типы как ReadonlyDeep<сам типа> и не знать проблем (реализацию ReadonlyDeep / DeepReadoly можно легко найти в сети).
Валидация в рантайте не должна быть частью TS тк TS не должен влиять на перформанс в райнайме. Кому нужно делают сами или используют множество существующих для этого библиотек. На практике, валидация в рантайме нужно если в систему поступают «ненадежные / сырые» данные от внешних источников. Но в таком случае в любом, даже строгом и компилируемом языке валидация будет выполнятся кастомным (например по описанной схеме) образом тк «сырые данные» это просто набор байт.
PS logrocket.com известны тем что постят подобные/сомнительные материалы ради некого хайпа, чтобы привлечь внимание к своему сервису. Персонаж Eric Elliott кстати из той же серии.
Событие то происходит не в самом компоненте, компонент только транслирует событие/нотификацию/порцию-данных-в-стриме в шаблон. По моему мнению async pipe нужно указывать отдельным пунктом при перечислении тригерров CD при использовании onPush стратегии тк для новичков это не очевидно.
если изменилось значение Input();
если произошло событие внутри компонента или его потомков;
если проверка была запущена вручную.
CD также дернется когда новое значение пролетает через AsyncPipe используемый в шаблоне компонента. Часто бывает удобно, особенно когда используется реактивный стор (NgRx или самодельный на BehaviourSubject).
Конечно подобные позиции для обычного senior или lead без функции менеджмента встречаются редко, но они есть, даже если судить только по личному опыту за последние несколько лет. Конечно если сидеть на жопе ровно, то хороших позиций не будет. Про долину ремарка была только относительно тесла-бонуса, остальное про наш континент.
Айтишники-водопроводчики это в компаниях где айти не является профильным направлением, где они расцениваются как балласт. В совсем шарагах с придурковатым менеджментом или руководством вышедшим из sales persons (больше по-западному). Ну и наверно в компаниях «работать в которых большая честь» (нематериальная мотивация базовый навык любого, даже придурковатого менеджера).
Речь не идет о совсем уж рядовом сотруднике, который будет просто выполнять команды пришедшие сверху, но о хорошем синьоре (не 23 лет, а скорее 30+). Быть опытным и уверенным в себе специалистом. Резюме с какими-никакими достижениями. Самому стучаться в разные двери не помешает. Знакомства, особенно полезно с возрастом. Лично мне за последние несколько лет реальные варианты значительно выше рынка попадались через ректутеров которые сами на меня выходили видимо по линкедин профилю (в одном случае был оффер). О Ламбо не слышал, но например в той самой долине даже на сайнап бонус джуниора от одного из грандов вполне можно брать теслу и не всегда самую бюджетную версию.
Платят, но понятно что в большинстве случаев это не те вакансии которые публикуются в паблике. Но и налоги в Европе приличные, хотя допустим в случае Швейцарии все равно получилось бы интересно или в NL с налоговой 30% скидкой для экспатов (на первые 5 лет вроде только).
Существуют готовые оптические кабели Thunderbolt 3, вроде до 100 метров тянут на полной скорости (40 Gbps), дальше видимо скорость будет падать, не вникал. Так вот через такой проводок можно все данные сразу передать, а не только картинку/звук. По сути можно изолировать компьютер в кладовке/подвале, провести такой провод к рабочему месту, там поставить хаб с разными портами и наслаждаться тишиной и отсутствием ящика в комнате.
Двухфакторная аутентификация это «пароль + еще что-то», то есть нужно знать и пароль и иметь доступ ко фторому фактору (через И, не ИЛИ). Если в вашем случае можно сбросить пароль просто имея доступ к телефонному номеру, то это мягко сказать гупость системы который в пользуетесь, а не двухфакторная аутентификация.
PS К тому же использовать номер телефона как второй фактор не дальновидно, лучше уже TOTP токены или хардварные ключи.
interface Action {
type: string;
name?: string;
} Для нормальной строгости все возможные экшены с их пайлоадом должны быть предетерминированы, а здесь сырые типы.
Для шаринга данных и сервисы и шину событий прикрутить можно и еще что-то придумать. Но в больших приложениях хочется использовать единый и стандартный подход. Кроме этого часто цель не только в шаринге данных между частями системы используя единый стор, но также сериализация и обратная операция состояния приложений.
Нюансы. Ну например такой нюанс что организацию обмена данными между компонентами можно делать и без input/output, например через центральный стор (ngrx/redux подобные поделки). Ведь input/output часто не самый удобный вариант, например когда нужно перекидывать данные между компонентом верхнего уровня и сидящим глубоко в иерархии или между «глубокими сидящими» компонентами в разных ветвях иерархии. Ну и разумеется иммутабельный центральный стор довольно удобно использовать c «onPush» компонентами.
Я вас наверно удивлю, но передача объекта по ссылке это обычное поведение в JS, здесь ведь нет встроенной иммутабельности. Если выполняется сериализация, то это уже часть логики приложения.
Главный секрет в том что это должно быть действительно десктопное приложение. То есть приложение предоставляющее дополнительный функционал по сравнению с обычной веб страницей за счет возможности интеграции с операционной системой что недоступно для браузеров (используя Node.js который встроен в Electron) и за счет возможности внедрения в оригинильную веб страницу произвольного кода что дает возможность расширить функционла на десктопе. К сожалению, как правило, это не так.
Конечно же это не смешно, а очень грустно. Ведь президент РФ оказывается не верит что граждане живут на ЗП в сотни раз ниже чем его министры тратят на гостиницу в день. Благодарю за развернутый ответ.
Меня просто окончательно выбила из колеи зарплата, которую я получил за первую половину мая 2019 года — это было что-то около 2600 рублей (повторяю прописью — две тысячи шестьсот рублей).
По первому пункту, если автор горазд писать подобный код, то стоило бы тогда попробовать объявлять все типы как ReadonlyDeep<сам типа> и не знать проблем (реализацию ReadonlyDeep / DeepReadoly можно легко найти в сети).
Валидация в рантайте не должна быть частью TS тк TS не должен влиять на перформанс в райнайме. Кому нужно делают сами или используют множество существующих для этого библиотек. На практике, валидация в рантайме нужно если в систему поступают «ненадежные / сырые» данные от внешних источников. Но в таком случае в любом, даже строгом и компилируемом языке валидация будет выполнятся кастомным (например по описанной схеме) образом тк «сырые данные» это просто набор байт.
PS logrocket.com известны тем что постят подобные/сомнительные материалы ради некого хайпа, чтобы привлечь внимание к своему сервису. Персонаж Eric Elliott кстати из той же серии.
PS К тому же использовать номер телефона как второй фактор не дальновидно, лучше уже TOTP токены или хардварные ключи.
interface Action {
Для нормальной строгости все возможные экшены с их пайлоадом должны быть предетерминированы, а здесь сырые типы.type: string;
name?: string;
}