как в TS можно сделать дженерик для обычного хэша? Object<T> не катит (Object is not generic), а { [s: string]: T } странноват (не изящно :))

и кто дружил lodash с ts? import { pickBy } from ‘lodash’ ругается pickBy(<Object>scopes, keys) ругается

и кто дружил lodash с ts? import { pickBy } from ‘lodash’ ругается pickBy(<Object>scopes, keys) ругается

import * as _ from 'lodash'; ... _.groupBy(xs, x => x.smth)

Норм, да

А React у нас с Flow оказывается работает... разочарование месяца...

А React у нас с Flow оказывается работает... разочарование месяца...

Это было вполне логичным решением свой же продукт интегрировать с другим своим продуктом

То да

Кто бы написал теперь генератор flow -> d.ts

А React у нас с Flow оказывается работает... разочарование месяца...

А в чем проблема?

И какие в flow есть синтаксические конструкции, которые ts не умеет?

Потому, что не с TS :)

Они немножечко несовместимы.

type vs interface и т.п.

Но жить это не мешает.

Они немножечко несовместимы.

Я не вникал, но в ts есть конструкция type, например

Есть

Flow это эти вот PropTypes?

import * as _ from 'lodash'; ... _.groupBy(xs, x => x.smth)

Да, так и решил. Но дальше тайпскрипт совсем пошел с ума сходить

Flow это эти вот PropTypes?

Нет, PropTypes для рантайм проверки. При исопльзовании TS и Flow они не так чтобы прям обязательны.

да, я понимаю, что runtime, я просто с 'Flow' не сталкивался, думал это одно и тоже. Это тогда наверно какая-то система аннотаций типов для JS альтернативная?

Да, именно так и есть.

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

Как-то мне огород с class Bar extends Foo<Bar> ... не очень нравится.

там есть this как возвращаемый тип

Ага, я тоже с ним уже разбежался A 'this' type is available only in a non-static member of a class or interface.

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

Для этих случаев есть позднее статическое связывание. Не вижу препятствий для определения типа на стадии компиляции типа возвращаемого статическим методом базового класса при его вызове в наследнике. Правда для этого наверное какое-то ключевое слово должно быть.

Что-то вроде {new(): static}

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

Точно.

типа create(x): thisClass { return new thisClass(x, y) }

Ну да. Только внутри логика сложнее немножко будет.

create при этом static в родителе

ага

Можно так сделать Child.create<Child>() но это будет оверхед

Пропозал на эту тему в TS есть

Сейчас читаю

Может в 2.0 есть такая штука

Можно так сделать Child.create<Child>() но это будет оверхед

а разве можно параметры в дженериках использовать для new?

Там new не будет :)

Он будет возвращать псевдо объект типа.

Но это не суть.

Главное дать понять, что возвращает тип класса от которго он унаследован.

А на твой вопрос, кстати, есть ответ

А, нет, нету

Короче пока самый адекватный вариант такой.

в спецификации 1.8 такого точно не было. а 2.0 я еще детально не штудировал..

wtf если ты скастишь объект к какому то классу, у него не появятся методы этого класса, нахуя.

wtf если ты скастишь объект к какому то классу, у него не появятся методы этого класса, нахуя.

Это же пример

Логика там будет сложнее

не проще тогда кастить полученный объект к своему классу Bar

Нет

Потому что эти методы будут вызываться многократно. Это не фабрика.

Вернее почти фабрика, но не она.

Проще сказать так: каждый раз кастовать при вызове этих статических методов не хочется совсем.

как тебе тогда function baz<T>(cls): T { return cls.baz() as T }

И таких методов статических будет около десятка.

а, фейл

все равно T указывать придется

ну лан, мне кажется фигней страдаешь

any any any и не паримся

any any any и не паримся

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

как тебе тогда function baz<T>(cls): T { return cls.baz() as T }

Нет проблемы T вынести на уровень класса Foo<T>

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

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

Я как раз от них и хочу уйти.

И вот почему

Короче, в классе, который мы хотим замиксовать, могут использоваться статические методы примеси.

class Foo<T> { static baz():T { return {} as T; } } class Bar { static baz2() { return this.baz(); ??? } } class FooBar = mixin(Foo, Bar)

Что-то вроде того

Поэтому надо Bar extends Foo

Но A extends B<A> как-то не гламурно

почему бы тебе все статические методы не заменить на обычные и не использовать обычное наследование

типа FooBuilder implements Builder<Foo> и погнал

Все просто. Мне эти методы не нужны в инстансе, т.к. он является объектом с данными.

ну, их и не будет

смысл в том чтобы у класса был метод build который и возвращал объект нужного тебе типа

в общем я ушел

Я тебя понял. Но мне надо иметь всю эту информацию на уровнее определения класса, а не в скомпонованном через build объекте. Это, в общем-то, почти тот же самый mixin получается.

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

А как ты этот метод определил? Ты же просто хочешь сделать фабричный метод?

А как ты этот метод определил? Ты же просто хочешь сделать фабричный метод?

В принципе да, будет несколько фабричных методов, которые возвращают инстансы дочерних классов. Но таких дочерних классов может быть сотня. Сами же фабричные методы будут вызываться через потомков и указывать каждый раз Foo.staticMethod<Foo>() считаю излишним. В PHP (sic!), к примеру, это решается через late static bindings (например function getInstance() { return new static } ).

Я тебя понял. Но мне надо иметь всю эту информацию на уровнее определения класса, а не в скомпонованном через build объекте. Это, в общем-то, почти тот же самый mixin получается.

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

Так это, если ты опишешь метод как staticMethod<T extends Foo>(): T

Этиз классов может быть сотня. Они должны знать о реализации методов базового класса, но никакие другие интерфейсы не должны.

Так это, если ты опишешь метод как staticMethod<T extends Foo>(): T

Да

А в реализации будет return new this или как там

То ts сам не зарулит?

Нет, в реализации будет логика гораздо сложнее.

Реализация возвращает не себя?

Что-то вроде вызова через стор (WeakMap, к примеру)

Да хоть хттп запрос, на выходе что?

Но возвращать всегда будет new Child(...)