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

eslint, prettier, standardjs

подскажите, можно импортировать json в ts?

Да

Ему d.ts прописать надо

кто-нибудь подскажите решение этой проблемы https://github.com/chybie/ts-json/issues/2

https://www.youtube.com/watch?v=9DK5jA5rQ8g Уже обсудили?

https://www.youtube.com/watch?v=9DK5jA5rQ8g Уже обсудили?

А ты пробовал Flow?

А ты пробовал Flow?

У него сборка в 5-6 раз быстрее?

Ой сомневаюсь ?

Но ведь вопрос всё равно надо задать

TypeScript-React-Starter #react https://github.com/Microsoft/TypeScript-React-Starter

TypeScript-React-Starter #react https://github.com/Microsoft/TypeScript-React-Starter

Круто!

кто-нибудь придерживается dependency inversion при написании ts-классов?

йа

вводит ли абстракции?)

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

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

а почему нет?

функция считай тот же объект, только с одним неявным методом

а функции уже что, не объект что ли?)

например, я бы с радостью испоьзовал метод last<T?source: Array<T> | string) для получения поледнего элемента массива/строки

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

Dep Inversion и Dep Injection это две большие разницы

чето я не понимаю сложности

в чем беда-то?

dep injection - Это один из паттернов Dep inversion, как я понимаю

не совсем

если вы хотите dep inversion, то поймите от чего и зачем вы хотите абстрагироваться

в полностью OOP-lang я бы создавал сервис с этим методом и передал бы его конструктору, например. Тогда зависимость внедрена явно. Если я просто вызову свободную функцию из класса, то зависимость неявная

в полностью OOP-lang я бы создавал сервис с этим методом и передал бы его конструктору, например. Тогда зависимость внедрена явно. Если я просто вызову свободную функцию из класса, то зависимость неявная

а что мешает ее передать явно?

import { last } from "My/Collection"

очень явно

и что такое "полностью ООП"?

без свободных функций

смолток что ли

java, С#

java, С#

они имеют отношения к ооп поменьше, чем жаваскрипт)

процедурщина на стероидах

в java даже лямбды есть

как и в шарпе собственно

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

в ts есть модули ж

ну давай так. какую задачу ты хочешь решить? почему глобальная функция тебе мешает?

не надо ничего в глобальную область пихать

import { last } from "My/Collection"

вот чем этот вариант не подходит?

причём здесь импорт?

Неужели без примера вопрос не понятен?ъ

не особо

причём здесь импорт?

решает проблему явных зависимостей

неявных)

ну т.е. делает их явными, а проблему неявных да

явные обычно не проблема)

явные обычно не проблема)

ну эт не совсем правда, другое дело, что неявные большая проблема)

function isEven(num: number) { return num % 2 == 0; } interface IPlacable { placeOnTheScreen(): void; } class Items { private items: IPlacable[]; place() { for (let item of this.items) { if (isEven(Math.random())) item.placeOnTheScreen(); }; } }

здесь isEven - неявная зависимость. В java или С# она бы передавалась в классе, динамические языки позволяют использовать её так, как япоказал. Если примерживаться инверсии зависимостей, как её внедрять, через конструктор?

это реальный пример?

нет

здесь isEven - неявная зависимость. В java или С# она бы передавалась в классе, динамические языки позволяют использовать её так, как япоказал. Если примерживаться инверсии зависимостей, как её внедрять, через конструктор?

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

это ничем не отличается от приватной функции, например

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

даже если isEven определена в другом модуле?

в чем смысл передачи isEven как зависимости?

почему не сделать ее приватным методом?

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

ERROR: S client not available

здесь это просто способ принятия решений, размещать объект или нет

не всякое "дублирование" кода надо устранять

знаю, обычно пишу её инлайн

классы вроде Utils или Tools это зачастую признак недостаточно продуманной доменной модели

повторяшь из учебника, и даже не понимаешь, о чём речь

тут одна свободная функция, какие util классы?

ты ее назвал утилитой

короче DIP про то, что у вас есть абстракция. Тут какой-то конкретной абстракции, за которой можно спрятать low-level module нет, поэтому и инверсию делать нет смысла

ладно, похоже, что Aleh прав

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

expression в if - принятие решение о размещении нового противника на экране, например

тогда сделай штуку "приниматель решения"

и ее внедряй

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

это уже будет какой-то внятный кусок доменной логики

который можно будет заменить на другой

спасибо за ответы

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

А, хотя что я туплю. Интерфейсы на то и интерфейсы, чтобы давать интерфейс. Ограничением входящих значений занимается что-то другое. Верно ведь?

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

union

А, можно вроде и так:

interface IComputer { type: 'ПК' | 'Моноблок' | 'ноутбук' | 'смартфон' | 'другое устройство'; installedOS: string; installedApps: string[]; }

А зачем I в интерфейсе? ?

ХЗ. Я новичок, я его всего лишь полгода изучаю

Не судите строго, каароч

Это соглашение именования интерфейсов из C#

Ну вот смотри, function handleSomething(something: ISomething) - какой здесь смысл в I? Это может быть как тип, так и интерфейс, так и класс

Грубо говоря, есть название сущности: Something. Всё остальное - лишний мусор вокруг

I, Interface, Abstract в названии - признак того, что чувак не подумал при написании хорошо

уже обсуждали)

Ну вот смотри, function handleSomething(something: ISomething) - какой здесь смысл в I? Это может быть как тип, так и интерфейс, так и класс

Мой класс использует интерфейсы. Интерфейсы в свою очередь юзают типы. А типы вообще элементарщину миксуют у себя там. Такая вот лестница говнокода. Но оно работает, и я не жалуюсь (правда, линтеры жалуются, но кто когда их слушал?).

Мой класс использует интерфейсы. Интерфейсы в свою очередь юзают типы. А типы вообще элементарщину миксуют у себя там. Такая вот лестница говнокода. Но оно работает, и я не жалуюсь (правда, линтеры жалуются, но кто когда их слушал?).

зачем вам линтер, если вы его не слушаете? ?