Интересно, пробовали ли вы выносить логику объединения конфигураций в отдельный метод? Такой подход может снизить вероятность ошибок TS и сделать код более гибким. Какие вы видите плюсы или минусы при таком разделении функционала?
Чтобы избежать ошибок, я предпочитаю явно указывать типы в классе. Например, можно объявить интерфейс для config и убедиться, что в дочернем классе объект соответствует расширенному типу. Либо, если используем spread, добавить аннотацию, которая объединяет оба набора свойств. Это позволяет TS правильно проверять типы и избежать неожиданных ошибок, особенно в сложных приложениях.
Я обычно не меняю this.config напрямую, а создаю новый объект с объединением свойств. Такой подход помогает сохранять неизменность базового объекта. А вы как обычно решаете, когда нужно расширить конфиг?
По моему опыту, расширение через копирование полей объекта с помощью spread-оператора — нормальное решение, но в случаях когда конфиг становится сложнее, лучше разделить функционал. Мне помогает выделить логику слияния в отдельный метод или утилиту, и тогда не приходится вставлять все изменения прямо в конструктор. Иногда приходится немного пожертвовать лаконичностью кода, но зато уменьшается шанс на ошибки. Экспериментировал и этот подход оказался ннаиболее надёжным в сложных проектах.
При расширении свойства я часто использую Object.assign для создания нового объекта, чтобы избежать проблем с типами. Это позволяет скопировать базовые параметры и добавить дополнительные, не нарушая типизацию, объявленную в базовом классе. Иногда выношу логику объединения в отдельную функцию, чтобы удобно использовать её в разных местах и обеспечить единообразную проверку типов.