Announcing TypeScript 2.1

Announcing TypeScript 2.1

Object Rest & Spread

We’ve been excited to deliver object rest & spread since its original proposal, and today it’s here in TypeScript 2.1. Object rest & spread is a new proposal for ES2017 that makes it much easier to partially copy, merge, and pick apart objects. The feature is already used quite a bit when using libraries like Redux.

With object spreads, making a shallow copy of an object has never been easier:

let copy = { ...original };

Similarly, we can merge several different objects so that in the following example, merged will have properties from foo, bar, and baz.

let merged = { ...foo, ...bar, ...baz };

We can even add new properties in the process:

let nowYoureHavingTooMuchFun = {
    hello: 100,
    ...foo,
    world: 200,
    ...bar,
}

...

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Недавно знову пригодились нововедення TypeScript 2.1+. Ну хіба не мега-класно, коли можна написати генерік, який бачить «що йому за клас чи об’єкт передали», і виходячи із цього, запрошує його властивості чи методи в іншому аргументі?

class MyClass
{
  one(c: boolean){};
  two(){};
}

function genericForClass
<T extends Function, K extends keyof T['prototype']>
(classHandler: T, method: K)
{
  // More code
}

genericForClass(MyClass, 'one') // OK
genericForClass(MyClass, 'fake') // Error

Тобто ви вже не допустите помилки у другому аргументі, коли вписуватимете назву, в даному випадку «one» чи «two».

Корочше, завдяки Restify, Angular DI та TypeScript, світ скоро побачить новий веб-фреймворк, де Hello World, хоч і буде трохи складнішим за стандартний ConnectJS/ExpressJS/KoaJS..., але зате й більш соліднішим без лапши-коду і т.д.:

import {Server, Response} from './';
import {Injectable} from '@angular/core';

@Injectable()
class HelloWorld
{
  constructor(private res: Response){}
  
  run()
  {
    this.res.send('Hello World!');
  }
}

const server = new Server
({
  providersPerRequest: [HelloWorld]
});

server.get('/', HelloWorld, 'run');

server.listen(8080, function()
{
  console.log('%s listening at %s', server.name, server.url);
});

А, в смислі видалення типів при компіляції? Так, залишився. Існують деякі обмеження в зв’язку із цим, але мені це дошкуляє досить рідко.

можливо він мав на увазі type erasure

В ад этот ваш тайпскрипт, я на йоптаскрипт перешел и всем советую https://yopta.space

Головна проблема TypeScript — це Мікрософт з їх постійним бжанням додати до будь-якого їх продукту все, що тільки можна. Не розумію, навіщо розширювати синтаксис(!) мови функціональними речами? Як такі ласкаві, додайте до глобалу той самий extend і не допамагайте народженню «а я можу іще й так» коду. У кого були труднощі з extend({}, obj, {...})? Чому мусимо рорзізняти трикрапки для одних речей і для зовсім інших? Чому операнд блоку з’являється в функції клонування? Це мова? Це афріканс якийсь.

Ну мабуть із одними функціями та змінними можна написати багато чого. Але це далеко не означає, що продуктивність праці, читабельність, підтримка... будуть такими ж як при написанні ООП-коду.

Можна розвинути вашу думку і дійти до використання IDE — для чого його використовувати? У кого виникали труднощі написання/читання коду у, наприклад, Notepad++? Навіщо інтегрувати там git’и різні, FTP-функціональність... що програмісти такі тупі щоб їм оці (понапридумували) підказки там різні, автокомпліти...

P.S. Фічі розширення об’єкта не мікрософт понавидумував, а це те, що пропонується для ES2017.

А де ж там ООП let obj = {...}? Я ж зовсім не висловлювався з приводу функтори-об’єкти. При тому, що TypeScript з об’єктами робить, що заманеться (що при неякісному коді призведе до труднощів знайти початок цього безладу), нехай вони там вже будуть. Кінець кінцем вийдуть розумні книжки, які усім розкажуть, які патерни з TypeScript люди мусять використовувати, а які будуть коштувати людино-тиждні. Але оцей {...} - це імхо те саме, що якийсь push або shift зробити у вигляді синтаксичної конструкції. Може й згодилося би для якоїсь «модної» мови, або специфічної, але ж не для універсальної.
Приблизно, як ?. в шарпі. Губляться дуже легко, але писати — швидко, згоден.

Думаю, что именно TypeScript станет тем единым языком для веб-клиентов и веб-серверов, который давно уже пророчили. А если его ещё научить легко взаимодействовать с Java-кодом, как, например, Scalia, то перспективы открываются просто прекрасные

Ну так в запустить ноду внутри jvm и взаимодействуй с java кодом как хочешь.

Не, не, не. Я ж специально написал легко взаимодействовать, а не просто взаимодействовать. В легко взаимодействовать входит:
А) наличие d.ts файлов для всех классов JavaSE
Б) маппинг базовых типов
В) автоматически конвертировать базовые типы при вызовах методов
Г) корректная работа Java-машины с классами из TypeScript
Д) поддержка работы со Spring Framework :)

