Ember: Unit-test Promise

Quelle

Javascript: “Pull to refresh”

Pull-to-refresh in (mobilen!) Webseiten nachzubauen, ist jetzt keine Raketenwissenschaft, aber doch so viel Aufwand, dass sich ggf. eine Library lohnt. Viele (? einige? apeatling, ember-gestures, …) bauen aber auf hammer auf, und das hat einen Bug (Beispiel, es gibt weitere Tickets) im Zusammenspiel von Panning (also dem “Pull” in “Pull-to-refresh”) und Scrolling. Zusammengefasst: Es geht nur eines von beiden. Mit ein wenig Drumherumgehacke bekommt man das etwas näher zusammengeführt, aber entweder kommt PanEnd dann gar nicht (was das “refresh” schwierig macht), oder bspw. die PanMove-Events kommen nicht zuverlässig (wodurch man den “pull” nicht 1:1 an den Finger des Nutzers hängen kann).

Ein npm-Modul, das nicht auf hammer aufbaut, wäre pulltorefreshjs (getestet mit 0.1.11 und 0.1.13):

In Ember sieht das als Komponente so aus:

Auf dem Handy sollte das so schon funktionieren. Auf dem Desktop hatte ich das Phänomen, dass Hochcrollen immer erst beim zweiten mal funktioniert hat (und auch dann nur, wenn zwischen Versuch 1 und 2 nicht zu viel Zeit lag). Weil: Die Lib immer beim Hochscrollen den Loader anzeigt, wenn man die Funktion shouldPullToRefresh nicht vom default !window.scrollY ummapt, bspw. auf

Hochscrollen geht sonst nur, so lange der Loader angezeigt wird 🙃

Generische npm Module in Ember

Wer, wie ich, die verfilzte komplexe Javascript-Umgebung etwas… “unübersichtlich” findet, und sich fragt, wie zur Hölle man ein nicht-Ember-spezifisches npm-Modul in Ember importiert, dem kann geholfen werden:

Erst Browserify:

dann, voilà:

Ember.js: Helper erweitern

Angenommen, ich habe eine Ember-Anwendung mit Zielplattform Handy. Dann möchte ich zentral an einer Stelle für alle Inputfelder Autokorrektur usw. deaktivieren:

Mit, und.

Ember.js: Vererbung in Routen

Angenommen, ich möchte ein default Verhalten auf viele Routen vererben, bsplw. das Handling von 403ern:

Und dann in irgendeiner Route:

Grundsätzlich kommt das von hier, ergänzt um die konkrete Implementierung des Error Handlings. Das findet sich hier in der Doku, wobei error.status nicht funktioniert, es muss result.errors[0].status sein.