Ну насчёт нет нужды это вряд ли. Можно обойтись — да

Там выше речь была о том чтобы дать возможность динамически назначать типы

собственно, зачем тогда статическая типизация?

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

Нет нужды использовать интерфейсы из чужих библиотек, наш код же не использует все их возможности, а только часть, для которой мы можем описать интерфейс самостоятельно для примера: const createPerson = () => ({ firstName: 'John', lastName: 'Doe' }) мы можем написать код: interface IPerson { firstName: string; } function showPerson(person: IPerson):void { console.log(person.firstName); } showPerson(createPerson()); и всё будет работать как надо

+

Нет нужды использовать интерфейсы из чужих библиотек, наш код же не использует все их возможности, а только часть, для которой мы можем описать интерфейс самостоятельно для примера: const createPerson = () => ({ firstName: 'John', lastName: 'Doe' }) мы можем написать код: interface IPerson { firstName: string; } function showPerson(person: IPerson):void { console.log(person.firstName); } showPerson(createPerson()); и всё будет работать как надо

Ну, это не такая уж и плохая идея. Я, наверное, перепишу этот код как ты предлагаешь, спасибо. Но в общем случае с утверждением не согласен. Наш код, например, использует все возможности этого внешнего интерфейса (все три, ага) :)

Ну динамически получать тип и потом его использовать, это не совсем путь статической типизации. (тем более получать из кода который пишешь не ты сам)

Почему динамически-то тип функции же известен

и записан статически

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

Я не уверен, что правильно называть это "приватным".

Этот тип используется в публичной функции. Методы этого типа мне известны снаружи и статически резолвятся. Если из этого типа что-то будут убирать, или в нём что-то будут менять — это будет ломающим изменением точно так же, как в любом публичном типе.

Единственная проблема: я не могу назвать имя этого типа, он анонимный.

Твоя идея с введением собственного интерфейса мне нравится значительно больше, чем имеющееся решение (которое я там сейчас в коде скотчем примотал). Но этот интерфейс будет копипастой из кода библиотеки. Копипаста — нехорошо.

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

парни

так что нашли нормального из tslint?

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

Не согласен с первым утверждением. Представим, что у библиотеки есть два метода: producer: () => ITerminal consumer: (ITerminal) => string Если я хочу получить объект из producer, сохранить его в локальной переменной, а потом передать в consumer — значит, мне нужен точный тип этого объекта, или полная копипаста интерфейса из кода библиотеки (спасибо структурной типизации, что это вообще работает). И я считаю, что копипастить в данном случае... странно. Я не хочу в данном случае менять внешнюю библиотеку или писать абстрактный адаптер (это нормальная задача, но она не имеет отношения к коду в данном случае). А то эдак получается, что нам вообще тайпинги от библиотек не нужны.

конкретно про ITerminal, я посмотрел там уже экспортиться этот интерфейс и проблема как бы решена, даже если бы автор действительно забил на это на всё всегда есть возможность форкнуть репу и использовать этот модуль по форку (где уже можно наэкспортить что угодно) то есть это не проблема Typescript в целом, это сложности opensource

на самом деле не экспортируется в main

Я поправил только чтоб index.d.ts экспортировался. Но из него не экспортируется интересующий нас тип :(

Это потому, что я не знаю, как правильно сделать. Кто-нибудь посоветует?

Скопировать нужный интерфейс в свой проект с другим названием?

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

Скопировать нужный интерфейс в свой проект с другим названием?

Но зачем? ._.

Я считаю, что нужно просто тайпинг сделать нормальный, чтоб он экспортировал тип ITerminal.

Да, должен. Но если его нет...

Тогда отправляешь пул-реквест и он появляется :)

и делаешь то что надо делать, пока они обрабатывают твой PR

Это-то понятно. Я локальное решение уже бахнул. Мне хочется по-нормальному теперь решить проблему :)

class DocumentList extends React.Component<Props, State> { render(): React.ReactElement<any> { return ( <DocumentListContainer/> ); } }

парни, а что тут вместо any писать?

пропсы DocumentList?

class DocumentList extends React.Component<Props, State> { render(): React.ReactElement<any> { return ( <DocumentListContainer/> ); } }

а я возвращаемый тип render() не указываю

ну тогда tsline typedef кидает )

чет я тож не понимаю, зачем писать у render тип результата

тип результата в interface/type пишу и вроде больше нигде)

нууу ок

typedef вырублю

Моя практика показала, что нужно типы как аргументов, так и результата, указывать по минимуму вообще

?

по минимуму это на жс писать?)

ну аргументов ts не позволяет не указывать)

export type Rule = any;

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

что можно вместо any написать чтобы оно хотя бы по названию типа проверяла?

не совсем понятно, что хочешь, чтобы проверялось

ну хотя бы чтобы на выходе был тип Rule

Моя практика показала, что нужно типы как аргументов, так и результата, указывать по минимуму вообще

Ругается на ошибки что ли?)) Для того, чтобы опускать типы аргументов и результата, нужно быть уверенным, что без этого код всё равно затипизируется правильно

хотя

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

понятно

тут тоже не осилили

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/mongodb/index.d.ts#L433

Ругается на ошибки что ли?)) Для того, чтобы опускать типы аргументов и результата, нужно быть уверенным, что без этого код всё равно затипизируется правильно

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

То есть почти везде

Я же не говорю "вообще не указывать типы". Я говорю "указывать в минимально необходимом количестве"

Ну вот функции рендера точно не нужно указывать, например)

Или, в том же реакте, указать функциональному компоненту тип StatelessComponent и уже не нужно напрямую указывать, что он принимает и что возвращает

Ну вот функции рендера точно не нужно указывать, например)

Потому что она выводится из родителя

Потому что она выводится из родителя

Так и я о том же

из return же

Что там, где выводятся типы, их указывать не надо

ERROR: S client not available

ну хотя бы чтобы на выходе был тип Rule

Генерик?

да это структура данных

генерик зачем? )

ну чтобы на выходе тот же тип был

<T>(v: T) => T

Хотя не очень понял что надо)

кто подскажет как быстро определить модуль, как any?

кто подскажет как быстро определить модуль, как any?

const moduleName: any

declare module "asd";

const moduleName: any

[ts] Could not find a declaration file for module 'peer'. 'c:/projects/meetover/node_modules/peer/lib/index.js' implicitly has an 'any' type.

посмотри в DefinitelyTyped

любое определение

declare module "asd";

где это нужно прописать? отдельный файлик?

declare module 'moduleName' { }

но any нельзя вызвать

где это нужно прописать? отдельный файлик?

в любом файле деклараций

d.ts

посмотри в DefinitelyTyped

для этого модуля устаревшие зависимости

для этого модуля устаревшие зависимости

Как пример

[ts] Could not find a declaration file for module 'peer'. 'c:/projects/meetover/node_modules/peer/lib/index.js' implicitly has an 'any' type.

https://www.npmjs.com/package/%40types%2Fpeerjs

ошибок там под миллион, версия сильно расходится с текущей

declare module 'moduleName' { }

экспорт добавить

в любом файле деклараций

а где его нужно разместить и как лучше назвать?

как угодно, у меня src/declarations.d.ts для такого лежит

там буквально 100 строк такой всякой ерунды

там буквально 100 строк такой всякой ерунды

спс

как угодно, у меня src/declarations.d.ts для такого лежит

а я по разным файликам кидаю

разницы нет

Да, но вроде как порядка больше;

хз, какой там порядок нужен в 100 строках)

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