Ismail/nodeMap
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs

Browse Source
This commit is contained in:
Ismail Ali
2025-05-27 19:41:17 +02:00
parent 257341475c
commit 97fbb6fdc1
86 changed files with 1452 additions and 1185 deletions
Download Patch File Download Diff File Expand all files Collapse all files

70
docs/redux/api/fromDB/fetchLocationDevices.md
View File

@@ -1,70 +0,0 @@
# 🌐 fetchLocationDevices
Diese Funktion lädt alle Geräte für einen bestimmten Standort aus der Datenbank via API-Endpunkt.
---
## 📍 Pfad
```
/redux/api/fromDB/fetchLocationDevices.js
```
---
## 📥 Funktion
```ts
export const fetchLocationDevices = async () => {
const response = await fetch("/api/talas_v5_DB/locationDevice/locationDevices");
if (!response.ok) {
throw new Error("Geräteliste konnte nicht geladen werden");
}
return await response.json();
};
```
---
## 📡 API-Endpunkt
```http
GET /api/talas_v5_DB/locationDevice/locationDevices
```
Dieser Endpunkt liefert eine JSON-Liste aller Geräte eines Standorts (z. B. für Map-Rendering, POI-Anzeige, Standortübersicht etc.).
---
## 🧪 Fehlerbehandlung
Falls der Request fehlschlägt (z. B. Statuscode ≠ 2xx), wird folgender Fehler ausgelöst:
```
"Geräteliste konnte nicht geladen werden"
```
Dies kann im Redux-Slice über den `.rejected`-Case ausgewertet werden.
---
## 🧩 Verwendung
```ts
import { fetchLocationDevices } from "@/redux/api/fromDB/fetchLocationDevices";
const result = await fetchLocationDevices();
console.log(result); // Erwartet: Array von Geräteobjekten
```
Diese Funktion wird typischerweise im Redux-Thunk `fetchLocationDevicesFromDB` verwendet:
```ts
const data = await fetchLocationDevices();
```
---
## 🔄 Zusammenhang
- Eingebunden in: [`locationDevicesFromDBSlice.js`](./locationDevicesFromDBSlice.md)
- Redux Thunk: `fetchLocationDevicesFromDB`

90
docs/redux/api/fromWebService.md
View File

@@ -1,90 +0,0 @@
# 📡 Webservices – Redux Integration (/redux/api/fromWebService)
In diesem Verzeichnis befinden sich alle Webservice-Fetch-Funktionen für die Kommunikation mit TALAS.web über SOAP-Endpunkte.
---
## Übergabe der Parameter über URL (`m`, `u`)
TALAS.web ruft die Kartenansicht in der Regel so auf:
```
http://[SERVER]:3000/?m=10&u=484
```
Daraus ergeben sich folgende Zuweisungen:
| URL-Parameter | Bedeutung | Variable im Code |
| ------------- | --------- | -------------------------------- |
| `m` | `idMap` | `const idMap = params.get("m")` |
| `u` | `idUser` | `const idUser = params.get("u")` |
### Beispiel:
```ts
const params = new URLSearchParams(window.location.search);
const idMap = params.get("m");
const idUser = params.get("u");
```
---
## Änderung am 2025-05-15
Vorher wurden Default-Werte über `.env.local` als Fallback genutzt:
```ts
const idMap = params.get("idMap") || process.env.NEXT_PUBLIC_DEFAULT_ID_MAP || "12";
```
Das wurde entfernt, um folgende Ziele zu erreichen:
- ❌ Keine fest eingetragenen Defaults im Browser sichtbar
- ✅ Verbindlichkeit: TALAS.web übergibt die Werte immer korrekt via URL
- 🔐 Sicherheit: Kein versehentliches Verwenden eines falschen Users
- 🔍 Fehler leichter erkennbar (Parameter nicht gefunden = echter Fehler)
---
## Hinweis zur Webservice-Konfiguration
Die Webservice-Basisadresse wird **nicht mehr über `.env.local` gesteuert**.
Stattdessen wird sie dynamisch im Client anhand des aktuellen Hostnamens bestimmt:
```js
const baseUrl = `${window.location.origin}/talas5/ClientData/WebServiceMap.asmx`;
```
➡ Dadurch ist kein Rebuild mehr nötig bei IP-Wechseln oder Serverumzügen.
Die Build-Version kann auf jedem Server wiederverwendet werden.
---
## Optional: Validierung einbauen
Falls gewünscht, kann ein expliziter Fehler ausgelöst werden:
```ts
if (!idMap || !idUser) {
throw new Error("Fehlende URL-Parameter: idMap oder idUser");
}
```
---
## Betroffene Dateien
Diese Änderung betrifft alle Funktionen in:
```
/redux/api/fromWebService/fetchGisStationsStatic.js
/redux/api/fromWebService/fetchGisStationsStaticDistrict.js
/redux/api/fromWebService/fetchGisStationsStatusDistrict.js
/redux/api/fromWebService/fetchGisStationsMeasurements.js
/redux/api/fromWebService/fetchGisSystemStatic.js
```
---
Diese Konvention stellt sicher, dass Webservices unabhängig von IP und Serverkonfiguration aufgerufen werden können.

