flow показывает, что сам тип записан не верно, а не его данные

ну у flow есть проблема с отображением ошибок

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

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

как мне написать такой объект с методом, который получает коллбек, и такй чтобы туда нельзя было передать коллбек который ожидает наследника параметром?

Это какое-то антинаследование получается. Если подумать это можно реализовать через дженерики, но это кривость, которую надо устранять, а не типами покрывать

С этим то что нет так? https://www.typescriptlang.org/play/index.html#src=interface%20A%20%7B%0D%0A%7D%0D%0A%0D%0Ainterface%20B%20%7B%0D%0A%20%20%20%20boom()%3A%20void%0D%0A%7D%0D%0A%0D%0A%0D%0Afunction%20test(fn%3A%20(a%3A%20A)%20%3D%3E%20void)%20%7B%0D%0A%20fn(%7B%7D)%0D%0A%7D%0D%0A%0D%0Avar%20a%3A%20A%20%3D%20%7B%7D%0D%0A%0D%0A%0D%0Avar%20fn%20%3D%20(b%3A%20B)%20%3D%3E%20b.boom()%3B%0D%0A%0D%0Atest(fn)

https://flowtype.org/try/#0PQKgBAAgZgNg9gdzCYAoVBjOA7AzgFzAEEAHEsAXjAAoBKSgPjAEYAmAZgG518BPEgKZgASnACu+IVQDeqMGBIBDfAAsAXGAIAnAJbYA5gBo5YLAFsSOAdnwaAYmOwZ8OnMfl6AJgIAeoiQIA-Br+ku6mKjownqECuMEi4pIA2gC6qAC+3Ki+llqEUI7OrtimWgLKArG4dGAhSUKy8uX4YlqlTfKmcBZWNhqkJOHySqoaAOTA44ZgJvIYkdHVGsnSGenyWZlAA

вот пример

конкретный код, конкретная ошибка, тайпскрипт пропускает

@vkurchatkin https://www.typescriptlang.org/play/index.html#src=class%20A%7B%7D%0D%0Aclass%20B%20extends%20A%7B%20test()%7B%7D%20%7D%0D%0A%0D%0Alet%20a%3A%20A%5B%5D%2C%20b%3A%20B%5B%5D%3B%0D%0Aa.push(new%20A)%3B%0D%0Ab.push(new%20B)%3B%0D%0Aa%20%3D%20b%3B%0D%0Aa.push(new%20A)%3B

вот проще пример

это все одно же

не, это не тоже самое

я понимаю, что flow вообще там полмира обсчитывает. Но можно было бы принять, что тип скорее всего правильно описан, а переменная - нет

не, тут ошибка правильно)

просто подсветка в редакторе странная

попробуй в консольке)

тоже самое

да-да

Property not found in object literal, и указывает на литерал

должен на сам объект материться, а матертися на тип. идиотизм

все нормально, но подсветка на первой строке

главное, что когда код пишешь, ощущение, что все ок. А потом внезапно 100500 ошибок

да, это известный косяк

а еще если хочешь полностью все типизировать

конкретный код, конкретная ошибка, тайпскрипт пропускает

Имплементация пустого интерфейса - это ты из Go взял что ли?)) В твоем случае B совместим с A https://www.typescriptlang.org/play/index.html#src=interface%20A%20%7B%0D%0A%09doom()%3A%20void%0D%0A%7D%0D%0A%0D%0Ainterface%20B%20%7B%0D%0A%20%20%20%20boom()%3A%20void%0D%0A%7D%0D%0A%0D%0A%0D%0Afunction%20test(fn%3A%20(a%3A%20A)%20%3D%3E%20void)%20%7B%0D%0A%20fn(%7B%7D)%0D%0A%7D%0D%0A%0D%0Avar%20a%3A%20A%20%3D%20%7B%7D%0D%0A%0D%0A%0D%0Avar%20fn%20%3D%20(b%3A%20B)%20%3D%3E%20b.boom()%3B%0D%0A%0D%0Atest(fn) Я добавил всего один метод в твой полезный пустой интерфейс и всё начало подчеркиваться

type AuthStartAction = {type: 'AUTH_START', ...} - вот из таких экшнов надо будет составить огромный union и пихнуть в дженерик стора

не, это не тоже самое

https://www.typescriptlang.org/play/index.html#src=class%20A%7B%7D%0D%0Aclass%20B%20extends%20A%7B%20test()%7B%7D%20%7D%0D%0A%0D%0Alet%20a%3A%20A%5B%5D%2C%20b%3A%20B%5B%5D%3B%0D%0Aa.push(new%20A)%3B%0D%0Ab.push(new%20B)%3B%0D%0Aa%20%3D%20b%3B%0D%0Aa.push(new%20A)%3B%0D%0Ab.forEach(%20i%20%3D%3E%20i.test()%20)%3B ну хз

> Имплементация пустого интерфейса - это ты из Go взял что ли?

не вижу проблемы ну да ладно

