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):
// TODO use unique identifier for mainElement, store result of init()
PullToRefresh.init({
mainElement:'.pull-to-refresh',
onRefresh:()=>{
get(this,'currentRouteInstance').refresh();
},
});
},
willDestroyElement(){
this._super(...arguments);
// TODO destroy current ptr only; id is returned by init()
PullToRefresh.destroyAll();
},
});
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
1
2
3
4
shouldPullToRefresh:()=>{
let scrollTop=this.$().parent()[0].scrollTop;
returnscrollTop===0;
},
Hochscrollen geht sonst nur, so lange der Loader angezeigt wird 🙃
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:
Angenommen, ich habe eine Ember-Anwendung mit Zielplattform Handy. Dann möchte ich zentral an einer Stelle für alle Inputfelder Autokorrektur usw. deaktivieren:
Angenommen, ich möchte ein default Verhalten auf viele Routen vererben, bsplw. das Handling von 403ern:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// routes/restricted.js
import Ember from"ember";
export defaultEmber.Route.extend({
actions:{
error(result){
if(result.errors[0].status==='403'){
this.transitionTo('login');
}else{
// Let the route above this handle the error.
returntrue;
}
}
}
});
Und dann in irgendeiner Route:
1
2
3
4
5
6
7
import Restricted from"../routes/restricted";
export defaultRestricted.extend({
model(){
returnthis.get('store').query(/* ... */);
}
});
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.
Darüber hinaus gibt es einen Bug in v1.2.14 (und in gewissen Szenarien auch darüber hinaus), bei dem newValues[i] immer gleich oldValues[i] ist. Der Fix dafür hat aber ebenfalls einen Bug: Die Dependecies werden nicht korrekt injected. Folgende Änderungen waren nötig:
1
2
3
4
5
6
7
// line 5: .config(function($provide){
.config(['$provide',function($provide){
// line 11: $provide.decorator('$rootScope', function($delegate, $parse) {
Apache kennt von haus aus nur Input Dialoge (korrigiert mich), und damit kann man natürlich “j”/”n”-Eingaben bauen (siehe Examples). Schöner ist aber ein richtiger Ja/Nein-Dialog, wie Javascripts confirm. Außerdem gibt es if/else nur mit Ant contrib, das nicht zwingend überall installiert ist. Bitte nennt mir eine schönere Lösung als die folgende, aber damit geht’s – Confirm-Dialoge und if/else-Verzweigung abhängig von der User-Eingabe:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<target name="_set URLs and ports"depends="use Proxy, setURLs, setURLsAndProxy">