Meteor: Speichern von Infos im Client

isn100_technical-sheetAnfangs hatte ich mir gedacht, ich muss mir erstmal E-Mail-Adressen im Client merken, bevor ich ein Update einer endgültigen Collection für Server und Client durchführe. Als bodenständiger Informatiker nahm ich ein Array. Für die Persistenz habe ich mir die Session ausgesucht:

// Gibt es das Array schon?
if(typeof(usersToShareWith) !== „object“) {
// wenn nicht, Array initialisieren
usersToShareWith = [];
}
// Array in Session speichern
Session.set(„usersToShareWith“, usersToShareWith);

Durch das Buch Discover Meteor ist mir aber schnell klar geworden, dass man unbedingt das Kern-Feature Collection nutzen sollte. Das spart Zeilen, denn hier kommen Persistenz und Reactivity von Haus aus mit. In Meteor.isClient ist wie folgt sogar eine Collection angelegt, die auch nur dort verfügbar ist:

UsersToShareWith = new Meteor.Collection(null);
UsersToShareWith.insert({email: input.value});

Noch schnell einen Helper gebaut und dann per Handlebars nutzbar:

Template.collTest.usersToShareWith = function() {
return UsersToShareWith.find({});
};

Heute habe ich wieder gelernt, dass der Variablen-Scope in JavaScript anders funktioniert als in Java/C#. Dabei habe ich gelernt den Global-Scope sauber zu halten (etwas Lektüre hatte ich) und mir das hoisting erneut angeschaut. Des Weiteren habe ich mir Mühe gegeben, meinen Code sauberer zu gestalten. Ich hoffe, das geht noch besser ;).

Außerdem habe ich

  • ein Update auf Meteor 0.9.1.1 gemacht und
  • livestamp ausgetauscht. Das Package funktionierte mit Meteor 0.9.0 nicht mehr, aber das Package livestamp-hs funktioniert (soweit ich sah wie gewünscht)

In meiner User-Story habe ich einiges geschafft und folgendes offen:

Done:

  • Check: echte E-Mail-Adresse? (nein: gelb)
  • Check: eigene E-Mail-Adresse? (ja: rot)
  • Check: Mail schon hinzugefügt? (ja: rot)
  • Check: User nicht vorhanden? (ja: rot, sonst: grün)
  • Hinzufügen bei grün mit Enter/Return möglich (sonst nicht)

TBD:

  • Workflow: Adressen nach Upload hinzufügbar
  • Nicht geteilte Uploads mit Benutzern in Collection verknüpfen

Du hattest die Frage nach einer Art Messenger aufgeworfen, um auf E-Mails verzichten zu können. Ich bin gerade auf HipChat von Atlassian und über Slack gestolpert.

Auf den ersten Blick wirkt HipChat reicher an Features und übersichtlicher. Beide machen aber einen guten Eindruck.

Vielleicht reicht auch das Blog, anschauen können wir uns das aber auch mal. Was meinst du? Ich würde dich bei beiden in ein Teamprojekt einladen.

Best practices for comments on code commit

Beim Kommentieren eines Commits hinterfragte ich, ob der Kommentar eigentlich sinnvoll gewählt ist und ob es best practices gibt. Die Allerbeste Antwort habe ich auf Stackoverflow gefunden:

Short, communicates what was changed, and provides some kind of reference for others to get more info without hunting you down.

Long:

  • You should be committing fairly often, with a single focus for every commit, so based on that, comments should be short and detail what the focus of the commit was.
  • I’m a fan of posting the what in your comment, with the why and the how being detailed elsewhere (ideally in your bug tracking). The why should be the ticket, and upon closing the ticket, you should have some kind of note about how that particular issue was addressed.
  • A reference to your bug tracking system is good if it isn’t handled otherwise (TRAC/SVN interaction, for example). The reason for this is to point other developers in the right direction if they’re looking for more information on the commit.
  • Don’t include specific file names unless the fix really complex and detail is needed. Even still, complex details probably belong in bug tracking with your implementation notes, not in version control. Files edited, diff details, etc, should hopefully be included with version control, and we don’t want to spend time duplicating this.

Given these ideas, an example commit comment for me would be something like

Req3845: Updated validation to use the new RegEx validation developed in Req3831.

<input type „file“> stylen

So schön sieht der Button mit ausgewählter Datei des Input-Elements mit Filepicker nicht aus. Die Motivation den etwas schicker zu machen ist groß. Die naheligenste Idee ist, ihn mit CSS zu „stylen“, doch stößt man sehr schnell an Grenzen.

Die naheliegenste Lösung erschien mir erstmal ein Div-Element zu nehemn, via CSS zu stylen und per JavaScript das click-Event des Div-Elements an das click-Event des Input-Elements binden:

Template.feed.events({
'click .addButton' : function() {
$('.fileBrowse').click();
}, 
[...] 
});

(Beispiel für Meteor)

Das eigentliche Input-Element möchte man dann nicht mehr sehen:

.fileBrowse {
display: none;
}

Für die Vollständigkeit hier die HTML-Elemente

<div class="addButton">+</div>
<input class="fileBrowse" type="file"/>

Projekte organisieren

Beim Einbauen der fileColletion und dem Upload ist mir aufgefallen, dass man ohne Inline-Warnungen und Debugging schnell in kleine Probleme läuft, die schwer aufzufinden sind, wenn sich unterschiedliche Funktionen der Anwendung in den gleichen Dateien sich über mehrere Verzeichnisse aufteilen:

  • /lib/collections.js …
  • /client/view1/view1template1.html …
  • /client/view2/view2template1.html …
  • /server/permissions.js …

Frei nach „teile und herrsche“ kann es schon bald im Projekt sinnvoll sein, es in Module aufzuteilen. Bei kleinen Modulen kann es so aussehen:

  • /modul1/modul1.js
  • /modul1/modul1.html
  • /modul1/modul1.css

Gut ist, dass man Ordner client, lib und server auch in Unterordnern nutzen kann, was bei komplexeren Modulen gut für die Aufteilung ist:

  • /modul1/lib/collections.js …
  • /modul1/client/modul1template1.html …
  • /modul1/client/modul1template1.css …
  • /modul1/client/modul1template1.js …
  • /modul1/server/modul1.js

Sollte eine Funktion gänzlich losgelöst Sinn ergeben, kann man diese auch ganz in ein GitHub-Projekt oder Package wegkapseln.

Die Idee hatte ich wohl nicht als erstes ;).