Василий Мажекин

Angular HTML compiler
Вот компонент которому можно передать динамический темплейт в строке и объект с данными, В проде тоже работает, там в главном модуле нужно один раз прописать модуль для jit

Посмотрите в этом направлении https://www.npmjs.com/package/@codehint-ng/tabs
Тут можно что угодно помещать в заголовки и контент табов можно размещать в произвольных компонентах в произвольных местах.

Да ангуляр-приложение представляйте как приложение работающее на машине пользователя, как десктопное или мобильное приложение. Только оно крутится в экосистеме браузеров, а не операционных систем.

Если будет левый токен, то при навигации по закрытым страницам вы же все равно какие то данные запрашиваете. Токен передается серверу в каждом таком запросе в хедере (данные закрытых страниц должны быть защищены на сервере), и если токен левый вам сервер вернёт ошибку 401, и если вы ее получили то делайте редирект на логин страницу или на страницу ошибки 401 и удаляйте токен.

// Объект
const obj = {
   a: 1, b: 2, c: 3, d: 4, e: 5
}

// Массив названий полей, которые нам нужны
const arrayOfRequiredFields = [ 'a', 'b', 'd' ]


const resObj = Object.keys(obj).reduce(
 (acc, key) => arrayOfRequiredFields.some(field => field === key) ? {...acc, key: obj[key]} : acc
, {});

Это девопс инженер, а не техлид

техлид-тимлид это мутная роль и странное наименование специалиста, когда не получается сформулиравать круг занятий и вспомнить профессию, выбирают "любого толкового программиста", "выражают ему свое восхищение", дают почетное звание тимлид-техлид-шмимлид, нагружают непонятным кругом обязанностей и полномочиями (от hr до постановки бизнес-задач и такое бывает), дают спокойно напороть отсебятины, чтоб он расписал все процессы как он их видит ))). И разработка превращается в секту под предводительством этого шамана.

Например, когда человек называет свою специализацию сразу понятно чем человек занимается на проекте, то ли это девопс-инженер, или ux-дизанер, или скрам-мастер, тестировщик, бекенд-разработчик, фронтенд-разработчик. Вопросов нет, понятно чем люди занимаются и за что отвечают. Техлид или тимлид, обычно туманно и непонятно объясняет свою позицию на проекте и владеет всем по чуть-чуть, но ничего глубоко и профессионально.

Законченный, якобы, проект с кривым кодом(архитектурой) - это как дом с кривым фундаментом, зачастую у него не то что низкая, у него отрицательная стоимость. То есть с нуля действительно дешевле переписать будет. Но как избежать повтора ситуации (когда вроде бы все готово, но по мелочам ничего не работает)? Для этого нужно заказчику или руководителю проекта добиватся законченных изолированных микро-решений на каждом участке (на каждой форме - диалоге - старнице). Нужно не боятся и менять первоначальные решения (просить дополнять или изменять функционалность) и смотреть как програмист будет подстраиватся под изменившиеся бизнес-требования (это реальные ситуации которые будут возникать в промышленном использовании продукта от пользователей). Если программист застревает - это и есть реальная скорость разработки проекта и признаки что проект не будет доведен до конца и выведен в эксплуатацию. А то что заказчику. там "архитекторы" накидывают код, и говорят что там все сделано и надо только дописать - это разработка нулевая или даже с минусовой стоимостью.

Ну тут как бы вот какая ситуация. Программирование такая штука, что самое страшное - это запутаться в собственном коде. В основном проекты факапятся именно из-за этого. Много программистов которые знают по чуть-чуть разные языки, апи, интерфейсы, всякие модные термины и т. п. Но очень мало программистов, которые знают их глубоко и могут организовать код так, чтобы и самим не запутаться и не запутать своих коллег. Для этого требуется опыт и умения, немного другие, чем небольшие знания языка и всяких апи. Тут нужны умения применять инструменты, рефакторинга и всяких приемов разделения проекта на части, декомпозиции.

Ну начинается проект все ок. Программист пишет - пишет вроде бы начинают появляться рабочие экраны или работающий функционал, но он не следит за чистотой кода, игнорит или не знает рекомендованные стайлгайды, стиль кода постоянно меняется, все накручивается на базовых примитивах типа for-if, нарушаются декомпозиционные сущности, рефакторинг собственного кода (для дальнейшего облегчения понимания) отсутствует (главное чтоб работал). Постоянно его костылит. И код превращается в кучу крепко завязанного, запутанного говна. Попытки внести фиксы или дополнительный функционал в такой код приводят к ещё большим проблемам. Причем снаружи - это действительно выглядит как будто что то не работает по мелочам. Но поддержка и развитие такого проекта останавливается и автору коду уже невмоготу с ним работать, потому что петля этого монолита уже крепко затянута. И человек либо тянет время и просит нанять ещё разработчиков, либо просто уходит на "лучший офер". Заказчик думает что там осталось совсем чуть чуть. И любая попытка погрузить нового программиста в этот проект проваливается.

