Feliz: Anleitung von Drittanbietern

Das sieht IMHO fantastisch aus.

Danke! Freut mich, dass es dir gefällt :smile:

Lässt sich das einfach für Inhalte von Drittanbietern wie Material-UI erweitern?

Sicher, aber der Ansatz ist etwas anders, weil wir keine diskriminierten Gewerkschaften verwenden. Ich versuche, etwas aufzuschreiben, wenn es die Zeit erlaubt, aber die Idee ist, dass Sie im Wesentlichen zwei Möglichkeiten haben:

• 1) Erweitern Sie den statischen Typ prop um weitere Funktionen
• 2) Erstellen Sie einen ähnlichen statischen Typ prop , spezifisch für Ihre Bibliothek (vielleicht Mui ), der alle Eigenschaften hat, die Mui benötigt. Sie könnten sogar prop mit Mui und Mui mit Mui-spezifischen (überladenen) Eigenschaften und Funktionen erweitern.

Erweitern ist so einfach wie:

type prop with
  static member hello (value: string) = Interop.mkAttr "hello" value 

Ob dies die "endgültige Form" der Bibliothek ist und wie sie erweitert werden kann, wird noch geprüft, da ich es zuerst ausprobieren möchte, indem ich Bibliotheken von Drittanbietern baue und sehe, wie es geht

Danke! Ich bin bereits dabei, etwas für MUI zu testen, nur für einen Bruchteil der API, um zu sehen, wie es funktioniert. Werde es wahrscheinlich irgendwann am Wochenende/-ende teilen, es wäre toll, wenn du es dir ansehen könntest, nur um zu sehen, ob ich auf dem richtigen Weg bin und dem Feliz-Spirit folge. Scheint bisher ein Erfolg zu sein!

Allerdings habe ich den bestehenden Typ prop nicht erweitert. Ich habe einen separaten prop -Typ in einem anderen Namensraum ( Feliz.MaterialUI ) definiert. Funktioniert scheinbar großartig; Sie erhalten natürlich Zugriff auf alle Mitglieder aller Matching-Typen, wenn Sie sowohl Feliz als auch Feliz.MaterialUI öffnen.

Ich habe einen Typ Mui , der Html entspricht und die eigentlichen Komponenten enthält.

