JavaScript WeakRef Observer પેટર્ન: મેમરી-અવેર ઇવેન્ટ સિસ્ટમ્સનું નિર્માણ

આધુનિક વેબ ડેવલપમેન્ટની દુનિયામાં, સિંગલ પેજ એપ્લિકેશન્સ (SPAs) ગતિશીલ અને પ્રતિભાવશીલ વપરાશકર્તા અનુભવો બનાવવા માટેનું ધોરણ બની ગઈ છે. આ એપ્લિકેશન્સ ઘણીવાર લાંબા સમય સુધી ચાલે છે, જટિલ સ્થિતિનું સંચાલન કરે છે અને અસંખ્ય વપરાશકર્તા ક્રિયાપ્રતિક્રિયાઓને હેન્ડલ કરે છે. જો કે, આ દીર્ધાયુષ્ય એક છુપી કિંમત સાથે આવે છે: મેમરી લીક્સનું વધતું જોખમ. મેમરી લીક, જ્યાં કોઈ એપ્લિકેશનને જરૂર ન હોય તેવી મેમરીને પકડી રાખે છે, તે સમય જતાં પ્રભાવને ઘટાડી શકે છે, જેનાથી સુસ્તતા, બ્રાઉઝર ક્રેશ અને નબળો વપરાશકર્તા અનુભવ થાય છે. આ લીક્સના સૌથી સામાન્ય સ્ત્રોતોમાંથી એક મૂળભૂત ડિઝાઇન પેટર્નમાં રહેલો છે: the Observer પેટર્ન.

The Observer પેટર્ન ઇવેન્ટ-ડ્રિવન આર્કિટેક્ચરનો મુખ્ય આધાર છે, જે ઑબ્જેક્ટ્સ (ઓબ્ઝર્વર્સ) ને કેન્દ્રીય ઑબ્જેક્ટ (વિષય) માંથી અપડેટ્સ સબ્સ્ક્રાઇબ કરવા અને પ્રાપ્ત કરવા સક્ષમ બનાવે છે. તે ભવ્ય, સરળ અને અતિ ઉપયોગી છે. પરંતુ તેના ક્લાસિક અમલીકરણમાં એક નિર્ણાયક ખામી છે: વિષય તેના ઓબ્ઝર્વર્સના મજબૂત સંદર્ભો જાળવી રાખે છે. જો એપ્લિકેશનના બાકીના ભાગને કોઈ ઓબ્ઝર્વરની જરૂર ન હોય, પરંતુ ડેવલપર તેને વિષયમાંથી સ્પષ્ટપણે અનસબ્સ્ક્રાઇબ કરવાનું ભૂલી જાય, તો તે ક્યારેય ગાર્બેજ કલેક્ટ થશે નહીં. તે મેમરીમાં ફસાયેલું રહે છે, જે તમારી એપ્લિકેશનના પ્રદર્શનને નબળું પાડે છે.

અહીં આધુનિક JavaScript, તેની ECMAScript 2021 (ES12) સુવિધાઓ સાથે, એક શક્તિશાળી ઉકેલ પૂરો પાડે છે. WeakRef અને FinalizationRegistry નો લાભ લઈને, આપણે મેમરી-અવેર Observer પેટર્ન બનાવી શકીએ છીએ જે આપમેળે પોતાને સાફ કરે છે, આ સામાન્ય લીક્સને અટકાવે છે. આ લેખ આ અદ્યતન તકનીકમાં ઊંડાણપૂર્વકનો અભ્યાસ છે. આપણે સમસ્યાનું અન્વેષણ કરીશું, સાધનોને સમજીશું, શરૂઆતથી મજબૂત અમલીકરણ બનાવીશું, અને આ શક્તિશાળી પેટર્નને તમારી વૈશ્વિક એપ્લિકેશન્સમાં ક્યારે અને ક્યાં લાગુ કરવી જોઈએ તેની ચર્ચા કરીશું.

મુખ્ય સમસ્યાને સમજવી: ક્લાસિક Observer પેટર્ન અને તેની મેમરી ફૂટપ્રિન્ટ

આપણે ઉકેલની કદર કરી શકીએ તે પહેલાં, આપણે સમસ્યાને સંપૂર્ણપણે સમજવી જોઈએ. The Observer પેટર્ન, જેને પબ્લિશર-સબ્સ્ક્રાઇબર પેટર્ન તરીકે પણ ઓળખવામાં આવે છે, તે ઘટકોને ડિબક કરવા માટે ડિઝાઇન કરવામાં આવી છે. એક Subject (અથવા Publisher) તેના આશ્રિતોની સૂચિ જાળવે છે, જેને Observers (અથવા Subscribers) કહેવાય છે. જ્યારે Subject ની સ્થિતિ બદલાય છે, ત્યારે તે આપમેળે તેના બધા Observers ને સૂચિત કરે છે, સામાન્ય રીતે તેમના પર કોઈ ચોક્કસ પદ્ધતિ, જેમ કે update(), ને કૉલ કરીને.

