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.jp.md
CHANGED
|
@@ -1,38 +1,34 @@
|
|
|
1
|
-
# Semantic
|
|
2
|
-
|
|
1
|
+
# **Semantic‑TypeScript**
|
|
2
|
+
**ストリーム処理、インデックス化。** あなたのデータを精密に制御。
|
|
3
3
|
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
### 概要
|
|
7
7
|
|
|
8
|
-
Semantic
|
|
8
|
+
Semantic‑TypeScriptは、ストリーム処理における重要な進化を表しており、JavaScriptジェネレーター、Java Streams、MySQLスタイルのインデックス作成から最も効果的なパラダイムを優雅に**統合**しています。その基本理念は強力かつ意図的です:従来の力任せの反復処理ではなく、インテリジェントなインデックス作成を通じて、非常に効率的なデータ処理パイプラインを構築します。
|
|
9
9
|
|
|
10
|
-
|
|
10
|
+
従来のライブラリが同期ループや煩雑なPromiseチェーンを強いるのに対し、Semantic‑TypeScriptは、現代のアプリケーション開発の要求に特化して設計された、**完全非同期**、機能的に純粋、かつ厳密に型安全な体験を提供します。
|
|
11
11
|
|
|
12
|
-
|
|
12
|
+
このモデルは洗練された制御フローを体現しています:データは、上流パイプラインが明示的に`accept`コールバックを呼び出す時だけ、下流のコンシューマーに渡されます。処理のタイミングについて、完全かつ細やかなコントロールを保持できます。処理は、必要とされる時、そしてその時にのみ正確に実行されます。
|
|
13
13
|
|
|
14
14
|
---
|
|
15
15
|
|
|
16
|
-
###
|
|
16
|
+
### 開発者がSemantic‑TypeScriptを選ぶ理由
|
|
17
17
|
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
・**予測可能なパフォーマンス** — 要件に基づいて、順序付きまたは順序なしのコレクターを選択できます。
|
|
27
|
-
|
|
28
|
-
・**メモリ効率** — ストリームは遅延評価されるため、メモリの懸念を軽減します。
|
|
29
|
-
|
|
30
|
-
・**未定義動作なし** — TypeScriptが型安全性とnull安全性を保証します。入力データは、コールバック関数内で明示的に変更されない限り、変更されません。
|
|
18
|
+
- **ボイラープレート不要のインデックス作成** – 各要素は本来備わっている、またはカスタマイズされたインデックスを自然に保有し、手動での追跡を不要にします。
|
|
19
|
+
- **純粋関数型かつ型安全** – 不変な操作と共に、完全で慣用的なTypeScriptの型推論を享受できます。
|
|
20
|
+
- **メモリリーク防止のイベントストリーム** – `useSubscription`パターンは、リソースセキュリティを第一原則として設計されています。`limit(n)`、`sub(start, end)`、`takeWhile(predicate)`を使用して論理的な境界を定義するだけで、ライブラリが購読の完全なライフサイクルを管理します。これにより、残留リスナーやメモリリークは発生しません。
|
|
21
|
+
- **組み込み統計スイート** – 外部依存なしで、`number`および`bigint`ストリームに対する平均、中央値、最頻値、分散、歪度、尖度を含む包括的な分析機能にアクセスできます。
|
|
22
|
+
- **予測可能で調整可能なパフォーマンス** – 正確なパフォーマンスと順序要件に合わせて、順序付きまたは順序なしのコレクターを選択できます。
|
|
23
|
+
- **本質的にメモリ効率が良い** – ストリームは遅延評価され、メモリ負荷を軽減するため、要素はオンデマンドで処理されます。
|
|
24
|
+
- **未定義動作なし** – TypeScriptが完全な型安全性とnull安全性を保証します。コールバック関数内で明示的に変更しない限り、ソースデータは不変のままです。
|
|
31
25
|
|
|
32
26
|
---
|
|
33
27
|
|
|
34
28
|
### インストール
|
|
35
29
|
|
|
30
|
+
お好みのパッケージマネージャーを使用して、プロジェクトにSemantic‑TypeScriptを統合します:
|
|
31
|
+
|
|
36
32
|
```bash
|
|
37
33
|
npm install semantic-typescript
|
|
38
34
|
```
|
|
@@ -43,180 +39,229 @@ yarn add semantic-typescript
|
|
|
43
39
|
|
|
44
40
|
---
|
|
45
41
|
|
|
46
|
-
###
|
|
42
|
+
### 実践的な紹介
|
|
43
|
+
|
|
44
|
+
以下の例は、基本的な変換から実際のイベント処理までの核心概念を示しています。
|
|
47
45
|
|
|
48
46
|
```typescript
|
|
49
|
-
import { useOf, useFrom, useRange,
|
|
50
|
-
|
|
51
|
-
//
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
//
|
|
58
|
-
|
|
59
|
-
.
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
.
|
|
47
|
+
import { useOf, useFrom, useRange, useSubscription, useText, useStringify } from "semantic-typescript";
|
|
48
|
+
|
|
49
|
+
// ====================================================================
|
|
50
|
+
// 例1: 基本的な操作と数値統計
|
|
51
|
+
// ====================================================================
|
|
52
|
+
// マッピング操作と終端統計操作を示します。変換後、パイプラインを統計コレクターに変換してから、`.summate()`などの終端メソッドを呼び出す必要があります。
|
|
53
|
+
|
|
54
|
+
const numericSum: number = useOf(10, 20, 30, 40)
|
|
55
|
+
.map((n: number): number => n * 2) // 各要素を2倍: [20, 40, 60, 80]
|
|
56
|
+
.toNumericStatistics() // 統計コレクターに変換
|
|
57
|
+
.summate(); // 終端操作: 200
|
|
58
|
+
|
|
59
|
+
// その他の統計メソッド(`.toNumericStatistics()`後に利用可能):
|
|
60
|
+
// .average(), .median(), .mode(), .variance(), .skewness(), .kurtosis()
|
|
61
|
+
|
|
62
|
+
// ====================================================================
|
|
63
|
+
// 例2: BigInt統計
|
|
64
|
+
// ====================================================================
|
|
65
|
+
// 数値統計と同様に動作しますが、BigIntデータ用に最適化されています。
|
|
66
|
+
|
|
67
|
+
const bigintSum: bigint = useOf(10n, 20n, 30n, 40n)
|
|
68
|
+
.map((n: bigint): bigint => n * 2n) // BigInt演算
|
|
69
|
+
.toBigIntStatistics() // BigInt統計コレクターに変換
|
|
70
|
+
.summate(); // 終端操作: 200n
|
|
71
|
+
|
|
72
|
+
// ====================================================================
|
|
73
|
+
// 例3: ストリーム反転のためのインデックス操作
|
|
74
|
+
// ====================================================================
|
|
75
|
+
// `.redirect()`メソッドを使用して、要素のインデックスを戦略的に再割り当てすることで要素を並べ替える方法を示し、反転などのカスタムパターンを可能にします。
|
|
76
|
+
|
|
77
|
+
const reversedArray: number[] = useFrom([1, 2, 3, 4, 5])
|
|
78
|
+
.redirect((_element: number, index: bigint): bigint => -index) // 負のインデックスにマッピング
|
|
79
|
+
.toOrdered() // 必須: 新しいインデックスでソートされた要素を収集
|
|
80
|
+
.toArray(); // 結果: [5, 4, 3, 2, 1]
|
|
81
|
+
|
|
82
|
+
// 単純な反転には、`.reverse()`も利用可能です。
|
|
83
|
+
|
|
84
|
+
// ====================================================================
|
|
85
|
+
// 例4: ストリームシャッフル
|
|
86
|
+
// ====================================================================
|
|
87
|
+
// インプレースシャッフルアルゴリズムを使用して、要素のインデックスをランダムに並べ替えます。
|
|
88
|
+
|
|
89
|
+
const shuffledArray: number[] = useFrom([1, 2, 3, 4, 5])
|
|
90
|
+
.shuffle() // インデックスをランダムに再割り当て
|
|
91
|
+
.toOrdered() // 新しいランダムなインデックスでソート
|
|
92
|
+
.toArray(); // 例: [2, 5, 1, 4, 3] (実行ごとに異なる)
|
|
93
|
+
|
|
94
|
+
// ====================================================================
|
|
95
|
+
// 例5: ストリームの循環ローテーション
|
|
96
|
+
// ====================================================================
|
|
97
|
+
// 要素を循環的にシフトします。正の値は右回転、負の値は左回転です。
|
|
98
|
+
|
|
99
|
+
// 右へ2ポジション回転
|
|
100
|
+
const rightRotated: number[] = useFrom([1, 2, 3, 4, 5])
|
|
101
|
+
.translate(2) // インデックスを右に2つシフト
|
|
72
102
|
.toOrdered()
|
|
73
|
-
.toArray();
|
|
103
|
+
.toArray(); // 結果: [4, 5, 1, 2, 3]
|
|
74
104
|
|
|
75
|
-
//
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
.toArray(); // [4, 5, 1, 2, 3]
|
|
105
|
+
// ====================================================================
|
|
106
|
+
// 例6: 無限範囲での遅延評価
|
|
107
|
+
// ====================================================================
|
|
108
|
+
// 理論的に無限のストリームを遅延的に処理し、必要な時だけ要素を計算します。
|
|
80
109
|
|
|
81
|
-
|
|
82
|
-
.
|
|
83
|
-
.
|
|
84
|
-
.
|
|
110
|
+
const firstTenMultiples: bigint[] = useRange(0n, 1_000_000n)
|
|
111
|
+
.filter(n => n % 17n === 0n) // 17の倍数を保持
|
|
112
|
+
.limit(10n) // 重要: 10番目の一致後に停止
|
|
113
|
+
.toUnordered() // ソートは不要
|
|
114
|
+
.toArray(); // 結果: [0, 17, 34, 51, 68, 85, 102, 119, 136, 153]
|
|
85
115
|
|
|
86
|
-
//
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
116
|
+
// `.limit(10n)`がなければ、パイプラインは100万要素すべてを処理します。
|
|
117
|
+
|
|
118
|
+
// ====================================================================
|
|
119
|
+
// 例7: 複雑なパイプラインの構築
|
|
120
|
+
// ====================================================================
|
|
121
|
+
// 複数の操作を順次組み合わせる方法を示します。
|
|
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()
|
|
91
130
|
.toArray();
|
|
92
131
|
|
|
93
|
-
//
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
132
|
+
// ====================================================================
|
|
133
|
+
// 例8: 管理されたDOMイベント購読
|
|
134
|
+
// ====================================================================
|
|
135
|
+
// 自動的でメモリリーク防止のクリーンアップ機能付きで、ブラウザイベントを監視します。
|
|
136
|
+
// `.limit(n)`の呼び出しは、リスナーの自動削除の境界を定義します。
|
|
137
|
+
|
|
138
|
+
// Windowターゲット用のサブスクライバーを定義
|
|
139
|
+
const windowSubscriber = {
|
|
140
|
+
mount: (target: Window): void => { /* セットアップロジック */ },
|
|
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 => { /* クリーンアップロジック */ }
|
|
148
|
+
};
|
|
98
149
|
|
|
99
|
-
|
|
100
|
-
//
|
|
101
|
-
useHTMLElement("#input", "change")
|
|
102
|
-
.limit(1)
|
|
150
|
+
useSubscription(window, windowSubscriber, "resize")
|
|
151
|
+
.limit(5n) // 5イベント後に自動的に購読解除
|
|
103
152
|
.toUnordered()
|
|
104
|
-
.forEach((
|
|
153
|
+
.forEach((ev: Event, idx) =>
|
|
154
|
+
console.log(`リサイズ #${idx}: ${(ev.target as Window).innerWidth}x${(ev.target as Window).innerHeight}`)
|
|
155
|
+
);
|
|
105
156
|
|
|
106
|
-
//
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
.forEach((event: Event) => submit(event));
|
|
111
|
-
|
|
112
|
-
// WebSocketのリスニング
|
|
113
|
-
let webSocket = new WebSocket("ws://localhost:8080");
|
|
114
|
-
webSocket.addEventListener("close", (): void => {
|
|
115
|
-
webSocket.close(); // WebSocketのライフサイクルは手動で管理
|
|
116
|
-
});
|
|
117
|
-
useWebSocket(webSocket, "message")
|
|
118
|
-
.limit(1)
|
|
119
|
-
.toUnordered()
|
|
120
|
-
.forEach((message: MessageEvent) => console.log(message.data));
|
|
157
|
+
// ====================================================================
|
|
158
|
+
// 例9: Unicodeコードポイントによる文字列処理
|
|
159
|
+
// ====================================================================
|
|
160
|
+
// マルチバイトUnicode文字を正しく処理しながら、文字列を反復処理します。
|
|
121
161
|
|
|
122
|
-
// 文字列をコードポイントでイテレート
|
|
123
162
|
useText("My emotion now is: 😊, and semantic is 👍")
|
|
124
163
|
.toUnordered()
|
|
125
|
-
.log(); //
|
|
164
|
+
.log(); // 各文字(絵文字を含む)を改行して出力します。
|
|
165
|
+
|
|
166
|
+
// ====================================================================
|
|
167
|
+
// 例10: 循環参照を含むオブジェクトの安全な文字列化
|
|
168
|
+
// ====================================================================
|
|
169
|
+
// 循環参照を含むオブジェクトを安全にシリアライズします。
|
|
126
170
|
|
|
127
|
-
|
|
128
|
-
let o = {
|
|
171
|
+
const obj = {
|
|
129
172
|
a: 1,
|
|
130
|
-
b: "text"
|
|
131
|
-
c: [o.a, o.b, o.c] // 循環参照
|
|
173
|
+
b: "text"
|
|
132
174
|
};
|
|
133
|
-
|
|
134
|
-
|
|
175
|
+
(obj as any).c = [obj.a, obj.b, (obj as any).c]; // 循環参照を導入
|
|
176
|
+
|
|
177
|
+
// const text: string = JSON.stringify(obj); // エラーをスロー
|
|
178
|
+
const text: string = useStringify(obj); // 安全に `{a: 1, b: "text", c: []}` を生成
|
|
135
179
|
```
|
|
136
180
|
|
|
137
181
|
---
|
|
138
182
|
|
|
139
|
-
###
|
|
183
|
+
### 核心概念
|
|
140
184
|
|
|
141
|
-
| 概念 | 目的 |
|
|
185
|
+
| 概念 | 目的 | 主な使用例 |
|
|
142
186
|
| :--- | :--- | :--- |
|
|
143
|
-
| `AsynchronousSemantic` |
|
|
144
|
-
| `SynchronousSemantic` |
|
|
145
|
-
| `toUnordered()` |
|
|
146
|
-
| `toOrdered()` |
|
|
147
|
-
| `toNumericStatistics()` |
|
|
148
|
-
| `toBigIntStatistics()` |
|
|
149
|
-
| `toWindow()` |
|
|
187
|
+
| `AsynchronousSemantic` | 非同期ストリーム、イベント、およびプッシュベースの遅延パイプラインのためのコアビルダー。 | リアルタイムイベント、WebSockets、DOMリスナー、または長時間実行/無限ストリーム。 |
|
|
188
|
+
| `SynchronousSemantic` | 同期、メモリ内、またはプルベースの即時評価パイプラインのビルダー。 | 静的データ、有限範囲、または即時の反復処理タスク。 |
|
|
189
|
+
| `toUnordered()` | 最速の終端コレクター。インデックス格納にMapを使用。 | 安定した順序が不要な性能重視のパス(時間・空間計算量 O(n))。 |
|
|
190
|
+
| `toOrdered()` | ソート済みでインデックスが安定した終端コレクター。 | 要素の順序を保持する必要がある場合、またはインデックスアクセスが必要な場合。 |
|
|
191
|
+
| `toNumericStatistics()` | `number`ストリームでの豊富な統計分析を可能にするコレクター。 | データ分析、メトリクス、統計計算。 |
|
|
192
|
+
| `toBigIntStatistics()` | `bigint`ストリームでの豊富な統計分析を可能にするコレクター。 | 大きな整数データセットの分析と統計。 |
|
|
193
|
+
| `toWindow()` | ストリームに対するスライディングおよびタンブリングウィンドウ操作を提供。 | 時系列分析、バッチ処理、ウィンドウ集計。 |
|
|
150
194
|
|
|
151
195
|
---
|
|
152
196
|
|
|
153
|
-
|
|
197
|
+
**必須の使用ルール**
|
|
154
198
|
|
|
155
|
-
1.
|
|
156
|
-
→
|
|
199
|
+
1. **イベントストリーム**(`useSubscription`などのファクトリー経由で作成)は`AsynchronousSemantic`を返します。
|
|
200
|
+
→ リスナーを終了させるために、`.limit(n)`、`.sub(start, end)`、`.takeWhile(predicate)`などの境界定義メソッドを**必ず**呼び出す必要があります。そうしないと、購読がアクティブなままになります。
|
|
157
201
|
|
|
158
|
-
2.
|
|
202
|
+
2. **終端操作**(`.toArray()`、`.count()`、`.forEach()`、`.findFirst()`など)は、パイプラインをコレクターに変換した**後にのみ**利用可能です:
|
|
159
203
|
```typescript
|
|
160
|
-
.toUnordered() //
|
|
204
|
+
.toUnordered() // 最大速度のため、順序は保証されません。
|
|
161
205
|
// または
|
|
162
|
-
.toOrdered() //
|
|
206
|
+
.toOrdered() // 安定した、ソートされた出力のため。
|
|
207
|
+
// または
|
|
208
|
+
.toNumericStatistics() // 統計メソッドのため。
|
|
163
209
|
```
|
|
164
210
|
|
|
165
211
|
---
|
|
166
212
|
|
|
167
213
|
### パフォーマンス特性
|
|
168
214
|
|
|
169
|
-
| コレクター | 時間計算量 | 空間計算量 |
|
|
215
|
+
| コレクター | 時間計算量 | 空間計算量 | 順序保証? | 理想的なシナリオ |
|
|
170
216
|
| :--- | :--- | :--- | :--- | :--- |
|
|
171
|
-
| `toUnordered()` | O(n) | O(n) | いいえ |
|
|
172
|
-
| `toOrdered()` | O(
|
|
173
|
-
| `toNumericStatistics()` | O(
|
|
174
|
-
| `toBigIntStatistics()` | O(
|
|
175
|
-
| `toWindow()` | O(
|
|
217
|
+
| `toUnordered()` | O(n) | O(n) | いいえ | 生のスループットが鍵。最終的な順序は重要でない。 |
|
|
218
|
+
| `toOrdered()` | O(n log n) | O(n) | はい(ソート済み) | 安定した順序、インデックスアクセス、または統計用の事前ソートが必要な場合。 |
|
|
219
|
+
| `toNumericStatistics()` | O(n log n) | O(n) | はい(内部ソート) | ソートされたデータを必要とする統計操作の実行。 |
|
|
220
|
+
| `toBigIntStatistics()` | O(n log n) | O(n) | はい(内部ソート) | BigIntデータでの統計操作。 |
|
|
221
|
+
| `toWindow()` | O(n log n) | O(n) | はい(内部ソート) | ソートされたインデックスから恩恵を受けるウィンドウ操作。 |
|
|
176
222
|
|
|
177
|
-
|
|
223
|
+
絶対的な速度が最重要である場合は`toUnordered()`を選択してください。ロジックが要素の順序に依存する場合にのみ、`toOrdered()`または統計コレクターを選択してください。
|
|
178
224
|
|
|
179
225
|
---
|
|
180
226
|
|
|
181
|
-
|
|
227
|
+
**現代ストリームライブラリとの比較分析**
|
|
182
228
|
|
|
183
|
-
|
|
|
229
|
+
| 機能 | Semantic‑TypeScript | RxJS | ネイティブ Async Iterators / Generators | Most.js |
|
|
184
230
|
| :--- | :--- | :--- | :--- | :--- |
|
|
185
|
-
| **TypeScript統合** |
|
|
186
|
-
| **組み込み統計分析** | `number
|
|
187
|
-
|
|
|
188
|
-
| **イベントストリーム管理** |
|
|
189
|
-
|
|
|
190
|
-
| **バンドルサイズ** | 非常に軽量。 |
|
|
191
|
-
| **API設計思想** |
|
|
192
|
-
|
|
|
193
|
-
|
|
|
194
|
-
| **学習曲線** |
|
|
195
|
-
|
|
196
|
-
**Semantic-TypeScriptの主な利点**
|
|
197
|
-
|
|
198
|
-
・ 独自の組み込み統計およびインデックス機能により、手動での `reduce` や外部ライブラリが不要。
|
|
231
|
+
| **TypeScript統合** | ファーストクラス、深い型付け、インデックス認識を内包。 | 優れているが、複雑なジェネリックチェーンを伴うことが多い。 | 良いが、手動の型注釈が必要。 | 強い、関数型ファーストの型付けスタイル。 |
|
|
232
|
+
| **組み込み統計分析** | `number`および`bigint`に対する包括的なネイティブサポート。 | ネイティブでは利用不可(カスタムオペレーターまたは他のライブラリが必要)。 | なし。 | なし。 |
|
|
233
|
+
| **インデックス作成と位置認識** | 各要素に対するネイティブで強力なBigIntインデックス作成。 | カスタムオペレーターが必要(例: `scan`、`withLatestFrom`)。 | 手動でのカウンター管理が必要。 | 基本的、組み込みのインデックスプロパティなし。 |
|
|
234
|
+
| **イベントストリーム管理** | 明示的で宣言的なライフサイクル制御を備えた、型安全な専用ファクトリー。 | 強力だが、メモリリークを防ぐためには注意深い手動購読管理が必要。 | イベントリスナーの手動登録とキャンセルトークンの管理。 | 良い`fromEvent`、一般的に軽量。 |
|
|
235
|
+
| **パフォーマンスとメモリ** | 卓越 – 最適化された`toUnordered()`および`toOrdered()`コレクターを提供。 | 非常に良いが、深いオペレーターチェーンはオーバーヘッドをもたらす可能性あり。 | 優れている(ネイティブオーバーヘッド最小限)。 | 優れている。 |
|
|
236
|
+
| **バンドルサイズ** | 非常に軽量。 | 大きい(ツリーシェイキング後でも)。 | ゼロ(言語のネイティブ機能)。 | 小さい。 |
|
|
237
|
+
| **API設計思想** | 明示的なインデックス意味論を持つ関数型コレクターパターン。 | リアクティブObservableパターン。 | 命令型Iterator / 宣言型Generatorパターン。 | 関数型、ポイントフリー構成。 |
|
|
238
|
+
| **フロー制御** | 明示的(`interrupt`、`.limit()`、`.takeWhile()`、`.sub()`)。 | 良い(`take`、`takeUntil`、`first`)。 | 手動(ループ内の`break`)。 | 良い(`take`、`until`)。 |
|
|
239
|
+
| **同期および非同期サポート** | 統一API – 両パラダイムに対するファーストクラスサポート。 | 主に非同期。 | 両方サポートされているが、手動ブリッジが必要。 | 主に非同期。 |
|
|
240
|
+
| **学習曲線** | 関数型およびインデックス付きコレクションパイプラインに慣れた開発者には穏やか。 | 急(オペレーター語彙が広範、Hot/Cold Observable概念)。 | 低から中程度。 | 中程度。 |
|
|
199
241
|
|
|
200
|
-
|
|
242
|
+
**Semantic‑TypeScriptの利点**
|
|
201
243
|
|
|
202
|
-
|
|
244
|
+
* **独自の能力:** 組み込みの統計およびインデックス作成機能により、手動の`reduce`操作や補助的なデータ分析ライブラリの必要性がなくなります。
|
|
245
|
+
* **予測可能なリソース管理:** イベントストリームに対する明示的な制御により、RxJSアプリケーションで発生しうる微妙なメモリリークを防止します。
|
|
246
|
+
* **統一された設計:** 同期および非同期ワークフロー両方の一貫したAPIにより、認知負荷とコード重複が減少します。
|
|
203
247
|
|
|
204
|
-
|
|
248
|
+
この比較は、従来のリアクティブフレームワークの複雑さなしに、高いパフォーマンス、堅牢な型安全性、および豊富なデータ処理機能を要求する現代のTypeScriptアプリケーションに、Semantic‑TypeScriptが特に適している理由を強調しています。
|
|
205
249
|
|
|
206
250
|
---
|
|
207
251
|
|
|
208
|
-
###
|
|
252
|
+
### 探求を始めよう
|
|
209
253
|
|
|
210
|
-
Semantic
|
|
254
|
+
Semantic‑TypeScriptは、複雑なデータフローを読みやすく、構成可能で、高性能なパイプラインに変換します。リアルタイムUIイベントの処理、大規模データセットの処理、分析ダッシュボードの構築のいずれにおいても、データベースレベルのインデックス作成のパワーと関数型プログラミングのエレガンスを提供します。
|
|
211
255
|
|
|
212
|
-
|
|
256
|
+
**次のステップ:**
|
|
213
257
|
|
|
214
|
-
|
|
258
|
+
* IDE内で直接、完全に型付けされたAPIを探索してください(すべてのエクスポートはメインパッケージエントリーポイントから利用可能です)。
|
|
259
|
+
* 複雑な非同期イテレータやリアクティブチェーンを、明確で意図的なSemanticパイプラインに置き換えた開発者の成長するコミュニティに参加してください。
|
|
215
260
|
|
|
216
|
-
|
|
261
|
+
**Semantic‑TypeScript** – ストリームと構造が出会う場所。
|
|
217
262
|
|
|
218
|
-
|
|
263
|
+
今日から構築を始め、考え抜かれたインデックス作成がもたらす明確な違いを体験してください。
|
|
219
264
|
|
|
220
|
-
|
|
265
|
+
**明確さをもって構築し、自信をもって前進し、意図をもってデータを変換する。**
|
|
221
266
|
|
|
222
|
-
|
|
267
|
+
MIT © Eloy Kim
|