Skip to content

TODO List 1. 📈 Sprint

Jump to bottom
linusha edited this page Apr 25, 2023 · 1 revision

Lively TODOs

  • Testing
    • Alle tests grün
    • CI server / Github Actions (Puppeteer/lively.headless)
    • Neue Tests schreiben für tools und components
  • Dokumentation
    • Github action die JS docs generiert
    • Dokumentation von core modules vervollständigen
      • lively.lang Docsstring Progress
        • functions - Robin
        • numbers - Linus
        • arrays - Linus
        • graph - Robin
        • properties - Robin
        • promise - Robin
        • object - Robin
        • string - Robin
    • Tutorials in Markdown (evt. verbinden mit js docs)
    • Irgendwann dann mal interaktive explaination
    • lively.next website neu machen (Projekt, History, Call for Funding, Examples, Tutorials, Documentation)
  • Modules
    • SystemJS durch neue version ersetzen
    • BabelJS aktualisieren und oder rausnehmen (TBD)
    • Module refresh bugs lösen. (Im detail anaylsieren)
    • Flatn eleminieren bzw. gucken warum wirs noch brauchen? Refactoring?
    • Lokalen ESM-CDN subserver einrichten, der die abhängigkeit zu jspm.dev eleminiert
    • Eliminate 3rd party deps (as much as possible)
    • Separate custom lively transform stuff (class transforms) and scope capturing transformations.
    • Introduce custom lv.js files (maybe replace cp.js?) that explicitly denote support for custom lively class transforms. This custom class transform will be supporting the decorator syntax for property definitions that complement the serializer. However class to function transform still universally required for proper module hot swapping and interoperability.
  • Build System
    • Support für build aus der bash (universal build script) Als Rollup Plugin!
    • Spagetti code im freezer refactoren
    • Ladegeschwindigkeit verbessern (Frozen lively bundle mit module hot swap injection points)
  • Tooling
    • GIT client verbessern: Evt. node.js pkg (was auch git kraken verwendet) benutzen um insbesondere eine leicht zugänglichere UI für das ein und auschecken von changes und branch management zu implementieren.
    • Docker Compose schreiben für zuverlässiges Entwicklen unter Win/Linux/MacOS
  • Morphic
    • Text rendering fixen
    • Text layout bugs fixen
    • Line numbers zu text hinzufügen
    • VDOM raus (CSS layout probleme fixen)
    • Canvas rendering support ausbauen
    • SVG editing support verbessern
    • Styleguide Worlds durch component file definitionen ersetzen
    • Allow to force hover, click and dark/light mode for policies (meta programming but useful for hacking and toolbuilding)
    • Move comments out of morphic and place them into lively.ide/world.js (or the comments morph entirely).
  • User System / Security

Weiterentwicklung der Component Architecture:

  • Custom Properties ermöglichen, die via ViewModel implementiert und dann via side bar kontrolliert werden können. Wie sieht das konkret aus?
  • Einfaches Interface um dynamisch zugewiesene Komponenten zu parametrisieren. Wir wollen hier explizit nicht ein Klassen/Attribut basiertes system ala CSS verwenden, denn das ist dann einfach nur ein langsameres CSS. (Ein Morphic CSS ergibt wenig Mehrwert). Stattdessen soll über das Tooling parametrisierte Komponenten erkannt und einfach austauschbar sein um auch komplexe Komponenten mit vielen dynamisch zugewiesenen Styles einfach zu variieren. Ausgangspunkt ist hier eine einfache (ohne viel Code) Möglichkeit Komponenten zu parametrieseren. Aktuell habe ich mit custom properties experimentiert, was noch recht umständlich und Fehleranfällig ist. Stattdessen, sollte es einen Kanonischen Weg geben im ViewModel gewisse Komponenten als dynamisch zu parametrisieren.
  • Wenn Komponenten + ViewModel Architektur ausgefeilt ist (Engineering), gilt es im nächsten Schritt den Brückenschlag zurück zur Prototyping (Tinkering) (also das, was Rick die ganze Zeit macht) Welt zu schlagen.
    • Hier ist das Problem, dass beim Prototyping zwangsläufig ein Mashup aus Morphs, Custom Morphs aber auch Komponenten mit ViewModels entsteht, bei dem es darum geht, wie Rick hier jede dieser Sorten von Bausteinen einfach anpassen und erweitern kann.
    • Das ist mit (Custom)Morphs schon recht gut möglich. Dieser Ansatz litt aber unter einer starken Bindung zwischen verhalten und UI. Des weiteren kann man das Verhalten nicht einfach vom Design trennen, was die Freiheit von Designern einschränkt. Das ist was ViewModels in erster Linie erreichen: Morphs und spezifisches Verhalten werden entkoppelt.
    • Lösungsidee: ViewModels können einfach per OE angesteuert und gesubclassed werden. Es steht zudem ein interaktives Interface zum definieren/anpassen von bindings und exposed props zur verfügung.
    • Des weitern muss der OE die erzeugten subclasses (Morphs als auch ViewModels) konsequent in das jeweilige Projekt einbetten. Hier helfen sinnvolle Default Konventionen aber auch die Möglichkeit für den User, eigene Zuordnungen vorzunehmen.
    • Per Halo (Direct manipulation) erzeugte Hierarchien müssen zuverlässig in component files überführt werden, sobald sie als solche deklariert sind. Wird ein Morph zur Komponente, serialisiert er sich nicht mehr in die welt sondern in eine component file. Dieses mapping wird vom System transparent vorgenommen und als symmetrische Beziehung aufrecht erhalten.
    • Bindings per ViewModel vs Connections zwischen morphs. Grundsätzlich wird beides supported, allerdings können connections nur in projektspezifischen Welten gespeichert werden. Eine Komponente sollte alle connections mit entsprechenden bindings ersetzen. Diese sollten in diesem Zuge erweitert werden um N -> N anstatt wie aktuell N -> 1 (Das view model) bindings zu ermöglichen. Entsprechend sollte auch ein automatisiertes übersetzen der connections auf diese binding deklaration im Hintergrund vonstatten gehen.
      • An dieser Stelle ist es auch noch einmal Ratsam über ein grundsätzliche Redesign des "Connection Wizards" nachzudenken.
      • Inspiration hier auch vom Apple InterfaceBuilder, oder Figma, Framer etc holen.
Clone this wiki locally