ચાલો JavaScript માં એક સરળ, ક્લાસિક અમલીકરણ જોઈએ.

એક સરળ Subject અમલીકરણ

અહીં એક મૂળભૂત Subject ક્લાસ છે. તેમાં observers ને સબ્સ્ક્રાઇબ કરવા, અનસબ્સ્ક્રાઇબ કરવા અને સૂચિત કરવા માટેની પદ્ધતિઓ છે.

class ClassicSubject {

  constructor() {

    this.observers = [];

  }

 

  subscribe(observer) {

    this.observers.push(observer);

    console.log(`${observer.name} સબ્સ્ક્રાઇબ થયું છે.`);

  }

 

  unsubscribe(observer) {

    this.observers = this.observers.filter(obs => obs !== observer);

    console.log(`${observer.name} અનસબ્સ્ક્રાઇબ થયું છે.`);

  }

 

  notify(data) {

    console.log('ઓબ્ઝર્વર્સને સૂચિત કરી રહ્યાં છીએ...');

    this.observers.forEach(observer => observer.update(data));

  }

}

અને અહીં એક સરળ Observer ક્લાસ છે જે Subject ને સબ્સ્ક્રાઇબ કરી શકે છે.

class Observer {

  constructor(name) {

    this.name = name;

  }

 

  update(data) {

    console.log(`${this.name} ને ડેટા પ્રાપ્ત થયો: ${data}`);

  }

}

છુપાયેલ ભય: લંબાતા સંદર્ભો

આ અમલીકરણ ત્યાં સુધી સંપૂર્ણ રીતે કાર્ય કરે છે જ્યાં સુધી આપણે આપણા ઓબ્ઝર્વર્સના જીવનચક્રનું ખંતપૂર્વક સંચાલન કરીએ છીએ. સમસ્યા ત્યારે ઊભી થાય છે જ્યારે આપણે તેમ કરતા નથી. એક મોટી એપ્લિકેશનમાં એક સામાન્ય દૃશ્યનો વિચાર કરો: એક લાંબા સમય સુધી ચાલતું વૈશ્વિક ડેટા સ્ટોર (Subject) અને એક અસ્થાયી UI ઘટક (Observer) જે તે ડેટામાંથી કેટલાકને પ્રદર્શિત કરે છે.

ચાલો આ દૃશ્યનું અનુકરણ કરીએ:

const dataStore = new ClassicSubject();

 

function manageUIComponent() {

  let chartComponent = new Observer('ChartComponent');

  dataStore.subscribe(chartComponent);

 

  // ઘટક તેનું કાર્ય કરે છે...

 

  // હવે, વપરાશકર્તા દૂર નેવિગેટ કરે છે, અને ઘટકની હવે જરૂર નથી.

  // એક ડેવલપર ક્લિનઅપ કોડ ઉમેરવાનું ભૂલી શકે છે:

  // dataStore.unsubscribe(chartComponent);

 

  chartComponent = null; // અમે ઘટકનો અમારો સંદર્ભ મુક્ત કરીએ છીએ.

}

 

manageUIComponent();

 

// એપ્લિકેશન જીવનચક્રમાં પછીથી...

dataStore.notify('નવો ડેટા ઉપલબ્ધ છે!');

In the `manageUIComponent` function, we create a `chartComponent` and subscribe it to our `dataStore`. Later, we set `chartComponent` to `null`, signaling that we are done with it. We expect the JavaScript garbage collector (GC) to see that there are no more references to this object and reclaim its memory.

But there is another reference! The `dataStore.observers` array still holds a direct, strong reference to the `chartComponent` object. Because of this single lingering reference, the garbage collector cannot reclaim the memory. The `chartComponent` object, and any resources it holds, will remain in memory for the entire lifetime of the `dataStore`. If this happens repeatedly—for example, every time a user opens and closes a modal window—the application's memory usage will grow indefinitely. This is a classic memory leak.

એક નવી આશા: WeakRef અને FinalizationRegistry નો પરિચય

ECMAScript 2021 એ ખાસ કરીને આ પ્રકારના મેમરી મેનેજમેન્ટ પડકારોને હેન્ડલ કરવા માટે બે નવી સુવિધાઓ રજૂ કરી: `WeakRef` અને `FinalizationRegistry`. તે અદ્યતન સાધનો છે અને તેનો ઉપયોગ સાવચેતીપૂર્વક થવો જોઈએ, પરંતુ આપણી Observer પેટર્નની સમસ્યા માટે, તે સંપૂર્ણ ઉકેલ છે.

WeakRef શું છે?

એક `WeakRef` ઑબ્જેક્ટ અન્ય ઑબ્જેક્ટનો નબળો સંદર્ભ ધરાવે છે, જેને તેનું લક્ષ્ય કહેવાય છે. નબળા સંદર્ભ અને સામાન્ય (મજબૂત) સંદર્ભ વચ્ચેનો મુખ્ય તફાવત આ છે: એક નબળો સંદર્ભ તેના લક્ષ્ય ઑબ્જેક્ટને ગાર્બેજ કલેક્ટ થતા અટકાવતો નથી.

