# Fragestunde mit Jens (13.11.19)
1. Kollaboratives Arbeiten: was passiert im Hintergrund auf dem Server?

- Nodejs server, können ausgeliefert werden an Browser, hat GitHub als Hintergrund, Browser ruft GET, OPTIONS, _git (Protokoll) für sync, commit, squash, checkout
- Jede Änderung wird autocommitted, wird auf dem Server gespeichert
- GET requests wissen, auf welcher Version man selbst ist -> conflicts lösen beim Speichern
- Character-weises Mergen

2. Ansichtsseiten aus Markdown generieren
- Im container geschrieben, kann Editor und view öffnen, lively-markdown view rendert Markdown, transformiert html
- Benötigt etwas magic für script tags (muss neu erzeugt werden, weil einfach nur so Code ausführen nicht okay ist, aber explizit nochmal einhängen schon) Umwandlung von script-tags in lively-script-tags für imports, Rückgabewerte benötigt
- Falls presentation: erst html erstellen, dann in lively-presentation packen für Slides

3. Links fixen, verhalten wird ausgetauscht, Links funktionieren nur für lively browser, nicht gleich für Internet-browser

4. Lively Elemente bestehen aus Webkomponenten (Events, properties, Verhalten, Zustand, Klassenhierarchie usw.
- Neue HTML-Elemente bekommen neuen, spezifischen Tag; können von anderen HTML-Elementen wiederverwendet werden, um komplexere Komponenten zu bauen, die ihre Implementierung verstecken
- Webkomponenten müssen Bindestrich enthalten!
- Neue Komponente: js-file, export default class MyComponent extends HTMLElement bzw Morph (kann nur get z.B.)
- Initialize, events registrieren
+ myComponent.html enthält template mit div, style usw.
- Man kann vom js file auf html Elemente im Schwesternfile zugreifen
- Lively-loader stellt sicher, dass das funktioniert
- Template wird kopiert und in die Shadow-Root der Komponente gepackt, wird vor dem initialize im js ausgeführt

6. Weg um Markdown-Datei vorzukompilieren, so dass es ohne Editor funktioniert, nur benutzte Komponenten laden mit Dependencies (ist bisher noch nicht da, wird mit uns zusammen erarbeitet)
- …-test.js, werden von Travis gefunden und ausgeführt oder vom Test Runner ausgeführt
- /tests, neue Datei anlegen, mit mocha (Testframework)
- Neue Komponenten direkt in Lively reintun, nicht in unseren BP-Ordner, dort nur Documentation, scratch usw.
- Wenn wir Travis wollen, müssen wir’s selber machen (Jens will nicht)

5. Babel: schreibt javascript um, um auch in alten Browsern Funktionalität zu unterstützen
- SystemJS: stößt Babel an
- Clientseitige Datenbank: indexDB
- Früher viel ServiceWorker um Requests abzufangen (da gab’s den Server zwischen dem Browser und Github noch nicht)

7. Dev methods (Standard Importe sind drin, für Development nützlich)
- Jsx: `var a = <div>;` Mischung aus html und javascript
- Active Expressions, rp19 implementation/proxy-based AExp sind beides Stefans Forschungsthemen, also für uns nicht relevant
- Support await in eval: globales await ohne async, Wunsch von Jens
- Swx cache: deprecated
- Create shapes by holding down keys (s, c, d, f)
- Local file index an

8. Reinklicken und Enter ;-)
- Weitere shortcuts: F8

9. Morphs als Thin Layer über HTML
10. Autocompletion im Workspace gibts, funktioniert mit aktiven Elementen gut, ist im Markdown aber noch nicht integriert, geht in js
11. Window snapping shift auf minimizing

### Questions

- #META: English questions would be better, German is ok, though!

1. Wie funktioniert das kollaborative Zusammenarbeiten / was genau passiert im Hintergrund beim Server?
    - #LivelyServer #Git 
    - #LivelySync #GitHub
    - #LivelyEditor #DiffMatchPatch
2. Wie werden die Ansichtsseiten erstellt / aus dem Markdown und javascript html?
    - #LivelyMarkdown #LivelyPresentation #LivelyScript #LivelyImport #LivelyDrawio
3. Namespaces - wann hat man welchen? Manchmal gibt es ja durchaus den lokalen, da man auf relative Pfade zugreifen kann, manchmal werden Dinge im globalen Namespace evaluiert.
    - a) JavaScript module namespace?
    - b) relative file paths?
    - c) body, shadow root of component 
4. Wie genau schaffen wir die Brücke von Dokumentation + Code in Markdown (was wir jetzt grad machen) zu wir schreiben Code mit Klassen und Funktionen usw. (ich denke immer noch an Squeak im Hintergrund und mir ist der Workflow da noch nicht so klar) L.Pf.
    - #Modules, #Components, #Tools,  etc
5. Welche Technologien und Frameworks sind im Hintergrund beteiligt (Nennung und Zusammenhang reicht)
    - #Babel #SystemJS 
    - #CodeMirror
    - #D3
    - #IndexDB
    - (#ServiceWorker)
    - fetch hooks / #PolymorphicIdentifier
6. Wir können nachvollziehen, dass lively cool zum prototypen ist. Aber was müssen wir beachten um eine production-ready webapp zu bauen, zu testen und zu deployen?
    - actually: light distribution (non-dev) version of Lively, e.g. functionality of a Markdown page without editing, is part of this project (and our support)
7. Was tun die Optionen in den Preferences?