Что-то не пашет.

https://www.typescriptlang.org/play/index.html#src=enum%20Enum%20%7B%0D%0A%20%20%20%20name1%2C%0D%0A%20%20%20%20name2%2C%0D%0A%7D%0D%0A%0D%0Ainterface%20I%20%7B%0D%0A%20%20%20%20%5Bname%3A%20Enum%5D%3A%20()%20%3D%3E%20void%3B%0D%0A%7D%0D%0A

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

Каждый раз, когда вижу у кого-то enum ?

Умеет

https://www.typescriptlang.org/play/index.html#src=enum%20Enum%20%7B%0D%0A%20%20%20%20name1%2C%0D%0A%20%20%20%20name2%2C%0D%0A%7D%0D%0A%0D%0Ainterface%20I%20%7B%0D%0A%20%20%20%20%5Bname%3A%20Enum%5D%3A%20()%20%3D%3E%20void%3B%0D%0A%7D%0D%0A

делай Issue

Надо поискать, может есть уже. Ещё не догуглил.

Каждый раз, когда вижу у кого-то enum ?

У нас их 30+ :3

Cry me a river

Короче можно просто делать так и не париться.

Я вот такую неприятность обнаружил вчера

Есть компонент со static member

Есть декоратор injectIntl

В общем, с ним статики пропадают

Умеет

Серьезно? Прям настоящие вычисляемые поля?

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

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

А можешь пример?

Я их юзаю вне юнит-тестов)

а не тормозят этот, перформанс?

Серьезно? Прям настоящие вычисляемые поля?

Ну вроде О.о

а не тормозят этот, перформанс?

В смысле?

Они же compile-time

шо?

It just so happens that TypeScript has something called a type guard. A type guard is some expression that performs a runtime check that guarantees the type in some scope.

https://www.typescriptlang.org/docs/handbook/advanced-types.html

It just so happens that TypeScript has something called a type guard. A type guard is some expression that performs a runtime check that guarantees the type in some scope.

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

Поместил enum в файл, где у меня экспортируются (без declare) только интерфейсы. И теперь для этого файла ошибка ts-loader: Module build failed: Error: Typescript emitted no output for noEmit стоит false Знаю, что enum сущность рантайма, а interface сущность этапа компиляции. Они не дружат в таком тандеме?

У файла расширение d.ts просто для дополнительной информации, не для declare.

Убрал export у enum и теперь пишет: A 'declare' modifier is required for a top level declaration in a .d.ts file.

Блин, короче, ну нужно было делать расширение d.ts Оно получается зарезервировано и нельзя использовать как обычное расширение .ts

Блин, короче, ну нужно было делать расширение d.ts Оно получается зарезервировано и нельзя использовать как обычное расширение .ts

Попытка отделить декларации от рантайм кода обречена на провал

Хотел отделить чисто для информативности. Теперь придётся переименовывать в что-то на подобии file.decl.ts

Хотел отделить чисто для информативности. Теперь придётся переименовывать в что-то на подобии file.decl.ts

или в file.h.ts

Да, но это ++ стайл.

jsxx

неа)) @ZeroBias так юзает, я тож. Весьма удобно

О, правда кто-то так делает? Класс.

jsxx

tspp

:)

или в file.h.ts

Давайте это протащим как стандарт де-факто в тс-сообществе.

зачем?

Информативно же.

Чтобы все друг друга понимали.

Неформальная конвенция.

я вообще не понимаю зачем использовать d.ts, если только они не около js файлов

Нее-нее. h.ts - это ведь не альтернатива для d.ts, это имено ts файл для декларации типов без declare. Например, для интерфейсов реакт-компонентов.

почему их просто в ts файле не писать?

почему их просто в ts файле не писать?

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

ГРуппировать надо сущности по бизнес-принадлежности.

^ все так

А не отделять декларации от использования

Если у меня есть модуль, в котором есть функция, которая принимает объект, который описан неким интерфейсом, нет ни одной причины не положить интерфейс рядом с фнукцией. А если он предполагает быть внешним, то ещё и экспортнуть его. Импортировать будет удобнее. export interface SomeFunctionArgShape { prop1: string prop2: string } export function SomeFunction(arg: SomeFunctionArgShape) { /* ... */ } И дальше: import {SomeFunction, SomeFunctionArgShape} from "./module" // и поехали

Иногда бывает, что модулей много, и все они составляют некую бизнес-единицу. Внутри какие-то типы переиспользуются. Тогда я делаю types.ts и кладу общие типы туда. Но там же могут быть guard-функции например, ничего страшного в этом нет.

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

А не отделять декларации от использования

у меня для одного ts файла может быть около 10-15 интерфейсов а также есть интерфейсы которые не привязаны ни к одному конкретному файлу, используются много где также есть интерфейсы только для бизнес сущностей

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

Тут уже сказывается лень придумывать названия )

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

Вся равно дальше папочки с модулями не уходит

а еще есть классы

и переменные

они тоже могут быть не привязаны к конкретным файлам

а еще есть классы

Угу, класс это вроде бы и тип, а вроде бы и рантайм

ага

А равно как и енумы

ERROR: S client not available

а енум вот не нужен

а енум вот не нужен

вот тоже не смог найти причину использовать enum

Был нужен пока не было string literal types

нужен нормальный енум, а тот, что есть не нужен. Так правильнее)

А сейчас легаси осталось

а вот .h.ts файлы юзаю ибо удобно, есть директория с бизнес сущностью и там типы

нужен нормальный енум, а тот, что есть не нужен. Так правильнее)

какой нормальный?

который делает проверки и не попадает в рантайм в виде странного объекта

что-то типа const enum

но с норм проверками

что-то типа const enum

Хотел только что предлоджить )

но их не оч удобно дебажить потом)

Какие-то противоречащие друг другу требования

Чтобы и дебажить было легко и в рантайм не попадало

пацаны

как это сраный jest заставить работать с TS

/Volumes/dev/apps/triplepoint/formbuilder/src/views/components/Sidebar/SidebarButton.tsx:1 ({"Object.<anonymous>":function(module,exports,require,__dirname,__filename,global,jest){import * as React from 'react';

подключил ts-jest

чот не але

а таргет какой?

es5

менял на ES6 — та же херня (

а на es3? :)

очень смешно

но тем не менее я уже голову сломал (

ну так-то да, чего-то ts-jest не але

очень смешно

ни разу не смешно, я es3 таргет юзаю

и это иногда оправдано

мда

throw "qweasd" воткнул в preprocessor.js

пофигу

в process()