જો કોઈ ઑબ્જેક્ટના એકમાત્ર સંદર્ભો નબળા સંદર્ભો હોય, તો JavaScript એન્જિન ઑબ્જેક્ટનો નાશ કરવા અને તેની મેમરી પાછી મેળવવા માટે સ્વતંત્ર છે. આ જ આપણને આપણી Observer સમસ્યા હલ કરવા માટે જોઈએ છે.

WeakRef નો ઉપયોગ કરવા માટે, તમે તેનો એક ઉદાહરણ બનાવો છો, લક્ષ્ય ઑબ્જેક્ટને કન્સ્ટ્રક્ટરને પાસ કરો છો. પછીથી લક્ષ્ય ઑબ્જેક્ટને ઍક્સેસ કરવા માટે, તમે deref() પદ્ધતિનો ઉપયોગ કરો છો.

let targetObject = { id: 42 };

const weakRefToObject = new WeakRef(targetObject);

 

// ઑબ્જેક્ટને ઍક્સેસ કરવા માટે:

const retrievedObject = weakRefToObject.deref();

 

if (retrievedObject) {

  console.log(`ઑબ્જેક્ટ હજી જીવંત છે: ${retrievedObject.id}`); // આઉટપુટ: ઑબ્જેક્ટ હજી જીવંત છે: 42

} else {

  console.log('ઑબ્જેક્ટ ગાર્બેજ કલેક્ટ થઈ ગયું છે.');

}

The crucial part is that `deref()` can return `undefined`. This happens if the `targetObject` has been garbage collected because no strong references to it exist anymore. This behavior is the foundation of our memory-aware Observer pattern.

FinalizationRegistry શું છે?

જ્યારે `WeakRef` ઑબ્જેક્ટને કલેક્ટ થવા દે છે, ત્યારે તે ક્યારે કલેક્ટ થયું છે તે જાણવાનો સ્પષ્ટ માર્ગ આપતો નથી. આપણે સમયાંતરે `deref()` તપાસી શકીએ છીએ અને આપણા ઓબ્ઝર્વર સૂચિમાંથી `undefined` પરિણામોને દૂર કરી શકીએ છીએ, પરંતુ તે બિનકાર્યક્ષમ છે. અહીં `FinalizationRegistry` કામમાં આવે છે.

A `FinalizationRegistry` lets you register a callback function that will be invoked after a registered object has been garbage collected. It's a mechanism for post-mortem cleanup.

તે કેવી રીતે કાર્ય કરે છે તે અહીં છે:

1. તમે ક્લિનઅપ કૉલબૅક સાથે રજિસ્ટ્રી બનાવો છો.
2. તમે રજિસ્ટ્રી સાથે ઑબ્જેક્ટને `register()` કરો છો. તમે એક `heldValue` પણ પ્રદાન કરી શકો છો, જે ડેટાનો એક ભાગ છે જે ઑબ્જેક્ટ કલેક્ટ થાય ત્યારે તમારા કૉલબૅકને પાસ કરવામાં આવશે. આ `heldValue` ઑબ્જેક્ટનો સીધો સંદર્ભ ન હોવો જોઈએ, કારણ કે તે હેતુને હરાવી દેશે!

// 1. ક્લિનઅપ કૉલબૅક સાથે રજિસ્ટ્રી બનાવો

const registry = new FinalizationRegistry(heldValue => {

  console.log(`એક ઑબ્જેક્ટ ગાર્બેજ કલેક્ટ થઈ ગયું છે. ક્લિનઅપ ટોકન: ${heldValue}`);

});

 

(function() {

  let objectToTrack = { name: 'અસ્થાયી ડેટા' };

  let cleanupToken = 'temp-data-123';

 

  // 2. ઑબ્જેક્ટને રજિસ્ટર કરો અને ક્લિનઅપ માટે ટોકન પ્રદાન કરો

  registry.register(objectToTrack, cleanupToken);

 

  // objectToTrack અહીં અવકાશની બહાર જાય છે

})();

 

// ભવિષ્યમાં કોઈક સમયે, GC ચાલ્યા પછી, કન્સોલ લોગ કરશે:

// "એક ઑબ્જેક્ટ ગાર્બેજ કલેક્ટ થઈ ગયું છે. ક્લિનઅપ ટોકન: temp-data-123"

મહત્વપૂર્ણ સાવચેતીઓ અને શ્રેષ્ઠ પદ્ધતિઓ

અમલીકરણમાં ઊંડાણપૂર્વક અભ્યાસ કરતા પહેલા, આ સાધનોના સ્વભાવને સમજવું મહત્વપૂર્ણ છે. ગાર્બેજ કલેક્ટરનું વર્તન અમલીકરણ-આધારિત અને બિન-નિર્ધારિત હોય છે. આનો અર્થ છે:

