AJAX-eyðublað bíður JSON en fær HTML: farðu í gegnum svarið skref fyrir skref

Eyðublaðinu er sent, hleðsluhringurinn birtist og stjórnborðið segir að óvænt tákni < sé að finna í JSON á stöðu 0. Síðan sjálf hleðst vel, og þess vegna er fyrsta hvatningin að kenna þáttaranum eða göngunum um. Venjulega er hvorugt viðriðið: sendingin er önnur beiðni en hleðsla síðunnar, og hún kom til baka með einhverju sem er ekki JSON. Vinna í þeirri röð sem vafrinn opinberar það í raun, því fjögur möguleg svör krefjast fjögurra mismunandi lagfæringa.

Skref 1: gríptu sendinguna sem raunverulega átti sér stað

Opnaðu Net-viðmótið áður en þú sendir, stilltu atburðaskrána þannig að hún varðveiti færslur milli síðuhleðslna og gerðu síðan eina skaðlausa prófunarsendingu á aðgangi sem þú mátt nota. Veldu beiðnina sem eyðublaðið sjálft hóf, ekki skjalsbeiðni síðunnar.

Farðu varlega með síur. XHR- eða Fetch-sía er þægileg, en ef ramminn sendir enn í gegnum faldan iframe eða eyðublað sem er búið til á gervi, þá felur sían hina einu beiðni sem skiptir máli. Sendu fyrst einu sinni án síu og sjáðu hvað birtist.

Fyrir valda beiðni skaltu skrá sex hluti áður en þú túlkar nokkuð: aðferðina, fulla slóð með fyrirspurnarstrengnum, stöðuna, keðju endurbeininga, Content-Type svarsins og fyrstu línur bolsins. Handbók Net-viðmótsins í Chrome DevTools nær yfir sýnirnar Headers, Response og Initiator þar sem þetta er, og samsvarandi viðmót í öðrum vöfrum sýna sömu svið.

Skref 2: staðfestu að þetta sé beiðnin sem þú heldur

Ótrúlega margar JSON-villur eru í raun leiðarvillur. Ef meðhöndlari sendingarinnar kastar undantekningu áður en hann kallar preventDefault, framkvæmir vafrinn innfædda POST-sendingu eyðublaðsins á það netfang sem action-eiginleikinn segir til um, og þjónninn svarar með heilli HTML-síðu. Meðhöndlarinn keyrir aldrei, svo JSON var aldrei beðið um.

Berðu saman slóðina í viðmótinu við slóðina sem JavaScriptið þitt kallar. Leitaðu að endurbeiningu sem endar annars staðar, vanti eða sé of mikið skástrik í lokin, misræmi í aðferð þar sem meðhöndlarinn sendir GET en endapunkturinn tekur við POST, eða eyðublaði sem sendir á afstæða slóð af síðu sem hefur flutt sig. Fylgdu keðju endurbeininga til enda og skráðu endanlegu slóðina, ekki þá fyrstu.

Kannaðu síðan upphafsmanninn. Ef beiðnin kom frá síðuhleðslu en ekki frá skriftunni þinni hefur þú þegar fundið vandamálið, og engin breyting á svarsþáttara mun hjálpa.

Skref 3: flokkaðu niðurstöðuna í fjóra flokka

Hver niðurstaða tilheyrir nákvæmlega einum þeirra, og flokkurinn ræður því hvar þú lítur næst.

Miðlínurnar eru þær sem fólk greinir rangt, því staðan er 200. Innskráningarsíða sem næst eftir endurbeiningu er fullkomlega gott HTTP-svar og mjög lélegt JSON-skjal. Efnisgerðin application/json lagar það ekki: hún er merkimiði, og rangmerktur bolur tekst samt ekki að þátta. Aðgangur lokaður er lína sem lítur út eins og lokin beiðni: viðmótið sýnir stöðu, en stefnan um mismunandi uppruna heldur bolnum eftir, svo fyrir skriftuna sem kallar er hann jafn ónothæfur og tímamörk.

Fjórða línan er jafn algeng á eldri PHP- og rammastöflum. Aðvörun um úreldingu sem prentuð er fyrir kóðaða hleðsluna framleiðir bol sem enginn JSON-þáttari tekur við, og oft er sú aðvörun öll skýringin.

Skref 4: lestu villu þáttarans bókstaflega

Villutextinn nefnir fyrsta stafinn sem braut þáttunina, og það greinir flokkinn venjulega án nokkurrar giskingar.

Tómur bolur með 200 er sérstakt tilvik: endapunkturinn keyrði, framleiddi ekkert, og eitthvað neðar tók það sem árangur. Það er bilun í samningi forritsins en ekki í flutningi, og hún á heima í næsta skrefi, ekki í milliþjóninum. Firefox og Safari orða sömu fjórar bilanir á annan hátt, svo paraðu við stafinn eða tóman bolinn en ekki nákvæma strenginn.

Skref 5: lagaðu lagið sem sannanirnar benda á

Fyrir leiðarvandamál skaltu laga beiðnina: leiðréttu action, komdu í veg fyrir að meðhöndlarinn falli í gegn, láttu endapunkt og aðferð passa og prófaðu aftur. Fyrir framsetningarvandamál skaltu laga það sem framleiddi bolinn og komast að því hvers vegna villuskjal er skilað þar sem gagnanna var vænst. Fyrir samningsvandamál skaltu lesa raunverulega vænta uppbyggingu rammans fyrir þá útgáfu sem þú keyrir og móta svarið eftir henni í stað þess að slaka á biðlinum.

Svar með lokuðum aðgangi þarf sína eigin ferð, því beiðnin sjálf getur verið rétt og bolurinn gæti aldrei náð til kóðans þíns. Berðu saman Access-Control-Allow-Origin svarsins við nákvæma Origin sem vafrinn sendi, og mundu að algildisstafur fullnægir ekki beiðni með skilríkjum. Paraðu credentials: 'include' hjá biðlinum við Access-Control-Allow-Credentials: true hjá þjóninum, og athugaðu hvort kallið hafi notað no-cors-ham, þar sem ógagnsær bolur er skjalfest niðurstaða en ekki galli.

Að skipta þáttaranum út fyrir eitthvað eftirlátara er eina lagfæringin sem forðast ætti. Að meta svarið sem kóða, eða afhýða texta þar til hann þáttast, felur misræmið í samningnum og bætir við innspýtingarflöt í staðinn fyrir þögn. Einnig er nauðsynlegt að athuga stöðuna aðskilda frá bolnum: 200 með villuhluti á forritstigi er eðlilegt í mörgum API og verður að meðhöndla með því að lesa hleðsluna.

Þegar þú þarft hjálp frá einhverjum öðrum skaltu deila lágmarksfærslu — aðferð, slóð, stöðu, endanlegri slóð eftir endurbeiningar, efnisgerð svarsins, lögun bolsins og væntum samningi — í stað hráa útflutningsins. Net-skrár innihalda vafrakökur, tákn, fyrirspurnarstrengi og persónuupplýsingarnar sem voru í eyðublaðinu, og sjálfvirk hreinsun er ekki yfirferð.

• Gríptu beiðnina án síu áður en þú breytir nokkurri kóðalínu.
• Staðfestu að upphafsmaðurinn hafi verið skriftan þín og endanlega slóðin sé endapunkturinn þinn.
• Flokkaðu svarið áður en þú snertir þáttarann.
• Lagaðu leið, aðgang, framsetningu eða samning, og aldrei með því að slaka á þáttaranum.