(Derzeit habe ich komponentenspezifische Requisiten in separaten Untermodulen von prop platziert, wie in #13 erwähnt.)

Ein möglicher Verbesserungspunkt in Feliz ist, reactElement und createElement zu haben, die nicht string akzeptieren, sondern ReactElementType (glaube ich). damit wir createElement (importDefault "@material-ui/core/Button") anrufen können. Ich habe diese beiden Helfer derzeit selbst erstellt.

Übrigens, sollten alle Mitglieder inline sein? Was sind die Vor-/Nachteile? Mir ist aufgefallen, dass Sie oben nicht inline verwendet haben, aber alles in Feliz ist inline .

Danke! Ich bin bereits dabei, etwas für MUI zu testen, nur für einen Bruchteil der API, um zu sehen, wie es funktioniert. Werde es wahrscheinlich irgendwann am Wochenende/-ende teilen, es wäre toll, wenn du es dir ansehen könntest, nur um zu sehen, ob ich auf dem richtigen Weg bin und dem Feliz-Spirit folge. Scheint bisher ein Erfolg zu sein!

Das ist großartig! Ich würde mich auf jeden Fall freuen, wenn Sie einen Blick darauf werfen

Allerdings habe ich den bestehenden Prop-Typ nicht erweitert. Ich habe einen separaten Requisitentyp in einem anderen Namespace (Feliz.MaterialUI) definiert. Funktioniert scheinbar großartig; Sie erhalten natürlich Zugriff auf alle Mitglieder aus allen übereinstimmenden Typen, wenn Sie sowohl Feliz als auch Feliz.MaterialUI öffnen.

Ich habe einen Typ Mui, der Html entspricht und die eigentlichen Komponenten enthält.

Das würde ich für Mui tun

(Derzeit habe ich komponentenspezifische Requisiten in separaten Untermodulen von prop platziert, wie in #13 erwähnt.)

Es macht Sinn für Mui, weil Sie so viele Optionen haben

Ein möglicher Verbesserungspunkt in Feliz besteht darin, ein „reactElement“ und „createElement“ zu haben, die nicht „string“, sondern „reactelementtype“ akzeptieren (glaube ich). damit wir createElement aufrufen können (importDefault "@material-ui/core/Button"). Ich habe diese beiden Helfer derzeit selbst erstellt.

Ich überprüfe die Mitglieder, die ich im Interop -Modul verwende. Ich habe gerade alles offengelegt, was ich in der Bibliothek verwendet habe, und es wird für die stabile Version überarbeitet

Übrigens, sollten alle Mitglieder inline sein? Was sind die Vor-/Nachteile? Mir ist aufgefallen, dass Sie oben nicht Inline verwendet haben, aber alles in Feliz ist Inline.

Ich hätte das erweiterte Mitglied oben einfügen sollen!

Die Faustregel lautet: Wenn der Wert der Eigenschaft primitiv ist wie ein String/int/bool/enum, dann fügen Sie die Eigenschaft ein, aber wenn Ihre Eigenschaft einen Wert basierend auf der Eingabe berechnet, ist es besser, ihn nicht einzufügen, da der Benutzer jedes Mal die Inline-Funktion aufruft, wird der gesamte Funktionsrumpf an dieser Stelle des Aufrufs eingebunden. Wenn ein Benutzer dieselbe Funktion also zehnmal in der gesamten Anwendung verwendet, wird der Funktionsrumpf zehnmal inline kompiliert, anstatt einmal definiert und zehnmal referenziert zu werden

Die Faustregel lautet: Wenn der Wert der Eigenschaft primitiv ist wie ein String/int/bool/enum, dann fügen Sie die Eigenschaft ein, aber wenn Ihre Eigenschaft einen Wert basierend auf der Eingabe berechnet, ist es besser, ihn nicht einzufügen, da der Benutzer jedes Mal die Inline-Funktion aufruft, wird der gesamte Funktionsrumpf an dieser Stelle des Aufrufs eingebunden. Wenn ein Benutzer dieselbe Funktion also zehnmal in der gesamten Anwendung verwendet, wird der Funktionsrumpf zehnmal inline kompiliert, anstatt einmal definiert und zehnmal referenziert zu werden

Gut zu wissen! Aber (im Zusammenhang mit Fable) warum dann überhaupt Inline? Was ist der Vorteil für die "einfachen" Funktions-/Methodenkörper?

• Bundle-Größe: Wenn diese Funktionen nicht verwendet werden (und es gibt Hunderte davon), werden sie trotzdem kompiliert, was die Bundle-Größe AFAIK aufbläht (die Auswirkungen sind natürlich immer noch relativ zur Gesamtgröße der Anwendung).
• Generische Typargumente: irrelevant für Feliz, aber im Kontext von Fable wird eine generische Funktion mit generischen Typargumenten nicht kompiliert, wenn der Ort des Aufrufs nicht inline ist (alle generischen Typargumente müssen zur Kompilierzeit statisch aufgelöst werden), außer in Sonderfällen wo Sie [<Inject>] ITypeResolver<'t> als optionales Argument einer statischen Klasse verwenden können (nur hochspezialisierte Bibliotheken verwenden diese Funktion, siehe Fable.SimpleJson/Thoth.Json)

Ich denke, babel macht Tree-Shaking und entfernt ungenutzte Funktionen, wenn Sie das Produktionspaket erstellen. Inlining würde das besiegen.

@Luiz-Monad Willst du damit sagen, dass im Idealfall nichts in Feliz inliniert werden sollte? Dass Inlining aus Gründen der Bündelgröße kontraproduktiv ist?

@Luiz-Monad Was du sagst, wäre großartig! Zumindest wenn das Kompilieren so funktionierte. Hier ist ein Beispiel, das Sie mit REPL ausprobieren können:

module App

type prop = 
  // does useless stuff
  static member f() = 
    [ 1 .. 100 ]
    |> List.map (fun x -> x * 20)
    |> List.collect (fun n -> [n; n])
    |> List.fold (+) 0

  // does useless stuff
  static member inline k() = 
    [ 1 .. 100 ]
    |> List.map (fun x -> x * 20)
    |> List.collect (fun n -> [n; n])
    |> List.fold (+) 0

  static member g() = 1

let value = prop.g()

printfn "%d" value

Wobei prop enthält:

• f() enthält einen Funktionskörper -> nicht inline und auch nicht verwendet
• k() enthält einen Funktionskörper -> Inline, aber nicht verwendet
• g() enthält eine Funktion -> nicht inline und verwendet

Sie würden denken, dass sowohl f() als auch g() nicht kompiliert werden, aber das ist nicht der Fall, f() (nicht inline und nicht verwendet) wird trotzdem kompiliert, aber k() (inlined, nicht verwendet) schafft es nicht in das kompilierte Bundle

import { fold, collect, map, ofSeq, ofArray } from "fable-library/List.js";
import { type } from "fable-library/Reflection.js";
import { rangeNumber } from "fable-library/Seq.js";
import { toConsole, printf } from "fable-library/String.js";
import { declare } from "fable-library/Types.js";
export const prop = declare(function App_prop() {});
export function prop$reflection() {
  return type("App.prop");
}
export function prop$$$f() {
  return fold(function folder(x$$1, y) {
    return x$$1 + y;
  }, 0, collect(function mapping$$1(n) {
    return ofArray([n, n]);
  }, map(function mapping(x) {
    return x * 20;
  }, ofSeq(rangeNumber(1, 1, 100)))));
}
export function prop$$$g() {
  return 1;
}
export const value = prop$$$g();
toConsole(printf("%d"))(value);

Es funktioniert tatsächlich, aber Sie müssen dafür webpack konfigurieren, denn das, was das Tree-Shaking bewirkt, ist nicht fabelhaft, also funktioniert es nicht in der REPL.

Vor

/// Library.fs
module Library

type prop = 
    // does useless stuff
    static member f() = 
      [ 1 .. 100 ]
      |> List.map (fun x -> x * 20)
      |> List.collect (fun n -> [n; n])
      |> List.fold (+) 0

    // does useless stuff
    static member inline k() = 
      [ 1 .. 100 ]
      |> List.map (fun x -> x * 20)
      |> List.collect (fun n -> [n; n])
      |> List.fold (+) 0


type AppMain =
    static member g() = 1

//// App.fs
module App

let value = Library.AppMain.g ()

printfn "%d" value

Nach dem

  declare(function Library_prop() { 
     // see its empty, this weren't removed too because of `keep_classnames: true, keep_fnames: true ` in the terser plugin
  });
  declare(function Library_AppMain() {
  });
  !function toConsole(arg) {
    return arg.cont(function (x) {
      console.log(x)
    })
  }(printf('%d')) (1),
  __webpack_require__.d(__webpack_exports__, 'value', function () {
    return 1
  })

Außerdem gibt es einen Vorbehalt für Ihren Test, die Eintragsdatei ist insofern etwas Besonderes, als Funktionen daraus nicht entfernt werden. (Ich denke, es hat etwas mit der Initialisierung statischer Klassen zu tun, etwas muss den statischen Initialisierungskonstruktor aufrufen, um Nebeneffekte auf die Module auszuüben.)

Siehe dieses Repository, das ich für diesen Test erstellt habe https://github.com/Luiz-Monad/test-tree-shaking

Vielen Dank für das Beispiel-Repo! Ich werde dies auf jeden Fall weiter untersuchen, um zu sehen, ob Inlining im Kontext von Feliz tatsächlich etwas Nützliches bewirkt

Ich werde dies auf jeden Fall weiter untersuchen, um zu sehen, ob Inlining im Kontext von Feliz tatsächlich etwas Nützliches bewirkt

Cool, bin gespannt was du findest :)

Das ist großartig! Ich würde mich auf jeden Fall freuen, wenn Sie einen Blick darauf werfen

Bitte sehen Sie sich den feliz -Zweig auf cmeeren/fable-elmish-electron-material-ui-demo an .

Der Großteil des Codes wird basierend auf den (HTML) API-Dokumenten automatisch generiert. Es gibt ein Generatorprojekt (hässlich und hackig, aber erledigt die Arbeit) und ein Projekt für die eigentlichen Bindungen. Im Renderer-Projekt wurde nur App.fs konvertiert, um die neuen Bindungen im Feliz-Stil zu verwenden.

Bitte schauen Sie es sich an, wenn Sie Lust dazu haben, und lassen Sie mich wissen, was Sie denken und wenn Sie Fragen haben.

@cmeeren Sieht sehr gut aus und viel besser als die aktuelle API IMHO, aber es ist immer noch ein bisschen schwer zu lesen, aber das liegt eher an der Natur der Bibliothek selbst, sie hat viele sehr spezifische Teile, mit denen Sie vertraut sein müssen. Ich denke, es gibt Teile, die verbessert werden könnten, nehmen Sie dieses Beispiel:

Mui.appBar [
  prop.className c.appBar
  prop.appBar.position.fixed'
  prop.children [
    Mui.toolbar [
      prop.children [
        Mui.typography [
          prop.typography.variant.h6
          prop.typography.color.inherit'
          prop.text (pageTitle model.Page)
        ]
      ]
    ]
  ]
]

Meine persönliche perfekte Version dieses Schnipsels wäre, es wie folgt umzuwandeln:

Mui.appBar [
  AppBar.className c.appBar
  AppBar.position.fixed'
  AppBar.children [
    Mui.toolbar [
      Toolbar.children [
        Mui.typography [
          Typography.variant.h6
          Typography.color.inherit'
          Typygraphy.text (pageTitle model.Page)
        ]
      ]
    ]
  ]
]

Auf diese Weise ist es einfach, Mui-Elemente zu finden, da Sie Mui einfach "durchpunktieren" können und sobald Sie Ihr Element gefunden haben ( appBar ), können Sie den Modulnamen "durchpunktieren" ( AppBar ). um die Eigenschaften zu definieren und so

Vielleicht behalten Sie auch AppBar in Kleinbuchstaben bei

Ich denke, Sie haben die Idee, aber um genauer zu sein, lautet die allgemeine Syntax dieser API wie folgt, wobei {Element} ein React-Element ist:

Mui.{element} [
  {Element}.{propName}.{propValue}
  {Element}.children [
    Mui.{otherElem} [
      {OtherElem}.{propName}.{propValue}
      // etc.
    ]
  ]
]

Was denkst du darüber? Diese API inspirierte auch die Bibliothek zu den Ideen von fabelhaften-einfachen-Elementen, wenn Sie eine konkrete Implementierung sehen möchten

Ich denke, das ist perfekt und genau das, wozu ich Ihre Meinung wissen wollte. Ich habe mich ursprünglich dafür entschieden, alles unter prop zu haben, da die Hauptbibliothek so funktionierte, aber natürlich gibt es nicht wirklich komponentenspezifische Props, während MUI mehr mehr weniger nur komponentenspezifische Props hat.

Ich denke, es sieht am besten aus, sich an Modulnamen in Kleinbuchstaben zu halten (und spart einen zusätzlichen Tastendruck), aber ich bin offen für Gegenargumente.

Gut, dass ich dieses Zeug automatisch generiert habe, das macht es einfach, es zu ändern.

Ich werde aktualisieren und Sie wissen lassen.

Es gibt jedoch eine Sache, zu der ich gerne Meinungen einholen möchte. Es ist das ClassName Zeug. Der makeStyles -Hook gibt ein Objekt mit den gleichen Props zurück wie das, an das es übergeben wurde, aber wo jedes (JSS-)Element durch eine Zeichenfolge ersetzt wurde, die der zu verwendende Klassenname ist (und an z prop.className ).

Nun, es gibt keine Möglichkeit, das in F# einzugeben, also muss ich mit dem arbeiten, was ich habe. Normalerweise sind alle Requisiten des Style-Objekts IStyleAttribute list . Das bedeutet, dass ich eine Überladung für prop.className hinzufügen kann, die IStyleAttribute list akzeptiert, was natürlich eine Lüge ist, da es sich zur Laufzeit um einen String handelt. Wenn Sie es tatsächlich bestanden hätten, IStyleAttribute list würde es fehlschlagen. Neben prop.className gilt dies auch für alle classes.<element>.<classesName> (verwendet in <element>.classes [ ... ] ). Sie akzeptieren auch einen Klassennamen (String).

Was ich getan habe, wie Sie sehen können, ist, dass alle IStyleAttribute list -Eigenschaften des Stilobjekts in asClassName eingeschlossen werden müssen, was im Grunde nur zu IClassName entpackt wird (ein Proxy für string , wenn Sie möchten). Und dann habe ich prop.className eine Überladung hinzugefügt, die IClassName #$ akzeptiert, und dafür gesorgt, dass alle classes Props IClassName akzeptieren. Ich mag es, dass es stärker typisiert ist, aber ich mag es nicht, dass es zusätzliche Eingaben erfordert ( asClassName für jede CSS-Regel der obersten Ebene). Der Compiler wird sich beschweren, wenn Sie es verpassen, aber er wird Ihnen nicht sagen, was zu tun ist, und es ist immer noch zusätzliches Rauschen.

Haben Sie dazu einen Beitrag?

Außerdem ist mir das aufgefallen:

f# listItem.divider ((page = Home))

Hier sind doppelte Klammern erforderlich, da F# es sonst so interpretiert, als würde es versuchen, listItem.divider mit dem (nicht vorhandenen) Parameter page aufzurufen, der auf Home (anstelle von value Parameter auf page = Home gesetzt). Sehen Sie eine Möglichkeit, das zu vermeiden?

Hallo @cmeeren , zuallererst liebe ich diese Syntax:

Mui.appBar [
  prop.className c.appBar
  appBar.position.fixed'
  appBar.children [
    Mui.toolbar [
      toolbar.children [
        Mui.typography [
          typography.variant.h6
          typography.color.inherit'
          prop.text (pageTitle model.Page)
        ]
      ]
    ]
  ]
]

Es sieht einfach so sauber und so einfach aus! Obwohl ich an Ihrer Stelle wahrscheinlich einige der generischen prop -Funktionen in komponentenspezifische Requisiten wie appBar.className anstelle von (oder neben) prop.className dupliziert hätte, so dass Sie sehen alle symmetrisch aus, aber noch wichtiger ist es, der Mui-spezifischen Komponente die IClassName -Überladung zu geben, anstatt dem generischen prop.className , das einen String akzeptiert, weil makeStyles auch Mui-spezifisch ist konstruieren und es macht Sinn, dass es nur für Mui-Komponenten gilt.

Ich denke, Sie haben die makeStyles so gut wie möglich angegangen, zumindest fällt mir jetzt kein besserer Weg ein (obwohl ich kein großer Fan von asClassName bin, vielleicht Styles.createClass statt? es liegt an Ihnen).

Was listItem.divider ((page = Home)) betrifft, ist es schwierig, Sie könnten eine Dummy-Funktion let when (x: bool) = x hinzufügen, aber das ist nur Lärm. Ich denke, es ist am besten, es als Compilerfehler einzureichen, da ich mir keinen Grund vorstellen kann, warum der F#-Compiler die richtige Überladung der Funktion nicht auflösen kann. Ich habe es nicht selbst versucht, aber ich werde es untersuchen, wenn es die Zeit erlaubt

Schließlich bin ich diese Woche nicht so reaktionsschnell wie sonst, weil ich jetzt im Urlaub bin, also kann ich vielleicht nicht alles lesen/prüfen etc.

Obwohl ich an Ihrer Stelle wahrscheinlich einige der generischen prop -Funktionen in komponentenspezifische Requisiten wie appBar.className anstelle von (oder neben) prop.className dupliziert hätte, so dass Sie sehen alle symmetrisch aus, aber noch wichtiger ist es, der Mui-spezifischen Komponente die IClassName -Überladung zu geben, anstatt dem generischen prop.className , das einen String verwendet, weil makeStyles auch Mui-spezifisch ist konstruieren und es macht Sinn, dass es nur für Mui-Komponenten gilt.

Schau es dir jetzt an :) Ich habe in den letzten Tagen drastische Verbesserungen und Erweiterungen vorgenommen, nur gepusht (nicht fertig, ich gehe derzeit alle MUI-Komponenten durch, um die generierten Props zu überprüfen und zu verbessern).

