или не так записать

но скорее я ошибусь на единицу где-то ))

да, это было бы круто

В kotlin есть case class-ы, и а-ля ML-ый паттерн-матчинг

ну так-то можно редьюсеры на хаскеле писать и транспайлить в js ))

а также прекрасный мир отсутствия дефинишнов под все библиотеки, которые тебе нужны))

Это из готовых к фронтенду решений

а также прекрасный мир отсутствия дефинишнов под все библиотеки, которые тебе нужны))

Да, это самая боль

вот поэтому я и написал, что типы и js вещи не всегда совместимые)

Вот типы для сортировки, для которой не нужны тесты https://github.com/davidfstr/idris-insertion-sort

ты всегда можешь сделать declare module "some-lib" и типизировать только свой обертку, которую юзаешь

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

create(name: string, shortname: string)

вот сигнатура

типы никак не уберегут от того, что ты перепутаешь name и shortname местами. И как раз это - большая часть ошибок

так юзай объекты

+1

create({ shortname, name})

https://flowtype.org/try/#0PQKgBAAgZgNg9gdzCYAoVAXAngBwKZgCCAxhgJZwB2A4gDwAqANGAAoB8YAvGAN6phhs+AFxgm-MDgCGWeFIAmolqgC+AbnRCCAJTzyArsTwAnWgGVmhDtwAUAZwxSMeURbBTSFSqMIBKLhxmGpi4BGaOzly86pqhRJ5UXBIAPvHkVHQA5AAiAKIAMrn0uQD6AGIA8hWZzDxgZIpgDsZklADmYCpsKWleWQDC2rmExeVVNbz1jc2tbcyUUgC2Lk0YLe2d3QKoUPqUCZRgxnqGJvYRK+FOeMwe6d69VP58AnYIZBjEABY2d14AdFpnhIBMQpHYCDkCkVSpVqqIXgIkccMPpjIceDEkZ0QWAwRCwJlBsNRnDMgjcQIUWiMVikSpcfI8FApPoYBhRL8DqJKGyYL4NAIGQz0EA

Набросал что-то

https://flowtype.org/try/#0PQKgBAAgZgNg9gdzCYAoVAXAngBwKZgCCAxhgJZwB2A4gDwAqANGAAoB8YAvGAN6phhs+AFxgm-MDgCGWeFIAmolqgC+AbnRCCAJTzyArsTwAnWgGVmhDtwAUAZwxSMeURbBTSFSqMIBKLhxmGpi4BGaOzly86pqhRJ5UXBIAPvHkVHQA5AAiAKIAMrn0uQD6AGIA8hWZzDxgZIpgDsZklADmYCpsKWleWQDC2rmExeVVNbz1jc2tbcyUUgC2Lk0YLe2d3QKoUPqUCZRgxnqGJvYRK+FOeMwe6d69VP58AnYIZBjEABY2d14AdFpnhIBMQpHYCDkCkVSpVqqIXgIkccMPpjIceDEkZ0QWAwRCwJlBsNRnDMgjcQIUWiMVikSpcfI8FApPoYBhRL8DqJKGyYL4NAIGQz0EA

еще есть смысл сделать reducer(): State

Можно для них типы завести - Name и ShortName и в зависимой системе типов сказать, что для любого name:Name и shortName:ShortName выполняется name.length>shortName.length. тогда не перепутаешь

еще есть смысл сделать reducer(): State

да, конечно

а зачем type Reducer?

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

угу, он дальше пригодится

в редьюсерах так можно. Но экшн криейторы же!

в принципе можно типизировать только самые простые, которые возвращают объект

они не нужны)

ну то есть, просто функция созает объект

чего сложного

я через сниппет обычно создаю сразу action creator + action type

ну, я говорил в такой схеме смущают строки)

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

но ок, мб попробую пару редьюсеров так запилить

Предложите абстракции для типизированных экшенов и типизированного листенера для шины

Что-то типа bus.emit(new DeleteAction<IDoc>("123"))

как листенер bus.on() на ваш взгляд должен выглядеть?

И как ловить такой экшен?

у тебя есть обощенный сервис, работающий с моделью документа определенного рода. Service<ISomeDoc>. Тебе нужно собрать сервис Creatable, Deletable и т/д/

