Arrow 1.2.0-RC ist jetzt verfügbar

Wir freuen uns, Arrow 1.2.0-RC zusammen mit einer neuen Arrow-Website ankündigen zu können. Diese Version führt ein brandneues Modul für Tippfehler ein und bietet mehr Optionen für die Ausfallsicherheit.

Auch auf dem Weg zu 2.0 kommen wir voran: Wir haben jede Funktion und jeden Typ, den wir zu entfernen beabsichtigen, als @Deprecated markiert, um vor der tatsächlichen Entfernung Anregungen aus der Community zu sammeln. Beachten Sie, dass diese Entscheidungen noch nicht endgültig sind. Eines unserer Ziele bei der 1.2.x-Serie ist es, Anregungen aus der Community zu sammeln, und wir freuen uns sehr, wenn Sie uns mitteilen, wie sich diese Änderungen auf Ihre Projekte auswirken.

Neue Website

Die Arrow-Website ist in den letzten Jahren organisch gewachsen. Die dortige Dokumentation war ziemlich vollständig, aber manchmal schwer zu finden. Die Annäherung von Arrow an die Version 2.0 war ein guter Zeitpunkt, um die Website zu aktualisieren, mit dem doppelten Ziel, Erstbenutzern den Einstieg in das Ökosystem zu erleichtern und gleichzeitig Power-Usern einen schnellen Zugang zu den Informationen zu ermöglichen, die sie benötigen.

Das Ergebnis ist eine brandneue Arrow-Website mit einem starken Fokus auf Anleitungen und Tutorials. Wir haben auch die API-Dokumente aufgefrischt, die direkte und prägnante Informationen bieten. Das Team von Xebia Functional hat uns mit einem neuen modernen, schlanken Design unterstützt.

Die neue Website wird in aller Öffentlichkeit entwickelt. Wenn Sie Ideen, Vorschläge oder Probleme haben, würden wir uns freuen, von Ihnen zu hören (oder eine PR zu veröffentlichen). Insbesondere, wenn Sie Arrow in Ihrer täglichen Arbeit oder in einem Nebenprojekt verwenden, sammeln wir Beispiele und Anwendungsfälle, die anderen Entwicklern den Einstieg in Arrow erleichtern können.

Tippfehler

Typisierte Fehler sind die wichtigste technische Neuerung in dieser Arrow-Version. Unter diesem abstrakten Namen verweisen wir auf einen neuen Ansatz für die Arbeit mit Fehlertypen, der unsere bisherigen Berechnungsblöcke und die Effect/EagerEffect Typen ersetzt.

Wenn Sie bereits either, result oder eine andere Art von Berechnungsblöcken verwenden, sollten Sie sich mit typisierten Fehlern vertraut machen. Innerhalb eines dieser Blöcke haben Sie die Möglichkeit, raise Fehler oder andere möglicherweise fehlerhafte Berechnungen mit bind einzubetten.

fun validPerson(name: String, age: Int): Either<UserProblem, User> = either {
  ensure(name.isNotEmpty()) { UserProblem.EmptyName }
  val validatedAge = validAge(age).bind()
  User(name, validatedAge)
}

Wir haben die Schnittstelle für die Fehlerakkumulation verbessert, die nun keine unterschiedlichen Typen mehr erfordert (wie bei Either und Validated in der Vergangenheit). Sie können mapOrAccumulate und zipOrAccumulate in jedem Block verwenden, um vom Fail-Fast-Modus "wegzuschalten".

fun validPerson(name: String, age: Int): Either<NonEmptyList<UserProblem>, User> = either {
  zipOrAccumulate(
    { ensure(name.isNotEmpty()) { UserProblem.EmptyName } },
    { validAge(age).bind() }
  ) { validName, validAge-> User(validName, validAge) }
}

Die Dichotomie zwischen "eifrigen" und "regulären" Effekten ist in dem neuen Framework für typisierte Fehler ebenfalls verschwunden. Dieselbe API funktioniert sowohl für suspended als auch für nichtsuspended Szenarien.

