Demian Smith

Это решит проблему:

<meta name="viewport" content="width=device-width">

TL;DR

"Портативные устройства часто рендерят страницы в виртуальном окне, называемым вьюпортом, ширина которого обычно больше ширины экрана" - mdn. Для обхода этого поведения используется свойство width мета-аттрибута viewport, равное значению device-width: content="width=device-width". В таком случае ширина вьюпорта будет равна ширине экрана устройства.

width - не единственное свойство, позволяющие изменять заложенное поведение вьюпорта, полный список доступен на mdn или в спеке. Стоит отметить, что это драфт, но современные браузеры его стараются имплементировать.

Другое свойство, используемое тобой в примере, - initial-scale, устанавливающие зум вьюпорта в определенное значение при первичном запуске сайта. Значение может варьироваться от 0.1 до 10. При 1 зум равен ширине вьюпорта (можно сказать, что в данном случае зум отсутствует). По дефолту же зум равен значению auto, который высчитывается путем деления исходного значения вьюпорта на значение реально отрендеренного холста, что позволяет отобразить весь холст на экране (формула чуть сложнее). В твоем случае зум равен ширине экрана (т.к. ширина вьюпорта равна ширине экрана через width=device-width), т.е. 320px. Когда ты устанавливаешь ограничение на минимальную ширину тела документа, равную, например, 480px, то по дефолту у тебя будет горизонтальный скролл при зуме равном 1. Это логичное поведение, заложенное в спеке. Это как пытаться посмотреть сайт с ограничение в 1600px в ширину с ноутбука, там тоже будет горизонтальный скролл.

Чтобы обойти это поведение достаточно установить initial-scale в значение auto, или убрать это свойство вообще, т.к. это значение по дефолту.

Строка false, разумеется приводится к true.
В РНР будет ровно то же самое, условие if('false') выполнится.

А чтобы false воспринималось как булево значение, а не как строка, надо либо сказать твоему яваскрипту, что он ждёт специальным образом кодированные данные, либо РНР - что он отправляет не HTML, а некий другой формат.

В общем, обилие комментаторов с советами вида "пальцем в небо" наглядно показывает уровень понимания средним пользователем похапе своих действий.

В целом направление мысли верное - система воспринимает переданное значение как строку, а не как булево значение. Но на этом мысль и останавливается.
Хотя при некотором усилии можно было бы продолжить и рассудить - что поскольку протокол НТТР чисто текстовый, то никакие булевы значения через него по умолчанию передать нельзя. А так же объекты, массивы, и прочие типы данных.
И для того чтобы сделать это возможным, был придуман специальный формат кодирования. Который позволяет передавать данные различнызх типовв, и который автор, несомненно, уже применяет (вследствие чего, собственно, из булева значения и получается строка false).

То есть единственным недостающим звеном в этой головоломке является контекст, в зависимости от которого яваскрипт будет воспринимать строку false либо как строку, либо как булево значение. То есть нужен способ РНР и яваскрипту договориться, в каком формате они обмениваются данными. Стандартным способом является НТТР заголовок Content-type. Который скажет браузеру, что данные не в дефолтом формате HTML, а в другом.

Либо как вариант, можно прямо при вызове функции ajax явно задать, в каком формате придут данные. Если озаботиться изучением документации по этой функции.

Во-первых, сейчас модератор грохнет ваш вопрос за нарушение пункта 3.8 правил. Во-вторых, парадигмы, подходы, шаблоны и принципы - это инструменты управления сложностью кодовой базы, а инструмент надо выбирать под задачу - не стоит наворачивать многоуровневую абстракцию на FizzBuzz. В-третьих, KISS не исключает SOLID.

В общем решил проблему одной строкой.
ИЕ как-то тупо реагировал не на эти стили, а на стили стороннего компонента выше по иерахии ДОМа.
Особенность рендера, что данные загружаются после моунтинга.
Видимо ИЕ принимал высоту контента без данных и не менял их после их подгружения.
Заменил у того верхнего родителя height: 100% на flex-grow: 1 и все норм стало

test.component.html:

// Пускай это компонент <app-test></app-test>
<p style="color: red;"><ng-content></ng-content></p>

// app.html:
<app-test>Behold the RED TEXT!</app-test>

