но они явно не {} и {}

я часто видел и сам не раз так делал

<{}, {}>?

React.Component<{}, {}> {}

синтаксис легальный

и зачем оно?

но в последнее время стал писать React.Component<any, any> {}

<{}, {}>?

похоже на смайлик

но в последнее время стал писать React.Component<any, any> {}

может тебе не нужен тс?

+1

да он никому не нужен

может тебе не нужен тс?

эй, я разве сказал, что я в продакшн пушу такое?

что за предположения вэч

я про прод ничего не говорил

я про прод ничего не говорил

на этапе прототипа структура пропсов и стейта бывает не ясна у компонента

поэтому ставлю заглушку

<T> - правильный обход any и вереницы type literals. <x,x> - нелегальная дичь. понятно.

<T> - правильный обход any и вереницы type literals. <x,x> - нелегальная дичь. понятно.

?

нет, нелегальная дичь — это то, что ты выше писал

Может кто-нибудь объяснить нубский вопрос, что значит, когда класс объявляется вот так: class A<{}, {}> {} Я понимаю, что дженерик, понимаю когда вот так, например, class A<T> {} - что значит, что для атрибутов / методов класса могут использоваться различные типы ("до первого" объявления типа)

^

Может кто-нибудь объяснить нубский вопрос, что значит, когда класс объявляется вот так: class A<{}, {}> {} Я понимаю, что дженерик, понимаю когда вот так, например, class A<T> {} - что значит, что для атрибутов / методов класса могут использоваться различные типы ("до первого" объявления типа)

все просто, дженериков можно быть необходимо несколько

для массива достаточно одного, для мапы нужно два

Для массива или какого-то друго типа же? )

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

Ага, понял теперь, спасибо )

при определении нельзя {} бтв

точнее не везде можно

и нигде не нужно

Это я усек :)

а я не понял

any vs {} в React.Component<P, S>

{} != any

да, это понял, я не понял почему нельзя юзать {}

О.о

я наоборот раньше писал any, а теперь пишу {} в случае если не известен тип стейта или пропсов

что значит не известен?

ну, например: был компонент стейтфул, а стал стейтлейс, в ходе рефакторинга, например пропсы остались, а на ф-цию еще не переделал т.е. не "не известен", а его нет

у меня редко стейт не {}

не, ну лайфцикл ж нужен бывает

а, да, ну я к тому, что в общем-то часто бывает нужно написать extends React.Component<FooProps, {}> и я пишу {} и не понимаю чем это плохо (писать {} вместо any)

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

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

я так делаю, но не знаю плохо ли это, а если плохо, то почему

export class Hello extends React.Component<HelloProps, undefined> { render() { return <h1>Hello from {this.props.compiler} and {this.props.framework}!</h1>; } }

вот так MS в примере делают

undefined ж дольше писать(

а, да, ну я к тому, что в общем-то часто бывает нужно написать extends React.Component<FooProps, {}> и я пишу {} и не понимаю чем это плохо (писать {} вместо any)

ну типа можно сделать this.state.toString()

а, все, догнал... или нет, мне бы на каком-нибудь простом примере: http://www.typescriptlang.org/play/#src=class%20Foo%3CT1%2C%20T2%3E%20%7B%0D%0A%20%20public%20state%3A%20T2%3B%0D%0A%0D%0A%20%20public%20foo()%20%7B%0D%0A%20%20%20%20console.log(this.state.toString())%0D%0A%20%20%7D%0D%0A%7D%0D%0A%0D%0Aclass%20Bar%20extends%20Foo%3C%7B%7D%2C%20any%3E%20%7B%0D%0A%20%20constructor()%20%7B%0D%0A%20%20%20%20super()%3B%0D%0A%20%20%20%20this.state%20%3D%20%7B%20x%3A%201%20%7D%3B%0D%0A%20%20%7D%0D%0A%7D%0D%0A%0D%0Aconst%20b%20%3D%20new%20Bar()%3B%0D%0Ab.foo()%3B

nvm ^ вопрос снят)

export class Some extends React.Component<void, void> {} же

так тоже видел да)

@vkurchatkin а ты во flow юзаешь interface?

да

но его отличия от {} непросто понять

но его отличия от {} непросто понять

от type alias? Ты просто писал, что это то, что надо выпилить из flow, но разница во flow такая же как и в ts - создания нового имени для типа и не создание)

нет, там много всяких мелких различий и багов

но это ж самое принципиальное?

насчет имени я даже не обращал внимания никогда

просто все остальное просто почему-то разные реализации

в общем, я не понимаю зачем функционально нужен interface

только усложняет жизнь

а зачем юзаешь?

ну во первых сижу на старой версии Flow - там есть разница с ковариантностью

Во вторых - чисто чтобы отделять типы-данные от типов-не данных

Т е interface - это объект с методами

Кстати в мастере сделали implements

ERROR: S client not available

Уж не знаю зачем

чтобы как в тс

да и без этого нормально

лишнее reserved word

Ребят, как сейчас по-правильному тип для window сделать? Начинаю уставать от <any>window...

Все всё делают через https://github.com/typings/typings, я так понимаю?

Ребят, как сейчас по-правильному тип для window сделать? Начинаю уставать от <any>window...

window должен быть в самих lib.d.ts файлах определен

lib.dom.d.ts

compilerOptions -> lib в tsconfig

я уже давно скоупед пакеты с дефинишнами юзаю с @types c npm https://www.npmjs.com/~types

> ompilerOptions -> lib в tsconfig можно чуть подробнее

да, сек

т.е. с ts идут дефинишны, для разных окружений

они лежат в соотв файликах и их можно подключать через tsconfig

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

{ "compilerOptions": { "target": "es6", "lib": ["es6", "es2017", "dom"], ...

вот, например, что у меня сейчас открыто в редакторе

сейчас ссылок накидаю

https://www.typescriptlang.org/docs/handbook/compiler-options.html – тут поиск по ключу --lib

https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript#including-built-in-type-declarations-with---lib

понял, спасибо!

Тогда еще такой вопрос, что делать, когда я хочу дописать руками что-то в window? (43,8): error TS2339: Property 'Events' does not exist on type 'Window'.

Тогда еще такой вопрос, что делать, когда я хочу дописать руками что-то в window? (43,8): error TS2339: Property 'Events' does not exist on type 'Window'.

https://www.typescriptlang.org/play/index.html#src=interface%20Window%20%7B%20Events%3A%20number%3B%20%7D%0D%0A%0D%0Awindow.Events.toString()%3B

только не размазывайте это по проекту

https://www.typescriptlang.org/docs/handbook/declaration-merging.html

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

Спасибо, ребят!

@mkusher Не хочет работать такая конструкция..

@m1neral на play же работает)

Может совсем старый lib.d.ts и он смержиться не может...

declare global { interface Window {

а так?