[jQuery] JS scripts niet asynchroon laden*

[wackmaniac]

Afgeplitst uit De Devschuur Coffee Corner - Iteratie 7

Nee, in dit geval niet; zit in de backend van ons CMS te werken en probeer met ajax een modal te vullen. jQuery heeft alleen bedacht dat de scripts-tags die erin staan wel even asynchroon kunnen worden geladen, maar dat geeft problemen, want script x heeft script y nodig. En er is geen manier om dit in te stellen. Enige optie is om zelf de response van de ajax-call te ontdoen van script-tags en deze zelf een voor een toe te voegen aan de html ...

[ Voor 8% gewijzigd door BtM909 op 07-08-2014 14:14 ]

[HuHu]

Dan gebruik je LABjs

[ Voor 45% gewijzigd door HuHu op 07-08-2014 11:41 ]

[wackmaniac]

Beetje rondgezocht idd, maar die knakker is wel actief op de interwebs; overal waar het ook maar zijdelings genoemd wordt komt hij wel even vertellen hoeveel beter het is dan vergelijkbare bibliotheken RequireJS schijnt ook wel aardig te zijn hierin. Vind de syntax van requirejs wat intuïtiever, maar dat zal mijn beperkte intelligentie wel zijn

[ Voor 16% gewijzigd door wackmaniac op 07-08-2014 11:45 ]

[BtM909]

wackmaniac schreef op donderdag 07 augustus 2014 @ 11:39:
Nee, in dit geval niet; zit in de backend van ons CMS te werken en probeer met ajax een modal te vullen. jQuery heeft alleen bedacht dat de scripts-tags die erin staan wel even asynchroon kunnen worden geladen, maar dat geeft problemen, want script x heeft script y nodig. En er is geen manier om dit in te stellen. Enige optie is om zelf de response van de ajax-call te ontdoen van script-tags en deze zelf een voor een toe te voegen aan de html ...

Wat? Je laadt met Ajax scripts in en die mogen niet async worden geladen en jij zegt dat je dat niet kan instellen met jQuery

edit:

Of ben je cross-domain bezig?

[ Voor 3% gewijzigd door BtM909 op 07-08-2014 13:00 ]

[D-Raven]

wackmaniac schreef op donderdag 07 augustus 2014 @ 11:39:
Nee, in dit geval niet; zit in de backend van ons CMS te werken en probeer met ajax een modal te vullen. jQuery heeft alleen bedacht dat de scripts-tags die erin staan wel even asynchroon kunnen worden geladen, maar dat geeft problemen, want script x heeft script y nodig. En er is geen manier om dit in te stellen. Enige optie is om zelf de response van de ajax-call te ontdoen van script-tags en deze zelf een voor een toe te voegen aan de html ...

Jij bent de gene die met ajax html gaat injecten (dat je deze als modal wilt tonen is dan niet zo relevant) natuurlijk word enige javascript dan async uitgevoerd.
Dat heeft niks met jquery te maken. Dat jquery enige javascript welke met ajax ingeladen wordt meteen uitvoerd is alleen maar fijn.

Dat jij vervolgens volgorde problemen hebt zitten in je javascript is niet de schuld van jquery

[wackmaniac]

Nou, dat ben ik niet helemaal met je eens; als ik de javascript asynchroon uitgevoerd wil hebben dan zet ik het async-attribuut wel op de script-tag. Dat hoeft jQuery niet voor mij te beslissen lijkt me

[dcm360]

Wat doe je dan speciaal om er voor te zorgen dat het script direct geladen wordt? Als je het puur injecteerd met iets als $('#elem').html(data) dan gaat de scheduler van de browser er gewoon mee aan de haal.

[D-Raven]

wackmaniac schreef op donderdag 07 augustus 2014 @ 13:10:
Nou, dat ben ik niet helemaal met je eens; als ik de javascript asynchroon uitgevoerd wil hebben dan zet ik het async-attribuut wel op de script-tag. Dat hoeft jQuery niet voor mij te beslissen lijkt me