Ich denke, Sie haben die makeStyles so gut wie möglich angegangen, zumindest fällt mir jetzt kein besserer Weg ein (obwohl ich kein großer Fan von asClassName bin, vielleicht Styles.createClass statt? es liegt an Ihnen).

Ich möchte es so kurz wie möglich halten, da es viel verwendet wird, aber ich bin offen für andere Namen. Obwohl ich halbwegs daran denke, nur eine IStyleAttribute list -Überlastung zu haben. Es wird möglicherweise ziemlich viel Rauschen entfernen, und ich bezweifle, dass es sehr gefährlich sein wird, selbst wenn es technisch falsch verwendet werden kann.

Was listItem.divider ((page = Home)) betrifft, ist es schwierig, Sie könnten eine Dummy-Funktion let when (x: bool) = x hinzufügen, aber das ist nur Lärm. Ich denke, es ist am besten, es als Compilerfehler einzureichen, da ich mir keinen Grund vorstellen kann, warum der F#-Compiler die richtige Überladung der Funktion nicht auflösen kann. Ich habe es nicht selbst versucht, aber ich werde es untersuchen, wenn es die Zeit erlaubt

Danke, ich habe jetzt ein Problem gemeldet: https://github.com/dotnet/fsharp/issues/7423

Schließlich bin ich diese Woche nicht so reaktionsschnell wie sonst, weil ich jetzt im Urlaub bin, also kann ich vielleicht nicht alles lesen/prüfen etc.

