NE
чот мне кажется, ты немного путаешь тёплое с мягким
не вижу проблемы в typeof выше
не вижу проблемы в typeof выше
Не принуждаю) небольшой комментарий прост
Size: a a a
2021 March 11
И
Не принуждаю) небольшой комментарий прост
я понимаю. подискутировать хочется)
NE
я понимаю. подискутировать хочется)
Окей) В чем проблема сделать prepend({params}: {params: Params}) => params.
🦜
Окей) В чем проблема сделать prepend({params}: {params: Params}) => params.
кринжово
🦜
prepend<Params> бы
И
Окей) В чем проблема сделать prepend({params}: {params: Params}) => params.
1. это не совсем честно (потому что там кроме Params есть Result). понятно, что структурная типизация и всё такое, но хотелось бы максимально точно описывать типы
2. Params уже есть внутри fx (Effect<Params, …>)
2.1. не хочу менять тип при изменении эффекта
2.2. не хочу вообще сюда импортировать этот тип, потому что guard работает с эффектом, а не с каким-то там конкретным типом — идейный я
2. Params уже есть внутри fx (Effect<Params, …>)
2.1. не хочу менять тип при изменении эффекта
2.2. не хочу вообще сюда импортировать этот тип, потому что guard работает с эффектом, а не с каким-то там конкретным типом — идейный я
NE
1. это не совсем честно (потому что там кроме Params есть Result). понятно, что структурная типизация и всё такое, но хотелось бы максимально точно описывать типы
2. Params уже есть внутри fx (Effect<Params, …>)
2.1. не хочу менять тип при изменении эффекта
2.2. не хочу вообще сюда импортировать этот тип, потому что guard работает с эффектом, а не с каким-то там конкретным типом — идейный я
2. Params уже есть внутри fx (Effect<Params, …>)
2.1. не хочу менять тип при изменении эффекта
2.2. не хочу вообще сюда импортировать этот тип, потому что guard работает с эффектом, а не с каким-то там конкретным типом — идейный я
1. Тут это не нужно, функции не нужно знать эту информацию. Расслаивать логику так, чтобы каждый получал только то, что нужно - я считаю правильным.
2. Это классно, что Params, где то есть, но ты впринципе хочешь «пофиксить» отсутствие map у guard и делаешь это максимально костыльным из возможных способов (остальные не супер, но не принуждают тебя хардкодить типы через typeof), который всего лишь чуть короче по количеству символов.
2.1 Твоё право, конкретно в этом узком кейсе typeof может и не очень страшен, но я его использование максимально избегаю.
2.2 Окей, согласен, не стоит костылём фиксить костыль)
2. Это классно, что Params, где то есть, но ты впринципе хочешь «пофиксить» отсутствие map у guard и делаешь это максимально костыльным из возможных способов (остальные не супер, но не принуждают тебя хардкодить типы через typeof), который всего лишь чуть короче по количеству символов.
2.1 Твоё право, конкретно в этом узком кейсе typeof может и не очень страшен, но я его использование максимально избегаю.
2.2 Окей, согласен, не стоит костылём фиксить костыль)
И
1. Тут это не нужно, функции не нужно знать эту информацию. Расслаивать логику так, чтобы каждый получал только то, что нужно - я считаю правильным.
2. Это классно, что Params, где то есть, но ты впринципе хочешь «пофиксить» отсутствие map у guard и делаешь это максимально костыльным из возможных способов (остальные не супер, но не принуждают тебя хардкодить типы через typeof), который всего лишь чуть короче по количеству символов.
2.1 Твоё право, конкретно в этом узком кейсе typeof может и не очень страшен, но я его использование максимально избегаю.
2.2 Окей, согласен, не стоит костылём фиксить костыль)
2. Это классно, что Params, где то есть, но ты впринципе хочешь «пофиксить» отсутствие map у guard и делаешь это максимально костыльным из возможных способов (остальные не супер, но не принуждают тебя хардкодить типы через typeof), который всего лишь чуть короче по количеству символов.
2.1 Твоё право, конкретно в этом узком кейсе typeof может и не очень страшен, но я его использование максимально избегаю.
2.2 Окей, согласен, не стоит костылём фиксить костыль)
звучит разумно
И
1. Тут это не нужно, функции не нужно знать эту информацию. Расслаивать логику так, чтобы каждый получал только то, что нужно - я считаю правильным.
2. Это классно, что Params, где то есть, но ты впринципе хочешь «пофиксить» отсутствие map у guard и делаешь это максимально костыльным из возможных способов (остальные не супер, но не принуждают тебя хардкодить типы через typeof), который всего лишь чуть короче по количеству символов.
2.1 Твоё право, конкретно в этом узком кейсе typeof может и не очень страшен, но я его использование максимально избегаю.
2.2 Окей, согласен, не стоит костылём фиксить костыль)
2. Это классно, что Params, где то есть, но ты впринципе хочешь «пофиксить» отсутствие map у guard и делаешь это максимально костыльным из возможных способов (остальные не супер, но не принуждают тебя хардкодить типы через typeof), который всего лишь чуть короче по количеству символов.
2.1 Твоё право, конкретно в этом узком кейсе typeof может и не очень страшен, но я его использование максимально избегаю.
2.2 Окей, согласен, не стоит костылём фиксить костыль)
а мне норм 🙂
I
О_О
И
DS
guard({
source: fetchCustomerFx.done,
filter: ({ result }) => Boolean(result),
target: saveCustomerCredentialsToLocationSearchFx.prepend(
({ params }: UnitValue<typeof fetchCustomerFx.done>) => params,
),
})A
DS
Наведи на таргет, че там?
A
A
Наведи на таргет, че там?
^
DS
Так не должно быть, значит что то я неверно сделал
A
ну он иначе ошибку бы вывалил бы, если бы разные типы были
а так мы семплим последний вызов эффекта
по сути, вроде можно в один гард упаковать
а так мы семплим последний вызов эффекта
по сути, вроде можно в один гард упаковать
A
Так не должно быть, значит что то я неверно сделал
почему?