[Useful Info] JS OOP - TypeScript
За всички, които не харесват OOP-то в JavaScript съществуват благинки, които ни позволяват да пишем по-културно такова, което се транслира до чисто JS.
Една такава благинка е TypeScript. В тази тема ще видите как се използва базово, примерите са извадени от официалния сайт.
Освен това ни се дават възможности за "типизиране" на езика и изкарване на грешки преди "компилация".
Как да започнем?
- Ако ползвате Visual Studio 2012 - инсталирате това - така ще имате компилатор и едитор за TypeScript.
- Ако ползвате Visual Studio 2013 Update 2 - TypeScript е in-build по default.
- TypeScript го има и в Node.js Tools for Visual Studio. Можете да сложите направо и този пакет.
- Може да се инсталира и през npm (Node.js) - npm install -g typescript
- Ако не използвате VS, компилаторът се вика по следния начин от command line-a: tsc example.ts - където example.ts е избраният ни TypeScript файл.
Базово използване:
function hello(name: string) {
return "Hello, " + person;
}
В този пример създаваме функция hello, която приема параметър name от тип string.
Извикването на функцията с друг тип данни би изкарало грешка:
var name = [0, 1, 2];
alert(hello(name));
Supplied parameters do not match any signature of call target
Въпреки грешката, изходен файл ще бъде създаден, TypeScript може да бъде ползван дори и с грешки в кода, смисълът е да ви предупреди предварително, че правите "мизерии".
Интерфейси (Interfaces):
TypeScript поддържа писането на interface-и, пример:
interface Person {
firstname: string;
lastname: string;
}
Използването им обаче е само за лична ориентация и подреждане на кода, интерфейсите се транслират до код без съдържание или иначе казано - до нищо, просто се премахват.
Класове (Classes):
class Student {
fullname : string;
constructor(public firstname, public middleinitial, public lastname) {
this.fullname = firstname + " " + middleinitial + " " + lastname;
}
}
Указването на public при приемането на параметри в конструктора ни позволява автоматичното създаване на property-та за тези параметри.
Нищо не разбрах? - TypeScript Лекция на Английски
Не ме кефи нещо... - Try CofeeScript
Мога ли да го ползвам на изпита? - Транслира се до чисто js, така че на който му е удобно може да го ползва.
За какво ми е да уча чисто ООП, не мога ли да науча направо това? - Не би било добре, не се ползва в много от компаниите, научете първо чисто ООП и после TypeScript или CofeeScript.
Юле, по принцип съм супер съгласен с теб, но то друга страна сме на двата фронта - ти, която обожаваш джаваскрипт, и аз - който му е трудно да преглътне, че нещата се случват там по такъв начин. :)
И се питам - тъй като ми е трудно да преглътна себе си и да пиша the javascript way, защо да не пиша по моя си начин на някакъв такъв език, пък после компайлъра ще го сведе до js? :)
@RoYaL Ще се помъча да отговоря на въпроса ти: "...защо да не пиша по моя си начин на някакъв такъв език, пък после компайлъра ще го сведе до js? :)". Просто така няма да трупаш опит с JavaScript, а с TypeScript... или там на каквото пишеш. А когато трябва да се ориентираш в чужд JavaScript коd ще ти е по трудно. Все пак ако работиш в екип, който е ориентиран към JS приложения на дали всички остани няма да пишат "the javascript way".
@milen8204 въпросът ми е по-скоро бизнес ориентиран. Ако съм в екип, който няма опит с javascript и the javascript way, а трябва да напише приложение на JS, защо да не пишем на близък до познатия ни синтаксис и парадигма, вместо тепърва да учим the javascript way. Аз нямам нищо против научаването на нови технологии, но няма ли да спадне delivery-то така, а и в процеса на работа, не е сигурно че учейки го и същевременно използвайки го, ще се използва по най-добрия възможен начин.
В крайна сметка, за да постигнеш целите си избираш най-suitable технологията по няколко критерия, единия от тях е с какъв човешки ресурс разполагаш. Ако хората ти знаят технологията "X" по-добре от "Y", а двете могат да постигнат еднакво добре крайната цел, няма никаква причина да избереш "Y".
Наистина, може би си е нужна доза фанатизъм, за да се пише vanilla JavaScript. Но в този ред на мисли, може да ви се стори забавна dejavu.js библиотечката. Нарича се така, защото... е досущ като нещо, което сте вече виждали :}
Нещата не са чак толкова нелогични в javascript. Просто се иска малко опит, за да се научат. Чак пък фанатизъм, малко пресилено.
Аз въобще не харесвам никакъв тип адаптери. Неправилно ми се вижда, ако искам да получа джаваскрипт да минавам през Typescript, Coffeescript, та дори и JQuery. Както и ако искам да получа CSS да минавам през SASS или LESS. Възприемам го като слабост на програмиста.
@ttitto, ако програмираш за кеф, сигурно има някакъв смисъл да се доказваш пред себе си/някого другиго, как умееш всичко по всички различни начини. Когато обаче програмирането се превърне в работа, каквото всъщност е (не изключвам работата да е удоволствие) тогава нещата придобиват по-бизнес смисъл. За TypeScript и CoffeeScript мога да те разбера. За jQuery и SASS/LESS обаче - не. Далеч не казвам, че jQuery е перфектната библиотека за целта, но е същото като да кажеш, че не би ползвал angular, а би си написал сам framework. Няма смисъл да преоткриваш топлата вода. Ако пишеш native javascript в един момент ще стигнеш до нуждата да си напишеш абстракциите, които има в jQuery. И тогава няма да ползваш jQuery а ... tvoeto-si-sobsvtenoQuery. Което най-вероятно само ти ще си разбираш. И вместо да пишеш $("#element").click() ще пишеш примерно get("#element").onClick(). Което само ще накара хората, с които работиш в екип, да им се налага да учат твоята абстракция, вместо да си ползват тази, която вече знаят - на jQuery, което между другото run-ва на 80% от сайтовете, които не ползват фреймуърк, а ползват javascript.
SASS те улеснява с променливи, mixin's и други неща, които ако не ги ползваш, рискуваш да имаш code-duplication и unmaintainable css.
Всички тези абстракции са измислени, не защото на който са му трябвали е слаб програмист, а защото намира нещата за по-правилни така. Такава е еволюцията на програмирането като цяло. Така са произлезли езиците във времето - това ще го направим в библиотека, онова ще го направим в библиотека и хоп - нов език. В крайна сметка, по твоята логика, да не ползваме C# защото върви с .NET Framework, който има около 10 пъти повече абстракции, от колкото jQuery.
И аз не харесвам фреймуърците, които имат doAll() метод и всичко върви на магия, но нямам нищо против някой да ме улесни. За академична цел може и даже е наложащо да научиш как работят нещата под абстракцията, но също толкова наложащо е и никога да не ти се налага да ги ползваш без нея.
Времето е скъпо - ценете го, както собственото, така и това на клиентите си.