semantic-typescript 0.7.0 → 0.8.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/asynchronous/semantic.d.ts +4 -0
- package/dist/asynchronous/semantic.js +3 -0
- package/dist/factory.d.ts +24 -71
- package/dist/factory.js +161 -648
- package/dist/guard.d.ts +0 -3
- package/dist/guard.js +0 -19
- package/dist/hash.js +3 -0
- package/dist/synchronous/semantic.d.ts +4 -0
- package/dist/synchronous/semantic.js +26 -7
- package/package.json +2 -2
- package/readme.cn.md +185 -131
- package/readme.de.md +186 -132
- package/readme.es.md +186 -132
- package/readme.fr.md +188 -134
- package/readme.jp.md +185 -140
- package/readme.kr.md +184 -139
- package/readme.md +187 -130
- package/readme.ru.md +186 -143
- package/readme.tw.md +190 -146
- package/dist/main.d.ts +0 -1
- package/dist/main.js +0 -6
package/readme.de.md
CHANGED
|
@@ -1,32 +1,34 @@
|
|
|
1
|
-
# **Semantic
|
|
2
|
-
**
|
|
1
|
+
# **Semantic‑TypeScript**
|
|
2
|
+
**Ströme, indiziert.** Ihre Daten unter präziser Kontrolle.
|
|
3
3
|
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
###
|
|
6
|
+
### Überblick
|
|
7
7
|
|
|
8
|
-
Semantic
|
|
8
|
+
Semantic‑TypeScript stellt eine bedeutende Weiterentwicklung in der Stream‑Verarbeitung dar und vereint elegant die effektivsten Paradigmen aus JavaScript‑Generatoren, Java‑Streams und MySQL‑artiger Indizierung. Die Grundidee ist sowohl leistungsfähig als auch bewusst gewählt: Ausnahmslos effiziente Datenverarbeitungspipelines durch intelligente Indizierung zu konstruieren, anstatt durch konventionelle Brute‑Force‑Iteration.
|
|
9
9
|
|
|
10
|
-
|
|
10
|
+
Wo typische Bibliotheken synchrone Schleifen oder umständliche Promise‑Ketten erzwingen, bietet Semantic‑TypeScript eine **vollständig asynchrone**, funktional reine und rigoros typsichere Erfahrung, die ausdrücklich für die Anforderungen moderner Anwendungsentwicklung konzipiert ist.
|
|
11
11
|
|
|
12
|
-
|
|
12
|
+
Dieses Modell verkörpert eine raffinierte Form des Kontrollflusses: Daten werden nur dann an den nachgelagerten Verbraucher weitergegeben, wenn die vorgelagerte Pipeline explizit den `accept`‑Callback aufruft. Sie behalten die vollständige, granulare Kontrolle über den Zeitpunkt – die Verarbeitung erfolgt genau dann und nur dann, wenn es erforderlich ist.
|
|
13
13
|
|
|
14
14
|
---
|
|
15
15
|
|
|
16
|
-
### Warum Entwickler
|
|
16
|
+
### Warum Entwickler Semantic‑TypeScript wählen
|
|
17
17
|
|
|
18
|
-
- **Zero
|
|
19
|
-
- **Rein
|
|
20
|
-
- **
|
|
21
|
-
- **Integrierte Statistik** –
|
|
22
|
-
- **Vorhersehbare
|
|
23
|
-
- **
|
|
24
|
-
- **Kein undefiniertes Verhalten** – TypeScript garantiert Typsicherheit und
|
|
18
|
+
- **Zero‑Boilerplate‑Indizierung** – Jedes Element besitzt inhärent seinen natürlichen oder maßgeschneiderten Index, wodurch manuelle Nachverfolgung entfällt.
|
|
19
|
+
- **Rein funktional & typsicher** – Genießen Sie vollständige, idiomatische TypeScript‑Inferenz zusammen mit unveränderlichen Operationen.
|
|
20
|
+
- **Leck‑sichere Ereignisströme** – Das `useSubscription`‑Muster wurde mit Ressourcensicherheit als erstem Prinzip entworfen. Sie definieren die logische Grenze – mittels `limit(n)`, `sub(start, end)` oder `takeWhile(predicate)` – und die Bibliothek verwaltet den vollständigen Abonnement‑Lebenszyklus. Dies stellt sicher, dass keine verbleibenden Listener und keine Speicherlecks entstehen.
|
|
21
|
+
- **Integrierte Statistik‑Suite** – Greifen Sie ohne externe Abhängigkeiten auf umfassende Analysen für sowohl `number`‑ als auch `bigint`‑Ströme zu, einschließlich Mittelwert, Median, Modus, Varianz, Schiefe und Kurtosis.
|
|
22
|
+
- **Vorhersehbare, fein abstimmbare Leistung** – Wählen Sie zwischen geordneten oder ungeordneten Sammlern, um Ihren genauen Leistungs‑ und Reihenfolgeanforderungen gerecht zu werden.
|
|
23
|
+
- **Inherent speichereffizient** – Ströme werden lazy evaluiert, verarbeiten Elemente bei Bedarf und entlasten so den Speicher.
|
|
24
|
+
- **Kein undefiniertes Verhalten** – TypeScript garantiert vollständige Typsicherheit und Nullsicherheit. Ihre Quelldaten bleiben unveränderlich, es sei denn, sie werden explizit in Ihren Callback‑Funktionen geändert.
|
|
25
25
|
|
|
26
26
|
---
|
|
27
27
|
|
|
28
28
|
### Installation
|
|
29
29
|
|
|
30
|
+
Integrieren Sie Semantic‑TypeScript mit Ihrem bevorzugten Paketmanager in Ihr Projekt:
|
|
31
|
+
|
|
30
32
|
```bash
|
|
31
33
|
npm install semantic-typescript
|
|
32
34
|
```
|
|
@@ -37,177 +39,229 @@ yarn add semantic-typescript
|
|
|
37
39
|
|
|
38
40
|
---
|
|
39
41
|
|
|
40
|
-
###
|
|
42
|
+
### Praktische Einführung
|
|
43
|
+
|
|
44
|
+
Die folgenden Beispiele demonstrieren Kernkonzepte, von grundlegenden Transformationen bis zur praktischen Ereignisbehandlung.
|
|
41
45
|
|
|
42
46
|
```typescript
|
|
43
|
-
import { useOf, useFrom, useRange,
|
|
44
|
-
|
|
45
|
-
//
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
//
|
|
52
|
-
|
|
53
|
-
.
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
.
|
|
47
|
+
import { useOf, useFrom, useRange, useSubscription, useText, useStringify } from "semantic-typescript";
|
|
48
|
+
|
|
49
|
+
// ====================================================================
|
|
50
|
+
// BEISPIEL 1: Grundlegende Operationen & numerische Statistik
|
|
51
|
+
// ====================================================================
|
|
52
|
+
// Demonstriert Mapping und terminale Statistikoperationen. Nach der Transformation muss die Pipeline in einen Statistik‑Collector umgewandelt werden, bevor terminale Methoden wie `.summate()` aufgerufen werden können.
|
|
53
|
+
|
|
54
|
+
const numericSum: number = useOf(10, 20, 30, 40)
|
|
55
|
+
.map((n: number): number => n * 2) // Verdoppelt jedes Element: [20, 40, 60, 80]
|
|
56
|
+
.toNumericStatistics() // In einen Statistik‑Collector umwandeln
|
|
57
|
+
.summate(); // Terminale Operation: 200
|
|
58
|
+
|
|
59
|
+
// Weitere statistische Methoden (verfügbar nach .toNumericStatistics()):
|
|
60
|
+
// .average(), .median(), .mode(), .variance(), .skewness(), .kurtosis()
|
|
61
|
+
|
|
62
|
+
// ====================================================================
|
|
63
|
+
// BEISPIEL 2: BigInt‑Statistik
|
|
64
|
+
// ====================================================================
|
|
65
|
+
// Funktioniert identisch zur numerischen Statistik, ist jedoch für BigInt‑Daten optimiert.
|
|
66
|
+
|
|
67
|
+
const bigintSum: bigint = useOf(10n, 20n, 30n, 40n)
|
|
68
|
+
.map((n: bigint): bigint => n * 2n) // BigInt‑Arithmetik
|
|
69
|
+
.toBigIntStatistics() // In BigInt‑Statistik‑Collector umwandeln
|
|
70
|
+
.summate(); // Terminale Operation: 200n
|
|
71
|
+
|
|
72
|
+
// ====================================================================
|
|
73
|
+
// BEISPIEL 3: Indexmanipulation zur Stromumkehrung
|
|
74
|
+
// ====================================================================
|
|
75
|
+
// Veranschaulicht die Neuanordnung von Elementen durch strategische Neuzuweisung ihrer Indizes mithilfe der `.redirect()`‑Methode, was benutzerdefinierte Muster wie Umkehrung ermöglicht.
|
|
76
|
+
|
|
77
|
+
const reversedArray: number[] = useFrom([1, 2, 3, 4, 5])
|
|
78
|
+
.redirect((_element: number, index: bigint): bigint => -index) // Auf negative Indizes abbilden
|
|
79
|
+
.toOrdered() // Essentiell: Sammelt Elemente sortiert nach ihren neuen Indizes
|
|
80
|
+
.toArray(); // Ergebnis: [5, 4, 3, 2, 1]
|
|
81
|
+
|
|
82
|
+
// Für einfache Umkehrung ist auch `.reverse()` verfügbar.
|
|
83
|
+
|
|
84
|
+
// ====================================================================
|
|
85
|
+
// BEISPIEL 4: Strom‑Mischen (Shuffle)
|
|
86
|
+
// ====================================================================
|
|
87
|
+
// Permutiert Elementindizes zufällig mit einem In‑Place‑Shuffle‑Algorithmus.
|
|
88
|
+
|
|
89
|
+
const shuffledArray: number[] = useFrom([1, 2, 3, 4, 5])
|
|
90
|
+
.shuffle() // Weist Indizes zufällig neu zu
|
|
91
|
+
.toOrdered() // Sortiert nach den neuen zufälligen Indizes
|
|
92
|
+
.toArray(); // Z.B.: [2, 5, 1, 4, 3] (variiert bei jeder Ausführung)
|
|
93
|
+
|
|
94
|
+
// ====================================================================
|
|
95
|
+
// BEISPIEL 5: Zirkuläre Strom‑Rotation
|
|
96
|
+
// ====================================================================
|
|
97
|
+
// Verschiebt Elemente zyklisch. Positive Werte rotieren nach rechts; negative Werte nach links.
|
|
98
|
+
|
|
99
|
+
// Rechts‑Rotation um 2 Positionen
|
|
100
|
+
const rightRotated: number[] = useFrom([1, 2, 3, 4, 5])
|
|
101
|
+
.translate(2) // Verschiebt Indizes um 2 nach rechts
|
|
66
102
|
.toOrdered()
|
|
67
|
-
.toArray();
|
|
103
|
+
.toArray(); // Ergebnis: [4, 5, 1, 2, 3]
|
|
68
104
|
|
|
69
|
-
//
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
.toArray(); // [4, 5, 1, 2, 3]
|
|
105
|
+
// ====================================================================
|
|
106
|
+
// BEISPIEL 6: Lazy Evaluation mit unendlichen Bereichen
|
|
107
|
+
// ====================================================================
|
|
108
|
+
// Verarbeitet theoretisch unendliche Ströme lazy, berechnet Elemente nur bei Bedarf.
|
|
74
109
|
|
|
75
|
-
|
|
76
|
-
.
|
|
77
|
-
.
|
|
78
|
-
.
|
|
110
|
+
const firstTenMultiples: bigint[] = useRange(0n, 1_000_000n)
|
|
111
|
+
.filter(n => n % 17n === 0n) // Behält Vielfache von 17
|
|
112
|
+
.limit(10n) // Kritisch: Stoppt nach dem 10. Treffer
|
|
113
|
+
.toUnordered() // Keine Sortierung erforderlich
|
|
114
|
+
.toArray(); // Ergebnis: [0, 17, 34, 51, 68, 85, 102, 119, 136, 153]
|
|
79
115
|
|
|
80
|
-
//
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
116
|
+
// Ohne `.limit(10n)` würde die Pipeline alle eine Million Elemente verarbeiten.
|
|
117
|
+
|
|
118
|
+
// ====================================================================
|
|
119
|
+
// BEISPIEL 7: Zusammensetzung einer komplexen Pipeline
|
|
120
|
+
// ====================================================================
|
|
121
|
+
// Demonstriert die sequentielle Komposition mehrerer Operationen.
|
|
122
|
+
|
|
123
|
+
const complexResult: number[] = useRange(1n, 100n)
|
|
124
|
+
.map(n => Number(n) * 2)
|
|
125
|
+
.filter(n => n > 50)
|
|
126
|
+
.shuffle()
|
|
127
|
+
.limit(5n)
|
|
128
|
+
.translate(2)
|
|
129
|
+
.toOrdered()
|
|
85
130
|
.toArray();
|
|
86
131
|
|
|
87
|
-
//
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
132
|
+
// ====================================================================
|
|
133
|
+
// BEISPIEL 8: Verwaltete DOM‑Ereignis‑Abonnements
|
|
134
|
+
// ====================================================================
|
|
135
|
+
// Hört auf Browser‑Ereignisse mit automatischer, lecksicherer Bereinigung.
|
|
136
|
+
// Der `.limit(n)`‑Aufruf definiert die Grenze für die automatische Listener‑Entfernung.
|
|
137
|
+
|
|
138
|
+
// Definiere einen Abonnenten für ein Window‑Ziel
|
|
139
|
+
const windowSubscriber = {
|
|
140
|
+
mount: (target: Window): void => { /* Setup‑Logik */ },
|
|
141
|
+
subscribe: (target: Window, event: keyof WindowEventMap, handler: EventListener): void => {
|
|
142
|
+
target.addEventListener(event, handler);
|
|
143
|
+
},
|
|
144
|
+
unsubscribe: (target: Window, event: keyof WindowEventMap, handler: EventListener): void => {
|
|
145
|
+
target.removeEventListener(event, handler);
|
|
146
|
+
},
|
|
147
|
+
unmount: (): void => { /* Cleanup‑Logik */ }
|
|
148
|
+
};
|
|
92
149
|
|
|
93
|
-
|
|
94
|
-
//
|
|
95
|
-
useHTMLElement("#input", "change")
|
|
96
|
-
.limit(1)
|
|
150
|
+
useSubscription(window, windowSubscriber, "resize")
|
|
151
|
+
.limit(5n) // Automatische Abmeldung nach 5 Ereignissen
|
|
97
152
|
.toUnordered()
|
|
98
|
-
.forEach((
|
|
153
|
+
.forEach((ev: Event, idx) =>
|
|
154
|
+
console.log(`Größenänderung #${idx}: ${(ev.target as Window).innerWidth}x${(ev.target as Window).innerHeight}`)
|
|
155
|
+
);
|
|
99
156
|
|
|
100
|
-
//
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
.forEach((event: Event) => submit(event));
|
|
105
|
-
|
|
106
|
-
// Auf einen WebSocket hören
|
|
107
|
-
let webSocket = new WebSocket("ws://localhost:8080");
|
|
108
|
-
webSocket.addEventListener("close", (): void => {
|
|
109
|
-
webSocket.close(); // WebSocket-Lebenszyklus manuell verwalten
|
|
110
|
-
});
|
|
111
|
-
useWebSocket(webSocket, "message")
|
|
112
|
-
.limit(1)
|
|
113
|
-
.toUnordered()
|
|
114
|
-
.forEach((message: MessageEvent) => console.log(message.data));
|
|
157
|
+
// ====================================================================
|
|
158
|
+
// BEISPIEL 9: String‑Verarbeitung nach Unicode‑Codepunkten
|
|
159
|
+
// ====================================================================
|
|
160
|
+
// Iteriert korrekt über einen String, behandelt Multi‑Byte‑Unicode‑Zeichen.
|
|
115
161
|
|
|
116
|
-
// Über einen String Code-Punkt für Code-Punkt iterieren
|
|
117
162
|
useText("My emotion now is: 😊, and semantic is 👍")
|
|
118
163
|
.toUnordered()
|
|
119
|
-
.log(); // Gibt
|
|
164
|
+
.log(); // Gibt jedes Zeichen (inkl. Emoji) in einer neuen Zeile aus.
|
|
120
165
|
|
|
121
|
-
//
|
|
122
|
-
|
|
166
|
+
// ====================================================================
|
|
167
|
+
// BEISPIEL 10: Sichere Stringifizierung zirkulärer Referenzen
|
|
168
|
+
// ====================================================================
|
|
169
|
+
// Serialisiert sicher Objekte, die zirkuläre Referenzen enthalten.
|
|
170
|
+
|
|
171
|
+
const obj = {
|
|
123
172
|
a: 1,
|
|
124
|
-
b: "text"
|
|
125
|
-
c: [o.a, o.b, o.c] // Zirkelbezug
|
|
173
|
+
b: "text"
|
|
126
174
|
};
|
|
127
|
-
|
|
128
|
-
|
|
175
|
+
(obj as any).c = [obj.a, obj.b, (obj as any).c]; // Führt zirkuläre Referenz ein
|
|
176
|
+
|
|
177
|
+
// const text: string = JSON.stringify(obj); // Wirft einen Fehler
|
|
178
|
+
const text: string = useStringify(obj); // Ergibt sicher `{a: 1, b: "text", c: []}`
|
|
129
179
|
```
|
|
130
180
|
|
|
131
181
|
---
|
|
132
182
|
|
|
133
183
|
### Kernkonzepte
|
|
134
184
|
|
|
135
|
-
| Konzept | Zweck |
|
|
185
|
+
| Konzept | Zweck | Hauptanwendungsfall |
|
|
136
186
|
| :--- | :--- | :--- |
|
|
137
|
-
| `AsynchronousSemantic` | Kern
|
|
138
|
-
| `SynchronousSemantic` | Builder für synchrone,
|
|
139
|
-
| `toUnordered()` |
|
|
140
|
-
| `toOrdered()` |
|
|
141
|
-
| `toNumericStatistics()` |
|
|
142
|
-
| `toBigIntStatistics()` |
|
|
143
|
-
| `toWindow()` |
|
|
187
|
+
| `AsynchronousSemantic` | Der Kern‑Builder für asynchrone Ströme, Ereignisse und push‑basierte lazy Pipelines. | Echtzeit‑Ereignisse, WebSockets, DOM‑Listener oder jeder langlebige/unendliche Strom. |
|
|
188
|
+
| `SynchronousSemantic` | Der Builder für synchrone, speicherinterne oder pull‑basierte eager Ströme. | Statische Daten, endliche Bereiche oder sofortige Iterationsaufgaben. |
|
|
189
|
+
| `toUnordered()` | Der schnellste terminale Collector, verwendet eine Map zur Indexspeicherung. | Leistungskritische Pfade, bei denen stabile Reihenfolge nicht erforderlich ist (O(n) Zeit & Speicher). |
|
|
190
|
+
| `toOrdered()` | Ein sortierter, indexstabiler terminaler Collector. | Wenn die Elementreihenfolge erhalten bleiben muss oder Indexzugriff benötigt wird. |
|
|
191
|
+
| `toNumericStatistics()` | Ein Collector, der umfangreiche statistische Analysen auf `number`‑Strömen ermöglicht. | Datenanalyse, Metriken und statistische Berechnungen. |
|
|
192
|
+
| `toBigIntStatistics()` | Ein Collector, der umfangreiche statistische Analysen auf `bigint`‑Strömen ermöglicht. | Analyse und Statistik für große Integer‑Datensätze. |
|
|
193
|
+
| `toWindow()` | Bietet Sliding‑ und Tumbling‑Window‑Operationen über einen Strom. | Zeitreihenanalyse, Batch‑Verarbeitung und Fenster‑Aggregationen. |
|
|
144
194
|
|
|
145
195
|
---
|
|
146
196
|
|
|
147
|
-
**
|
|
197
|
+
**Wesentliche Nutzungsregeln**
|
|
148
198
|
|
|
149
|
-
1. **
|
|
150
|
-
→ Sie **müssen** `.limit(n)`, `.sub(start, end)` oder `.takeWhile()` aufrufen, um
|
|
199
|
+
1. **Ereignisströme** (erstellt über Fabriken wie `useSubscription`) geben ein `AsynchronousSemantic` zurück.
|
|
200
|
+
→ Sie **müssen** eine grenzendefinierende Methode wie `.limit(n)`, `.sub(start, end)` oder `.takeWhile(predicate)` aufrufen, um den Listener zu beenden. Andernfalls bleibt das Abonnement aktiv.
|
|
151
201
|
|
|
152
|
-
2. **Terminale Operationen** (`.toArray()`, `.count()`, `.
|
|
202
|
+
2. **Terminale Operationen** (`.toArray()`, `.count()`, `.forEach()`, `.findFirst()`, etc.) sind **erst nach** der Umwandlung der Pipeline in einen Collector **verfügbar**:
|
|
153
203
|
```typescript
|
|
154
|
-
.toUnordered() //
|
|
204
|
+
.toUnordered() // Für maximale Geschwindigkeit, Reihenfolge nicht garantiert.
|
|
155
205
|
// oder
|
|
156
|
-
.toOrdered() //
|
|
206
|
+
.toOrdered() // Für stabile, sortierte Ausgabe.
|
|
207
|
+
// oder
|
|
208
|
+
.toNumericStatistics() // Für statistische Methoden.
|
|
157
209
|
```
|
|
158
210
|
|
|
159
211
|
---
|
|
160
212
|
|
|
161
213
|
### Leistungsmerkmale
|
|
162
214
|
|
|
163
|
-
|
|
|
215
|
+
| Collector | Zeitkomplexität | Speicherkomplexität | Reihenfolge garantiert? | Ideales Szenario |
|
|
164
216
|
| :--- | :--- | :--- | :--- | :--- |
|
|
165
|
-
| `toUnordered()` | O(n) | O(n) | Nein |
|
|
166
|
-
| `toOrdered()` | O(
|
|
167
|
-
| `toNumericStatistics()` | O(
|
|
168
|
-
| `toBigIntStatistics()` | O(
|
|
169
|
-
| `toWindow()` | O(
|
|
217
|
+
| `toUnordered()` | O(n) | O(n) | Nein | Rohdurchsatz ist entscheidend; Endreihenfolge irrelevant. |
|
|
218
|
+
| `toOrdered()` | O(n log n) | O(n) | Ja (sortiert) | Stabile Reihenfolge, Indexzugriff oder Vorsortierung für Statistiken. |
|
|
219
|
+
| `toNumericStatistics()` | O(n log n) | O(n) | Ja (interne Sortierung) | Durchführung statistischer Operationen, die sortierte Daten erfordern. |
|
|
220
|
+
| `toBigIntStatistics()` | O(n log n) | O(n) | Ja (interne Sortierung) | Statistische Operationen auf BigInt‑Daten. |
|
|
221
|
+
| `toWindow()` | O(n log n) | O(n) | Ja (interne Sortierung) | Fensteroperationen, die von sortierten Indizes profitieren. |
|
|
170
222
|
|
|
171
|
-
|
|
223
|
+
Wählen Sie `toUnordered()`, wenn absolute Geschwindigkeit entscheidend ist. Entscheiden Sie sich nur dann für `toOrdered()` oder einen Statistik‑Collector, wenn Ihre Logik von der Elementreihenfolge abhängt.
|
|
172
224
|
|
|
173
225
|
---
|
|
174
226
|
|
|
175
|
-
**
|
|
227
|
+
**Vergleichende Analyse mit modernen Stream‑Bibliotheken**
|
|
176
228
|
|
|
177
|
-
|
|
|
229
|
+
| Merkmal | Semantic‑TypeScript | RxJS | Native Async Iterators / Generators | Most.js |
|
|
178
230
|
| :--- | :--- | :--- | :--- | :--- |
|
|
179
|
-
| **TypeScript
|
|
180
|
-
| **Integrierte
|
|
181
|
-
| **
|
|
182
|
-
| **
|
|
183
|
-
| **Leistung &
|
|
184
|
-
| **Bundle
|
|
185
|
-
| **API
|
|
186
|
-
| **
|
|
187
|
-
| **
|
|
188
|
-
| **Lernkurve** | Flach für Entwickler, die mit funktionalen und indizierten Pipelines vertraut sind. | Steiler (
|
|
231
|
+
| **TypeScript‑Integration** | Erstklassig, tief typisiert mit inhärenter Index‑Wahrnehmung. | Hervorragend, beinhaltet jedoch oft komplexe Generika‑Ketten. | Gut, erfordert jedoch manuelle Typannotationen. | Stark, mit funktional‑first‑Typisierungsstil. |
|
|
232
|
+
| **Integrierte Statistik‑Analyse** | Umfassende native Unterstützung für `number` und `bigint`. | Nicht nativ verfügbar (erfordert benutzerdefinierte Operatoren oder andere Bibliotheken). | Keine. | Keine. |
|
|
233
|
+
| **Indizierung & Positionsbewusstsein** | Native, leistungsstarke BigInt‑Indizierung für jedes Element. | Erfordert benutzerdefinierte Operatoren (z.B. `scan`, `withLatestFrom`). | Manuelle Zählerverwaltung notwendig. | Basis, keine integrierte Index‑Eigenschaft. |
|
|
234
|
+
| **Ereignisstrom‑Management** | Dedizierte, typsichere Fabriken mit expliziter, deklarativer Lebenszyklus‑Steuerung. | Leistungsstark, erfordert jedoch sorgfältige manuelle Abonnementverwaltung, um Lecks zu verhindern. | Manuelles Anhängen von Event‑Listenern und Verwaltung von Abbruchtokens. | Gutes `fromEvent`, generell leichtgewichtig. |
|
|
235
|
+
| **Leistung & Speicher** | Herausragend – bietet optimierte `toUnordered()` und `toOrdered()` Collector. | Sehr gut, tiefe Operator‑Ketten können jedoch Overhead einführen. | Hervorragend (minimaler nativer Overhead). | Hervorragend. |
|
|
236
|
+
| **Bundle‑Größe** | Sehr leichtgewichtig. | Substantiell (selbst mit Tree‑Shaking). | Null (natives Sprachfeature). | Klein. |
|
|
237
|
+
| **API‑Design‑Philosophie** | Funktionales Collector‑Muster mit expliziter Index‑Semantik. | Reaktives Observable‑Muster. | Imperatives Iterator / deklaratives Generator‑Muster. | Funktional, point‑free Komposition. |
|
|
238
|
+
| **Flusskontrolle** | Explizit (`interrupt`, `.limit()`, `.takeWhile()`, `.sub()`). | Gut (`take`, `takeUntil`, `first`). | Manuell (`break` in Schleifen). | Gut (`take`, `until`). |
|
|
239
|
+
| **Sync & Async Support** | Vereinheitlichte API – Erstklassiger Support für beide Paradigmen. | Hauptsächlich asynchron. | Beide unterstützt, aber mit manueller Brücke. | Hauptsächlich asynchron. |
|
|
240
|
+
| **Lernkurve** | Flach für Entwickler, die mit funktionalen und indizierten Collection‑Pipelines vertraut sind. | Steiler (umfangreicher Operator‑Wortschatz, Hot/Cold‑Observable‑Konzepte). | Niedrig bis mittel. | Mittel. |
|
|
189
241
|
|
|
190
|
-
**
|
|
242
|
+
**Der Semantic‑TypeScript‑Vorteil**
|
|
191
243
|
|
|
192
|
-
* Einzigartige
|
|
193
|
-
* Explizite Kontrolle über
|
|
194
|
-
*
|
|
244
|
+
* **Einzigartige Fähigkeiten:** Integrierte Statistik‑ und Index‑Funktionen eliminieren die Notwendigkeit manueller `reduce`‑Operationen oder ergänzender Datenanalyse‑Bibliotheken.
|
|
245
|
+
* **Vorhersehbare Ressourcenverwaltung:** Explizite Kontrolle über Ereignisströme verhindert die speicherlecks, die in RxJS‑Anwendungen subtil auftreten können.
|
|
246
|
+
* **Vereinheitlichtes Design:** Eine konsistente API für sowohl synchrone als auch asynchrone Workflows reduziert kognitive Belastung und Code‑Duplizierung.
|
|
195
247
|
|
|
196
|
-
Dieser Vergleich
|
|
248
|
+
Dieser Vergleich unterstreicht, warum Semantic‑TypeScript besonders gut für moderne TypeScript‑Anwendungen geeignet ist, die hohe Leistung, robuste Typsicherheit und umfangreiche Datenverarbeitungsfunktionen ohne die Komplexität traditioneller reaktiver Frameworks erfordern.
|
|
197
249
|
|
|
198
250
|
---
|
|
199
251
|
|
|
200
|
-
###
|
|
252
|
+
### Beginnen Sie Ihre Erkundung
|
|
253
|
+
|
|
254
|
+
Semantic‑TypeScript verwandelt komplexe Datenflüsse in lesbare, komponierbare und hochleistungsfähige Pipelines. Egal, ob Sie Echtzeit‑UI‑Ereignisse verarbeiten, umfangreiche Datensätze bearbeiten oder Analyse‑Dashboards erstellen – es bietet die Leistung von Datenbank‑Level‑Indizierung mit der Eleganz der funktionalen Programmierung.
|
|
201
255
|
|
|
202
|
-
|
|
256
|
+
**Ihre nächsten Schritte:**
|
|
203
257
|
|
|
204
|
-
|
|
258
|
+
* Erkunden Sie die vollständig typisierte API direkt in Ihrer IDE (alle Exporte sind über den Hauptpaket‑Einstiegspunkt verfügbar).
|
|
259
|
+
* Werden Sie Teil der wachsenden Community von Entwicklern, die komplexe asynchrone Iteratoren und reaktive Ketten durch klare, intentionale Semantic‑Pipelines ersetzt haben.
|
|
205
260
|
|
|
206
|
-
|
|
207
|
-
* Treten Sie der wachsenden Community von Entwicklern bei, die verschachtelte asynchrone Iteratoren durch saubere Semantic-Pipelines ersetzt haben.
|
|
261
|
+
**Semantic‑TypeScript** – wo Ströme auf Struktur treffen.
|
|
208
262
|
|
|
209
|
-
|
|
263
|
+
Beginnen Sie noch heute mit dem Bauen und erleben Sie den spürbaren Unterschied, den durchdachte Indizierung bringt.
|
|
210
264
|
|
|
211
|
-
|
|
265
|
+
**Bauen Sie mit Klarheit, handeln Sie mit Vertrauen und transformieren Sie Daten mit Absicht.**
|
|
212
266
|
|
|
213
|
-
|
|
267
|
+
MIT © Eloy Kim
|