https://www.typescriptlang.org/play/index.html#src=interface%20IUpdateable%20%7B%20update()%3Avoid%20%7D%0D%0Ainterface%20IDeletable%20%7B%20delete()%3Avoid%20%7D%0D%0Alet%20updater%20%3D%20%3CIUpdateable%3E%20%7B%0D%0A%09update()%3Avoid%20%7B%0D%0A%20%20%20%20%20%20console.log('update')%0D%0A%20%20%20%20%7D%0D%0A%7D%0D%0Alet%20remover%20%3D%20%3CIDeletable%3E%20%7B%0D%0A%09delete()%3Avoid%20%7B%0D%0A%20%20%20%20%20%20console.log('update')%0D%0A%20%20%20%20%7D%0D%0A%7D%0D%0A%0D%0A%0D%0Afunction%20extendClass%3CT%2C%20U%3E(first%3A%20T%2C%20second%3A%20U)%3A%20T%20%26%20U%20%7B%0D%0A%20%20let%20result%20%3D%20%3CT%20%26%20U%3E%20%7B%7D%0D%0A%20%20for%20(let%20id%20in%20first)%0D%0A%20%20%20%20result%5Bid%5D%20%3D%20first%5Bid%5D%0D%0A%0D%0A%20%20for%20(let%20id%20in%20second)%0D%0A%20%20%20%20if%20(!result.hasOwnProperty(id))%0D%0A%20%20%20%20%20%20result%5Bid%5D%20%3D%20second%5Bid%5D%0D%0A%20%20return%20result%3B%0D%0A%7D%0D%0Afunction%20extend3%3CT%2C%20U%2C%20V%3E(first%3A%20T%2C%20second%3A%20U%2C%20last%3A%20V)%20%7B%0D%0A%09return%20extendClass(extendClass(first%2Csecond)%2Clast)%0D%0A%7D%0D%0Afunction%20fabric%3CT%2CU%3E(model%3A%20%7Bnew(...arguments%3AU%5B%5D)%3A%20T%20%7D%2C...args%3AU%5B%5D)%20%7B%0D%0A%20%20%20%20return%20new%20model(...args)%3B%0D%0A%7D%0D%0A%0D%0Afunction%20Editable%20%3CT%2C%20P%2C%20U%2C%20D%3E(classType%3A%7Bnew(...args%3AP%5B%5D)%3AT%7D%2Cupd%3AU%2Cdel%3AD%2C...args%3AP%5B%5D)%20%7B%20%20%0D%0A%20%20%20%20return%20extend3(fabric(classType%2C...args)%2C%20upd%2C%20del)%0D%0A%7D%0D%0A%0D%0Aclass%20A%20%7B%0D%0A%09ping()%3Avoid%20%7B%0D%0A%09%09console.log('A%3A%3Aping')%3B%0D%0A%09%7D%0D%0A%7D%0D%0A%0D%0Alet%20a%20%3D%20Editable(A%2Cupdater%2Cremover)%0D%0A%0D%0Aa.ping()%3B%20%20%2F%2F%20A%3A%3Aping%0D%0Aa.update()%20%2F%2F%20update%0D%0Aa.delete()%20%2F%2F%20delete

В kotlin есть case class-ы, и а-ля ML-ый паттерн-матчинг

это из скалы с груви спижжено

груви? там вообще статических типов нет

Oleg https://flowtype.org/try/#0PQKgBAAgZgNg9gdzCYAoVAXAngBwKZgDKeMeAxhnAE4A8AKgDRgCyAfGALxhgAUAbgC4wdAJSd2AfmYBudAEsAdhjxUoAQzIEAQgFcAzvXYBvVNzwBbORn5DRQvnDkATWdz06ARnrJU5HvDRsPHok5JRUQsSkFNT0TGxMUApCPOZCzGIc7A7OIvaOLqgAvkA

груви? там вообще статических типов нет

а, да

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

но в ML и flow наиболее приятно

во flow? паттерн матчинг?

Без рантайма или манглинга толком паттерн матчинг не сделать

Полюбас rtti сильный нужен

А ни flow ни тайпа этого не дают

в языке не будет

своими силами — дорого

Дорого в плане раньайм затрат перфоманса или реализации?

перформанса

Aaaaaa

ага, сегодня в лс подгон сделали)

Так только на входе внешних апи делать надо

был такой исследовательский проект safe typescript

https://www.microsoft.com/en-us/research/video/safe-typescript-safe-and-efficient-gradual-typing-for-typescript/

во flow? паттерн матчинг?

adt

https://www.microsoft.com/en-us/research/video/safe-typescript-safe-and-efficient-gradual-typing-for-typescript/

решили, что безопасность не нужна

Я думал сделать rtti по d.ts

И все еще думаю попробовать

без паттерн матчинга это не настоящие adt