• તમે ભવિષ્યવાણી કરી શકતા નથી કે ક્યારે કોઈ ઑબ્જેક્ટ કલેક્ટ થશે. તે અપ્રાપ્ય બન્યા પછી સેકન્ડો, મિનિટો અથવા તેનાથી પણ લાંબા સમય સુધી હોઈ શકે છે.
• તમે FinalizationRegistry કૉલબૅક્સ સમયસર અથવા અનુમાનિત રીતે ચાલવા પર નિર્ભર રહી શકતા નથી. તે ક્લિનઅપ માટે છે, નિર્ણાયક એપ્લિકેશન લોજિક માટે નથી.
• WeakRef અને FinalizationRegistry નો અતિશય ઉપયોગ કોડને સમજવામાં મુશ્કેલ બનાવી શકે છે. જો ઑબ્જેક્ટના જીવનચક્ર સ્પષ્ટ અને વ્યવસ્થિત હોય તો હંમેશા સરળ ઉકેલો (જેમ કે સ્પષ્ટ unsubscribe કૉલ્સ) ને પસંદ કરો.

આ સુવિધાઓ એવી પરિસ્થિતિઓ માટે શ્રેષ્ઠ અનુકુળ છે જ્યાં એક ઑબ્જેક્ટ (ઓબ્ઝર્વર) નું જીવનચક્ર ખરેખર બીજા ઑબ્જેક્ટ (વિષય) થી સ્વતંત્ર અને અજાણ હોય.

`WeakRefObserver` પેટર્નનું નિર્માણ: એક સ્ટેપ-બાય-સ્ટેપ અમલીકરણ

હવે, ચાલો મેમરી-સેફ `WeakRefSubject` ક્લાસ બનાવવા માટે `WeakRef` અને `FinalizationRegistry` ને જોડીએ.

પગલું 1: `WeakRefSubject` ક્લાસ સ્ટ્રક્ચર

આપણો નવો ક્લાસ સીધા સંદર્ભોને બદલે observers માટે `WeakRef` સંગ્રહિત કરશે. તેમાં observers સૂચિના સ્વચાલિત ક્લિનઅપને હેન્ડલ કરવા માટે `FinalizationRegistry` પણ હશે.

class WeakRefSubject {

  constructor() {

    this.observers = new Set(); // સરળ દૂર કરવા માટે Set નો ઉપયોગ

 

    // ફાઇનાલાઇઝર કૉલબૅક. તે રજિસ્ટ્રેશન દરમિયાન આપણે પ્રદાન કરેલ હેલ્ડ વેલ્યુ પ્રાપ્ત કરે છે.

    // આપણા કિસ્સામાં, હેલ્ડ વેલ્યુ પોતે WeakRef ઇન્સ્ટન્સ હશે.

    this.cleanupRegistry = new FinalizationRegistry(weakRefObserver => {

      console.log('ફાઇનાલાઇઝર: એક ઓબ્ઝર્વર ગાર્બેજ કલેક્ટ થઈ ગયું છે. ક્લિનઅપ કરી રહ્યાં છીએ...');

      this.observers.delete(weakRefObserver);

    });

  }

}

આપણે આપણા observers સૂચિ માટે `Array` ને બદલે `Set` નો ઉપયોગ કરીએ છીએ. આ એટલા માટે છે કારણ કે `Set` માંથી આઇટમ કાઢી નાખવી એ `Array` ને ફિલ્ટર કરવા (O(n)) કરતાં ઘણી વધુ કાર્યક્ષમ (O(1) સરેરાશ સમય જટિલતા) છે, જે આપણા ક્લિનઅપ લોજિકમાં ઉપયોગી થશે.

પગલું 2: `subscribe` પદ્ધતિ

subscribe પદ્ધતિથી જાદુ શરૂ થાય છે. જ્યારે કોઈ ઓબ્ઝર્વર સબ્સ્ક્રાઇબ કરે છે, ત્યારે આપણે:

1. ઓબ્ઝર્વર તરફ નિર્દેશ કરતો `WeakRef` બનાવીશું.
2. આ `WeakRef` ને આપણા `observers` સેટમાં ઉમેરીશું.
3. મૂળ ઓબ્ઝર્વર ઑબ્જેક્ટને આપણા `FinalizationRegistry` સાથે રજિસ્ટર કરીશું, નવા બનાવેલા `WeakRef` નો `heldValue` તરીકે ઉપયોગ કરીને.

// WeakRefSubject ક્લાસની અંદર...

