Sun_Day

Исправить

document.getElementById("form").innerHTML == sum
На
document.getElementById("form").value == sum

Препроцессор типа sass, бэм(если нужен), семантическая верстка, адаптивы всякие.

руководства по верстке

Нет никакого единого руководства по верстке, где бы было собрано все, что вы хотите. Ролики на ютубе/статьи в интернете. Мб какая-нибудь штмл академи, хз. Все зависит от вашего уровня знаний, верстать умею и каша в коде - как-то мало совместимо.

Если просто нужен принцип организации css, то пользуйтесь каким-нибудь sass'ом. Если порядок в html, то изучайте семантическую верстку.

Когда юзер находится в вашем веб приложении, он создает определенные действия. Действия связаны с состоянием. А redux это набор утилит для глобального хранения состояния(state) в приложении.
Таким образом, вы создаете какие-то объекты и они меняются в зависимости от состояния. Пользователь это видит как некие различные реакции на его действия.

export class AppComponent {
  public items = [
    {
      name: "Ivan",
      count: 2
    },
    {
      name: "Petr",
      count: 14
    }
  ];

  public increment(index) {
    this.items[index].count += 1;
  }

  public decrement(index) {
    this.items[index].count -= 1;
  }
}

<div *ngFor="let item of items; index as i">
  <p>{{item.name}}</p>
  <p>{{item.count}}</p>
  <button (click)="increment(i)">increment</button>
  <button (click)="decrement(i)">decrement</button>
</div>

Во-первых, у вас в корне неверное решение, хотя бы потому что не соответствует условию:

find all integers
Тут же тест:

solEquaStr(90005) --> "[[45003, 22501], [9003, 4499], [981, 467], [309, 37]]"

Ваше решение вернет лишь первый и единичный случай. Нужно вернуть все.
Поэтому, цикл вайл тут тоже не подойдет.
Во-вторых, у вас неверное условие итерации. Нужно итерироваться iterator <= sqrt(N) (или pt1 <= sqrtN в вашем решении)
Нецелых чисел может быть очень много, особенно для больших чисел, поэтому по условию нужно вернуть целые числа(isInteger). Если при итерации не будет пары целых чисел, то решений нет, возвращаем пустой массив.

Ну и двигать поинтеры - тоже в корне неверно, нужно искать x,y.
x = (d + i) / 2;
y = (d - i) / 4

Решение выше вполне норм. Вот что-то похожее.

function solequa(n) {
    const sqrtN = Math.sqrt(n);
    const result = [];
    let x, y, d;
    for (let i = 1; i <= sqrtN; i++) {
        d = n / i;
        x = (d + i) / 2;
        y = (d - i) / 4
        if (Number.isInteger(x) && Number.isInteger(y)) {
            result.push([x, y]);
        }
    }
    return result;
}

Дело вкуса. Не могу сказать, что это очень плохой подход, но и используют его нечасто.

Проблемы, которые могут возникнуть - это конфликт имен с другими либами, которые используют такой подход.
Это пожалуй самая существенная проблема. Касается встроенных, стандартных объектов js'a, типа string, array и т.п.

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

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

Использовал полифилл.
Этот

if (!Element.prototype.matches) {
  Element.prototype.matches =
    Element.prototype.msMatchesSelector ||
    Element.prototype.webkitMatchesSelector;
}

if (!Element.prototype.closest) {
  Element.prototype.closest = function(s) {
    var el = this;

    do {
      if (Element.prototype.matches.call(el, s)) return el;
      el = el.parentElement || el.parentNode;
    } while (el !== null && el.nodeType === 1);
    return null;
  };
}

Или

(function(ELEMENT) {
    ELEMENT.matches = ELEMENT.matches || ELEMENT.mozMatchesSelector || ELEMENT.msMatchesSelector || ELEMENT.oMatchesSelector || ELEMENT.webkitMatchesSelector;
    ELEMENT.closest = ELEMENT.closest || function closest(selector) {
        if (!this) return null;
        if (this.matches(selector)) return this;
        if (!this.parentElement) {return null}
        else return this.parentElement.closest(selector)
      };
}(Element.prototype));