— Губозакаточную машинку этому господину!

Тут, скорее всего, лучшим решением будет написать компилятор TypeScript ->Java bytecode.

Писать java код на TypeScript? Зачем? В чем тут легкость взаимодействия и взаимодействия чего? jvm с jvm? Так там и сейчас все прекрасно... :)

Re: Писать java код на TypeScript? Зачем?

Сейчас часто приходится дублировать кучу кода на клиентской и серверной части:
а) сущности которыми обменивается клиент и сервер приходится объявлять в двух местах.
б) методы валидации входных данных так же приходится писать на клиенте на JS и на сервере на Java.
в) enum’ы (состояния, типы, статусы,...) часто приходится дублировать на сервере и на клиенте.
г) хотелось бы иметь общую систему исключений (одни и те же классы) на клиенте и сервере
д) еще куча всего...

Если и там и там можно будет писать на TypeScript кучу кода можно будет выбросить/не писать. А меньше кода — меньше баг, проще отладка, проще поддержка, короче время разработки и т.д.

Если и там и там можно будет писать на TypeScript кучу кода можно будет выбросить/не писать. А меньше кода — меньше баг, проще отладка, проще поддержка, короче время разработки и т.д.
Так же думали создатели GWT. И где сейчас GWT?

Создатели GWT предложили свое решение, которое оказалось не слшком хорошим. Но это не значит, что проблемы нет.

Именно существующую проблему GWT пробовал решить, просто оптимальным решением оказался не приход серверного языка (коих сотни) на клиент, а приход клиентского языка на сервер.

10 лет назад, когда был запущен GWT, всем было очевидно, что JS плохо подходит для тяжелых сереврных проектов, поэтому и остановились на портировании Java на клиент.
Сейчас же, с появлением ES2015 / ES2017, JS начал все сильнее походить на нормальный язык программирования.

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

просто оптимальным решением оказался не приход серверного языка (коих сотни) на клиент, а приход клиентского языка на сервер
Пока еще ничего не оказалось. Пока еще все по-старому. Доля «клиентских» языков на бекенде все еще пренебрежительно мала.
И проблема GWT ИМХО не в том, какой язык там используется — серверный или клиентский, а в том КАК он используется, в сопутствующих инструментах, в получающейся в результате нежелательной магии.

Мабуть, тепер мало сенсу інтегрувати дві різні мови, коли Node.js+TypeScript може справитись з багатьма задачами не гірше за Java.

Java сильна огромным набором библиотек и фреймворков с открытым исходным кодом. Тот же Spring Framework, например. Голый TypeScript на сервере никому не нужен, там уже давно с нуля ничего не пишут. Но если Scala можно компилировать в bytecode, то почему TypeScript нельзя?

Так про голий TypeScript на сервері ніхто й не говорить. Є якраз те, про що ви говорите по відношенню до Java — тисячі бібліотек визначенні як для TypeScript. Ставиться будь-яка бібліотека зараз дуже просто:

npm install --save @types/lodash

Ну давайте, називайте задачу, яка справді потрібна бізнесу і яку робить Java, але не зробить Node.js + TypeScript (окрім desktop/mobile application, звичайно ж).

Репутація людини, яка аргументовано щось критикує, а не просто тролить.

Це ви про моє виключення «desktop/mobile application»? Так, я читав мельком про NativeScript, але подумалось, що це щось нове, що не зможе поки що конкурувати з аналогами Java application. А от як бекенд-сервер, особливо для веба, то інтуїтивно припускаю, що Node.js + TypeScript таки зробить «що хочеш», що вміє Java.

По большей части, все сделает и даже может дешевле сделает. Фишка в том, что очень часто докупаются уже готовые решения, а эти решения либо на .нете, либо на джаве, и интегрировать эти штуки проще когда у тебя в штате есть .нетчики либо явисты (которые у тебя же и делают бэк или какие-то другие решения)

жир вже просто протікає в сусідні топіки

Мова це взагалі 10те, зазвичай же працюєш з API, при чому різні команди відповідальні за різні частини проекту. Яка різниця на якій мові та чи інша команда буде працювати зі своїм API.
А джаваскриптерам аби зі всіма проблемами на фронтові впоратись, перш ніж хоронити Джаву

Де ви побачили хороніння Java? Питання піднято: «чи варто робити гібрид, чи краще таки обійтись однією мовою?». Абсолютно очевидна відповідь — краще обійтись однією мовою, справлялася б лише вона з поставленими задачами.

Так от — таки справиться Node.js з багатьма, якщо не з усіма, задачами в якості бекенд сервера. А TypeScript прямо дуже добре допомагає уникати типових помилок для JavaScript.

P.S. І мова таки має значення, якщо ви програміст, а не ПМ який-небудь.