Объясняйте заказчику, что код очень сильно запутан. Приводите упрощенные примеры запутанности и приводите примеры их решения. Воспринимайте этот запутанный проект - как челендж для себя. Думайте о том, что если вы его распутаете, поблочно перепишете и разложите все по полочкам, ваша стоимость увеличится в разы как специалиста. Оцените свои силы, научитесь жёсткому параллельному рефакторингу вместе с текущими задачами, декомпозируйте код на части, изолируйте части кода. Заказчику не произносите слово "рефакторинг". А писать с нуля - это не вариант. Вы просто протянете время и не факт, что не придёте к тому же, что сделал предыдущий разработчик. И потом свалите. Лучше научитесь плавно метаморфизировать проект при этом выполняя текущие задачи.

Причем если предыдущий автор ушел с проекта - это не самая плохая ситуация, Вы спокойно рефакторите код, перестраиваете блоки, декомпозируете сущности и как-то худо бедно выводите проект из кризиса. Но если автор ещё работает на проекте, то это ситуация гораздо сложнее, вы постоянно будете сталкиваться сопротивлением, что типа все в порядке, просто "вы не умеете работать с этим кодом" (запутанным говном), которое вам нужно "просто пофиксить", а не рефакторить и понимать.

И самый интересный финт, получается такой, что в глазах заказчика автор(источник проблем и говнокода) будет выглядеть как некий профессионал с гениальным кодом и архитектурой, код которого никто понять и поддерживать не может, потому что якобы все приходящие на проект не достаточно квалифицированы.

Да... работа такая у программиста запутанное(сложное) делать понятным(простым), а не наоборот.

По-моему вы тут нагородили проблем из ничего. Из вами написанного вывод: ни в чем не уверен, ничего полностью не знаю, нет опыта, предлагают синицу в руках, а вы думаете может поболтаться ещё без работы и без опыта и искать какие то коммерческие рельсы. Там не спокойные рельсы, а очень высокая конкуренция особенно среди джуниоров. Конечно соглашайтесь на текущее предложение, сейчас вы никто с дипломом, а после пары лет будете специалист с опытом, и вас коммерческие рельсы сами найдут. Тем более, что опыт работы программистом в Минобороны для коммерческих рельс звучит впечатляюще.

В сторону тимлида не надо развиваться - это промежуточное состояние, неопределившегося пока специалиста - и не программист (зачастую программировать уже не охота и начинают утрачиваться программистские скилы), и не управленец (не успевает освоить нужные знания по управлению), просто пока думает куда развиваться дальше, либо продолжать программировать, проектировать ПО и развиваться сильным техническим спецом (айти архитектура), либо углубляться и переходить в профессиональное управление разработкой и становиться скрам-мастером. Профессии будущего.

Заверните в промисы и устанавливайте очередность какую пожелаете.

image$ = new Promise((resolve) => {
 $('.image').load(() => {
  alert ('2'); 
  resolve();
 });
});

alert1$ = new Promise(
(resolve) => {
 alert(1); resolve();
})

alert3$ = new Promise....

// желаемую очередность установите тут
image$.then(() => { 
 return alert1$;
}).then(() => {
 return alert3$;
}).then(() => {  });

бесплатные и полубесплатные скрам доски
https://azure.microsoft.com/en-us/services/devops/...
https://trello.com
https://www.pipefy.com
https://asana.com
https://www.zoho.com/projects
https://www.icescrum.com
https://www.yodiz.com
https://www.vivifyscrum.com

Да не переживайте, это обычная ситуация, это скорее всего случай когда валится проект, руководство ищет выход из кризиса, какому нибудь лиду предлагает кандидатов, а он упирается и отсеевает всех, чтобы все от него зависело. А если вы ещё и знания показываете вам вообще туда дорога закрыта. В крайнем случае там может появится очень сильно лояльный джун на которого потом повесят ответственность за весь факап (типа лучше него невозможно спецов найти). И ничего по большому счету тут сделать нельзя, пока все не лопнет, и не поменяют всех вместе с лидом.