subscribe(observer) {

  // આ સંદર્ભ સાથેનો ઓબ્ઝર્વર પહેલાથી જ અસ્તિત્વમાં છે કે કેમ તે તપાસો

  for (const ref of this.observers) {

    if (ref.deref() === observer) {

      console.warn('ઓબ્ઝર્વર પહેલાથી જ સબ્સ્ક્રાઇબ થયેલ છે.');

      return;

    }

  }

 

  const weakRefObserver = new WeakRef(observer);

  this.observers.add(weakRefObserver);

 

  // મૂળ ઓબ્ઝર્વર ઑબ્જેક્ટને રજિસ્ટર કરો. જ્યારે તે કલેક્ટ થાય,

  // ત્યારે ફાઇનાલાઇઝરને `weakRefObserver` દલીલ તરીકે કૉલ કરવામાં આવશે.

  this.cleanupRegistry.register(observer, weakRefObserver);

 

  console.log('એક ઓબ્ઝર્વર સબ્સ્ક્રાઇબ થયું છે.');

}

આ સેટઅપ એક ચતુરાઈભર્યો લૂપ બનાવે છે: વિષય ઓબ્ઝર્વરનો નબળો સંદર્ભ ધરાવે છે. રજિસ્ટ્રી ઓબ્ઝર્વરનો મજબૂત સંદર્ભ (આંતરિક રીતે) ધરાવે છે જ્યાં સુધી તે ગાર્બેજ કલેક્ટ ન થાય. એકવાર કલેક્ટ થયા પછી, રજિસ્ટ્રીનું કૉલબૅક નબળા સંદર્ભ ઇન્સ્ટન્સ સાથે ટ્રિગર થાય છે, જેનો ઉપયોગ આપણે આપણા `observers` સેટને સાફ કરવા માટે કરી શકીએ છીએ.

પગલું 3: `unsubscribe` પદ્ધતિ

સ્વચાલિત ક્લિનઅપ હોવા છતાં, આપણે હજી પણ મેન્યુઅલ `unsubscribe` પદ્ધતિ પ્રદાન કરવી જોઈએ તેવા કિસ્સાઓ માટે જ્યાં નિર્ધારિત દૂર કરવાની જરૂર છે. આ પદ્ધતિને આપણા સેટમાં યોગ્ય `WeakRef` શોધવાની જરૂર પડશે, દરેકને ડિરેફરન્સ કરીને અને તેને આપણે દૂર કરવા માંગતા ઓબ્ઝર્વર સાથે સરખાવીને.

// WeakRefSubject ક્લાસની અંદર...

unsubscribe(observer) {

  let refToRemove = null;

  for (const weakRef of this.observers) {

    if (weakRef.deref() === observer) {

      refToRemove = weakRef;

      break;

    }

  }

 

  if (refToRemove) {

    this.observers.delete(refToRemove);

    // મહત્વપૂર્ણ: આપણે ફાઇનાલાઇઝરમાંથી પણ અનરજિસ્ટર કરવું જોઈએ

    // જેથી કૉલબૅક પછીથી બિનજરૂરી રીતે ચાલતું અટકે.

    this.cleanupRegistry.unregister(observer);

    console.log('એક ઓબ્ઝર્વર મેન્યુઅલી અનસબ્સ્ક્રાઇબ થયું છે.');

  }

}

પગલું 4: `notify` પદ્ધતિ

notify પદ્ધતિ આપણા `WeakRef` ના સેટ પર પુનરાવર્તિત થાય છે. દરેક માટે, તે વાસ્તવિક ઓબ્ઝર્વર ઑબ્જેક્ટ મેળવવા માટે તેને `deref()` કરવાનો પ્રયાસ કરે છે. જો `deref()` સફળ થાય, તો તેનો અર્થ છે કે ઓબ્ઝર્વર હજી જીવંત છે, અને આપણે તેની `update` પદ્ધતિને કૉલ કરી શકીએ છીએ. જો તે `undefined` પરત કરે છે, તો ઓબ્ઝર્વર કલેક્ટ થઈ ગયું છે, અને આપણે તેને ફક્ત અવગણી શકીએ છીએ. `FinalizationRegistry` આખરે તેના `WeakRef` ને સેટમાંથી દૂર કરશે.

// WeakRefSubject ક્લાસની અંદર...

notify(data) {

  console.log('ઓબ્ઝર્વર્સને સૂચિત કરી રહ્યાં છીએ...');

  for (const weakRefObserver of this.observers) {

    const observer = weakRefObserver.deref();

    if (observer) {

      // ઓબ્ઝર્વર હજી જીવંત છે

      observer.update(data);

    } else {

      // ઓબ્ઝર્વર ગાર્બેજ કલેક્ટ થઈ ગયું છે.

      // FinalizationRegistry આ WeakRef ને સેટમાંથી દૂર કરવાનું સંભાળશે.

      console.log('સૂચના દરમિયાન ડેડ ઓબ્ઝર્વર સંદર્ભ મળ્યો.');

    }

  }

}

બધું એકસાથે મૂકવું: એક વ્યવહારુ ઉદાહરણ