Erwischt, kein Problem. Ich werde weiterhin Probleme posten, wenn ich auf Dinge stoße, und Sie antworten einfach in Ihrer eigenen Zeit.

Schau es dir jetzt an :) Ich habe in den letzten Tagen drastische Verbesserungen und Erweiterungen vorgenommen, nur gepusht (nicht fertig, ich gehe derzeit alle MUI-Komponenten durch, um die generierten Props zu überprüfen und zu verbessern).

Sieht wirklich gut aus, auch mit den generierten Dokumenten 😍 Vielleicht ist es an der Zeit, ein eigenes Repo einzubauen?

Ich möchte es so kurz wie möglich halten, da es viel verwendet wird, aber ich bin offen für andere Namen. Obwohl ich halbwegs daran denke, nur eine IStyleAttribute-Listenüberladung zu haben. Es wird möglicherweise ziemlich viel Rauschen entfernen, und ich bezweifle, dass es sehr gefährlich sein wird, selbst wenn es technisch falsch verwendet werden kann.

Das würde auch funktionieren, Fable-Bibliotheken betrügen die ganze Zeit das Typsystem ;)

Danke, ich habe jetzt ein Problem gemeldet: dotnet/fsharp#7423

Fantastisch! Vielen Dank

Sieht wirklich gut aus, auch mit den generierten Dokumenten 😍 Vielleicht ist es an der Zeit, ein eigenes Repo einzubauen?

