Спасибо, то что надо

ребят, привет. Чет протупляю с типами в ТС Есть объявление типа (часть интерфейса) interface SwitchItemsLayout { section: string; switchText: string; switchComponent: React.ReactNode; } interface SideBarProps { * switchItems: { [key: string]: SwitchItemsLayout }; * вот где собсна выдыет const switchItems = { 'login': { section: 'login', switchText: 'Log In', switchComponent: <p>???</p> }, 'register': { section: 'register', switchText: 'Sign Up', switchComponent: <RegistrationWizard /> }, }; получаю на выходе error TS2322: Type '{}' is not assignable to type 'IntrinsicAttributes & void & { children?: ReactNode; }'. Type '{}' is not assignable to type 'void'. ЧЯДНТ?

из примера не понятно как тип используется

и где подключается

как раз таки когда ты работаешь один, то ты в голове как правило можешь все нюансы удержать. А вот в команде тс сильно помогает находить ошибки на ранних стадиях. Считай типы этакими тестами, которые писать не надо. Вот мне недавно пришлось один метод сделать из синхронного асинхронным. Метод использовался много где, и все эти места каскадно пришлось сделать асинхронными и так по рекурсии. Я не знаю сколько бы я проторчал без ts вкупе с tslint и правилом no-floating-promises

?про рефакторинг

а вижу

ребят, привет. Чет протупляю с типами в ТС Есть объявление типа (часть интерфейса) interface SwitchItemsLayout { section: string; switchText: string; switchComponent: React.ReactNode; } interface SideBarProps { * switchItems: { [key: string]: SwitchItemsLayout }; * вот где собсна выдыет const switchItems = { 'login': { section: 'login', switchText: 'Log In', switchComponent: <p>???</p> }, 'register': { section: 'register', switchText: 'Sign Up', switchComponent: <RegistrationWizard /> }, }; получаю на выходе error TS2322: Type '{}' is not assignable to type 'IntrinsicAttributes & void & { children?: ReactNode; }'. Type '{}' is not assignable to type 'void'. ЧЯДНТ?

скинь гист

скинь гист

насколько развернуто? там NDA

Разобрасля, немного не тот тип передавал в компонентах

/report

Ребят, кто работал с криптой на уровне апи? Напишите в личку

Всем привет. Выношу из проекта общие компоненты в отдельный пакет, чтобы можно было использовать на нескольких проектах (в том числе и не TS). И возникла такая проблема - некоторые компоненты используют другие компоненты и я использую baseUrl: "./src", чтобы писать import AnotherComponent from 'components'; вместо import AnotherComponent from '../AnotherComponent'; Поставил target=es6, т.к. все потребители будут использовать rollup/webpack и babel опущу кучу ворнингов и всяких непоняток с настройками, получилось с помощью npx tsc сгенерировать файлы, но там всё ещё import AnotherComponent from 'components'; то есть потребитель пакета скорее всего не сможет такой путь разрезолвить и собрать, так ведь? Есть ли обходные пути, или придется писать относительные импорты? Может быть есть какие-то подробные мануалы, как публиковать библиотеки?

посмотрел на antd - они использую относительные пути

как правильно тайп аннотации при деструктировании объекта прописывать?

если уже описан интерфейс

ps. там не authorID, а author в интерфейсе

хм, получилось вроде { time, text, author }: ChatMessageProps.. до этого не работало :\

Ребят, посоветуйте как правильно писать filter массива: https://www.typescriptlang.org/play/index.html#src=const%20ar%20%3D%20%5B1%2C%202%2C%20null%2C%204%5D%3B%0D%0A%0D%0Aconst%20far%20%3D%20ar.filter(%0D%0A%20%20%20%20el%20%3D%3E%20typeof%20el%20%3D%3D%3D%20'number'%0D%0A)

меня просто убивает что отфильтрованные массив имеет тот же тип что и изначальный

хотя null, например отфильтрован

Может так? https://www.typescriptlang.org/play/index.html#src=const%20ar%3A%20Array%3Cnumber%20%7C%20null%3E%20%3D%20%5B1%2C%202%2C%20null%2C%204%5D%3B%0D%0A%0D%0Aconst%20far%3AArray%3Cnumber%3E%20%3D%20ar.filter(%0D%0A%20%20%20%20el%20%3D%3E%20typeof%20el%20%3D%3D%3D%20'number'%0D%0A)

https://www.typescriptlang.org/play/index.html#src=const%20ar%20%3D%20%5B1%2C%202%2C%20null%2C%20'4'%5D%3B%0D%0A%0D%0Aconst%20far%20%3D%20ar.filter(%0D%0A%20%20%20%20el%20%3D%3E%20typeof%20el%20%3D%3D%3D%20'number'%0D%0A)%20as%20number%5B%5D%3B

https://www.typescriptlang.org/play/index.html#src=const%20ar%20%3D%20%5B1%2C%202%2C%20null%2C%20'4'%5D%3B%0D%0A%0D%0Aconst%20far%20%3D%20ar.filter(%0D%0A%20%20%20%20el%20%3D%3E%20typeof%20el%20%3D%3D%3D%20'number'%0D%0A)%20as%20number%5B%5D%3B

Есть какая-то разница между const far: Array<number> = ... и const far = [].filter( ... ) as number[]? (я не набрасываю, правда не знаю)

Есть какая-то разница между const far: Array<number> = ... и const far = [].filter( ... ) as number[]? (я не набрасываю, правда не знаю)

в первом случае мы объявляем типы, и он сравнит их при присвоении во втором мы форсим компилятор думать, что это именно такой тип

Первый путь безопаснее?

Интересно как компилятор поймет, что после фильтрации только цифры остались в массиве.

Первый путь безопаснее?

ну, они скорее про другое as для объявлений не юзается, он для вывода+пара-тройка кейсов нужен(но в целом да, первый путь безопаснее) И да, компилятор никак не поймет, ибо это рантайм уже

Понятно, спасибо за объяснение)

https://www.typescriptlang.org/play/index.html#src=const%20ar%20%3D%20%5B1%2C%202%2C%20null%2C%20'4'%5D%3B%0D%0A%0D%0Aconst%20far%20%3D%20ar.filter(%0D%0A%20%20%20%20el%20%3D%3E%20typeof%20el%20%3D%3D%3D%20'number'%0D%0A)%20as%20number%5B%5D%3B

спасибо. Возьму ваш пример.

Приветик, есть такой код: class A { foo(a: string, b: number): boolean { return false } } class B extends A { foo(a) { return true } } Можно ли как-то описать сигнатуру в d.ts или ещё как-либо чтобы в классе B в методе foo выводились типы аргументов

или придется каждый раз писать в наследнике foo(a: string, b: number)?

а ты ж указал аргумент а как any

там нечему выводиться

да, но тип не должен от родителя приехать?

нет

хуёво, ну ок

то что имена совпадают вообще не значит что это параметр родителя

это не хуево это правильно

да это понятно, я не про имена, а про тип

ты переопределил метод

все, он новый

совершенно другой

хочешь старый, не переопределяй

ну… если я верну не верный тип или укажу первым аргументом number - то он ругнется

если оставишь все как есть не ругнется

а ретурн да

Есть такое понятие как интерфейс класса

это значит что у него есть определенные методы который возвращают определенные значения

в большинстве языков аргументы методов не учитываяются, вот в тс похоже тоже не учитываются

в общем пиши всегда типы руками, не придется потом вспоминать ничего

в большинстве языков аргументы методов не учитываяются, вот в тс похоже тоже не учитываются

ну не, во многих строготипизированных языках можно написать несколько имплементаций метода с разными аргументами и будет вызываться соответствующий

Окей, валидно)

