In pg gibt es ein setting welches nicht in den docs oder den types dokumentiert ist, das aber dafür sorgt das text richtig encodiert wird.
const client = new Pool({
connectionString: process.env.DATABASE_URL,
// required in oder to make utf8 work
client_encoding: "utf8",
} as ClientConfig & {
client_encoding: string;
})Das Issue das mich darauf gebracht hat ist:
https://github.com/brianc/node-postgres/issues/906Links zu Karten oder Websites die beschreiben was mit den verlinkten Worten gemeint ist
Funktion um Karten in einem Konsistenten muster und nach Wahl mit einem Formular zu erstellen.
In Clye gibt es keine Ordner, wie man sie gewohnt ist. Das sorgt aber nicht dafür das in Clye ein Kartenchaos herrschen muss, stattdessen erlaubt und unterstützt Clye dabei Karten sinnvoll zu organisieren.
Unser Gehirn denkt nicht in Ordnern, In Ordnersystemen ist es nicht immer eindeutig wo Daten liegen, Anpassung einer Ordnerstruktur oft nicht möglich
Kurz zusammengefasst, Ordner funktionieren nur wenn beim Ablegen genau klar ist wie die Informationen genau gefunden werden sollen, z.B. ich Brauche Rechnungen für Buchhaltung also lege ich sie in Buchhaltung ab. Ändert sich das jedoch, oder gibt es mehrere mögliche Szenarien in der Zukunft, oder weiß nicht jeder bescheid oder passen die Berechtigungen nicht oder ... , sind Ordner eher suboptimal.
Im großen und ganzen helfen in Clye vor allem Indexkarten, Clye-Tags und Definitionslinks. Die Grundidee von Clye ist es alles in möglichst kleinen sich selbst beschreibenden Karten zu speichern. Das bedeutet eine Karte sollte Links zu allen Informationen haben die nötig sind um die Karte zu Verstehen. Beim Schreiben überlegt man, ob irgend eine beliebige Person verstehen könnte was mit der Karte gemeint ist. Wenn nicht, definiert man die potentiell unklaren Wörter. Dabei unterstützt auch Clye automatisch und es entwickelt sich eine Art Wörterbuch, das Clye, AI und anderen Nutzern hilft alles zu verstehen und sinnvol zu strukturieren.
Ein Beispiel wäre eine Karte über ein Buch. Damit klar ist das es sich um ein Buch handelt kann der Clye-Tag Buch gesetzt werden. Damit kann man darüber direkt alle Bücher finden die in Clye gespeichert sind. Außerdem können Informationen über das Buch wie der Autor direkt in dieser Karte erfasst und verlinkt werden. Das erlaubt das Auffinden des Buches anhand des Autors.
Möchte man nun alle Karten die man gelesen hat gruppieren, ist das eine andere Information die nicht das Buch beschreibt (ist ja keine Eigenschaft des Buches, dass es von dir gelesen wurde) sondern sollte auf einer eigenen Karte "Bücher die ich gelesen habe" verlinkt werden. Diese Karte nennt man Indexkarte, da ihr Zweck das Verlinken zu anderen Karten ist.
Um nun Karten effektiv finden zu können geht das am einfachsten über die entsprechende Karte. Alle relevanten Karten werden dann darunter aufgelistet. Es ist außerdem möglich alle Verlinkungen zu dieser Karte in Backlinks zu sehen. Somit sieht man einfach, wenn das Buch z.B. auch in der Liste eines Kollegen ist.
Generell Nutzt man in Clye vor allem die Suche und Filter und speichert/teilt gegebenenfalls Indexkarten die zu filtern oder speziellen Karten zeigen um die Organisation zu behalten. Ist ein bestimmtes Kartenformat gewünscht können auch Vorlagen benutzt werden, die außerdem alle damit erstellten Karten gruppieren und auch als komplette Formulare genutzt werden können.
Komponente die URL und browser history verwaltet und das Rendern davon abhängiger views ermöglicht
Wenn man Next.js nutzt handelt nextjs in der Regel alle Interaktionen mit der history dank des App-Routers. Leider ist dieser immernoch recht beschrenkt in was dieser darstellen kann und bei jeder Änderung der Seite wird ein Request an das Backend gemacht. Das ist gut und nötig wenn es sich um herkömmliche Websitest handelt. Stört jedoch bei Webapps die offline und sowieso nur Clientseitig laufen sollen.
Glücklicherweise ist es jedoch möglich einen eigenen Router zu nutzen und damit Next.js komplett außenvor zu lassen. Dabei kann dieser direkt die History-API benutzen und auch entsprechend auf diese reagieren. Wichtig ist jedoch das für diese Verhalten keine next links und nicht die next/navigation api benutzt werden können und statdessen die des eigenen Routers verwendet werden muss.
Häufig schlägt typescript radix-ui vor obwohl man doch selber die Komponenten überschrieben hat, oder man bekommt empfehlungen aus irgend welchen Paketen, obwohl man eigentlich fast nur bestimmte benötigt. All das lässt sich mit einem Typescript plugin lösen. Deises ist schon als default sehr gut für shadcn-ui, kann aber auch für viele andere Szenarien angepasst werden.
https://github.com/tidalhq/ts-plugin-sort-import-suggestionsDrauf gestoßen bin ich über ein Github Issue https://github.com/microsoft/TypeScript/issues/51155
Wichtig ist eine Karte sollte immer selbsterklärend sein. Das bedeutet, wenn eine Karte z.B. eine Aufgabe erklärt, dann sollte man zur ausführung der Karte lediglich Informationen benötigen die auf der Karte verlinkt sind.
Indexkarten und damit einher gehend Kanbans hingegen bieten weiter Organisationsebenen die weitere Informationen dazu umfassen wie z.B. wer es machen soll oder wann es gemacht werden soll... Jedoch sollten diese z.B. nicht genutzt werden um zu Sagen das es um die Seitenleiste geht, da diese Information in der Karte vorhanden sein sollte und damit implizit zugänglich ist
Eine Karte, die als Inhaltsverzeichnis dient und auf andere Karten verweist. Damit erfüllt eine Indexkarte einen ähnlichen Zweck wie in anderen Systemen Hashtags, Ordner oder Kategorien.
Zusätzlich bieten Karten jedoch den Vorteil, dass man eine genauere Beschreibung der verlinkten Inhalte und dem eigentlichen Sinn der Gruppierung hinterlegen kann.
Hinzu kommen dann noch die üblichen Karten-Features wie: flexibles teilen der Austausch per Kommentar