https://www.typescriptlang.org/play/index.html#src=interface%20IUpdateable%20%7B%20update()%3Avoid%20%7D%0D%0Ainterface%20IDeletable%20%7B%20delete()%3Avoid%20%7D%0D%0Alet%20updater%20%3D%20%3CIUpdateable%3E%20%7B%0D%0A%09update()%3Avoid%20%7B%0D%0A%20%20%20%20%20%20console.log('update')%0D%0A%20%20%20%20%7D%0D%0A%7D%0D%0Alet%20remover%20%3D%20%3CIDeletable%3E%20%7B%0D%0A%09delete()%3Avoid%20%7B%0D%0A%20%20%20%20%20%20console.log('update')%0D%0A%20%20%20%20%7D%0D%0A%7D%0D%0A%0D%0A%0D%0Afunction%20extendClass%3CT%2C%20U%3E(first%3A%20T%2C%20second%3A%20U)%3A%20T%20%26%20U%20%7B%0D%0A%20%20let%20result%20%3D%20%3CT%20%26%20U%3E%20%7B%7D%0D%0A%20%20for%20(let%20id%20in%20first)%0D%0A%20%20%20%20result%5Bid%5D%20%3D%20first%5Bid%5D%0D%0A%0D%0A%20%20for%20(let%20id%20in%20second)%0D%0A%20%20%20%20if%20(!result.hasOwnProperty(id))%0D%0A%20%20%20%20%20%20result%5Bid%5D%20%3D%20second%5Bid%5D%0D%0A%20%20return%20result%3B%0D%0A%7D%0D%0Afunction%20extend3%3CT%2C%20U%2C%20V%3E(first%3A%20T%2C%20second%3A%20U%2C%20last%3A%20V)%20%7B%0D%0A%09return%20extendClass(extendClass(first%2Csecond)%2Clast)%0D%0A%7D%0D%0Afunction%20fabric%3CT%2CU%3E(model%3A%20%7Bnew(...arguments%3AU%5B%5D)%3A%20T%20%7D%2C...args%3AU%5B%5D)%20%7B%0D%0A%20%20%20%20return%20new%20model(...args)%3B%0D%0A%7D%0D%0A%0D%0Afunction%20Editable%20%3CT%2C%20P%2C%20U%2C%20D%3E(classType%3A%7Bnew(...args%3AP%5B%5D)%3AT%7D%2Cupd%3AU%2Cdel%3AD%2C...args%3AP%5B%5D)%20%7B%20%20%0D%0A%20%20%20%20return%20extend3(fabric(classType%2C...args)%2C%20upd%2C%20del)%0D%0A%7D%0D%0A%0D%0Aclass%20A%20%7B%0D%0A%09ping()%3Avoid%20%7B%0D%0A%09%09console.log('A%3A%3Aping')%3B%0D%0A%09%7D%0D%0A%7D%0D%0A%0D%0Alet%20a%20%3D%20Editable(A%2Cupdater%2Cremover)%0D%0A%0D%0Aa.ping()%3B%20%20%2F%2F%20A%3A%3Aping%0D%0Aa.update()%20%2F%2F%20update%0D%0Aa.delete()%20%2F%2F%20delete

выглядит неплохо, но сразу инстанс это маловероятно.

Я бы вообще там функции эти по одной закидывал, с тем же интерфейсом)

Но суть думаю примерно такая)

MobX нужен или не нужен?

Идеально!

Я бы вообще там функции эти по одной закидывал, с тем же интерфейсом)

а есть вариант чтобы именно класс собирался?

MobX нужен или не нужен?

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

Oleg https://flowtype.org/try/#0PQKgBAAgZgNg9gdzCYAoVAXAngBwKZgDKeMeAxhnAE4A8AKgDRgCyAfGALxhgAUAbgC4wdAJSd2AfmYBudAEsAdhjxUoAQzIEAQgFcAzvXYBvVNzwBbORn5DRQvnDkATWdz06ARnrJU5HvDRsPHok5JRUQsSkFNT0TGxMUApCPOZCzGIc7A7OIvaOLqgAvkA

Володь, а на TS?

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

Зачем его выпиливать? ?

Ну на ts 2.0 я думаю аналогично

Продолжаю собирать предложения по реализации шины типизированных экшенов. bus.emit(new DeleteAction<IDoc>("123")) как должен выглядеть и работать bus.on()?

Зачем его выпиливать? ?

не удобно с ним работать

кто какой DI предпочитает в ts?

Disability insurance?

IoC

:{{

dependency injection

я понимаю)

причем тут DI

и TS

в ts есть типы, было бы прикольно на их основе компилировать ioc

но у нас пока руками простейший контейнер

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

От количества зависит

Свитч линеен

Свойство - хеш

До десятка точно свитч должен выиграть

Дальше хз

там что-то было про 128й кейс

дальше деопт

это всё что я знаю :D

@vkurchatkin а ты не пробовал BuckleScript?

там 1.0 вышел

Oleg вот этот хвалили https://github.com/inversify/InversifyJS