ચાલો આપણા UI ઘટકના દૃશ્યને ફરીથી જોઈએ, પરંતુ આ વખતે આપણા નવા `WeakRefSubject` નો ઉપયોગ કરીને. આપણે સરળતા માટે પહેલાના સમાન `Observer` ક્લાસનો ઉપયોગ કરીશું.

// સમાન સરળ Observer ક્લાસ

class Observer {

  constructor(name) {

    this.name = name;

  }

  update(data) {

    console.log(`${this.name} ને ડેટા પ્રાપ્ત થયો: ${data}`);

  }

}

હવે, ચાલો એક વૈશ્વિક ડેટા સેવા બનાવીએ અને એક અસ્થાયી UI વિજેટનું અનુકરણ કરીએ.

const globalDataService = new WeakRefSubject();

function createAndDestroyWidget() {

  console.log('--- નવું વિજેટ બનાવી અને સબ્સ્ક્રાઇબ કરી રહ્યાં છીએ ---');

  let chartWidget = new Observer('RealTimeChartWidget');

  globalDataService.subscribe(chartWidget);

 

  // વિજેટ હવે સક્રિય છે અને સૂચનાઓ પ્રાપ્ત કરશે

  globalDataService.notify({ price: 100 });

 

  console.log('--- વિજેટનો નાશ કરી રહ્યાં છીએ (અમારો સંદર્ભ મુક્ત કરી રહ્યાં છીએ) ---');

  // આપણે વિજેટ સાથે કામ પૂર્ણ કરી લીધું છે. આપણે આપણા સંદર્ભને null પર સેટ કરીએ છીએ.

  // આપણે unsubscribe() ને કૉલ કરવાની જરૂર નથી.

  chartWidget = null;

}

createAndDestroyWidget();

console.log('--- વિજેટ નાશ પછી, ગાર્બેજ કલેક્શન પહેલા ---');

globalDataService.notify({ price: 105 });

createAndDestroyWidget() ચલાવ્યા પછી, chartWidget ઑબ્જેક્ટ હવે ફક્ત આપણા `globalDataService` ની અંદરના `WeakRef` દ્વારા જ સંદર્ભિત છે. કારણ કે આ એક નબળો સંદર્ભ છે, ઑબ્જેક્ટ હવે ગાર્બેજ કલેક્શન માટે યોગ્ય છે.

જ્યારે ગાર્બેજ કલેક્ટર આખરે ચાલે છે (જેની આપણે ભવિષ્યવાણી કરી શકતા નથી), ત્યારે બે વસ્તુઓ થશે:

1. `chartWidget` ઑબ્જેક્ટ મેમરીમાંથી દૂર કરવામાં આવશે.
2. આપણા `FinalizationRegistry` નું કૉલબૅક ટ્રિગર થશે, જે પછી મૃત `WeakRef` ને `globalDataService.observers` સેટમાંથી દૂર કરશે.

જો આપણે ગાર્બેજ કલેક્ટર ચાલ્યા પછી ફરીથી `notify` કૉલ કરીએ, તો `deref()` કૉલ `undefined` પરત કરશે, મૃત ઓબ્ઝર્વર છોડી દેવામાં આવશે, અને એપ્લિકેશન કોઈપણ મેમરી લીક્સ વિના કાર્યક્ષમ રીતે ચાલવાનું ચાલુ રાખશે. આપણે ઓબ્ઝર્વરના જીવનચક્રને વિષયથી સફળતાપૂર્વક ડિબક કર્યું છે.

`WeakRefObserver` પેટર્નનો ઉપયોગ ક્યારે કરવો (અને ક્યારે ટાળવો)

આ પેટર્ન શક્તિશાળી છે, પરંતુ તે સિલ્વર બુલેટ નથી. તે જટિલતા રજૂ કરે છે અને બિન-નિર્ધારિત વર્તન પર આધાર રાખે છે. તે ક્યારે કાર્ય માટે યોગ્ય સાધન છે તે જાણવું મહત્વપૂર્ણ છે.

આદર્શ ઉપયોગના કિસ્સાઓ