А для чого всіх під одну грєбьонку? Головне інтерфейс нормальний затвердити по якому будуть взаємодіяти різні частини аплікухи, на якій же мові вони написані, як на мене, байдуже. Можливо тоді джаваскриптери щей базами даних будуть займатись та девопс задачами?

Можливо тоді джаваскриптери щей базами даних будуть займатись та девопс задачами?

Якщо таке питаєте, то схоже ви не в курсі, що Node.js працює і з файловою системою, і з пам’яттю, і має вже драйвери для більшості, якщо не для усіх, найпоширеніших баз даних, і шифрує, і працює з поштою... має чудовий пакетний менеджер, який підтягує необхідні залежності від інших бібліотек, працює з git’ом, будує усю екосистему для проекта, таски через gulp’и там різні — усе однією мовою.

Чи я неправильно зрозумів і під гібридом мається на увазі GWT, або інше рішення, коли бекенд генерує код для фронтенда?

Ну в даному випадку, гібридною системою я називаю таку систему, в якій бізнес-логіки закладена більше, ніж однією мовою.

В TypeScript 2.1 заработал async/await как в C#. Хорошая штука, хотя я уже и приловчился писать кучу калбеков. Сроднился с костылями так сказать.

Думаю больше всего эту фичу оценят ASP.NET разработчики. Хотелось бы услышать их мнение. Если есть такие на ДОУ, отпишитесь плиз.

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

Звучит как намёк, что впервые эта фича появилась в питоне. К сожалению с питоном близко не знаком, а гуглить лень.

никаких намеков, в питоне оно действительно появилось только недавно

так, правда. „PEP 492 — Coroutines with async and await syntax” 09-Apr-2015. не знаю коли це було в .net але думаю раніше

в шарпі воно з’явилось літом 2012, з виходом 5ої версії

:) так норм, аж 3 роки йшло до Пітончика

Ні, у TypeScript 2.1 конструкцію async/await тепер можна транспілювати навіть у ES 5, ES3, чого раніше не було. Але раніше теж можна було використовувати async/await, якщо транспіляція була у ES6 або ES7.

Для бекенду я вже давно використовую async/await, бо нода давно розуміє ES6. А ось для фронтенда це справді нововведення.

Ця бібліотека дозволяє транспілювати ES2015 у ES5, так же ш? Якщо так, то проблем для такої транспіляції давно вже немає, в тому числі і для TypeScript (за виключенням async/await).

ця бібліотека юзається як плагін до бабеля, і цей плагін дозволяє використовувати генератори і await. Тому я не розумію, про яке нововведення ви говорите

Нововедення стосується TypeScript, раніше він не вмів транспілювати async/await -> ES3/ES5.

а бабель вмів, тому в зв’язці з ним можна було юзати await і раніше, і навіть на фронті

А с ts что, нельзя? сам то понял хоть что написал? в type script async/await юзали точно так же компилив его в es6, а потом через babel в es5.

ну вот именно это я и хочу сказать. В то время как топикстартер пишет, что

Для бекенду я вже давно використовую async/await, бо нода давно розуміє ES6. А ось для фронтенда це справді нововведення.

Андрій, де ви прочитали що я пишу це за фронтденд взагалі? Це я написав в контексті TypeScript. Що там може бути незрозумілим? Тим більше нижче я уточнив...

Хром55, ФФ-дев и Опера-дев это из коробки уже поддерживают. caniuse.com/#feat=async-functions

Эта ситуация мне напоминает DirectX и видеокарты. Сначала какае-то фичи появлялась в DirectX, а потом частично реализовывалась в железе в различных видеокартах. Все, чего не было в железе, делалось софтом.

TypeScript — это сейчас некая универсальная платформа (ака DirectX), а браузеры — 3D-ускорители, которые могут нативно поддерживать какие-то функции, а могу и нет. И TypeScript во время компиляции обязан учитывать все многообразие платформ, на которых будет исполняться сгенерированный JS-код.

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

type BooleanifiedPerson = { [P in keyof Person]: boolean };
вот чувствую, что такая запись будет здорово смущать людей

Це ви просто не звикли. Я раніше використовував ось таке оголошення типу:

type DatabaseType = 'mysql' | 'postgresql' | 'mssql';

let driver: DatabaseType;

Таким чином ви кажете, що змінна driver може мати лише одне із трьох указаних значень.

І тепер, з новим синтаксисом:

interface Person {
    name: string;
    age: number;
    location: string;
}

let propName: keyof Person;

Ваш запис досить просто читати:

type BooleanifiedPerson = { [P in keyof Person]: boolean };

let obj: BooleanifiedPerson

Тобто, об’єкт obj повинен мати строго ті ключі, які перераховані у інтерфейсі Person, але кожне значення такого ключа має логічний тип.

Там есть более интересные фичи чем эта

Може бути, я дочитав до цієї і зразу ж від радості поділився на ДОУ.

Подписаться на комментарии