Mehr Widerstandsfähigkeit

Das Resilience-Modul bietet jetzt Unterstützung für Sagas. Sagas behandeln den Fall, dass mehrere Operationen, die sich über verschiedene Microservices erstrecken, als Einheit erfolgreich sein oder fehlschlagen müssen, da sonst ein inkonsistenter Zustand entstehen könnte. Dies wird erreicht, indem für jede Operation eine kompensierende Aktion deklariert wird. Im folgenden Beispiel versuchen wir, einen Zähler zu erhöhen, ihn aber zu verringern, wenn die Operation fehlschlägt.

saga({
  Counter.increment()
}) {
  Counter.decrement()
}

Ähnlich wie bei Arrow mit Resource garantiert die Implementierung, dass kompensierende Aktionen ausgeführt werden, wenn es die Regeln der strukturierten Gleichzeitigkeit erwarten lassen.

Wir planen, unsere Anstrengungen an dieser Front zu verdoppeln. Wir haben die Resilience-Typen in ein neues arrow-resilience Modul ausgelagert, das uns mehr Freiheit gibt, schneller zu iterieren als der Rest von Arrow, für den Stabilität ein Muss ist.

Der Weg zu 2.0

Arrow 1.2.0 legt alle Arbeiten fest, um Ihnen den Umstieg auf die bevorstehende Version 2.0 zu erleichtern. Wir haben jede Funktion, die wir in der neuen Hauptversion entfernen wollen, als @Deprecated gekennzeichnet. In den meisten Fällen bieten wir direkte Ersetzungen mit ReplaceWith, was zu schnellen Korrekturen in IDEs wie IntelliJ führt, und für globalere Änderungen stellen wir OpenRewrite-Skripte zur Verfügung. Alles wird in der Migrationsanleitung für diese Version erklärt. Wenn Ihr Code ohne Verwerfungswarnungen in 1.2.0 kompiliert werden kann, sollte er vollständig quellkompatibel mit 2.0 sein.

Um einen Überblick über die wichtigsten Verwerfungen zu geben:

• Validated wird ersetzt, um einen einzigen Either Typ zur Darstellung logischer Fehler zu haben. Die Fehlerakkumulationsfunktionen in Validated wurden in mapOrAccumulate und zipOrAccumulate zusammengefasst.
• Der Mechanismus für typisierte Fehler ersetzt effect und Berechnungsblöcke.
• Wir haben die Verkleinerung der API-Oberfläche vieler Typen fortgesetzt. Ein wichtiges Beispiel ist traverse, das zugunsten der Verwendung von map innerhalb eines typisierten Fehlerblocks veraltet ist.
• Semigroup und Monoid verlassen uns in Arrow 2.0 ebenfalls. Wir haben uns entschlossen, uns der Kotlin-Praxis anzupassen und das leere Element und die Kombinationsfunktion als Parameter zu verwenden, wie in fold.

Wir bekräftigen, dass wir eine verlängerte Gnadenfrist planen, bevor Arrow 2.0 veröffentlicht wird. Wir haben zu diesem Zeitpunkt keinen festen Zeitplan, da einige der kommenden Änderungen in Kotlin selbst die Richtung weiter beeinflussen könnten. Während dieser Zeit werden wir weiterhin Module der Serie 1.2.x veröffentlichen, um Probleme zu beheben, die API zu verbessern und den Migrationsprozess weiter zu unterstützen.

Xebia Kotlin

Wir, das funktionale Team bei Xebia, sind große Fans von Kotlin und erforschen die vielen Möglichkeiten, die es für die Backend-Szene bietet. Wir sind stolze Betreuer von Arrow, einer Reihe von Begleitbibliotheken zu Kotlins Standardbibliothek, Coroutines und Compiler, und bieten Kotlin-Schulungen an, um Kotlin-Experten zu werden. Wenn Sie mit uns sprechen möchten, können Sie unser Kontaktformular verwenden oder uns auf dem Kotlin Slack folgen.