• લાંબા સમય સુધી ચાલતા Subjects અને ટૂંકા સમય સુધી ચાલતા Observers: આ પ્રમાણભૂત ઉપયોગનો કેસ છે. એક વૈશ્વિક સેવા, ડેટા સ્ટોર, અથવા કેશ (Subject) જે સમગ્ર એપ્લિકેશન જીવનચક્ર માટે અસ્તિત્વમાં છે, જ્યારે અસંખ્ય UI ઘટકો, અસ્થાયી કાર્યકરો, અથવા પ્લગઈન્સ (Observers) વારંવાર બનાવવામાં આવે છે અને નાશ પામે છે.
• કેશિંગ મિકેનિઝમ્સ: એક કેશની કલ્પના કરો જે એક જટિલ ઑબ્જેક્ટને કેટલાક ગણતરી કરેલા પરિણામ સાથે મેપ કરે છે. તમે કી ઑબ્જેક્ટ માટે `WeakRef` નો ઉપયોગ કરી શકો છો. જો મૂળ ઑબ્જેક્ટ એપ્લિકેશનના બાકીના ભાગમાંથી ગાર્બેજ કલેક્ટ થાય છે, તો `FinalizationRegistry` આપમેળે તમારી કેશમાં અનુરૂપ એન્ટ્રીને સાફ કરી શકે છે, મેમરી બ્લોટને અટકાવે છે.
• પ્લગઇન અને એક્સટેન્શન આર્કિટેક્ચર્સ: જો તમે એક કોર સિસ્ટમ બનાવી રહ્યા છો જે તૃતીય-પક્ષ મોડ્યુલોને ઇવેન્ટ્સ પર સબ્સ્ક્રાઇબ કરવાની મંજૂરી આપે છે, તો `WeakRefObserver` નો ઉપયોગ સ્થિતિસ્થાપકતાનું સ્તર ઉમેરે છે. તે નબળી રીતે લખેલા પ્લગઇનને અનસબ્સ્ક્રાઇબ કરવાનું ભૂલી જવાને કારણે તમારી કોર એપ્લિકેશનમાં મેમરી લીક થવાથી અટકાવે છે.
• DOM તત્વો પર ડેટા મેપિંગ: ઘોષણાત્મક ફ્રેમવર્ક વિનાના દૃશ્યોમાં, તમે DOM તત્વ સાથે કેટલાક ડેટાને સાંકળવા માંગી શકો છો. જો તમે આને DOM તત્વને કી તરીકે રાખીને નકશામાં સંગ્રહિત કરો છો, તો જો તત્વ DOM માંથી દૂર કરવામાં આવે પરંતુ તમારા નકશામાં હજી પણ હોય તો તમે મેમરી લીક બનાવી શકો છો. `WeakMap` એક સારો વિકલ્પ છે, પરંતુ સિદ્ધાંત સમાન છે: ડેટાનું જીવનચક્ર તત્વના જીવનચક્ર સાથે જોડાયેલું હોવું જોઈએ, તેનાથી વિરુદ્ધ નહીં.

ક્લાસિક Observer સાથે ક્યારે વળગી રહેવું

• ચુસ્તપણે જોડાયેલા જીવનચક્ર: જો વિષય અને તેના ઓબ્ઝર્વર્સ હંમેશા એકસાથે અથવા સમાન અવકાશમાં બનાવવામાં આવે છે અને નાશ પામે છે, તો `WeakRef` ની ઓવરહેડ અને જટિલતા બિનજરૂરી છે. એક સરળ, સ્પષ્ટ `unsubscribe()` કૉલ વધુ વાંચી શકાય તેવું અને અનુમાનિત છે.
• પ્રદર્શન-નિર્ણાયક હોટ પાથ: The `deref()` method has a small but non-zero performance cost. જો તમે સેકન્ડ દીઠ હજારો ઓબ્ઝર્વર્સને સેંકડો વખત સૂચિત કરી રહ્યા છો (દા.ત., એક ગેમ લૂપમાં અથવા ઉચ્ચ-આવર્તન ડેટા વિઝ્યુલાઇઝેશનમાં), તો સીધા સંદર્ભો સાથેનું ક્લાસિક અમલીકરણ ઝડપી હશે.
• સરળ એપ્લિકેશન્સ અને સ્ક્રિપ્ટ્સ: નાની એપ્લિકેશન્સ અથવા સ્ક્રિપ્ટ્સ માટે જ્યાં એપ્લિકેશનનો જીવનકાળ ટૂંકો હોય અને મેમરી મેનેજમેન્ટ નોંધપાત્ર ચિંતાનો વિષય ન હોય, ત્યાં ક્લાસિક પેટર્ન અમલ કરવા અને સમજવામાં સરળ હોય છે. જ્યાં તેની જરૂર ન હોય ત્યાં જટિલતા ઉમેરશો નહીં.
• જ્યારે નિર્ણાયક ક્લિનઅપ જરૂરી હોય: જો તમને કોઈ ઓબ્ઝર્વર અલગ થાય તે જ ક્ષણે કોઈ ક્રિયા કરવાની જરૂર હોય (દા.ત., કાઉન્ટર અપડેટ કરવું, ચોક્કસ હાર્ડવેર સંસાધનને મુક્ત કરવું), તો તમારે અવશ્ય મેન્યુઅલ `unsubscribe()` પદ્ધતિનો ઉપયોગ કરવો જોઈએ. The non-deterministic nature of `FinalizationRegistry` makes it unsuitable for logic that must execute predictably.

સોફ્ટવેર આર્કિટેક્ચર માટે વ્યાપક અસરો