ну не, во многих строготипизированных языках можно написать несколько имплементаций метода с разными аргументами и будет вызываться соответствующий

Перегрузка

Спасибо

в том же цпп, где есть разные имплементации это банальное расширение интерфейса, они работают как "разные" методы

в том же цпп, где есть разные имплементации это банальное расширение интерфейса, они работают как "разные" методы

это перегрузка, угу https://msdn.microsoft.com/en-us/library/5dhe1hce.aspx

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

А вы всегда пишите на ТС в ООП стиле ? Или миксуете ? Например..какой то модуль просто экспортируемые функции и т.д.

Я всегда пишу в говнокод-стиле

Оч удобно

Как в жс

По ходу это я сильно упариваюсь

Ну иногда и я упарываюсь, но когда нужна экстра строгость, в большинстве случаев я пишу как в ноде + типы. Но я не скажу что это подходящий вариант, у меня опыта мало

А вы всегда пишите на ТС в ООП стиле ? Или миксуете ? Например..какой то модуль просто экспортируемые функции и т.д.

Если под "ооп стилем" подразумевается "похоже на джаву", то сомнительное решение, потому что очень многое гораздо удобнее сделать просто функциями

Тут мне кажется дело не в функциях а в жс данных, обьекты собственно

Это популярно, стандартный тип данных

