În fiecare versiune a unui proiect de lungă durată la care lucrez sunt incluse ca la o dublă de probleme de reparat ori sâcâieli de îmbunătățit. Una din ele suna destul de ciudat și privea o pagină construită în totalitate în jurul a două instanțe de Kendo Scheduler, ambele inițializate și configurate folosind libăria lor ajutătoare pentru ASP.NET MVC.

Chiar că

Pe scurt, utilizatorii reclamau că uneori, fără vreun tipar anume, după ce operau actualizări sau ștergeri informațiile vechi rămâneau agățate-n interfață. La prima vedere totul părea bine cuplat, adică folosind evenimentele Save, Edit respectiv Remove:

.Events( e => { 
    e.DataBound( "abc_consoleDatabound" ); 
    e.Save( "abc_saveEvent" ); 
    e.Edit( "abc_editEvent" ); 
    e.Remove( "abc_deleteEvent" ); 
    e.Navigate( "abc_navigate" ); 
    e.Cancel( "abc_cancel" ); 
})

Pe de altă parte, analizând traficul: uneori apelul de recitire a informațiilor era finalizat corect, adică după cel ce opera modificarea propriu-zisă, alteori… ba. Și, desigur, atunci când ordinea era aiurea, se lăsa impresia că modificările de fapt nu se operau, însă, odată reîncarcată complet pagina, totul se prezenta conform așteptărilor.

Ce se întâmpla până la urmă? Să fie rușii de vină? Suntem siguri prin analogie, dar eu am descoperit altceva: acele evenimente înregistrate sunt declanșate înainte de lansarea cererii corespunzătoare către server, ceea ce înseamnă că reîmprospătarea informațiilor în acest punct înseamnă că vor fi două cereri concurente ce se vor finaliza într-o ordine imprevizibilă.

Am căutat să văz dacă există ceva de genul SaveEnd, EditEnd respectiv RemoveEnd pentru a putea temporiza mai bine operațiunea de recitire, într-un moment de timp când se poate ști cu precizie că operațiunea precedentă a fost finalizată.

Nu există expre’ așa ceva, singura improvizație ce se poate face fiind evenimentul RequestEnd pentru sursa de date configurată. Problema este că-i generic: este generat pentru orice operațiune, fiind de competența funcției atașate să discrimineze între ce-i de interes și ce nu. În cazul meu mă interesa doar tipul cererii, tip ce poate fi convenabil inspectat folosind proprietatea type a obiectului-eveniment transmis funcției.

function abc_handleDsRequestEnd(e: kendo.data.DataSourceRequestEndEvent) { 
    if (e.type === 'destroy' 
        || e.type == 'create' 
        || e.type == 'update') { 
        refreshAllTheThings(); 
    } 
}

Iar cuplarea la componenta Kendo Scheduler:

.DataSource( d => d 
    //(...) 
    .Events( e => { 
        e.RequestEnd( "abc_handleDsRequestEnd" ); 
    }) 
)

E o abordare de reținut, întrucât sunt și alte componente din suita Kendo ce prezintă aceast vid în raportarea diverselor momente în ciclul lor de funcționare.