61
docs/redux/api/fromWebService/README.md
View File

@@ -1,61 +0,0 @@
# 📁 Webservice-Dokumentation – fromWebService
Dieses Verzeichnis dokumentiert alle Webservice-Aufrufe,
die über `/redux/api/fromWebService/` im Projekt ausgeführt werden.
---
## 🌐 Hintergrund
Die TALAS.web-Anwendung übergibt `idMap` und `idUser` über die URL-Parameter:
```
http://<server>/talas5/MessagesMap/mapTypeC.aspx?m=12&u=484
```
Daraus entstehen Webservice-Aufrufe wie:
```
/talas5/ClientData/WebServiceMap.asmx/GisSystemStatic?idMap=12&idUser=484
```
Alle Webservices nutzen den Port 80 – auch in der Entwicklungsumgebung.
Daher wird zentral über `.env.local` gesteuert:
```env
NEXT_PUBLIC_API_PORT_MODE=dev
```
---
## 📄 Enthaltene Dokumentationen
| Dateiname | Zweck |
|----------------------------------------|--------------------------------------|
| [`fetchGisSystemStatic.md`](./fetchGisSystemStatic.md) | Systemübersicht aller Geräte |
| [`fetchGisStationsMeasurements.md`](./fetchGisStationsMeasurements.md) | Messwerte der Geräte |
| [`fetchGisStationsStatic.md`](./fetchGisStationsStatic.md) | Statische Standortinformationen |
| [`fetchGisStationsStaticDistrict.md`](./fetchGisStationsStaticDistrict.md) | Gerätestruktur je Bezirk |
| [`fetchGisStationsStatusDistrict.md`](./fetchGisStationsStatusDistrict.md) | Aktueller Gerätestatus nach Bezirk |
---
## 🔁 Verzeichnisstruktur
```bash
/docs
└── frontend
└── redux
└── api
└── fromWebService
├── fetchGisSystemStatic.md
├── fetchGisStationsMeasurements.md
├── fetchGisStationsStatic.md
├── fetchGisStationsStaticDistrict.md
├── fetchGisStationsStatusDistrict.md
└── README.md ← (diese Datei)
```
---
Diese Übersicht hilft Entwicklern beim Einstieg und zeigt, wie zentrale Webservice-Kommunikation im Projekt funktioniert.

81
docs/redux/api/fromWebService/fetchGisStationsMeasurements.md
View File

