Обчные API в JS либах бессмысленно неудобные

это правильно

вот прям не согласен) lodash, bluebird отточены уже давным давно, смысл брать их TS/Flow аналоги, если тайпинги есть?

ну, есть исключения

https://www.typescriptlang.org/play/#src=new%20Promise%3Cstring%3E(resolve%20%3D%3E%20resolve(100500))%3B ?

Не увидел коммент. Нет, это не решение, нет гарантий, что на вызывающей стороне не будут резолвить этот промис с тем типом, что надо.

Очень часто делается куча вариантов аргументов просто ради красоты

Не увидел коммент. Нет, это не решение, нет гарантий, что на вызывающей стороне не будут резолвить этот промис с тем типом, что надо.

ты при создании промиса можешь у resolve тип прописать

function foo(): Promise<string> { return new Promise((resolve: (value: string) => void) => { value(123) }); }

убого, но ты связался с типами в JS и с TS. Страдай)

Очень часто делается куча вариантов аргументов просто ради красоты

вот да) это кстати бесит)

Очень часто делается куча вариантов аргументов просто ради красоты

а ты вроде lodash не юзаешь как раз?)

нет

особо вроде не надо

ок, а если бы юзал, свои тайпинги по мере необходимости - норм вариант?)

ну да

свои тайпинг, в которых только то, что нужно, так как нужно

одним способом

function foo(): Promise<string> { return new Promise((resolve: (value: string) => void) => { value(123) }); }

так это не отличается от того, что предложил @chicoxyzzy

в то же время flow хорошо обрабатывает эту ситуацию

убого, но ты связался с типами в JS и с TS. Страдай)

добро пожаловать:)

кстати, всё еще надо делать? import * as React from 'react';

вроде как --allowSyntheticDefaultImports решает

https://www.typescriptlang.org/docs/handbook/compiler-options.html

надо проверить)

--allowSyntheticDefaultImports Allow default imports from modules with no default export. This does not affect code emit, just typechecking.

@fkuril эта опция не влияет на аутпут. В то же время ts не добавляет интероп для опредления формата модуля – commonjs или es6, как это делает бабель. а раз у тск нет интеропа, а у ректа нет дефолтного экспорта, import React from 'react' не должен работать

Короче вебпак не прав))

добро пожаловать в ченжлоги тогда

а можно носом тыкнуть в эти самые чейнджлоги? потому что в тех, что в репозитории (https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript) об этом ничего не нашел, в ишьюсах до сих пор спрашивают об этой проблеме, а о задаче такой нашёл только это https://github.com/Microsoft/TypeScript/issues/9562

Короче вебпак не прав))

это не вебпак, это бабель

по идее, можно поставить target в es6 и "дотранспливать" бабелем.

это проблема тайпингов реакта, выше говорили же

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

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

проблема тайпингов реакта как раз и решается опцией "--allowSyntheticDefaultImports"

ну да, скорее проблема es2015 import и commonjs

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

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

вот только бабель вкрутил интероп (по сути костыль), понимая проблемы пользователей, а тс – нет

ну, бабель выдумали костыль и если бы параллельно тс выдумали бы костыль, то получилось бы два конкурирующих подхода

и в ущерб этому правильному поведению, нормально в 2016 мы можем использовать ТС лишь как плагин к бабелю

да и сам бабель свой интероп ж ломал

да и сам бабель свой интероп ж ломал

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

ну да, просто не обновлялись)

:)

так а зачем вообще * as A вам в реальных задачах?

так а зачем вообще * as A вам в реальных задачах?

вот именно, незачем писать import * as React from 'react';

ну да

import { Component } from "react";

import { Component } from "react";

а вместо JSX использовать createElement?

вообще вариант, лишь бы не import * as React from 'react';

а в чем проблема TS использовать тот же костыль что и babel?)

а в чем проблема TS использовать тот же костыль что и babel?)

угу, это решило бы проблемы многих людей

а вместо JSX использовать createElement?

заэкспоузить реакт на весь проект

ну или еще как угодно подсовывать в *sx

ну или еще как угодно подсовывать в *sx

интересное решение, подумаю об этом

мы экспоузим и не паримся

несколько версий реакта на одной странице не встречается

ну или еще как угодно подсовывать в *sx

а как вы это делаете?

{ test: require.resolve("react"), loader: "expose?React" },

{ test: require.resolve("react"), loader: "expose?React" },

таааак. а вот с этим как быть?

declare const React где-нибудь в ваших файлах деклараций

declare const React где-нибудь в ваших файлах деклараций

точно! я переживал по поводу того, что подставится перед .createElement – React, не знал этого.

крутое решение

ERROR: S client not available

проблемы созданной технологией, призванной решать проблемы других технологий

у бабеля собстно проблема с * as blabla

крутое решение

;)

у бабеля собстно проблема с * as blabla

какая?

module.exports = function() {}

точно! я переживал по поводу того, что подставится перед .createElement – React, не знал этого.

ну да... так ведь и бабель с реакт пресетом делает то же самое, просто даже не задумывался, о том, что ТАК можно, когда в скоупе модуля нет React

module.exports = function() {}

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

ну, если заимпортить ее через import * as f from ""; то она потеряется и сделать f() нельзя будет

ага, тк это дефолтный экспорт в commonjs

нет конечно

export default function() {}

тоже не получишь функцию при import * as f

ну только это не дефолтный экспорт в commonjs

он и есть

exports.foo = function() {} - именованный

в es2015 export default это экспорт чего-то под именем дефолт

нет. это дефолтный экспорт, ты же default не получаешь при import * as foo?)

сделали бы флаг babelCompat и упростили всем жизнь. но нет)

нет. это дефолтный экспорт, ты же default не получаешь при import * as foo?)

так, почему это "дефолтный" экспорт?)

потому что у модуля есть дефолтный экспорт и есть именованные

имя не может быть default

также как switch-case. есть все случаи, а есть дефолтный случай

имя не может быть default

ну, может быть задано только ключевым словом

но имя у него все равно есть, оно дефолт

ну да, но имя у него все равно вполне конкретное

в данном случае, речь идет о синтаксисе import DEFAULT, { NAMED} from 'MODULE'

а не о том, что они отдельно "хранятся"

вот тут описано, почему дефолта нет в экспортируемых именах

If SameValue(n, "default") is false, then