Ich habe darüber nachgedacht, aber es gibt immer noch ein paar wichtige Fehler (z. B. #27), die ich lieber mit der Bequemlichkeit herausfinden würde, alles am selben Ort zu haben, also denke ich, dass ich es dort lassen werde, bis es fertig ist für eine Vorabveröffentlichung auf nuget (wird hoffentlich nicht zu lange dauern).

@Zaid-Ajaj Ich bin gerade fertig mit Feliz.MaterialUI. Wird bald in einem separaten Repo veröffentlicht. Es wäre großartig, wenn Sie es überprüfen würden, in erster Linie, um einige Designentscheidungen zu überprüfen und die Konsistenz mit Feliz sicherzustellen, aber auch, um einige Implementierungssachen zu überprüfen (z. B. verwende ich Dinge, die Sie intern machen, oder gibt es Dinge, die ich verwende nicht von Feliz, sollte aber verwenden).

Ist es in Ordnung, wenn ich beim Erstellen des neuen Repositorys Probleme erstelle, in denen ich erkläre, was ich überprüfen möchte, und Sie tagge?

Ich habe jetzt einen Entwurf von Feliz.MaterialUI nach cmeeren/Feliz.MaterialUI hochgeladen . Ich habe mehrere Probleme mit Dingen erstellt, die ich überprüfen möchte.

Ich wäre Ihnen sehr dankbar, wenn Sie die Zeit finden könnten, sie sich anzusehen!

Es ist nicht nötig, viel Zeit für jedes Thema aufzuwenden; Ich möchte wirklich nur eine zweite Meinung aus den in meinem vorherigen Kommentar genannten Gründen. Ich gehe gerne ins Unkraut, wenn Sie möchten, aber auch nur "das sieht gut aus" wäre großartig.

Es besteht natürlich keine Eile. :)

Tolle Arbeit @cmeeren! Auf den ersten Blick sehen die Einbände sehr sauber aus, ich werde mir in den nächsten Tagen jede Ausgabe anschauen, versprochen :smile:

Hey! Besteht die Möglichkeit, sich weiter mit den Problemen zu befassen? Wieder keine Eile, nur eine freundliche Erinnerung, da ich seit ein paar Wochen nichts mehr von dir gehört habe 😃

Ich habe mir die Probleme tatsächlich angesehen, aber wie ich bereits sagte, ob eine API gut ist oder nicht, kommt von Anwendungsfällen, deshalb habe ich Sie gebeten, eine Alpha-Version zu veröffentlichen, damit ich sie ausprobieren kann, aber ich hatte keine Zeit dafür noch (es war diese Woche im Hinterkopf :smile:)

Hallo @cmeeren , ich denke, wir können das als gelöst betrachten, oder? Ich werde das Thema schließen, bitte öffnen Sie es für weitere Diskussionen bei Bedarf erneut