Im Zuge der Masterklasse Mobile im 2.Semester habe ich ein neues Semesterprojekt umgesetzt. TripSync soll die Urlaubsplanung vereinfachen und alle wichtigen Funktionen in einer App vereinen. Im Zuge der vorgegebenen 82 h habe ich mich dabei auf die wichtigsten Funktionen und Screens fokussiert.

Screens und deren Features

Die App beinhaltet eine Authentifizierung, sodass die Funktionen erst nach dem Login bzw. der Registrierung genutzt werden können.

Profil

Hat man sich eingeloggt, kann man in seinem Profil alle seine geplanten Urlaube verwalten. Hier lässt sich einer der aufgelisteten Urlaube auswählen, der dann für alle anderen Tabs bzw. Screens gilt. Man kann einen neuen erstellen, einem beitreten oder einen löschen bzw. verlassen. Im Profil gibt es außerdem die Möglichkeit sich über das Menü wieder abzumelden.

Um einem Urlaub beizutreten, benötigt man den zugehörigen Code. Dem bzw. der Ersteller*in wird nach dem Erstellen des Urlaubs die Möglichkeit geboten, den Code mittels der „Share“-Funktion zu teilen.

Info

Auf dem Info-Screen werden alle Informationen zum aktuellen Urlaub angezeigt. Dazu gehören Titel, Zeitraum, Beschreibung und die Teilnehmer*innen. Hierbei kann man die Informationen auch bearbeiten und den Code nochmals teilen, falls man noch wen hinzufügen möchte.

Packliste

Die Packliste ermöglicht es mehreren Personen, gemeinsam eine Urlaubscheckliste zu erstellen und direkt zuzuweisen, wer was mitnimmt. Dabei gibt es oben den allgemeinen Bereich mit noch nicht zugeordneten Gegenständen und nachfolgend für jedes Mitglied einen eigenen, angefangen mit sich selbst. Es können Einträge hinzugefügt, gelöscht, in den eigenen oder in den allgemeinen Bereich verschoben und als eingepackt markiert werden.

Restliche Screens

Es soll auch noch weitere Screens bzw. Tabs geben, die beispielsweise einen Kostenrechner oder gemeinsame Notizen beinhalten. Im Zuge der 82 h wurden diese aber nicht umgesetzt.

Technologien

Backend

• NestJS
• Prisma
• Zod und zod-prisma-type für Type Generation
• Swagger
• Docker

Frontend

• React Native mit Expo
• Native Wind (Tailwind für React Native)
• Zustand für State Management
• OpenAPI Generator
• Libraries: react-native-bottom-sheet, react-native-elements, react-native-bouncy-checkbox etc.

Challenges und Learnings

Backend

Im Backend interessierte mich die Verwendung von Prisma. Dabei hat man ein zentrales Schema-File und kann sich die Types generieren lassen. Zusätzlich zu den generierten Types brauchte ich jedoch eigene DTOs, die ich mittels zod Schemas und Helper Methods umsetze. Ich habe auch auf eine ordentliche Swagger Dokumentation geachtet, sodass ich dann im Stande war, OpenAPI Generator für das Frontend zu verwenden. Es war einerseits sehr praktisch sich darum nicht kümmern zu müssen, andererseits wurde es mühsam, wenn man beispielsweise den Typ eines Objekts brauchte, welches nur innerhalb eines Arrays vorkommt. Diese stehen einem zwar auch zur Verfügung, doch die Namen werden immer länger und unleserlicher. Ich habe dann in solchen Fällen begonnen, eigene Types zu erstellen, die dann auf die generierten verweisen.

Es war anfangs eine Challenge herauszufinden, wie man bei zod Schemas Beispielwerte für Swagger mitgibt. Die Library @anatine/zod-openapi bietet hierbei mittels Methoden wie extendApi die Lösung.

Nachdem wir dieses Semester einen Docker-Workshop hatten, entschied ich mich dafür Docker auch für dieses Projekt zu verwenden und setzte erstmals alles selbst auf.

Frontend

Im Frontend musste ich mich erstmal zurechtfinden, da ich zwar bereits React verwendet hatte, aber nicht React Native. Anfangs war für mich klar, dass ich auch Native Wind einbaue, da ich sehr oft Tailwind CSS nutze. Bei Komponenten aus Libraries ist jedoch das Problem, dass viele (noch) kein Native Wind unterstützen, und somit musste ich oftmals auf gutes altes CSS zurückgreifen. Allgemein hatte ich das Gefühl, dass man bei React Native sehr oft auf Libraries der Community angewiesen ist, da React Native selbst nicht viele vorgestylte Komponenten bietet. Das ist ein Unterschied zu Ionic, den ich bemerkt habe.

Unter anderem verwendete ich das UI-Toolkit React Native Elements. Dieses kommt mit der Option, ein Theme zu erstellen, wobei neben Farben auch die default Styles der Komponenten festgelegt werden können, was sehr hilfreich war. React Native selbst bietet auch ein Color Theme, wodurch ich im Endeffekt beide nutze. Man müsste sich hier noch besser einlesen, was hierbei die Best Practice Lösung ist.

An der Kombination React Native mit Expo war sehr praktisch, dass man Änderungen mittels der Expo Go App schnell auf seinem Handy testen konnte. Das war auch sehr nötig, denn schnell wurde klar, es ist nicht so einfach die App bzw. die externen Komponenten auf jeder Plattform zum Laufen zu bringen, ohne dass unerwartete Verhaltensweisen auftreten. Manchmal gibt es auch Libraries, die nur Komponenten für iOS und Android zur Verfügung stellen, wodurch das Testen im Web schwierig wird.

Neben React Native habe ich mich im Rahmen des Projekts intensiv mit Zustand beschäftigt. Im Vergleich zu Redux ist es eine einfachere State Management Lösung, welche aber trotzdem eine Vielzahl nützlicher Features bietet. Um Logik zu trennen, habe ich meinen Store in Slices unterteilt. Zustand bietet außerdem die Funktion, den Store zu persistieren, wodurch ich manche Daten, wie z.B. den bzw. die User*in, den aktuellen Urlaub etc., zusätzlich lokal speichern konnte.

Fazit

Das Projekt hat mir vor allem einen Einblick in React Native mit Expo gegeben. Das Framework ist einerseits sehr mächtig, auf der anderen Seite können die vielen externen Komponenten mühsam werden. Ich habe aber auch viel Neues in Bezug auf Zustand und Prisma in Kombination mit zod gelernt. Auch die gesehenen Vor- und Nachteile von OpenAPI Generator werden hilfreich für weitere Projekte sein.