https://developer.mozilla.org/en-US/docs/Web/API/E...
https://developer.mozilla.org/ru/docs/Web/API/Elem...

Все зависит от задач. В реакте важно делать компоненты как можно более мелкими(главное совсем не переусердствовать, хоть это и непросто). Декомпозировать. Это важно особенно с компонентами, которые могут стать переиспользуемыми.

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

То есть, будет вполне норм, если в стартовом компоненте, с которого начинается отрисовка приложения, и начальная логика - это как правило App component, у вас будет:

const App = () => {
  <Header />
  ... other components
  <Footer />
}

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

const input = document.querySelector(".placeholder");

input.addEventListener("keydown", (e) => {
    const condition = e.target.value.length < 5 ? "new" : "password";
    input.placeholder = condition;
})

<input class="placeholder" placeholder="password">

Но как указали в комментарии - лучше выводить какой-то текст рядом, потому что в плейсхолдере он скрывается введенным текстом. Например:

const input = document.querySelector(".placeholder");
const output = document.querySelector(".for-error");

input.addEventListener("input", (e) => {
     const condition = e.target.value.length < 5 ? "the password is too short" : "";
     output.textContent = condition;
})

<input class="placeholder" placeholder="password">
<span class="for-error"></span>

Ну и поподробнее изучить тему валидации форм.
click

Ну если вы говорите, что это модули, то вы можете использовать export/import между модулями, т.е шарить код среди этих файлов. Плюс у каждого модуля отдельная область видимости.
На загрузку влияет в том смысле, что такие скрипты автоматически маркируются как defer(можно погуглить).

Но это как бы почти не используется. Обычно жс модули гонят через инструменты сборки типа webpack, чтобы собрать определенный bundle и он соответственно уже куда-то подключается.

У чего конкретно? У select или у option?

У select

select {
  color: green;
}
//
.personal_form-select_choise {
  color: green;
}

У option

select option[value="1"] {
  color: green
}
//
.personal_form-select_choise option[value="1"] {
  color: green
}

<option value="1">новый предмет</option>

Возьмите свойство localStorage(в данном случае window.localStorage - это одно и то же).
И обойдите его циклом, получив все value.
localstorage

for (let i = 0; i < localStorage.length; i+= 1) { 
const key = localStorage.key(i)
const value = localStorage[key];
console.log(value);
}

Ну и дальше делайте что нужно со списком value'сов и выводите в html.

Разные среды разработки, разница в стиле разработки, если коротко.

Тут все немного запутанно насчет Require и Common.

Это модульные системы.

До выхода стандарта ES6, когда в js по сути появилась модульная система из коробки, модули реализовывались в основном с помощью двух стандартов - это CommonJS и AMD.

CommonJS - это стандарт по модульной системе в js вне браузера, для node.js. В node.js тоже есть встроенная функция require, есть module.exports. Все это реализация стандарта CommonJS.
Nodejs сейчас es6 модульную систему поддерживает(import/export). То есть, официальный синтаксис джаваскрипта. И если коротко, то с выходом ES6, CommonJS немножко потерял свою былую целесообразность, поскольку появился официальный синтаксис javascript, который это реализовывает. Раньше в js, в рамках официального синтаксиса такого не было.

AMD - это стандарт, который отпочковался от CommonJS, разработан для асинхронной загрузки модулей. Использует функцию define, которой описывается модуль и require, которой он подключается. Расшифровывается как Асинхронное определение модуля.

RequireJS - это библиотека для поддержки асинхронных модулей в браузерах. То есть она для браузеров. Это не стандарт. Это реализация стандарта AMD.

Объяснил как мог, не знаю как еще проще).