Das ist mit Abstand das beste TS quick Tutorial was ich bis jetzt gesehen habe. Kein Clickbaiting und elendiges in die Länge ziehen mit Basics. Vielen Dank, Abo ist raus :) .
Mein Auswahlkriterium für dieses Video war das Bild in der YT-Vorschau: da ist einer mit der gleichen Gewichtsklasse wie ich- der ist bestimmt nett. Und was muss ich sagen - nicht nur nett sondern auch ein hervorragender Tutor, der in erstklassiger Art und Weise das Ganze rüberbringt.
Vielen Dank. Ab 07:07 habe ich die Stop-Taste gedrückt und werde mir erst mal Deinen Beitrag "JavaScript lernen: Eine Einführung in 100 Minuten" ansehen.
Wieder Mal ein wunderbares Tutorial! Scheint mir gar nicht Mal so schwer zu sein. Ich bin gerade dabei, mein erstes kleines npm module zu erstellen. Dabei kam ich über JSDoc (was mir schon gut gefallen hat) wiederum auf den Gedanken, ob es nicht sinnvoll wäre nicht direkt Typescript zu verwenden. Das gibt nicht nur mir Vorteile, sondern auch den Personen, welche das Modul einmal verwenden möchten.
[gr] Vielen lieben Dank - und es freut mich, dass Du (wieder) einen Schritt weiter gekommen bist 😊 Und das mit TypeScript, dass das nicht nur Dir, sondern auch den Verwender:innen nützt, finde ich eine schöne Überlegung 😊
Hallo Golo. Vielen Dank für diese Einführung in TypeScript. Du hast mir grade einen Zahn gezogen. Ich war einer von denen die dachten mal lieber TypeScript anstelle von Javascript lernen zu wollen. Ich vertraue auf Deine Einschätzung da ich schon viele Deiner Videos gesehen und meistens sehr viel daraus gelernt habe. Somit geht's jetzt los oder besser gesagt weiter mit Javascript. War übrigens ein dringender Rat auch von anderen das zu tun. War wie immer sehr interessant und gut präsentiert. Hab ne gute Zeit und bis sicher bald. Gruss aus der Schweiz.
Super Zusammenfassung! Ich würde die Todos als Kopie zurückgeben, damit man die Werte in der "echten Liste" nicht von außen ändern kann. Falls man da noch Observable-Funktionalität einbauen möchte, könnte man dieses sonst über getAll... umgehen.
[gr] Ja, das ist ein guter Punkt - wobei ich den Aufwand, ein Deep-Clone zu machen, nicht immer haben wollte, sondern nur in bestimmten Fällen … aber prinzipiell ja 😉
sehr sehr geil abgesehen von dem sprung bei 7 min wo plötzlich das projekt mit passenden dateien offen ist oder nicht einmal der cmd zur installation genannt wurde
[gr] Danke für das Lob 😊 Was den "Sprung" angeht - bei 8:21 erkläre ich die Dateien ja, bis dahin ist auch nichts installiert worden, und die Installation erfolgt über "npm install typescript", den nenne ich aber auch explizit (bei 9:07).
Super Video. "unknown" war mir bisher nicht so geläufig, werde ich definitiv nun regelmäßig anstelle von "any" verwenden! Bezüglich euer Exports: Wieso schreibt ihr die Exports denn gesondert ans Dateiende anstelle das jeweilige Interface etc. an der Stelle der Deklaration zu exportieren? Damit es immer an der gleichen Stelle ist, etwa falls "private" Hilfsfunktionen in der gleichen Datei enthalten sind aber nicht exportiert werden sollen? Nutzen viel Kotlin, da wird analog zu Java die Visibility bei der Deklaration festgelegt (public, internal, private). Hilfsfunktionen wären demnach "private" und die eigentliche top-level Funktion wäre "public / internal". Beispiel in TS: function foo() { return 2 } export function bar() { return foo() + 3 } Beispiel in Kotlin: private fun foo() = 2 public fun bar() = foo() + 3 Ihr hättet dann vermutlich: function foo() { return 2 } function bar() { return foo() + 3 } export { bar }; Mich würde nur der Beweggrund interessieren. Bisher nutzen wir in unserem TS-Projekten die Syntax im 1. Beispiel. In unseren Kotlin-Projekten entsprechend die Syntax im 2. Beispiel.
[gr] Danke für das Feedback 😊 Was die Exports angeht, hat das vor allem den Sinn, dass es übersichtlicher ist, wenn am Dateiende nur ein einziges Export steht, und die nicht wild verstreut in der Datei sind, mal hier, mal dort. Und, dass es eben dateiübergreifend konsistent ist. Das ist eigentlich schon alles 😊
Ich benutze gerade in einem neuen Projekt Typescript, obwohl ich vorher sehr, sehr wenig Javascript programmiert habe und finde das eigentlich gar nicht so übel. Man muss dazu sagen, dass ich vorher recht viel in Kotlin gemacht habe und dort insbesondere die funktionalen Elemente sehr geschätzt habe und ich großen Wert darauf gelegt habe, ein statisches Typsystem zur Compilezeit zur haben, weil das einfach unglaublich viele dumme Fehler eliminieren kann. Ich finde das jedenfalls ganz angenehm, allerdings würde ich gerne mittelfristig die Variante "Kotlin nach JS kompilieren" versuchen. Könntet ihr dazu eventuell auch mal ein Video machen? Das finde ich unglaublich interessant, da ja Kotlin sich mit dem Multiplatform-Builds auch explizit das Ziel gesetzt hat, Backend und Frontend in einer Sprache zu entwickeln und gerade Gradle und sein sehr mächtiges Ökosystem den Build-und Deploymentprozess extrem angenehm macht. Das wäre auf jeden Fall total cool :)
[gr] Vielen Dank für Deinen Kommentar und Dein Feedback 😊 Prinzipiell gehen wir immer sehr gerne auf Wünsche ein, ich will aber auch keine falschen Versprechungen machen: Es ist leider eher unwahrscheinlich, dass so ein Video zu Stande kommt, einfach deshalb, weil wir überhaupt nichts mit Kotlin (und auch nicht dem Java-Ökosystem) zu tun haben, und wir daher nicht wirklich etwas fundiertes dazu sagen können. Tut mir leid 😕
Es gibt Compose for Web von Jetbrains/Kotlin. Ein Freund hat das schon produktiv im Einsatz. Ich persönlich finde Kotlin immer noch schöner (Syntax und SDK).
Sehr cooles Video. Mir persönlich haben die Fallbeispiele gefallen wo etwas seinen Einsatz finden könnte. Interessant wäre es, wenn man noch das ganze ausgeführt hätte. Würde man da die build/app.js, wie üblich ausführen?Wie würde der automatisierte Workflow aussehen um nicht erst "npx tsc" auszuführen und dann bspw. node "./build/app.js". Mir fällt nur die Anpassung in der package.json ein, worin man im script-block sowas wie "start": "npx tsx | node ./build/app.js" zustehen hat. Vielen Dank (:
[gr] Das freut mich sehr, vielen Dank 😊 Um nicht immer von Hand "npx tsc" ausführen zu müssen - guck Dir mal "ts-node" an: www.npmjs.com/package/ts-node Ich denke, das ist, was Du (für die Entwicklung) haben willst 😊
[NG/FR] Servus👋🏻. Vielen Dank für den lieben Kommentar, nein um Softwareentwickler zu werden, musst du nicht unbedingt studieren. Es kommt immer ein bisschen darauf an, in welchen Bereich du möchtest. Schaue dir doch mal die Ausbildungsberufe an z.B: FachInformatiker (FIAE). PS: wenn du dich mit uns und unserer Community austauschen möchtest für weitere solcher Fragen komm doch auf unseren Discord: discord.gg/ZQbSDQyJ2m
Ich hätte gerne ein Video zu Fehlerbehandlung allgemein. Den "Happy Path" krieg ich nämlich geschrieben, beim abweichen davon bin ich mir nie so ganz sicher wieviel davon wo abfangen. Und ich hab eine geringe Frustrationstoleranz. Deswegen wüsste ich gerne, wie man das möglichst effizient macht, ohne graue Haare darüber zu bekommen.
Danke für Deinen Kommentar 😊 Allerdings habe ich die Frage noch nicht ganz verstanden, das Thema klingt aber nach einem spannenden für ein Video - magst Du mir dazu eventuell mal eine E-Mail an golo [dot] roden [at] thenativeweb [dot] io schreiben?
Bei verschwindet leider die Fehlermeldung bei 'uuid' nicht. Selbst wenn ich @types/uuid installiere bleibt die Meldund "Cannot find module 'uuid' or its corresponding type declarations.ts(2307)". Auf der Homepage zum Projekt definitleytyped wird übrigens auch nichts mehr angezeigt. Kann das evtl. zusammenhängen?
Wenn die Kompatibilität über die strukturelle Gleichheit von Daten entschieden wird, wo wird hier die Möglichkeit unterschiedlicher Prototypen betrachtet? Geht es dabei nur um own properties von Objekten?
[gr] Das ist tatsächlich eine gute Frage, wo die Grenzen liegen, beziehungsweise was alles berücksichtigt wird - da wir kaum mit Vererbung arbeiten, hatten wir das Problem (glaube ich) noch nie. Wäre aber mal spannend, sich damit zu beschäftigen …
[gr] ts-node kompiliert während der Laufzeit, und das auch nur rein in-memory. Das erspart Dir beim Entwickeln daher immer das explizite Aufrufen von tsc, ist aber etwas langsamer als wenn es vorkompiliert wäre. tsc ist der klassische Compiler, der zunächst kompiliert, das Ergebnis auf Disk schreibt, und das führst Du dann mit Node aus.
@@thenativeweb Danke für die Antwort. Macht es für mich als Entwickler denn einen Unterschied, ob ich tsc & node oder ts-node als start script deklariere? In beiden Fällen muss ich doch immer nur "npm start" aufrufen. Bei ts-node hätte ich dann halt den build folder nicht, da der javascript code nur im Arbeitsspeicher existiert, aber sonst? Gibt es bei sehr großen Projekt vielleicht nen merkbaren Unterschied in der Startzeit?
Warum keine Accessor Properties anstelle der getter-Funktionen? Im Gegensatz zu z.B. Java kennt Javascript ja echte getter und setter, die in Java ja nur als Konvention existieren. Ist es zudem eine gute Idee in getAllTodos tatsächlich eine Referenz auf die private Todo-Liste zurückzugeben?
[gr] Ja, hätte man auch mit einem Accessor machen können - ich nutze die tatsächlich fast gar nicht, auch wenn ich Dir nicht sagen kann, warum. Wäre aber tatsächlich eine Option gewesen. Und was das Zurückgeben der Referenz angeht: Kommt darauf an - in dem Fall hätte man sicherlich auch eine Kopie erstellen können. Wenn die Liste aber sehr, sehr groß ist, wird das eventuell ineffizient, und man will dann stattdessen tatsächlich eher eine Referenz zurückgeben. Das muss IMHO von Fall zu Fall entschieden werden. In dem Fall fand ich es nicht wichtig, weil das Ziel des Videos ja nicht ist, Design-Entscheidungen zu erklären, sondern erst mal die Sprache TypeScript an sich.
[gr] Ah 😊. „Vanilla“ bedeutet so viel wie die „Standardvariante“, ohne großartige Extras. So wie beispielsweise Vanilleeis eben auch das „gängige“ eis ist, wo man davon ausgehen kann, dass das den meisten schmeckt, mit dem man nichts falsch macht, was aber häufig eben auch nicht besonders spektakulär ist.
Hey, ich bin ein bisschen verwirrt, du meinstest, JavaScript-Funktionen müssen immer einen Rückgabewert besitzen. Ist das wirklich so? MFG Btw richtg gutes Video ;-)
Schon lustig zu sehen wie Programmiersprachen sich verändern. JS(TS) und PHP rüsten OOP Features nach. Das strukturelle Typsystem haut mich nicht vom Hocker. Wenn ich in Java (oder ner anderen OOP Sprache) zwei Klassen habe die genau die selben Attribute haben würde ich das als Entwickler-Fehler ansehen und nicht als Feature.
[gr] Es geht darum, dass Du mit einem strukturellen Typsystem zum Beispiel viel einfacher etwas mocken kannst, weil Du kein Interface oder eine gemeinsame Basisklasse oder ähnliches brauchst. Es genügt, wenn es von der Form her "passt".
Als Java Entwickler der seit nem Jahr Typescript macht kann ich dir sagen, dass einen das Typensystem wirklich vom Hocker haut, wenn ein Experte neben dir sitzt und dir ein paar Advanced Features erklärt. Das sind Sachen, die kriegst du in Java so gar nicht abgebildet bzw. du müsstest mit vielen Runtime Checks arbeiten, wo Typescript dir schon sehr früh sagen würde „ne Junge den Wert kannst du der Variable gar nicht zuweisen“. Oder dass Typen sich in if-Blöcken ändern können, wenn du in der Bedingung einen Typen ausschließt. Man geht echt ganz anders an die Programmierung ran, wenn man solche Mittel hat.
Das Tutorial hat mir sehr gut gefallen. Leider bekomme ich beim kompilieren diesen Fehler: 37 const todo = this.todos.find(todo => todo.id === id); ~~~~ ToDoList.ts:48:33 - error TS2550: Property 'find' does not exist on type 'ToDo[]'. Do you need to change your target library? Try changing the 'lib' compiler option to 'es2015' or later. Hat jemand eine Idee warum?
[gr] Im Prinzip gibt Dir der Fehler schon einen Hinweis, wie Du das Problem lösen kannst / musst. In der tsconfig.json gibt es in der Sektion compilerOptions das Setting lib, und das musst Du auf es2015 oder eben eine neuere Version stellen. Das heißt, entweder steht dort ein Wert wie es5 oder gar es3 drin, oder der Wert ist gar nicht gesetzt, oder Du hast keine tsconfig.json in Deinem Projekt. Für Details dazu siehe www.typescriptlang.org/tsconfig#lib
Das ist mit Abstand das beste TS quick Tutorial was ich bis jetzt gesehen habe. Kein Clickbaiting und elendiges in die Länge ziehen mit Basics. Vielen Dank, Abo ist raus :) .
[gr] Vielen herzlichen Dank für das tolle Feedback 😊
Deep Dive Videos sind eine super Idee, gerne mehr davon. Vielen Dank Golo.
[gr] Gerne - und vielen Dank für das tolle Feedback! 😊
Danke Golo, deine Art und Weise des Erklärens hilft mir sehr in den Entsprechenden Themengebieten voran zu kommen.
[gr] Danke schön, das freut mich 😊
Danke Golo, du hast es wirklich super gemacht!
[gr] Vielen Dank 😊
Wie auf Knopfdruck, genau DAS brauche ich gerade für mein Praktikum. Vielen Dank! :))
[gr] Perfekt 😊
Viel Spaß und Erfolg im Praktikum 😊
Super gutes Tutorial! Am Anfang Zielgruppe definiert und dann in zielgruppengerechter pace (nicht zu lahm, nicht zu schnell) das Wichtigste erklärt.
[gr] Das freut mich, vielen Dank 😊
Danke! Sehr hilfreiche Lehrvideos!
[gr] Vielen, vielen Dank 🥰
Mein Auswahlkriterium für dieses Video war das Bild in der YT-Vorschau: da ist einer mit der gleichen Gewichtsklasse wie ich- der ist bestimmt nett. Und was muss ich sagen - nicht nur nett sondern auch ein hervorragender Tutor, der in erstklassiger Art und Weise das Ganze rüberbringt.
[gr] Vielen lieben Dank - freut mich 😊
Vielen Dank. Ab 07:07 habe ich die Stop-Taste gedrückt und werde mir erst mal Deinen Beitrag "JavaScript lernen: Eine Einführung in 100 Minuten" ansehen.
[gr] Viel Erfolg 😊
Danke für dieses gut verständliche und kurze Tutorial
[gr] Gerne 😊
Hammer! Einfach nur gut. Könnte man nicht besser machen. Strukturierte, geballte Zusammenfassung. Danke dafür!
[gr] Vielen, vielen Dank 😊
Vielen Dank für dieses ausführliche Thema zu meiner Lieblingsprogrammiersprache ❤️ Wird geteilt.
[gr] Gern geschehen - und vielen Dank 😊
Wieder Mal ein wunderbares Tutorial!
Scheint mir gar nicht Mal so schwer zu sein.
Ich bin gerade dabei, mein erstes kleines npm module zu erstellen. Dabei kam ich über JSDoc (was mir schon gut gefallen hat) wiederum auf den Gedanken, ob es nicht sinnvoll wäre nicht direkt Typescript zu verwenden.
Das gibt nicht nur mir Vorteile, sondern auch den Personen, welche das Modul einmal verwenden möchten.
[gr] Vielen lieben Dank - und es freut mich, dass Du (wieder) einen Schritt weiter gekommen bist 😊
Und das mit TypeScript, dass das nicht nur Dir, sondern auch den Verwender:innen nützt, finde ich eine schöne Überlegung 😊
@@thenativeweb vielen Dank!😊
Dein Kanal müsste viel mehr Abos haben! Deine Tutorials sind spitze und so angenehm zu verfolgen. Danke dafür! Abo ist raus 👍
[gr] Vielen, vielen Dank 😊
Danke für das hilfreiche und gut zusammengefasste Video!
[gr] Danke schön 😊
Sehr hilfreich und anschaulich! Danke Golo!
[gr] Gerne 😊
Hallo Golo. Vielen Dank für diese Einführung in TypeScript. Du hast mir grade einen Zahn gezogen. Ich war einer von denen die dachten mal lieber TypeScript anstelle von Javascript lernen zu wollen. Ich vertraue auf Deine Einschätzung da ich schon viele Deiner Videos gesehen und meistens sehr viel daraus gelernt habe. Somit geht's jetzt los oder besser gesagt weiter mit Javascript. War übrigens ein dringender Rat auch von anderen das zu tun. War wie immer sehr interessant und gut präsentiert. Hab ne gute Zeit und bis sicher bald. Gruss aus der Schweiz.
[gr] Freut mich, vielen Dank 😊
Alles dabei für den Einstieg in TS, super Video!
[gr] Danke schön 😊
Danke für die sehr gute Einführung in TS. Habe noch viel gelernt und direkt ein Abo dagelassen.
[gr] Vielen Dank, das freut mich sehr 😊
Super. Tolle Erklärungen. Hilfreich auch bei c#.
Toll auch dein tempo.
Vielen Dank für das Video! Sehr angenehm erklärt.
[gr] Das freut mich, vielen Dank 😊
Sehr gute Einführung, gerne mehr davon
[gr] Vielen Dank 😊
Gute Einführung
[gr] Vielen Dank 😊
Super Video, vielen Dank dafür!
[gr] Gern geschehen, freut mich 😊
Immer wieder nice die Videos. Super erklärt. Habe aktuell mit Angular zutun und da helfen unterschiedliche Perspektiven :)
[gr] Das freut mich, vielen Dank 😊
sensationel erklärt! danke!
[gr] Vielen, vielen Dank, das freut mich sehr 😊
bin gerade dabei meine restapi auf ts umzustellen und das weiterleiten deines videos erspart jede menge erklärbär arbeit für mich 😉
@@mattiashorvath9865 [gr] Schön - das freut mich 😊
Sehr gute Einführung! Danke dafür :)
[gr] Gerne 😊
Danke für das gute Video😁.
direkt für die Ausbildung im Sept. vorbereiten da die Firma Angular nutzt.
[gr] Vielen lieben Dank 😊
Super Tutorial. Danke hierfür!
Starkes Video
[gr] Vielen Dank 😊
Vielen Dank, sehr gut erklärt
gerne mehr davon !
[gr] Vielen Dank 😊
Bravo, danke!
Danke, Große Hilfe
Sehr schön 👌
[gr] Danke ☺️
Super Zusammenfassung! Ich würde die Todos als Kopie zurückgeben, damit man die Werte in der "echten Liste" nicht von außen ändern kann. Falls man da noch Observable-Funktionalität einbauen möchte, könnte man dieses sonst über getAll... umgehen.
[gr] Ja, das ist ein guter Punkt - wobei ich den Aufwand, ein Deep-Clone zu machen, nicht immer haben wollte, sondern nur in bestimmten Fällen … aber prinzipiell ja 😉
sehr sehr geil abgesehen von dem sprung bei 7 min wo plötzlich das projekt mit passenden dateien offen ist oder nicht einmal der cmd zur installation genannt wurde
[gr] Danke für das Lob 😊
Was den "Sprung" angeht - bei 8:21 erkläre ich die Dateien ja, bis dahin ist auch nichts installiert worden, und die Installation erfolgt über "npm install typescript", den nenne ich aber auch explizit (bei 9:07).
@@thenativeweb mich haben auch die bereits vorhandenen dateien irritiert.
Super Video. "unknown" war mir bisher nicht so geläufig, werde ich definitiv nun regelmäßig anstelle von "any" verwenden!
Bezüglich euer Exports: Wieso schreibt ihr die Exports denn gesondert ans Dateiende anstelle das jeweilige Interface etc. an der Stelle der Deklaration zu exportieren? Damit es immer an der gleichen Stelle ist, etwa falls "private" Hilfsfunktionen in der gleichen Datei enthalten sind aber nicht exportiert werden sollen? Nutzen viel Kotlin, da wird analog zu Java die Visibility bei der Deklaration festgelegt (public, internal, private). Hilfsfunktionen wären demnach "private" und die eigentliche top-level Funktion wäre "public / internal".
Beispiel in TS:
function foo() { return 2 }
export function bar() { return foo() + 3 }
Beispiel in Kotlin:
private fun foo() = 2
public fun bar() = foo() + 3
Ihr hättet dann vermutlich:
function foo() { return 2 }
function bar() { return foo() + 3 }
export { bar };
Mich würde nur der Beweggrund interessieren. Bisher nutzen wir in unserem TS-Projekten die Syntax im 1. Beispiel. In unseren Kotlin-Projekten entsprechend die Syntax im 2. Beispiel.
[gr] Danke für das Feedback 😊
Was die Exports angeht, hat das vor allem den Sinn, dass es übersichtlicher ist, wenn am Dateiende nur ein einziges Export steht, und die nicht wild verstreut in der Datei sind, mal hier, mal dort. Und, dass es eben dateiübergreifend konsistent ist.
Das ist eigentlich schon alles 😊
Ich benutze gerade in einem neuen Projekt Typescript, obwohl ich vorher sehr, sehr wenig Javascript programmiert habe und finde das eigentlich gar nicht so übel. Man muss dazu sagen, dass ich vorher recht viel in Kotlin gemacht habe und dort insbesondere die funktionalen Elemente sehr geschätzt habe und ich großen Wert darauf gelegt habe, ein statisches Typsystem zur Compilezeit zur haben, weil das einfach unglaublich viele dumme Fehler eliminieren kann. Ich finde das jedenfalls ganz angenehm, allerdings würde ich gerne mittelfristig die Variante "Kotlin nach JS kompilieren" versuchen. Könntet ihr dazu eventuell auch mal ein Video machen? Das finde ich unglaublich interessant, da ja Kotlin sich mit dem Multiplatform-Builds auch explizit das Ziel gesetzt hat, Backend und Frontend in einer Sprache zu entwickeln und gerade Gradle und sein sehr mächtiges Ökosystem den Build-und Deploymentprozess extrem angenehm macht. Das wäre auf jeden Fall total cool :)
[gr] Vielen Dank für Deinen Kommentar und Dein Feedback 😊
Prinzipiell gehen wir immer sehr gerne auf Wünsche ein, ich will aber auch keine falschen Versprechungen machen: Es ist leider eher unwahrscheinlich, dass so ein Video zu Stande kommt, einfach deshalb, weil wir überhaupt nichts mit Kotlin (und auch nicht dem Java-Ökosystem) zu tun haben, und wir daher nicht wirklich etwas fundiertes dazu sagen können.
Tut mir leid 😕
Es gibt Compose for Web von Jetbrains/Kotlin. Ein Freund hat das schon produktiv im Einsatz. Ich persönlich finde Kotlin immer noch schöner (Syntax und SDK).
@@Massenhaft1 vielen Dank für den Tipp! Das muss ich mir ganz dringend mal anschauen!
Jetbrains hat Kurse für alles, die sind wirklich sehr gut und gratis.
.. naja, dann wird's wohl ne Ente sein ... das wär auch n schöner T-Shirt Spruch 😅
[gr] Auf jeden Fall 🦆
Außer die Ente fühlt sich heute als Wolf 😂
Sehr cooles Video. Mir persönlich haben die Fallbeispiele gefallen wo etwas seinen Einsatz finden könnte.
Interessant wäre es, wenn man noch das ganze ausgeführt hätte. Würde man da die build/app.js, wie üblich ausführen?Wie würde der automatisierte Workflow aussehen um nicht erst "npx tsc" auszuführen und dann bspw. node "./build/app.js". Mir fällt nur die Anpassung in der package.json ein, worin man im script-block sowas wie "start": "npx tsx | node ./build/app.js" zustehen hat.
Vielen Dank (:
[gr] Das freut mich sehr, vielen Dank 😊
Um nicht immer von Hand "npx tsc" ausführen zu müssen - guck Dir mal "ts-node" an: www.npmjs.com/package/ts-node
Ich denke, das ist, was Du (für die Entwicklung) haben willst 😊
Hi, perfektes Video für mich. Ich möchte Softwareentwickler werden muss ich dafür studieren?
[NG/FR] Servus👋🏻. Vielen Dank für den lieben Kommentar, nein um Softwareentwickler zu werden, musst du nicht unbedingt studieren. Es kommt immer ein bisschen darauf an, in welchen Bereich du möchtest. Schaue dir doch mal die Ausbildungsberufe an z.B: FachInformatiker (FIAE). PS: wenn du dich mit uns und unserer Community austauschen möchtest für weitere solcher Fragen komm doch auf unseren Discord: discord.gg/ZQbSDQyJ2m
Ich hätte gerne ein Video zu Fehlerbehandlung allgemein. Den "Happy Path" krieg ich nämlich geschrieben, beim abweichen davon bin ich mir nie so ganz sicher wieviel davon wo abfangen. Und ich hab eine geringe Frustrationstoleranz. Deswegen wüsste ich gerne, wie man das möglichst effizient macht, ohne graue Haare darüber zu bekommen.
Danke für Deinen Kommentar 😊
Allerdings habe ich die Frage noch nicht ganz verstanden, das Thema klingt aber nach einem spannenden für ein Video - magst Du mir dazu eventuell mal eine E-Mail an golo [dot] roden [at] thenativeweb [dot] io schreiben?
@@thenativeweb Hab dir eine Mail gesendet.
Mit einem enum hat den Vorteil magic strings zu vermeiden, oder?
Bei verschwindet leider die Fehlermeldung bei 'uuid' nicht. Selbst wenn ich @types/uuid installiere bleibt die Meldund "Cannot find module 'uuid' or its corresponding type declarations.ts(2307)". Auf der Homepage zum Projekt definitleytyped wird übrigens auch nichts mehr angezeigt. Kann das evtl. zusammenhängen?
Wie wäre es denn mal mit einem Video über die Typescript Utility Types?
[gr] Das ist eine schöne Idee, vielen Dank dafür - die habe ich auf unsere Liste aufgenommen 😊
Wenn die Kompatibilität über die strukturelle Gleichheit von Daten entschieden wird, wo wird hier die Möglichkeit unterschiedlicher Prototypen betrachtet? Geht es dabei nur um own properties von Objekten?
[gr] Das ist tatsächlich eine gute Frage, wo die Grenzen liegen, beziehungsweise was alles berücksichtigt wird - da wir kaum mit Vererbung arbeiten, hatten wir das Problem (glaube ich) noch nie. Wäre aber mal spannend, sich damit zu beschäftigen …
Was ist denn der Unterschied zwischen ts-node und dem package.json script tsc & node?
[gr] ts-node kompiliert während der Laufzeit, und das auch nur rein in-memory. Das erspart Dir beim Entwickeln daher immer das explizite Aufrufen von tsc, ist aber etwas langsamer als wenn es vorkompiliert wäre.
tsc ist der klassische Compiler, der zunächst kompiliert, das Ergebnis auf Disk schreibt, und das führst Du dann mit Node aus.
@@thenativeweb
Danke für die Antwort.
Macht es für mich als Entwickler denn einen Unterschied, ob ich tsc & node oder ts-node als start script deklariere?
In beiden Fällen muss ich doch immer nur "npm start" aufrufen. Bei ts-node hätte ich dann halt den build folder nicht, da der javascript code nur im Arbeitsspeicher existiert, aber sonst? Gibt es bei sehr großen Projekt vielleicht nen merkbaren Unterschied in der Startzeit?
Warum keine Accessor Properties anstelle der getter-Funktionen? Im Gegensatz zu z.B. Java kennt Javascript ja echte getter und setter, die in Java ja nur als Konvention existieren. Ist es zudem eine gute Idee in getAllTodos tatsächlich eine Referenz auf die private Todo-Liste zurückzugeben?
[gr] Ja, hätte man auch mit einem Accessor machen können - ich nutze die tatsächlich fast gar nicht, auch wenn ich Dir nicht sagen kann, warum. Wäre aber tatsächlich eine Option gewesen.
Und was das Zurückgeben der Referenz angeht: Kommt darauf an - in dem Fall hätte man sicherlich auch eine Kopie erstellen können. Wenn die Liste aber sehr, sehr groß ist, wird das eventuell ineffizient, und man will dann stattdessen tatsächlich eher eine Referenz zurückgeben. Das muss IMHO von Fall zu Fall entschieden werden. In dem Fall fand ich es nicht wichtig, weil das Ziel des Videos ja nicht ist, Design-Entscheidungen zu erklären, sondern erst mal die Sprache TypeScript an sich.
ist vanilla ein synonym für O.G? kenn das nur von WoW Vanilla xD
[gr] Was bedeutet O.G?
@@thenativeweb original, ursprünglich, Bsp. Wow classic ist das o.g spiel
[gr] Ah 😊. „Vanilla“ bedeutet so viel wie die „Standardvariante“, ohne großartige Extras. So wie beispielsweise Vanilleeis eben auch das „gängige“ eis ist, wo man davon ausgehen kann, dass das den meisten schmeckt, mit dem man nichts falsch macht, was aber häufig eben auch nicht besonders spektakulär ist.
Hey, ich bin ein bisschen verwirrt, du meinstest, JavaScript-Funktionen müssen immer einen Rückgabewert besitzen. Ist das wirklich so? MFG Btw richtg gutes Video ;-)
Stay hung, guys ;-)
[gr] Und nicht zu vergessen: Stay fooli 😉
Schon lustig zu sehen wie Programmiersprachen sich verändern. JS(TS) und PHP rüsten OOP Features nach. Das strukturelle Typsystem haut mich nicht vom Hocker. Wenn ich in Java (oder ner anderen OOP Sprache) zwei Klassen habe die genau die selben Attribute haben würde ich das als Entwickler-Fehler ansehen und nicht als Feature.
[gr] Es geht darum, dass Du mit einem strukturellen Typsystem zum Beispiel viel einfacher etwas mocken kannst, weil Du kein Interface oder eine gemeinsame Basisklasse oder ähnliches brauchst. Es genügt, wenn es von der Form her "passt".
Als Java Entwickler der seit nem Jahr Typescript macht kann ich dir sagen, dass einen das Typensystem wirklich vom Hocker haut, wenn ein Experte neben dir sitzt und dir ein paar Advanced Features erklärt. Das sind Sachen, die kriegst du in Java so gar nicht abgebildet bzw. du müsstest mit vielen Runtime Checks arbeiten, wo Typescript dir schon sehr früh sagen würde „ne Junge den Wert kannst du der Variable gar nicht zuweisen“. Oder dass Typen sich in if-Blöcken ändern können, wenn du in der Bedingung einen Typen ausschließt. Man geht echt ganz anders an die Programmierung ran, wenn man solche Mittel hat.
Das Tutorial hat mir sehr gut gefallen.
Leider bekomme ich beim kompilieren diesen Fehler:
37 const todo = this.todos.find(todo => todo.id === id);
~~~~
ToDoList.ts:48:33 - error TS2550: Property 'find' does not exist on type 'ToDo[]'. Do you need to change your target library? Try changing the 'lib' compiler option to 'es2015' or later.
Hat jemand eine Idee warum?
[gr] Im Prinzip gibt Dir der Fehler schon einen Hinweis, wie Du das Problem lösen kannst / musst. In der tsconfig.json gibt es in der Sektion compilerOptions das Setting lib, und das musst Du auf es2015 oder eben eine neuere Version stellen. Das heißt, entweder steht dort ein Wert wie es5 oder gar es3 drin, oder der Wert ist gar nicht gesetzt, oder Du hast keine tsconfig.json in Deinem Projekt.
Für Details dazu siehe www.typescriptlang.org/tsconfig#lib
@@thenativeweb Hallo Golo, hat geklappt. :) Danke.
[gr] Gerne 😊