[JS] MVC-opbouw, goed zo?

[Rekcor]

Ik ben me aan het verdiepen in MVC voor webapplicaties. Dat is nog een puzzel, vooral als de webapplicatie zowel client als server-side code bevat.

Maar goed, de opbouw is als volgt

code:

View         |   Controller        |     Model
-----------------------------------------------
user action -->  processing  ------->    update
                                           |
                                           |
update      <--  onmodelupdate    <--------+

Een gebruiker drukt bijv. op een knop in de view, de controller doet iets en updated het model. Dit genereert een onupdate event in de controller, die (evt) weer wat processing doet en tegen de view zegt: hier is de nieuwe data, update jezelf.

Zo ver, zo goed. (toch?)

Echter, de view heeft wat tijd nodig voor die update. Het zijn maar ms, maar er moeten DOM-elementen aangemaakt/verwijderd/aangepast worden. In dat tijdsbestek kan de controller alweer een nieuwe opdracht voor de view hebben, die de eerste update doorkruist (bijv. omdat een DOM-element al moet worden aangepast, die in de eerste update aangemaakt moest worden). Dus eigenlijk moet het zo zijn dat de controller wacht totdat de view klaar is.

code:

View         |   Controller        |     Model
-----------------------------------------------
user action -->  processing  ------->    update
                                           |
                                           |
update      <--  onmodelupdate    <--------+  
  |
  |
  +-------------> onviewready

Mijn vraag: is dit een goede oplossing, of zit er fundamenteel iets verkeerd als ik hierop uitkom?

[R4gnax]

JavaScript is single-threaded. Tenzij je acties hebt die componenten bevatten die expliciet asynchroon afgerond worden (XmlHttpRequest, setTimeout/setInterval, communicatie met web workers, etc.) zal het onmogelijk zijn om een tweede event van de UI te ontvangen terwijl de afhandeling van een eerste event nog loopt.

De use-case waar er asynchrone acties zijn, los je typisch op door interactie met de user interface tijdelijk te blokkeren en dat duidelijk, maar niet al te hinderlijk zichtbaar te maken.

Dat laatste doe je bijvoorbeeld bij acties gestart door een gebruiker door een spinner/throbber dichtbij of op de knop te zetten waarmee de gebruiker de actie gestart heeft en alle noodzakelijke inputs tijdelijk readonly te maken. (Vooral niet door een opzichtige modal overlay over je hele pagina heen te projecteren.)

[Rekcor]

R4gnax schreef op woensdag 11 december 2013 @ 20:35:
JavaScript is single-threaded. Tenzij je acties hebt die componenten bevatten die expliciet asynchroon afgerond worden (XmlHttpRequest, setTimeout/setInterval, communicatie met web workers, etc.) zal het onmogelijk zijn om een tweede event van de UI te ontvangen terwijl de afhandeling van een eerste event nog loopt.

Dit is inderdaad het geval (met name AJAX-requests).

R4gnax schreef op woensdag 11 december 2013 @ 20:35:
De use-case waar er asynchrone acties zijn, los je typisch op door interactie met de user interface tijdelijk te blokkeren en dat duidelijk, maar niet al te hinderlijk zichtbaar te maken.

Ok, maar dan kan het nog misgaan. Ik kan bijv. op een item in de lijst klikken, die in werkelijkheid niet meer bestaat, en waarvan de AJAX request die het model updated terugkomt nadat ik geklikt heb.

[R4gnax]

Rekcor schreef op donderdag 12 december 2013 @ 08:36:
Ok, maar dan kan het nog misgaan. Ik kan bijv. op een item in de lijst klikken, die in werkelijkheid niet meer bestaat, en waarvan de AJAX request die het model updated terugkomt nadat ik geklikt heb.

Dus terwijl die AJAX request nog loopt zorg je dat je niet op items in 'de lijst' kunt klikken. Dwz je maakt visueel duidelijk dat die lijst tijdelijk ergens mee bezig is en je negeert zolang click events die op de controller voor die lijst binnen komen.

[Rekcor]

R4gnax schreef op donderdag 12 december 2013 @ 08:56:
[...]


Dus terwijl die AJAX request nog loopt zorg je dat je niet op items in 'de lijst' kunt klikken. Dwz je maakt visueel duidelijk dat die lijst tijdelijk ergens mee bezig is en je negeert zolang click events die op de controller voor die lijst binnen komen.

Mmmm.... dit lijkt me geen goede oplossing, want er lopen voortdurend AJAX-requests (ook van evt. plugins). Dit zou betekenen dat >25% van de tijd de UI uitstaat...

[R4gnax]

Rekcor schreef op donderdag 12 december 2013 @ 09:03:
[...]


Mmmm.... dit lijkt me geen goede oplossing, want er lopen voortdurend AJAX-requests (ook van evt. plugins). Dit zou betekenen dat >25% van de tijd de UI uitstaat...

Ik schreef ook "die AJAX request", als in: "die ene specifieke". Je kunt toch gewoon bijhouden welk model een uitstaand AJAX request heeft, of niet?

[Rekcor]

Zeker, maar dan krijg je dus een UI waarbij voortdurend widgets/elementen actief/inactief worden. Misschien dat het in de praktijk meevalt, maar mij lijkt het storend.

Overigens zitten we nu op het niveau van de gebruiker, terwijl mijn eerste zorg is: de code. Eigenlijk moet die er voortdurend rekening mee houden bijv. dat een element tijdens het updaten verwijderd kan zijn.

[TheNephilim]

Rekcor schreef op donderdag 12 december 2013 @ 09:17:
Zeker, maar dan krijg je dus een UI waarbij voortdurend widgets/elementen actief/inactief worden. Misschien dat het in de praktijk meevalt, maar mij lijkt het storend.

Overigens zitten we nu op het niveau van de gebruiker, terwijl mijn eerste zorg is: de code. Eigenlijk moet die er voortdurend rekening mee houden bijv. dat een element tijdens het updaten verwijderd kan zijn.

Dat zou (lijkt mij) mee moeten vallen. Behalve dat gebruikers meestal niet erg snel zijn, zijn webservers tegenwoordig best rap. Zelfs op consumentenhosting hebben wij hier met Ajax geen last van extreme vertraging. Als je geen grote datasets op gaat halen, moet het dus prima te doen zijn.