теперь вот так: https://www.typescriptlang.org/play/index.html#src=interface%20A%20%7B%0D%0A%09doom()%3A%20void%0D%0A%7D%0D%0A%0D%0Ainterface%20B%20%7B%0D%0A%09doom()%3B%20void%0D%0A%20%20%20%20boom()%3A%20void%0D%0A%7D%0D%0A%0D%0A%0D%0Afunction%20test(fn%3A%20(a%3A%20A)%20%3D%3E%20void)%20%7B%0D%0A%20fn(%7B%20doom()%20%7B%7D%20%7D)%0D%0A%7D%0D%0A%0D%0A%0D%0A%0D%0Avar%20fn%20%3D%20(b%3A%20B)%20%3D%3E%20b.boom()%3B%0D%0A%0D%0Atest(fn)

> В твоем случае B совместим с A Но не наоброт в том и проблема

@vkurchatkin у flow нет implements?

Нет, зачем?

Это для номинальной типизации нужно

для явности)

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

а не ловить неправильные вызовы

Ну если у тебя в коде где то реализация присваивается к интерфейсу, то так и будет

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

и это простой способ этого добиться

хотя хз, может это привычка

Ну, для удобства - да

а можно сказать flow, чтобы запускался для файлов .ts ?)

и .tsx

Не думаю

Вообще это скорее всего баг, даже по меркам тайпскрипта

нет не баг, специально так сделано, и описано почему https://github.com/Microsoft/TypeScript/wiki/FAQ#why-are-function-parameters-bivariant

нашёл таки понятное описание

бред

export interface ISomeProps { SomeComponent: React.Component<IConfirmDialogProps, any> | React.StatelessComponent<IConfirmDialogProps> | React.ClassicComponent<IConfirmDialogProps, any> } error TS2604: JSX element type 'SomeComponent' does not have any construct or call signatures. Какие предложения?

оюъяснение про массивы - понятно, но причем здесь функции?

массивы можно считать ковариантыми, если ты мамой клянешься, что только читаешь

функции нельзя считать ковариантными относительно аргументов никогда

массивы можно считать ковариантыми, если ты мамой клянешься, что только читаешь

ага, а тип ReadOnlyArray только обещают

привет, кто-нибудь настраивал breakpoint на node и ts в visual studio code, уж очень хочется :)

нашел решение, как завести breakpoints и sourcemap на node/typescript + webpack, искал долго, так что держите, может пригодится http://stackoverflow.com/questions/36470946/debug-webpack-bundled-node-ts-with-visual-studio-code

https://twitter.com/typescriptlang/status/770655712183590912

+ в майлстоунах теперь нет 2.0.1, а есть 2.0.3 и 2.0.5

как кто указывает класс реактового компонента свойству в интерфейсе? React.StatelessComponent все ломает.

export interface ISomeDocFormProps { ConfirmDialog: IConfirmDialog } export type IConfirmDialog = React.ComponentClass<IConfirmDialogProps> | React.ClassicComponentClass<IConfirmDialogProps> OK но при добавлении | React.StatelessComponent<IConfirmDialogProps> получаю error TS2604: JSX element type 'ConfirmDialog' does not have any construct or call signatures.

как указать типизированную Stateless Function Component свойству

Ну все как умерли

Следующий вопрос. Нужны миксины с рабочим instanceof. Кто чем пользуется или как решает проблемы композиции

Следующий вопрос. Нужны миксины с рабочим instanceof. Кто чем пользуется или как решает проблемы композиции

А что не так с instanceof? Ts 2

type guards isFile(): this is File { return this instanceof File; }

Нужны примешивания классов с рабочим instanceof

instanceof а причём тут ts?

На ts

В идеале декоратором

https://www.youtube.com/watch?v=Qiqsg02nXFE

сидим уже наготове

пните меня когда начнется плз

вроде начинается

Когда я вижу что никакими костылями не получить миксины с работающим instanceof в ts, я думаю ну почему, почему dart не смогли нормально распиарить

Все ведь как положено. class Marstro extends Person with Musical, Aggressive, Denented {}

а зачем это нужно?

а зачем это нужно?

больше миксинов богу миксинов

из декларации не видно? Собирать классы по поведению, а потом в зависимости от этого строить в том числе и интерфейс.

для этого нужны типы в рантайме

т. е. не нужны

абрамов чет пришел

из декларации не видно? Собирать классы по поведению, а потом в зависимости от этого строить в том числе и интерфейс.

там есть механизм, а реального кейса нет. По мне это какое-то ненужно

Реальных кейсов овердохрена

И ts это появится, только хз когда

Они спред уже второй год не могут сделать

спред даже не на 3 стейдже кагбэ

какие кейсы, например?

и там не все так просто

Да понятно что вывести типы при таком динамизме не просто

какие кейсы, например?

Ты человек идущий, думающий, значит есть у тебя действия идти и думать, которые изменяют состояние положение и температура мозгов. И когда я открываю твою карточку в виде реактового контрола, то там автоматом только две кнопки - думать и идти. А все потому что когда я тебя собирал класс ДумающийИИдущийЧеловек расширяющий Человек вместе с Думающий и Идущий

Извините))

Ты человек идущий, думающий, значит есть у тебя действия идти и думать, которые изменяют состояние положение и температура мозгов. И когда я открываю твою карточку в виде реактового контрола, то там автоматом только две кнопки - думать и идти. А все потому что когда я тебя собирал класс ДумающийИИдущийЧеловек расширяющий Человек вместе с Думающий и Идущий

вот чето мне кажется это самое неправильное использование наследования, которое можно придумать

Но вообще это делается композицией

Но вообще это делается композицией

и да

JS вообще изначально на прототипах, сам боженька велел делать всё композицией))