@@ -1,81 +0,0 @@
# 🌐 fetchGisStationsMeasurements – Geräte-Messwerte abrufen
## Zweck
Diese Funktion ruft Messwerte aller Geräte einer Karte ab.
Die Daten werden vom Webservice `GisStationsMeasurements` bereitgestellt.
---
## Webservice-Endpunkt
```
GisStationsMeasurements?idMap={idMap}&idUser={idUser}
```
---
## Besonderheit: Port-Steuerung per Umgebungsvariable
Die Webservices (z. B. `WebServiceMap.asmx`) laufen **immer auf Port 80** –
auch in der Entwicklungsumgebung.
Um das zu berücksichtigen, wird der Port über `.env.local` gesteuert:
```env
NEXT_PUBLIC_API_PORT_MODE=dev
```
### Beispiel (aus dem Code):
```js
const mode = process.env.NEXT_PUBLIC_API_PORT_MODE;
const apiBaseUrl =
mode === "dev"
? `${window.location.protocol}//${window.location.hostname}:80/talas5/ClientData/WebServiceMap.asmx`
: `${window.location.origin}/talas5/ClientData/WebServiceMap.asmx`;
```
---
## Parameter
| URL-Parameter | Beschreibung | Übergabe durch TALAS.web |
|---------------|--------------|---------------------------|
| `m` | Map-ID | Ja |
| `u` | User-ID | Ja |
Diese Parameter werden clientseitig aus der URL gelesen:
```js
const params = new URLSearchParams(window.location.search);
const idMap = params.get("m");
const idUser = params.get("u");
```
---
## Beispiel-Aufruf
```
http://10.10.0.13/talas5/MessagesMap/mapTypeC.aspx?m=12&u=484
```
→ ergibt folgenden Webservice-Aufruf:
```
http://10.10.0.13/talas5/ClientData/WebServiceMap.asmx/GisStationsMeasurements?idMap=12&idUser=484
```
---
## Siehe auch
- `.env.local` → `NEXT_PUBLIC_API_PORT_MODE`
- `docs/frontend/redux/api/fromWebService/fetchGisSystemStatic.md`
- API-Datei: `/redux/api/fromWebService/fetchGisStationsMeasurements.js`
---
📄 Pfad: `/docs/frontend/redux/api/fromWebService/fetchGisStationsMeasurements.md`

78
docs/redux/api/fromWebService/fetchGisStationsStatic.md
View File

@@ -1,78 +0,0 @@
# 🌐 fetchGisStationsStatic – Standortdaten der Karte abrufen
## Zweck
Diese Funktion ruft die statischen Standortinformationen aller Geräte für eine bestimmte Karte ab.
Sie nutzt den Webservice-Endpunkt `GisStationsStatic`.
---
## Webservice-Endpunkt
```
GisStationsStatic?idMap={idMap}
```
---
## Besonderheit: Port-Steuerung über Umgebungsvariable
Die Webservices laufen immer auf Port 80 – auch in der Entwicklungsumgebung.
Die Funktion erkennt dies anhand der Umgebungsvariable in `.env.local`:
```env
NEXT_PUBLIC_API_PORT_MODE=dev
```
### Codeauszug:
```js
const mode = process.env.NEXT_PUBLIC_API_PORT_MODE;
const apiBaseUrl =
mode === "dev"
? `${window.location.protocol}//${window.location.hostname}:80/talas5/ClientData/WebServiceMap.asmx`
: `${window.location.origin}/talas5/ClientData/WebServiceMap.asmx`;
```
---
## Parameter
| URL-Parameter | Beschreibung | Übergabe durch TALAS.web |
|---------------|--------------|---------------------------|
| `m` | Map-ID | Ja |
Die Map-ID wird aus der URL gelesen:
```js
const params = new URLSearchParams(window.location.search);
const idMap = params.get("m");
```
---
## Beispiel
```
http://10.10.0.13/talas5/MessagesMap/mapTypeC.aspx?m=12&u=484
```
→ wird zu:
```
http://10.10.0.13/talas5/ClientData/WebServiceMap.asmx/GisStationsStatic?idMap=12
```
---
## Siehe auch
- `.env.local` → `NEXT_PUBLIC_API_PORT_MODE`
- `fetchGisSystemStatic.md`
- `fetchGisStationsMeasurements.md`
---
📄 Pfad: `/docs/frontend/redux/api/fromWebService/fetchGisStationsStatic.md`

77
docs/redux/api/fromWebService/fetchGisStationsStaticDistrict.md
View File

@@ -1,77 +0,0 @@
# 🌐 fetchGisStationsStaticDistrict – Statische Gerätebezirksdaten abrufen
## Zweck
Diese Funktion ruft alle statischen Geräte- und Sektordaten eines bestimmten Kartenbereichs ab.
Sie basiert auf dem Webservice-Endpunkt `GisStationsStaticDistrict`.
---
## Webservice-Endpunkt
```
GisStationsStaticDistrict?idMap={idMap}&idUser={idUser}
```
---
## Portsteuerung über Umgebungsvariable
Da die Webservices in allen Umgebungen auf Port 80 laufen, wird der Zugriff über eine Umgebungsvariable gesteuert:
```env
NEXT_PUBLIC_API_PORT_MODE=dev
```
### Codebeispiel:
```js
const mode = process.env.NEXT_PUBLIC_API_PORT_MODE;
const apiBaseUrl =
mode === "dev"
? `${window.location.protocol}//${window.location.hostname}:80/talas5/ClientData/WebServiceMap.asmx`
: `${window.location.origin}/talas5/ClientData/WebServiceMap.asmx`;
```
---
## URL-Parameter
| Parameter | Beschreibung | Wird übergeben durch |
|-----------|--------------|------------------------|
| `m` | Map-ID | TALAS.web (in URL) |
| `u` | User-ID | TALAS.web (in URL) |
```js
const params = new URLSearchParams(window.location.search);
const idMap = params.get("m");
const idUser = params.get("u");
```
---
## Beispiel
```
http://10.10.0.13/talas5/MessagesMap/mapTypeC.aspx?m=12&u=484
```
→ wird übersetzt zu:
```
http://10.10.0.13/talas5/ClientData/WebServiceMap.asmx/GisStationsStaticDistrict?idMap=12&idUser=484
```
---
## Siehe auch
- `.env.local` → `NEXT_PUBLIC_API_PORT_MODE`
- `fetchGisStationsStatic.js`
- `fetchGisStationsMeasurements.js`
- `fetchGisSystemStatic.js`
---
📄 Pfad: `/docs/frontend/redux/api/fromWebService/fetchGisStationsStaticDistrict.md`

78
docs/redux/api/fromWebService/fetchGisStationsStatusDistrict.md
View File

@@ -1,78 +0,0 @@
# 🌐 fetchGisStationsStatusDistrict – Gerätestatus nach Bezirken abrufen
## Zweck
Diese Funktion ruft die aktuellen Statusdaten aller Geräte eines bestimmten Kartenbezirks ab.
Sie basiert auf dem Webservice-Endpunkt `GisStationsStatusDistrict`.
---
## Webservice-Endpunkt
```
GisStationsStatusDistrict?idMap={idMap}&idUser={idUser}
```
---
## Portsteuerung über Umgebungsvariable
Da die Webservices in allen Umgebungen über Port 80 laufen,
wird der Zugriff über eine Umgebungsvariable in `.env.local` konfiguriert:
```env
NEXT_PUBLIC_API_PORT_MODE=dev
```
### Codebeispiel:
```js
const mode = process.env.NEXT_PUBLIC_API_PORT_MODE;
const apiBaseUrl =
mode === "dev"
? `${window.location.protocol}//${window.location.hostname}:80/talas5/ClientData/WebServiceMap.asmx`
: `${window.location.origin}/talas5/ClientData/WebServiceMap.asmx`;
```
---
## URL-Parameter
| Parameter | Beschreibung | Übergabe durch TALAS.web |
|-----------|--------------|---------------------------|
| `m` | Map-ID | Ja |
| `u` | User-ID | Ja |
```js
const params = new URLSearchParams(window.location.search);
const idMap = params.get("m");
const idUser = params.get("u");
```
---
## Beispiel
```
http://10.10.0.13/talas5/MessagesMap/mapTypeC.aspx?m=12&u=484
```
→ wird übersetzt zu:
```
http://10.10.0.13/talas5/ClientData/WebServiceMap.asmx/GisStationsStatusDistrict?idMap=12&idUser=484
```
---
## Siehe auch
- `.env.local` → `NEXT_PUBLIC_API_PORT_MODE`
- `fetchGisStationsStaticDistrict.js`
- `fetchGisStationsMeasurements.js`
- `fetchGisSystemStatic.js`
---
📄 Pfad: `/docs/frontend/redux/api/fromWebService/fetchGisStationsStatusDistrict.md`

76
docs/redux/api/fromWebService/fetchGisSystemStatic.md
View File

@@ -1,76 +0,0 @@
# 🌐 fetchGisSystemStatic – Geräte-Systemdaten abrufen
## Zweck
Diese Funktion ruft die Gerätestatus-Übersicht für eine bestimmte Karte ab:
WebService-Endpunkt:
```
GisSystemStatic?idMap={idMap}&idUser={idUser}
```
---
## Besonderheit bei der URL
Die Webservices (z. B. `WebServiceMap.asmx`) laufen **immer auf Port 80**,
egal ob im Entwicklungsmodus (`localhost`, `:3000`) oder auf dem Testserver (`10.10.0.13`).
Daher wird im Code explizit `:80` gesetzt – gesteuert über die Umgebungsvariable:
```env
NEXT_PUBLIC_API_PORT_MODE=dev
```
### Beispiel (aus dem Code):
```js
const mode = process.env.NEXT_PUBLIC_API_PORT_MODE;
const apiBaseUrl = mode === "dev" ? `${window.location.protocol}//${window.location.hostname}:80/talas5/ClientData/WebServiceMap.asmx` : `${window.location.origin}/talas5/ClientData/WebServiceMap.asmx`;
```
---
## Parameter
Die Funktion liest folgende URL-Parameter ein:
| URL-Parameter | Beschreibung | Übergabe durch TALAS.web |
| ------------- | ------------ | ------------------------ |
| `m` | Map-ID | Ja |
| `u` | User-ID | Ja |
Diese werden aus der URL wie folgt gelesen:
```js
const params = new URLSearchParams(window.location.search);
const idMap = params.get("m");
const idUser = params.get("u");
```
---
## Beispiel-Aufruf
TALAS-Aufruf:
```
http://10.10.0.13/talas5/MessagesMap/mapTypeC.aspx?m=12&u=484
```
wird im Webservice-Request zu:
```
http://10.10.0.13/talas5/ClientData/WebServiceMap.asmx/GisSystemStatic?idMap=12&idUser=484
```
---
## Siehe auch
- `.env.local` → `NEXT_PUBLIC_API_PORT_MODE`
- `docs/fromWebService.md`
- API-Datei: `/redux/api/fromWebService/fetchGisSystemStatic.js`
- 📄 Pfad: `/docs/frontend/redux/api/fromWebService/fetchGisSystemStatic.md`

25
docs/redux/slices/database/locationDevicesFromDBSlice.md Normal file
View File

@@ -0,0 +1,25 @@
<!-- /docs/redux/slices/database/locationDevicesFromDBSlice.md -->
# 🧩 locationDevicesFromDBSlice.js
Redux-Slice für das Laden von Geräten aus der Datenbank-Tabelle `location_device`.
## Zustand
```js
{
devices: [],
status: "idle" | "loading" | "succeeded" | "failed",
error: string | null
}
```
## Thunk
- `fetchLocationDevicesThunk` (async)
## Selector
```js
selectLocationDevices = (state) => state.locationDevicesFromDB.devices
```

23
docs/redux/slices/database/locationDevicesSlice.md Normal file
View File

@@ -0,0 +1,23 @@
<!-- /docs/redux/slices/database/locationDevicesSlice.md -->
# 🧩 locationDevicesSlice.js
Zweite Variante des Slices für Geräte (veraltet oder parallel verwendet).
## Zustand
```js
{
data: [],
status: "idle" | "loading" | "succeeded" | "failed",
error: string | null
}
```
## Selector
```js
selectLocationDevices = (state) => state.locationDevices.data
```
⚠️ Beachte: Duplikat zu `locationDevicesFromDBSlice.js`

24
docs/redux/slices/database/priorityConfigSlice.md Normal file
View File

@@ -0,0 +1,24 @@
<!-- /docs/redux/slices/database/priorityConfigSlice.md -->
# 🧩 priorityConfigSlice.js
Lädt die Prioritätskonfiguration für Marker (z. B. zur farblichen Darstellung).
## Zustand
```js
{
data: [],
status: "idle" | "succeeded"
}
```
## Thunk
- `fetchPriorityConfigThunk`
## Selector
```js
selectPriorityConfig = (state) => state.priorityConfig.data
```

103
docs/redux/slices/db/locationDevicesFromDBSlice.md
View File

@@ -1,103 +0,0 @@
# 📦 locationDevicesFromDBSlice
Zuständig für das Laden und Speichern der Geräteinformationen pro Standort (Location) aus der Datenbank.
## 🧠 Zweck
Dieses Slice verwaltet die Geräte, die mit einem bestimmten Standort (Location) verknüpft sind.
Es nutzt ein `createAsyncThunk`, um die Daten vom Webservice bzw. von der lokalen Datenbank zu laden.
---
## 🔁 Datenfluss
1. **Dispatch `fetchLocationDevicesFromDB()`**
2. **Daten werden über `fetchLocationDevices()` geladen**
3. **Status wird aktualisiert (`loading`, `succeeded`, `failed`)**
4. **Geräte-Liste (`devices`) wird gespeichert**
---
## 🧩 Slice-Definition
```js
initialState: {
devices: [], // Geräte-Liste pro Standort
status: "idle", // "idle" | "loading" | "succeeded" | "failed"
error: null // Fehlernachricht im Fehlerfall
}
```
---
## 🔧 Actions
| Action Type | Beschreibung |
|--------------------------------------------|--------------------------------------------------|
| `fetchLocationDevicesFromDB/pending` | Startet den Ladeprozess |
| `fetchLocationDevicesFromDB/fulfilled` | Speichert die empfangenen Geräte in `devices` |
| `fetchLocationDevicesFromDB/rejected` | Speichert die Fehlermeldung in `error` |
---
## 📥 Async Thunk
```ts
export const fetchLocationDevicesFromDB = createAsyncThunk(
"locationDevicesFromDB/fetchLocationDevicesFromDB",
async () => {
return fetchLocationDevices(); // API-Aufruf aus services/api
}
);
```
Die Funktion `fetchLocationDevices()` befindet sich unter:
```
/redux/api/fromDB/fetchLocationDevices.js
```
---
## 🧪 Verwendung in Komponenten
### Beispiel mit `useSelector` & `useDispatch`
```tsx
import { useSelector, useDispatch } from "react-redux";
import { fetchLocationDevicesFromDB } from "@/redux/slices/db/locationDevicesFromDBSlice";
const dispatch = useDispatch();
const devices = useSelector((state) => state.locationDevicesFromDB.devices);
const status = useSelector((state) => state.locationDevicesFromDB.status);
useEffect(() => {
dispatch(fetchLocationDevicesFromDB());
}, []);
```
---
## 🧩 Integration im Store
```ts
import locationDevicesFromDBReducer from "./slices/db/locationDevicesFromDBSlice";
export const store = configureStore({
reducer: {
locationDevicesFromDB: locationDevicesFromDBReducer,
// weitere Slices ...
},
});
```
---
## 📌 Hinweis
Dieses Slice ist Bestandteil der neuen Redux-Architektur (ehemals Recoil)
→ siehe auch `CHANGELOG.md` Version `1.1.97` bis `1.1.98`.
```
Pfad: /redux/slices/db/locationDevicesFromDBSlice.js
```

93
docs/redux/slices/db/poiTypesSlice.md
View File

@@ -1,93 +0,0 @@
# 🧭 poiTypesSlice
Verwaltet die Point-of-Interest (POI) Typen, die vom Server bereitgestellt werden – z. B. für die Darstellung von Symbolen oder Layer-Kategorien in der Karte.
---
## 📍 Datei
```
/redux/slices/db/poiTypesSlice.js
```
---
## 📦 Initialer State
```ts
{
data: [], // Liste der POI-Typen
status: "idle" // Ladezustand: "idle" | "loading" | "succeeded" | "failed"
}
```
---
## ⚙️ Async Thunk: `fetchPoiTypes`
```ts
export const fetchPoiTypes = createAsyncThunk("poiTypes/fetchPoiTypes", async () => {
let API_BASE_URL = "";
if (typeof window !== "undefined") {
API_BASE_URL = `${window.location.protocol}//${window.location.hostname}:3000`;
} else {
API_BASE_URL = "http://localhost:3000";
}
const response = await fetch(`${API_BASE_URL}/api/talas_v5_DB/poiTyp/readPoiTyp`);
return await response.json();
});
```
---
## 🔁 Lifecycle im Slice
| Zustand | Beschreibung |
|--------------------|--------------------------------------|
| `pending` | Setzt `status = "loading"` |
| `fulfilled` | Speichert `payload` in `state.data` und setzt `status = "succeeded"` |
| `rejected` | Setzt `status = "failed"` |
---
## 🧪 Verwendung im Component
```tsx
import { useSelector, useDispatch } from "react-redux";
import { fetchPoiTypes } from "@/redux/slices/db/poiTypesSlice";
const dispatch = useDispatch();
const poiTypes = useSelector((state) => state.poiTypes.data);
const status = useSelector((state) => state.poiTypes.status);
useEffect(() => {
dispatch(fetchPoiTypes());
}, []);
```
---
## 🧩 Store Integration
```ts
import poiTypesReducer from "./slices/db/poiTypesSlice";
export const store = configureStore({
reducer: {
poiTypes: poiTypesReducer,
// weitere ...
},
});
```
---
## 🌐 API-Endpunkt
```http
GET /api/talas_v5_DB/poiTyp/readPoiTyp
```
Erwartet JSON-Antwort mit allen verfügbaren POI-Typen für die App.

64
docs/redux/store.md Normal file
View File

@@ -0,0 +1,64 @@
<!-- /docs/redux/store.md -->
# 🧠 Redux Store (store.js)
Zentrale Konfiguration des globalen Redux-Stores für die Anwendung.
Er verwaltet Zustand für Daten aus Webservices, der Datenbank und UI-Status.
---
## 🔌 Verwendung
```js
import { Provider } from "react-redux";
import { store } from "../redux/store";
<Provider store={store}>
<App />
</Provider>
```
---
## 🔁 Struktur
Der Store besteht aus drei Bereichen:
### 1. `database`
- `poiMarkers`, `addPoi`, `poiLayerVisible`
- `gisLinesFromDatabase`, `polylineLayerVisible`
- `readPoiMarkersStore`, `priorityConfig`, `locationDevicesFromDB`
### 2. `webservice`
- `gisStationsStaticDistrict`, `gisStationsStatusDistrict`, `gisSystemStatic`
- `gisStationsMeasurements`, `gisLinesStatusFromWebservice`, `userRights`
### 3. `ui / interaktiv`
- `mapLayers`, `selectedDevice`, `selectedPoi`, `selectedArea`
- `lineVisibility`, `zoomTrigger`, `urlParameter`, `polylineContextMenu`
- `polylineEventsDisabled`, `addPoiOnPolyline`
---
## ⚙️ Einrichtung
```js
export const store = configureStore({
reducer: {
selectedDevice: selectedDeviceReducer,
poiMarkers: poiMarkersReducer,
...
}
});
```
---
## 📁 Pfad
```bash
/redux/store.js
```