В первом случае значение присвоено по умолчанию всем новым объектам класса. (так обычно не делают)
Во втором случае используется прямое присваивание. (так тоже обычно не делают)

Можно подменить глобальный fetch своей оберткой, и в ней выполнять нужный вам код, т.е. внутри выполнить оригинальный fetch и после него вызывать свои функции.

Но может стоит посмотреть сам сниппет, может у него события какие нормальные есть?

Это извечная тема для дискуссий. Стандартизация - настолько размытое понятие, что оно просто игнорируется и все "стандартизируют" код по-своему) В команде это часто зависит от предпочтений тим лида. Выносите так, как вам удобно - важно чтобы вы думали. Вы правильно делаете, что выделяете абстракцию. Например, эту функцию можно вынести просто как рендер списков, не привязывайте её к компонентам. Назовите папку src/utils.

В каждой команде, выделяют абстракции по-своему, поэтому если вы вообще понимаете что выделять абстракции нужно, то чего вам стоит сейчас вынести в src/utils, а потом, если вашей команде не понравится, вынести куда-то ещё - смысл тот же.

Сначала отфильтруйте массив, а потом мапьте:

tasks.filter(task => task.EX === 5).map(task => (
   <Task key={task.ID} task={task} />
))

В сущность должны передаваться конкретные параметры: $id, $login, а не массив $userData, из которого потребуется извлекать эти данные, проверять их тип и существование. При таком подходе вы можете использовать типизацию и будете уверены в переданных данных.

Вы так же можете создавать сущность разными фабричными методами.

Исключение должно быть в методе get() вашего репозитория. И не путайте методы find() и get():

• find() — возвращает сущность или null.
  
• get() — возвращает сущность или исключение.
  

// library.d.ts
type DefaultExport = {
  run(): void;
  check?: (count: number) => void;
};
declare const de: DefaultExport;
export default de;

В приложении должен быть один и только один источник правды. На роль такого источника очень хорошо подходят хранилища состояний, предоставляемые такими библиотеками, как redux/mobx/vuex/...
Если в приложении несколько источников правды, то раньше или позже между ними возникнет конфликт, который приведет к трудноотлаживаемым багам.

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

Во-первых - опечатка:

cildren

Во-вторых - зачем reduce? Достаточно map:

const copyTree = (tree, f) =>
  tree.map(n => {
    n = f instanceof Function ? f(n) : { ...n };
    if (n.children instanceof Array) {
      n.children = copyTree(n.children, f);
    }
    return n;
  });


const dataCopy = copyTree(data, ({ name: key, ...x }) => ({ key, ...x }));

const traversal = (arr, prevKey, key) => arr.map((o) => {
  const newObj = {
    ...o, 
    [key]: o[prevKey], 
    children: traversal(o.children, prevKey, key)
  }; 
  delete newObj[prevKey];
  return newObj;
});

const newArr = traversal(data, 'name', 'key');

P.S. ваш код не работает из-за опечатки в названии свойства в последнем объекте

Я делаю систему контроля яркости.
Я хочу настраивать яркость всего (гирлянды, люстры, фонарика, экрана телефона).
В коде выглядит примерно так

class BrightControl
   public void setDefaultBright(Object obj){
         obj.setBright(10);
   }
}

Метод setDefaultBright принимает любой объект. Ведь мне всё равно яркость чего настраивать.
Мой код используют другие разработчики, я не могу контролировать их.
Как мне убедиться, что у объекта, который мне пришел в качестве аргумента, есть метод setBright?
Я пишу интерфейс, и говорю, что метод setDefaultBright принимает только объекты, которые реализуют этот интерфейс.

Если кроме меня самого никто не будет использовать эту систему контроля яркости. То я просто буду держать у себя в голове, что в метод setDefaultBright можно отправлять только объекты, у которых есть метод setBright, но поддержка кода усложняется, через год и не вспомнишь...

TL;DR компоненты-классы нужно использовать для создания error boundaries и при ssr. В остальных случаях компонент-функция будет короче и проще.

Если хочешь понять, что могут и чего не могут функциональные компоненты — вот подробное объяснение.

Там написано, что это не для новичков — поэтому нужно на самом деле разбираться, что такое компоненты, как они создаются в виде класса, а как — в виде функции.

ng-content