JavaScript જેવી ઉચ્ચ-સ્તરીય ભાષામાં નબળા સંદર્ભોનો પરિચય પ્લેટફોર્મના પરિપક્વતાનો સંકેત આપે છે. તે ડેવલપર્સને વધુ અત્યાધુનિક અને સ્થિતિસ્થાપક સિસ્ટમો બનાવવાની મંજૂરી આપે છે, ખાસ કરીને લાંબા સમય સુધી ચાલતી એપ્લિકેશન્સ માટે. આ પેટર્ન આર્કિટેક્ચરલ વિચારમાં પરિવર્તનને પ્રોત્સાહિત કરે છે:

• સાચું ડિબકલિંગ: તે ડિબકલિંગનું એક સ્તર સક્ષમ કરે છે જે ફક્ત ઇન્ટરફેસથી આગળ વધે છે. આપણે હવે ઘટકોના જીવનચક્રને પણ ડિબક કરી શકીએ છીએ. વિષયને હવે તેના ઓબ્ઝર્વર્સ ક્યારે બનાવવામાં આવે છે કે નાશ પામે છે તે વિશે કંઈપણ જાણવાની જરૂર નથી.
• ડિઝાઇન દ્વારા સ્થિતિસ્થાપકતા: તે સિસ્ટમો બનાવવામાં મદદ કરે છે જે પ્રોગ્રામરની ભૂલ પ્રત્યે વધુ સ્થિતિસ્થાપક હોય. એક ભૂલી ગયેલ `unsubscribe()` કૉલ એક સામાન્ય બગ છે જેને ટ્રેક કરવો મુશ્કેલ હોઈ શકે છે. આ પેટર્ન તે ભૂલોના સમગ્ર વર્ગને ઘટાડે છે.
• ફ્રેમવર્ક અને લાઇબ્રેરી લેખકોને સક્ષમ કરવા: અન્ય ડેવલપર્સ માટે ફ્રેમવર્ક, લાઇબ્રેરીઓ અથવા પ્લેટફોર્મ બનાવનારાઓ માટે, આ સાધનો અમૂલ્ય છે. તે મજબૂત API ના નિર્માણની મંજૂરી આપે છે જે લાઇબ્રેરીના ગ્રાહકો દ્વારા દુરુપયોગ માટે ઓછા સંવેદનશીલ હોય છે, જે એકંદરે વધુ સ્થિર એપ્લિકેશન્સ તરફ દોરી જાય છે.

નિષ્કર્ષ: આધુનિક JavaScript ડેવલપર માટે એક શક્તિશાળી સાધન

ક્લાસિક Observer પેટર્ન સોફ્ટવેર ડિઝાઇનનો એક મૂળભૂત નિર્માણ બ્લોક છે, પરંતુ મજબૂત સંદર્ભો પરનો તેનો આધાર લાંબા સમયથી JavaScript એપ્લિકેશન્સમાં સૂક્ષ્મ અને નિરાશાજનક મેમરી લીક્સનો સ્ત્રોત રહ્યો છે. ES2021 માં `WeakRef` અને `FinalizationRegistry` ના આગમન સાથે, આપણી પાસે હવે આ મર્યાદાને દૂર કરવા માટેના સાધનો છે.

આપણે લંબાતા સંદર્ભોની મૂળભૂત સમસ્યાને સમજવાથી માંડીને શરૂઆતથી જ સંપૂર્ણ, મેમરી-અવેર `WeakRefSubject` બનાવવાની યાત્રા કરી છે. આપણે જોયું છે કે `WeakRef` ઑબ્જેક્ટ્સને કેવી રીતે 'ઓબ્ઝર્વ' કરવામાં આવે ત્યારે પણ ગાર્બેજ કલેક્ટ થવા દે છે, અને કેવી રીતે `FinalizationRegistry` આપણી ઓબ્ઝર્વર સૂચિને સ્વચ્છ રાખવા માટે સ્વચાલિત ક્લિનઅપ મિકેનિઝમ પ્રદાન કરે છે.

જો કે, મહાન શક્તિ સાથે મહાન જવાબદારી આવે છે. આ અદ્યતન સુવિધાઓ છે જેનો બિન-નિર્ધારિત સ્વભાવ કાળજીપૂર્વક વિચારણાની જરૂર છે. તે સારી એપ્લિકેશન ડિઝાઇન અને ખંતપૂર્વક જીવનચક્ર વ્યવસ્થાપનનો વિકલ્પ નથી. પરંતુ જ્યારે લાંબા સમય સુધી ચાલતી સેવાઓ અને અસ્થાયી ઘટકો વચ્ચે સંચારનું સંચાલન જેવા યોગ્ય સમસ્યાઓ પર લાગુ કરવામાં આવે છે - ત્યારે WeakRef Observer પેટર્ન એક અપવાદરૂપે શક્તિશાળી તકનીક છે. તેના પર પ્રભુત્વ મેળવીને, તમે વધુ મજબૂત, કાર્યક્ષમ અને સ્કેલેબલ JavaScript એપ્લિકેશન્સ લખી શકો છો, જે આધુનિક, ગતિશીલ વેબની માંગને પહોંચી વળવા તૈયાર છે.