szQocks

типа, антипаттерн...

но это все равно вызов метода в конструкторе, что не приветствуется.

Бред. Вот кем не приветствуется - вот он пускай и не приветствует и тихо миро плавает в своем болотце. Спокойно вызывайте приватный инициализатор в конструкторе - это как раз нормально. Конструктор - это и есть инициализатор объекта. Он даже называется "конструктор" - сборщик объекта. Его для этого и придумали. Выносить часть инициализации из инициализатора - на самом неделе не самая умная идея. А вот разбить инициализацию на разные логические части и разнести в разные методы - как раз таки очень даже хорошая практика. Декомпозиция, небольшие и простые функции/процедуры и все такое прочее.

Как вариант маска. В идеале SVG, чтобы края были ровнее

Ваш код работать не будет.
Анонимная функция, в которой вы задаёте значение переменной dd будет вызвана только при наступлении события message, то есть при приходе сообщения от WS-сервера. А это сообщение может прийти как сразу же, так и через час.
Кроме того, даже при приходе события, вызов функции будет помещён в очередь и выполнится только после завершения выполнения текущего кода, то есть когда console.log(vv) уже отработает.

Состояние компонента должно содержать три значения - индекс печатаемой строки, количество отображаемых символов, направление печати (печатаем или стираем, т.е., в какую сторону надо изменять количество отображаемых символов, увеличивать или уменьшать). Дальше понятно что - setInterval или рекурсивный setTimeout, изменяем количество отображаемых символов, если дошли до конца строки - меняем направление, дошли до начала - меняем направление и индекс строки. Вот как-то так:

const defaults = {
  index: 0,
  length: 0,
  step: 1,
};

function Typewriter({ strings, delay }) {
  const [ state, setState ] = useState(null);

  useEffect(() => {
    setState(() => ({...defaults}));
  }, [ strings ]);

  useEffect(() => {
    const timeoutId = setTimeout(setState, delay, ({...state}) => {
      state.length += state.step;
      if (state.length === strings[state.index].length) {
        state.step = -1;
      } else if (state.length === 0) {
        state.step = 1;
        state.index = (state.index + 1) % strings.length;
      }
      return state;
    });

    return () => clearTimeout(timeoutId);
  });

  return <div>{strings?.[state?.index]?.slice(0, state?.length)}</div>;
}

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

Потому что memo использует поверхностное сравнение, а у вас на входе примитив (просто число). А если функцию написать без useCallback она действительно создаётся новая, а в текущем useCallback пустой список зависимостей - значит и функция не будет пересоздаваться (это и не нужно).

Градиентом нарисовать:

const { filledColor: F, emptyColor: E, ...props } = defineProps({
  value: Number,
  maxValue: Number,
  segments: {
    type: Number,
    default: 5,
  },
  filledColor: {
    type: String,
    default: 'red',
  },
  emptyColor: {
    type: String,
    default: 'black',
  },
});

const background = val =>
  val >= 1 ? F :
  val <= 0 ? E :
             `linear-gradient(to right, ${F}, ${F}, ${val * 100}%, ${E} ${val * 100}%)`;

<div class="rating">
  <div
    v-for="i in segments"
    :style="{ background: background(value / maxValue * segments - i + 1) }"
    class="rating-segment"
  ></div>
</div>

Деструкция выглядит так: const { status } = result;
Вы же создаёте переменную status и в неё записываете объект {result: result}.
Поэтому возвращает ваша функция вот такую конструкцию:

{
  data: ...,
  status: {
    result: result,
  }
}

Можно регулярками, но я бы использовал специализированную библиотеку path-to-regexp:

import pathToRegexp from 'path-to-regexp';

// real route
const route = '/notifications/:id/';

// regexp
const keys = [];
const regexp = pathToRegexp(route, keys);

// test route
const testRoute = '/notifications/123/';

if (regexp.exec(testRoute)) {
  console.log(`URL match from: ${route}`);
} else {
  console.log(`URL not match from: ${route}`);
}

Почитал комменты и понял, что лучше иметь немного другую модель.
Есть к примеру таблица:

CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(255) NOT NULL,
    email VARCHAR(255) NOT NULL,
    password_hash VARCHAR(255) NOT NULL,
    registration_status TINYINT(1) NOT NULL DEFAULT 0,
    registration_token VARCHAR(255) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

При регистрации, устанавливаем "registration_token", к примеру, через uniqid() или openssl_random_pseudo_bytes() и на почту отправляем специальную ссылку с, к примеру, гет запросом: domain.com/?email="email"&token="registration_token"
Пользователь переходит по ссылке, в бд идет проверка, есть ли такая запись и меняет "registration_status"=1
Почему этот вариант лучше? Потому что так ты не сможешь обойти сообщение с почты, т.к. не будешь знать, какой токен тебе выдался для подтверждения и будет недостаточно просто 1 раз увидеть пример подтверждающей ссылки, чтобы новые аккаунты активировать по определенному шаблону ссылки.

А по "created_at" отслеживаешь старые аккаунты и удаляешь, если потребуется.

Посмотрите на Beacon API. Он как раз предназначен для аналитики.
А обычные запросы браузер имеет полное право обрывать потому что полагает что в нём уже нет никакого смысла раз вы покидаете страницу.

А ещё в MDN прелагают использовать событие visibilitychange вместо beforeunload.
https://developer.mozilla.org/en-US/docs/Web/API/N...

.avatar {
	position: relative;
	width: 150px;
	height: 150px;
-	border-radius: 50%;
-	overflow: hidden;
+	clip-path: circle(50%);
}

Посмотрите на результат выполнения следующего кода с [Symbol.iterator]() { return this; } и без:

const iter = new Range(1, 5)[Symbol.iterator]();
console.log(iter.next().value);
console.log(iter.next().value);
console.log([...iter]);

Не выдумывайте, всё рендерится.

Почему видимых изменений нет? Потому что обновляете одно состояние, а рендер выполняете на основе другого, items в App и items в ElementsList - это разные массивы. Не надо никакого useState в ElementList, выполняйте рендер на основе prop'а; метод onDelete перенесите в App и тоже передавайте в ElementList через props.

Незачем накручивать градусы до огромных цифр - достаточно по достижению 360 возвращать в 0. А в остальном - никаких проблем не должно быть. На производительности практически никак не отразится.