We praten langs elkaar heen merk ik. Jij hebt het over de script urls in je ajax-loaded content. Ik heb het over het feit dat als je via ajax iets in gaat laden, het per definitie async is omdat het niet tijdens je normale page load gebeurd

Maargoed helpdesken via de devschuur is sowieso niet handig

[wackmaniac]

D-Raven schreef op donderdag 07 augustus 2014 @ 13:22:
[...]

Maargoed helpdesken via de devschuur is sowieso niet handig

Het probleem is ook opgelost, het begon met een klagende zucht

dcm360 schreef op donderdag 07 augustus 2014 @ 13:19:
Wat doe je dan speciaal om er voor te zorgen dat het script direct geladen wordt? Als je het puur injecteerd met iets als $('#elem').html(data) dan gaat de scheduler van de browser er gewoon mee aan de haal.

Exact wat jij doet, maar jQuery vindt het dan nodig om de scripts eruit te filteren en zelf in te laden met jQuery.getScript().

[BtM909]

Ja dat klopt, maar getScript staat standaard op async. Als je dat niet wilt, dan zet je het toch tijdelijk uit

http://api.jquery.com/jQuery.ajaxSetup/

Ik ga dit allemaal even afsplitsen, zodat het wellicht nog gevonden kan worden door anderen!

[wackmaniac]

Ik kan in de docs niet vinden dat je die instelling in de ajaxSetup kan aanpassen. Ajax zelf heeft ook een async-optie, misschien verwar je die met elkaar?

[BtM909]

http://api.jquery.com/jquery.getscript/

Die doet expliciet (kan je niet overriden) async: true... Je kan met die ajaxSetup het globaal (dus voor alle requests) omzetten naar false (moet je alleen niet vergeten om die daarna weer op true te zetten).

[wackmaniac]

Dat zou wel eens een elegantere oplossing zijn. Ik ben alleen bang dat mijn inline-blokken door de browser worden opgepakt, terwijl jQuery nog bezig is de scripts te includen. Dat heb ik alleen nog niet getest.

[R4gnax]

BtM909 schreef op donderdag 07 augustus 2014 @ 14:12:
Ja dat klopt, maar getScript staat standaard op async. Als je dat niet wilt, dan zet je het toch tijdelijk uit

http://api.jquery.com/jQuery.ajaxSetup/

Ik ga dit allemaal even afsplitsen, zodat het wellicht nog gevonden kan worden door anderen!

jQuery.getScript() is een simpele alias voor jQuery.ajax({ dataType : "script" }) en als in de broncode voor dat ajax transport gaat kijken, dan kom je er al snel achter dat het inladen altijd gebeurt door een <script async="true" src="..."> element te injecteren in je pagina. Dit gebeurt dus per definitie altijd async.

Script elementen met een src attribuut zijn trouwens volgens de HTML specificatie altijd async als ze dynamisch geinjecteerd worden, en dus is eigenlijk de async="true" kwalificatie ook overbodig. (Maar jQuery bevat deze waarschijnlijk omdat sommige oudere browser revisies dit gedrag niet compleet juist volgens specificatie implementeren.)

wackmaniac schreef op donderdag 07 augustus 2014 @ 16:32:
Dat zou wel eens een elegantere oplossing zijn. Ik ben alleen bang dat mijn inline-blokken door de browser worden opgepakt, terwijl jQuery nog bezig is de scripts te includen. Dat heb ik alleen nog niet getest.

De elegante oplossing hier, is om je CMS en server-side applicatie een schop geven en e.e.a. daar correct beginnen op te lossen. Stop bijvoorbeeld eens met mixed mode HTML & JS over de lijn te sturen en kijk eens naar beter gestructureerde oplossingen.

Klinkt ook een beetje als een houtje-touwtje organisch gegroeid gedrocht waar nodig de snoeischaar in de client<->server communicatie architectuur gezet moet worden.

