Mawasiliano ishirini yalipaswa kuhifadhiwa kwenye CRM, lakini UI ilionyesha alama ya kijani ya mafanikio na operesheni hiyo haikufanya kitu bila kutoa taarifa. Msaidizi (helper) wa TypeScript unaofanya uwanja wa error kuwa lazima katika mabadiliko (mutations) ya Supabase-JS sasa unawalazimu watengenezaji kukabiliana na hitilafu hiyo badala ya kuificha.

Kwa nini muundo wa kurudisha wa Supabase-JS ni mtego

Kifaa cha JavaScript cha Supabase (@supabase/supabase-js) hakirushi hitilafu (exceptions) wakati uandishi wa hifadhidata unakataliwa. Badala yake, unatatua ahadi (promise) kwa kutumia kitu { data, error }. Ikiwa sera ya usalama wa kiwango cha mstari (RLS), ukiukaji wa ufunguo wa kipekee (unique-key violation), au kizuizi kingine chochote kinazuia hoja (query), data inarudi kama null na error ina ujumbe wa hifadhidata. Kifaa kinachukulia kuwa mwaliki (caller) atakagua error; hakikatishi wito huo kamwe.

Katika vitendo, misingi mingi ya kodi (codebases) inachukulia wito huo kama operesheni ya "fire-and-forget" (fanya na usahau):

await supabase
  .from('contacts')
  .update({ statut: 'ancien', archived_at: now })
  .eq('id', id)

return { ok: true }

Wakati update inazuiliwa na sheria ya RLS, ahadi (promise) bado inatatuliwa. Kwa sababu mtengenezaji hajachambua (destructure) { error }, hitilafu hiyo haionekani. Kazi (function) inarudisha { ok: true }, UI inaonyesha mafanikio, na data inabaki bila kubadilika. Hakuna kumbukumbu (logs) zinazoonekana, hakuna taarifa ya Sentry inayochochewa, na hitilafu inaweza kukaa kwa siku nyingi.

Linter pekee haitoshi

Zana za uchambuzi wa tuli (static analysis tools) zinaweza kuonya wakati sifa ya error inapupuuzwa, lakini haziwezi kusimamia mkataba wa wakati wa utendaji (runtime contract). Mtengenezaji bado anaweza kuandika const _ = await … na kutuliza onyo, au anaweza kuongeza maoni (comment) ili kuzima sheria hiyo. Tatizo la msingi ni kwamba mfumo wa aina (type system) unaruhusu wito kufanikiwa bila hata kutaja error.

Msaidizi wa mutate(): kufanya usimamizi wa hitilafu kuwa lazima

Mwandishi alitengeneza kifuniko (wrapper) kidogo kinachoitwa mutate() ambacho kinabadilisha muundo wa aina ya kurudisha. Badala ya { data, error }, msaidizi huyo anarudisha tuple [data, error] ambapo error ni uwanja unaohitajika. TypeScript kisha inakataa kukamilisha (compile) wito wowote unaotupa kipengele cha pili.

async function mutate<T>(promise: Promise<{ data: T | null; error: any }>) {
  const { data, error } = await promise
  // Send error to Sentry immediately
  if (error) Sentry.captureException(error)
  return [data, error] as const
}

Matumizi yanakuwa ya wazi:

const [result, err] = await mutate(
  supabase
    .from('contacts')
    .update({ statut: 'ancien', archived_at: now })
    .eq('id', id)
)

if (err) {
  // Handle or rethrow
  return { ok: false, message: err.message }
}
return { ok: true, data: result }

Ikiwa mtengenezaji anasahau kunasa err, TypeScript inatoa hitilafu: “Tuple type [T, any] ya urefu wa 2 haina kipengele kwenye index 1.” Kodi haitakamilika (compile) mpaka hitilafu hiyo itatuliwe. Msaidizi pia unaingiza uwekaji wa Sentry (Sentry instrumentation), ukihakikisha kuwa kila kukataliwa kwa hifadhidata kunarekodiwa hata kama mwaliki baadaye ataificha.

Nini kiko hatarini

  • Uadilifu wa data – Hitilafu zisizoonekana huruhusu hali isiyo sahihi kuingia kwenye uzalishaji (production). Mawasiliano yaliyohifadhiwa ambayo hayakuondoka kwenye orodha hai yanaweza kusababisha ripoti za baadaye kuwa zisizo sahihi.
  • Imani ya mtumiaji – UI inayodai mafanikio wakati hakuna kilichobadilika inaharibu ujasiri. Wateja wanaona “imehifadhiwa” lakini bado wanapata mawasiliano hayo kwenye utafutaji.
  • Muda wa mtengenezaji – Kukimbiza hitilafu zisizoonekana (phantom bugs) kunatumia saa nyingi. Usimamizi wa wazi wa hitilafu huibua tatizo pale linapotokea, na kufupisha mzunguko wa utatuzi wa hitilafu (debugging loop).
  • Gharama za uendeshaji – Kuongeza mistari michache ya kodi na kifuniko (wrapper) kidogo ni kidogo sana ikilinganishwa na gharama ya tukio la upotevu wa data usioonekana.

Makubaliano ya kutoa na kupokea (The trade-off)

Msaidizi huongeza uandishi mrefu: kila wito wa mabadiliko (mutation) sasa unarudisha tuple, na wawakili lazima waandike kizuizi cha if (err). Baadhi ya timu zinaweza kuona hili kama kelele za boilerplate, hasa kwa vitendo rahisi vya CRUD ambapo wanatarajia mafanikio. Hoja ya kinyume ni kwamba kodi hiyo ya ziada ni kinga, si kipengele cha hiari. Katika mazingira ambapo usahihi wa data ni muhimu sana—mifumo ya CRM, fedha, afya—kulazimisha ukaguzi huo unajilipa wenyewe.

Nini kinafuata

Mwandishi anaahidi sehemu ya tatu inayochunguza sera za RLS zinazorudisha mistari sifuri bila maelezo. Mtindo huo, kama ilivyo kesi ya hitilafu isiyoonekana, unaficha hitilafu nyuma ya hoja (query) inayoonekana kufanikiwa. Kwa pamoja, mfululizo huu unalenga kufichua upande wa “uvumi” wa API ya Supabase na kuwapa watengenezaji zana madhubuti za kudai ukweli.

Funzo: Muundo wa Supabase-JS unaruhusu uandishi ulioshindwa kuonekana kama mafanikio isipokuwa ukumbuke kusoma uwanja wa error. Kwa kufunika wito kwenye msaidizi unaosimamiwa na TypeScript unaofanya error kuwa lazima na kuirekodi kwenye Sentry, unageuza hitilafu zisizoonekana kuwa matukio yanayoonekana na yanayoweza kushughulikiwa. Ongezeko dogo la ukubwa wa kodi unakununulia uaminifu wa data na imani ya mtumiaji—vitu viwili ambavyo mafanikio yoyote yasiyoonekana hayawezi kuleta kamwe.