Как мы написали, а потом переписали онбординг сервис

хаха, лайк

Как мы написали, а потом переписали онбординг сервис

В первой версии у нас так и было, но здесь будут проблемы:

1. mapConfigEventToStepEvent будет бесконечно расширяемой мапой из-за того что у нас будут появляться новый шаги. Метод приватный и нужно будет писать какие-то интеграционные тесты, чтобы проверить правильность работы класса. Из-за раздуваемости этой мапы, тесты будут очень хрупкие и и них будет увесистая фаза Arrange

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

const OUR_FIRST_ONBOARDING = {
	id: "НАШ_ПЕРВЫЙ_ОНБОРДИНГ",
	steps: [
		{
			id: "ID_ПЕРВОГО_ШАГА",
      // Этот параметр спрячется в классе
			type: StepTypes.CLICK,
		}
	]
}


const OUR_FIRST_ONBOARDING = {
	id: "НАШ_ПЕРВЫЙ_ОНБОРДИНГ",
	steps: [
		new StepClick{
			id: "ID_ПЕРВОГО_ШАГА",
		}
	]
}

Как мы написали, а потом переписали онбординг сервис

Привет, спасибо за комментарий. Валидное замечание. Когда мы делали первую версию, легче было сделать так, как ты написал, но мы пошли немного дальше и теперь нужно описывать только интерфейс класса и все.

А дальше используешь его так:

// Конфиг
const OUR_FIRST_ONBOARDING = {
	id: "НАШ_ПЕРВЫЙ_ОНБОРДИНГ",
	steps: [
		new StepClick{
			id: "ID_ПЕРВОГО_ШАГА",
		}
	]
}


// Вызов события в основном приложении
OUR_FIRST_ONBOARDING.steps[0].emitEvent()