[ Voor 6% gewijzigd door R4gnax op 08-08-2014 09:04 ]

[wackmaniac]

Het verdient wellicht niet de schoonheidsprijs, maar soms moet je pragmatisch zijn; het geheel is opgebouwd middels verschillende widgets die elke hun eigen functionaliteit bepalen (beetje separation of concerns-idee). Je zou verschillende oplossingen kunnen bedenken (LABjs/RequireJS-achtige constructies, alle javascript op voorhand al inladen, de html en javascript los gaan trekken in de response), maar die zijn niet allemaal even werkbaar.

Wat je zegt lijkt trouwens niet helemaal te kloppen:

When a script element node is created, if it is being flagged as parser-inserted, set its force-async flag to false. Otherwise, set its force-async flag to true. (Note that createContextualFragment, innerHTML and XSLTProcessor::transformToFragment-created scripts are not flagged as parser-inserted.) This flag setting happens before any attributes (even parser-set ones) are set on the node (so a fragment parser-set async attribute may modify the flag shortly after).

bron en discussie

[R4gnax]

wackmaniac schreef op vrijdag 08 augustus 2014 @ 09:12:
Het verdient wellicht niet de schoonheidsprijs, maar soms moet je pragmatisch zijn; het geheel is opgebouwd middels verschillende widgets die elke hun eigen functionaliteit bepalen (beetje separation of concerns-idee). Je zou verschillende oplossingen kunnen bedenken (LABjs/RequireJS-achtige constructies, alle javascript op voorhand al inladen, de html en javascript los gaan trekken in de response), maar die zijn niet allemaal even werkbaar.

Die oplossingen zijn hartstikke werkbaar als je applicatie van meet af aan goed in elkaar zou steken. Maar als je tot aan nu inderdaad een houtje-touwtje oplossing hebt gehanteerd waarbij browser scripting eigenlijk een ondergeschoven kindje is, dan gaat dat niet werken, nee.

Wat betreft dit opzetten met RequireJS; asynchronous module definitions zijn bij uitstek geschikt voor 'self-contained' widgets. Zet ergens een data-module attribuut op met het module ID dat geladen moet worden, gebruik even op een te inserten DOM fragment een querySelectorAll om die dingen te vinden en gebruik de require functie om de root module + automatisch alle dependencies binnen te halen.

Dat kan on-demand en met zaken als de RequireJS optimizer en de bundling feature die sinds RequireJS 2.10 bestaat, kan dat ook nog verdomd efficient. (Been there, done that.)

wackmaniac schreef op vrijdag 08 augustus 2014 @ 09:12:

Wat je zegt lijkt trouwens niet helemaal te kloppen:

[...]

bron en discussie

Lees de officiële W3 spec even? http://www.w3.org/TR/html...-1.html#attr-script-async

Daar kun je zien dat het ontbreken v/e async attribuut (dwz de async property is false) bij scripts die niet parser-inserted zijn, enkel inhoudt dat de scripts 'in volgorde' en 'zo snel mogelijk' uitgevoerd moeten worden. Er wordt nergens gegarandeerd dat ze onmiddelijk synchronous uitgevoerd moeten worden en dat de hele rest van de browser moet wachten. Dat is enkel en alleen het geval voor script elementen die een inline code block bevatten.

[wackmaniac]

Hmmz, toch niet helemaal goed gelezen dan.

Tja, legacy code... Zal hier de boel eens achter de broek gaan zitten en een PoC maken obv AMD en mss dat het dan toch nog gaat gebeuren

[R4gnax]

wackmaniac schreef op vrijdag 08 augustus 2014 @ 16:01:
Hmmz, toch niet helemaal goed gelezen dan.

Kan ik me inkomen hoor. Dat stuk van de spec is namelijk geen doorkomen aan. Zelf destijds ook 3x opnieuw door moeten lezen voordat het een beetje klikte.