В жаве форсятся классы, в жс есть куча других удобных вариантов создавать объекты

Да, особенно если их не создавать а собирать. Я бы привел аналогию а моделями, но некоторые в них вкладывают оверлогику

Типа каждый обьект обязан иметь конструтор - джавастайл

А вы всегда пишите на ТС в ООП стиле ? Или миксуете ? Например..какой то модуль просто экспортируемые функции и т.д.

А иначе не получается, писать на функциональном стиле не получится потому что тс не поддерживает самой базовой для фп вещи - композицию функций (не умеет пробрасывать типы через дженерик функции ) https://www.typescriptlang.org/play/#src=function%20promisify%3CInput%2C%20Output%3E(fn%3A%20(a%3A%20Input)%3D%3EOutput)%3A%20(a%3A%20Input)%20%3D%3E%20Promise%3COutput%3E%20%7B%0A%20%20return%20a%20%3D%3E%20Promise.resolve(fn(a))%0A%7D%0A%0Afunction%20track%3CInput%3E(e%3A%20Input)%3A%20Input%20%7B%0A%20%20console.log(e)%3B%0A%20%20return%20e%3B%0A%7D%0Aclass%20Foo%20%7B%20bar()%7B%7D%20%7D%0Aconst%20promisifiedTrack%20%3D%20promisify(track)%3B%0ApromisifiedTrack(new%20Foo()).then(x%3D%3Ex.bar())%3B

А иначе не получается, писать на функциональном стиле не получится потому что тс не поддерживает самой базовой для фп вещи - композицию функций (не умеет пробрасывать типы через дженерик функции ) https://www.typescriptlang.org/play/#src=function%20promisify%3CInput%2C%20Output%3E(fn%3A%20(a%3A%20Input)%3D%3EOutput)%3A%20(a%3A%20Input)%20%3D%3E%20Promise%3COutput%3E%20%7B%0A%20%20return%20a%20%3D%3E%20Promise.resolve(fn(a))%0A%7D%0A%0Afunction%20track%3CInput%3E(e%3A%20Input)%3A%20Input%20%7B%0A%20%20console.log(e)%3B%0A%20%20return%20e%3B%0A%7D%0Aclass%20Foo%20%7B%20bar()%7B%7D%20%7D%0Aconst%20promisifiedTrack%20%3D%20promisify(track)%3B%0ApromisifiedTrack(new%20Foo()).then(x%3D%3Ex.bar())%3B

Пфф, говнокодеры смотрят и смеются

как правильно тайп аннотации при деструктировании объекта прописывать?

Ест не ошибаюс то както так const { huy: string; djigurda: number; } = this.props;

Ест не ошибаюс то както так const { huy: string; djigurda: number; } = this.props;

Это переименование жсное, а не аннотации

как правильно тайп аннотации при деструктировании объекта прописывать?

насколько я вижу, тебе необходимо типизировать аргументы функции, это делается так: type TQwe = { bar: number; buzz: string; } // вариант 1 type TFunc = (list: TQwe[]) => number; const func: TFunc = list => list.length; // вариант 2 const func2 = (list: TQwe[]): number => list.length

Это переименование жсное, а не аннотации

С точкозапятыми на конце строк это превращается в тайпинги

С точкозапятыми на конце строк это превращается в тайпинги

С точкозапятыми это упадет

С точкозапятыми это упадет

++

если же хочешь что бы при деструктуризации у тебя подсасывались нужные типы к переменным, то тогда необходимо указать тип родительского объекта, а TS сам остальное выведет: type TQwe = { bar: number; buzz: string; foo: boolean; } declare const dataSource: TQwe; const { bar, buzz, foo } = dataSource;