Skip to content

Latest commit

 

History

History
71 lines (60 loc) · 3.74 KB

File metadata and controls

71 lines (60 loc) · 3.74 KB

Cocoar.Calendar.iOS

Swift-Port der Vue-Kalenderkomponente @cocoar/vue-calendar (/Users/bwi/git/cocoar-ui-vue/packages/calendar). Vollständige Analyse: docs/vue-calendar-analyse.md.

Paritäts-Grenze (Entscheid bwi 2026-07-12): Die beiden Ports DÜRFEN in Bedienung und Aussehen auseinanderdriften — Web und iOS werden anders benutzt. Die Grenze ist die Package-Struktur:

  • CocoarCalendarCore (Berechnungen): MUSS exakt verhaltensgleich zum Web bleiben. Die TS-core/*-Quellen sind die Spezifikation, nicht Inspiration; die Fixtures pinnen das. Nie forken — Core-Änderungen nur als Nachzug eines Upstream-Fixes (Fixtures regenerieren).
  • CocoarCalendarUI (Handling + Optik): darf iOS-Konventionen folgen (Beispiele: Wochen-Strip, Swipe-Paging, Gesten-Matrix, Long-Press=Drag). Jede bewusste Abweichung vom Vue-Rendering im Code als „documented deviation" kommentieren, damit Absicht von Versehen unterscheidbar bleibt.

Struktur

  • Sources/CocoarCalendarCore/ — pure Logik, 1:1-Port der core/*.ts-Module (Zeit-Kernel mit DST-Resolver, Kalender-Mathe, Overlap-/Layout-Engines, Drop-Pipeline MoveMath). Kein SwiftUI, kein Foundation-Calendar in der Datumsarithmetik (eigene zivile Algorithmen, Determinismus).
  • Sources/CocoarCalendarUI/ — SwiftUI-Schicht (Theme, DayColumn, TimeGrid, Week/Day/Month/Agenda-Views, Shell/Controller).
  • Tests/.../Fixtures/*.jsonNIEMALS von Hand editieren. Generiert aus der echten Vue-Implementierung via tools/gen-fixtures*.ts; sie sind der Verhaltens-Contract. Bei Bedarf Generator anpassen und neu laufen lassen: <esbuild> tools/gen-fixtures-X.ts --bundle --format=esm --platform=node --outfile=tools/gen-fixtures-X.bundle.mjs && node tools/gen-fixtures-X.bundle.mjs (esbuild aus dem pnpm-Store des Vue-Repos, Pfad siehe Git-History).
  • demo/ — Simulator-Demo-App. Projekt generieren: cd demo && xcodegen generate; bauen via xcodebuild -project CocoarCalendarDemo.xcodeproj -scheme CocoarCalendarDemo -destination 'platform=iOS Simulator,name=iPhone 17 Pro' -derivedDataPath DerivedData build. Launch-Arg -demoView Woche|Monat|Agenda wählt die Start-View (scriptbare Screenshots).

Befehle

  • Tests: swift test (läuft auf macOS; Package kompiliert für iOS 26 + macOS 26).
  • Tests filtern: swift test --filter <SuiteName>.

Regeln (Projekt-Vorgaben bwi)

  • Wochenansicht responsive nur über horizontalSizeClass (einzige Lese-Stelle: WeekView.swift): compact = Wochen-Strip + eine DayColumn, regular = 7 DayColumns. Nie UIDevice/Idiom. Eine DayColumn, ein Layouter.
  • Timeline- und Year-View sind außerhalb des Scopes.
  • Theming: CalendarTheme.light (Vue-Fallbacks) + .dark (aus den vue-ui-Dark-Primitives abgeleitet, seit 2026-07-10); adaptiv via .calendarTheme(light:dark:). Neue Farben immer als Token in BEIDE Presets, nie hartkodiert in Views.
  • SwiftUI-pure (kein UIKit-Import — Package muss auf macOS kompilieren).
  • end ist überall exklusiv (RFC 5545); Sub-Sekunden-Check bei Mitternachts-Enden beachten.
  • Sortier-Tiebreaks der Layouter exakt beibehalten (start ASC, end DESC, id ASC — UTF-16-Code-Unit-Vergleich für ids), sonst driftet die Lane-Zuweisung gegenüber dem Web.
  • Gierige SwiftUI-Leaves (nacktes Color.clear, GeometryReader, minHeight-only) niemals in gepinnte/fix-hohe Bereiche — hat schon einmal das komplette Grid kollabiert.
  • Layout-Engine-Aufrufe hoisten, nie in GeometryReader-Closures oder pro Zeile neu rechnen; keine DateFormatter-Allokationen in Row-Bodies.

Verifikation

Logik-Änderungen: swift test (Fixture-Parität). UI-Kompositions-Änderungen zusätzlich im Simulator sichten (Demo-App bauen + Screenshot) — Logik-Tests sehen SwiftUI-Layout-Kollaps nicht.