キ
попробуй сделать
condition ? renderPickerItem!(...)Size: a a a
2021 January 18
キ
то есть поставить !
キ
если я все правильно понял то должно хоть че то поменяться 🗿
A
а разве не понятно?
renderPickerItem необязательно находится в пропсах ?: потому его вызов может обернуться либо never либо React.ReactNode, never можно интерпретировать как undefined, следовательно <Item> будет возвращать либо React.ReactNode, либо undefined, а дальше дело техники, не?Я проверяю есть ли renderPickerItem
A
キ
а блин я почему то подумал что там два разных значения и что в кондишне в тернарке это другая переменная
キ
как сломать все мои предположения за одно утверждение
M
пишут https://stackoverflow.com/questions/54905376/type-error-jsx-element-type-null-undefined-is-not-a-constructor-functi не использовать реактнод с функциями
A
пишут https://stackoverflow.com/questions/54905376/type-error-jsx-element-type-null-undefined-is-not-a-constructor-functi не использовать реактнод с функциями
Спасибо, заменил на
ReactElementB
Илья
Дак из редукса подгружаются
У тебя там в
connect App обвёрнут?2021 January 19
В
const log = DEV ? console.log : noop;Unsafe call of an any typed value.eslint@typescript-eslint/no-unsafe-call)
это о чем?
каждый из элементов определяется корректно ts но в выражении - ругается
const noop = (): void => { };
И
У тебя там в
connect App обвёрнут?Да
B
Илья
Да
То есть он не убирает из проспов прокинутое?
B
Илья
Да
А ты гуглил? Вот такое есть, тут немного тайпингов https://stackoverflow.com/questions/41808408/react-redux-typescript-connect-has-missing-type-error
И
А ты гуглил? Вот такое есть, тут немного тайпингов https://stackoverflow.com/questions/41808408/react-redux-typescript-connect-has-missing-type-error
В таких случаях сложно Гуглу правильный вопрос задать. Спасибо, почитаю.
KS
Utin Alexey
Привет всем.
Как создать интерфейс, чтобы один из ключей был: или только Single, или SIngle && (Base | Intermediate | Full), т.е.
enum Some {
Base = "base",
Intermediate = "intermediate",
Full = "full",
Single = "single"
}Как создать интерфейс, чтобы один из ключей был: или только Single, или SIngle && (Base | Intermediate | Full), т.е.
interface Foo {
option: {
[Some.Single]: []
или
[Some.Single]: [],
[Some.Full]: [] //к примеру
}
}Вообще есть некое заклинание, чтобы сделать exclusive or, но я бы сделал в виде tuple (см на
extra){
single: T1,
extra?: [Exclude<Some, Some.Single>, T2],
}KS
Но если очень надо соблюсти именно такой API (потому что его задаёт внешняя библиотека), то вот про дистрибутивность, тоже вчера обсуждали
https://github.com/microsoft/TypeScript/issues/33110
https://github.com/microsoft/TypeScript/issues/33110
KS
{ [Some.Single]: T } & DistributeRecord<Exclude<Some, Some.Single>, T>для
DistributeRecord берёшь RecordItemsOrNull из примера по ссылке и заменяешь null на neveru
Ivan Iesaulov
Прямое указание типов (даже там, где тс может сам их вывести) уменьшает время сборки проекта?
Да, явное аннотирование типов (прежде всего, типов возвращаемых значений у функций) может ускорять тайп-чекинг, особенно при инкрементальной компиляции (явно указанные типы компактнее выведенных, и TS быстрее читает и записывает файл с JSON-представлением результатов предыдущей компиляции): Using Type Annotations.
Однако разница будет заметна, скорее всего, только на крупных проектах (сколько времени занимают разные шаги компиляции, можно посмотреть с помощью флага extendedDiagnostics).
Поэтому решение о явном указании типов лучше принимать из других соображений.
В средних проектах удобно полагаться на автовывод, и писать меньше типов.
В крупных проектах, с сильным зацеплением между модулями, с наличием разных потребителей модулей, может быть оправдано использование принципа инверсии зависимостей, требующего явного и отдельного от имплементаций определения всех типов, от которых зависит модуль.
Внутри модуля это может выглядеть, как дублирование (зачем импортировать откуда-то тип возвращаемого значения функции в модуле, если она сама может вывести этот тип?), но явное указание типов позволяет изменять реализацию модуля без правок в коде его потребителей.
Однако разница будет заметна, скорее всего, только на крупных проектах (сколько времени занимают разные шаги компиляции, можно посмотреть с помощью флага extendedDiagnostics).
Поэтому решение о явном указании типов лучше принимать из других соображений.
В средних проектах удобно полагаться на автовывод, и писать меньше типов.
В крупных проектах, с сильным зацеплением между модулями, с наличием разных потребителей модулей, может быть оправдано использование принципа инверсии зависимостей, требующего явного и отдельного от имплементаций определения всех типов, от которых зависит модуль.
Внутри модуля это может выглядеть, как дублирование (зачем импортировать откуда-то тип возвращаемого значения функции в модуле, если она сама может вывести этот тип?), но явное указание типов позволяет изменять реализацию модуля без правок в коде его потребителей.
LC
ts-node не хочет подключать таргет библиотеки из tsconfig'а, что делать? он вообще может поддерживать es2019?