જાવાસ્ક્રિપ્ટ મોડ્યુલ્સમાં ક્રાંતિ: સોર્સ ફેઝ ઇમ્પોર્ટ્સનું ઊંડાણપૂર્વક વિશ્લેષણ

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

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

વિશ્વભરના ડેવલપર્સ માટે, જાવાસ્ક્રિપ્ટ ટૂલિંગ, ફ્રેમવર્ક અને એપ્લિકેશન આર્કિટેક્ચરમાં નવીનતાની આગામી લહેર માટે તૈયારી કરવા માટે આ પ્રસ્તાવને સમજવો ચાવીરૂપ છે. આ વિસ્તૃત માર્ગદર્શિકા સોર્સ ફેઝ ઇમ્પોર્ટ્સ શું છે, તે કઈ સમસ્યાઓનું નિરાકરણ લાવે છે, તેના વ્યવહારુ ઉપયોગના કિસ્સાઓ અને સમગ્ર વૈશ્વિક જાવાસ્ક્રિપ્ટ સમુદાય પર તેની સંભવિત ઊંડી અસરનું અન્વેષણ કરશે.

જાવાસ્ક્રિપ્ટ મોડ્યુલ્સનો સંક્ષિપ્ત ઇતિહાસ: ESM સુધીનો માર્ગ

સોર્સ ફેઝ ઇમ્પોર્ટ્સના મહત્વને સમજવા માટે, આપણે સૌ પ્રથમ જાવાસ્ક્રિપ્ટ મોડ્યુલ્સની યાત્રાને સમજવી જોઈએ. તેના ઇતિહાસના મોટા ભાગના સમય માટે, જાવાસ્ક્રિપ્ટમાં નેટિવ મોડ્યુલ સિસ્ટમનો અભાવ હતો, જેના કારણે સર્જનાત્મક પરંતુ ખંડિત ઉકેલોનો સમયગાળો આવ્યો.

ગ્લોબલ્સ અને IIFEsનો યુગ

શરૂઆતમાં, ડેવલપર્સ HTML ફાઇલમાં બહુવિધ <script> ટૅગ્સ લોડ કરીને ડિપેન્ડન્સીઝનું સંચાલન કરતા હતા. આનાથી ગ્લોબલ નેમસ્પેસ (બ્રાઉઝરમાં window ઑબ્જેક્ટ) પ્રદૂષિત થયું, જેના કારણે વેરિયેબલ ટકરાવ, અણધારી લોડિંગ ક્રમ અને જાળવણી માટે એક દુઃસ્વપ્ન સર્જાયું. આને ઘટાડવા માટે એક સામાન્ય પેટર્ન હતી ઇમિડિએટલી ઇન્વોક્ડ ફંક્શન એક્સપ્રેશન (IIFE), જેણે સ્ક્રિપ્ટના વેરિયેબલ્સ માટે એક ખાનગી સ્કોપ બનાવ્યો, તેમને ગ્લોબલ સ્કોપમાં લીક થતા અટકાવ્યા.

સમુદાય-સંચાલિત ધોરણોનો ઉદય

જેમ જેમ એપ્લિકેશન્સ વધુ જટિલ બનતી ગઈ, તેમ તેમ સમુદાયે વધુ મજબૂત ઉકેલો વિકસાવ્યા:

• CommonJS (CJS): Node.js દ્વારા લોકપ્રિય, CJS એક સિંક્રોનસ require() ફંક્શન અને exports ઑબ્જેક્ટનો ઉપયોગ કરે છે. તે સર્વર માટે ડિઝાઇન કરવામાં આવ્યું હતું, જ્યાં ફાઇલસિસ્ટમમાંથી મોડ્યુલ્સ વાંચવું એ એક ઝડપી, બ્લોકિંગ ઓપરેશન છે. તેની સિંક્રોનસ પ્રકૃતિ તેને બ્રાઉઝર માટે ઓછી યોગ્ય બનાવે છે, જ્યાં નેટવર્ક વિનંતીઓ એસિંક્રોનસ હોય છે.
• એસિંક્રોનસ મોડ્યુલ ડેફિનેશન (AMD): બ્રાઉઝર માટે રચાયેલ, AMD (અને તેનું સૌથી લોકપ્રિય અમલીકરણ, RequireJS) મોડ્યુલ્સને એસિંક્રોનસ રીતે લોડ કરે છે. તેની સિન્ટેક્સ CommonJS કરતાં વધુ વર્ણનાત્મક હતી પરંતુ ક્લાયન્ટ-સાઇડ એપ્લિકેશન્સમાં નેટવર્ક લેટન્સીની સમસ્યાનું નિરાકરણ લાવી.

માનકીકરણ: ES મોડ્યુલ્સ (ESM)

આખરે, ECMAScript 2015 (ES6) એ એક નેટિવ, માનકીકૃત મોડ્યુલ સિસ્ટમ રજૂ કરી: ES મોડ્યુલ્સ. ESM એ સ્વચ્છ, ઘોષણાત્મક સિન્ટેક્સ (import અને export) સાથે બંને વિશ્વના શ્રેષ્ઠ પાસાઓને એકસાથે લાવ્યું જેનું સ્થિર રીતે વિશ્લેષણ કરી શકાય છે. આ સ્થિર પ્રકૃતિ બંડલર્સ જેવા ટૂલ્સને કોડ ચલાવતા પહેલા ટ્રી-શેકિંગ (બિનઉપયોગી કોડ દૂર કરવો) જેવા ઓપ્ટિમાઇઝેશન કરવાની મંજૂરી આપે છે. ESM એસિંક્રોનસ બનવા માટે ડિઝાઇન કરવામાં આવ્યું છે અને હવે તે બ્રાઉઝર્સ અને Node.js પર સાર્વત્રિક ધોરણ છે, જે ખંડિત ઇકોસિસ્ટમને એકીકૃત કરે છે.

આધુનિક ES મોડ્યુલ્સની છુપી મર્યાદાઓ

ESM એક મોટી સફળતા છે, પરંતુ તેની ડિઝાઇન ફક્ત રનટાઇમ વર્તન પર કેન્દ્રિત છે. એક import સ્ટેટમેન્ટ એક ડિપેન્ડન્સી દર્શાવે છે જેને એપ્લિકેશન ચાલતી વખતે મેળવવી, પાર્સ કરવી અને એક્ઝિક્યુટ કરવી આવશ્યક છે. આ રનટાઇમ-કેન્દ્રિત મોડેલ, શક્તિશાળી હોવા છતાં, ઘણા પડકારો બનાવે છે જેનું ઇકોસિસ્ટમ બાહ્ય, બિન-પ્રમાણભૂત ટૂલ્સ વડે નિરાકરણ લાવી રહ્યું છે.

સમસ્યા 1: બિલ્ડ-ટાઇમ ડિપેન્ડન્સીઝનો પ્રસાર

આધુનિક વેબ ડેવલપમેન્ટ બિલ્ડ સ્ટેપ પર ભારે આધાર રાખે છે. અમે અમારા સોર્સ કોડને પ્રોડક્શન માટે ઓપ્ટિમાઇઝ્ડ ફોર્મેટમાં રૂપાંતરિત કરવા માટે TypeScript, Babel, Vite, Webpack, અને PostCSS જેવા ટૂલ્સનો ઉપયોગ કરીએ છીએ. આ પ્રક્રિયામાં ઘણી ડિપેન્ડન્સીઝનો સમાવેશ થાય છે જેની જરૂર ફક્ત બિલ્ડ ટાઇમ પર હોય છે, રનટાઇમ પર નહીં.

TypeScriptનો વિચાર કરો. જ્યારે તમે import { type User } from './types' લખો છો, ત્યારે તમે એવી એન્ટિટી ઇમ્પોર્ટ કરી રહ્યા છો જેનું કોઈ રનટાઇમ સમકક્ષ નથી. TypeScript કમ્પાઇલર કમ્પાઇલેશન દરમિયાન આ ઇમ્પોર્ટ અને ટાઇપ માહિતીને ભૂંસી નાખશે. જોકે, જાવાસ્ક્રિપ્ટ મોડ્યુલ સિસ્ટમના દ્રષ્ટિકોણથી, તે માત્ર બીજું એક ઇમ્પોર્ટ છે. બંડલર્સ અને એન્જિનોએ આ "ટાઇપ-ઓન્લી" ઇમ્પોર્ટ્સને હેન્ડલ કરવા અને કાઢી નાખવા માટે વિશેષ લોજિક હોવું જરૂરી છે, એક ઉકેલ જે જાવાસ્ક્રિપ્ટ ભાષા સ્પષ્ટીકરણની બહાર અસ્તિત્વમાં છે.

સમસ્યા 2: ઝીરો-કોસ્ટ એબ્સ્ટ્રેક્શન્સની શોધ

ઝીરો-કોસ્ટ એબ્સ્ટ્રેક્શન એક એવી સુવિધા છે જે ડેવલપમેન્ટ દરમિયાન ઉચ્ચ-સ્તરની સુવિધા પૂરી પાડે છે પરંતુ કોઈ રનટાઇમ ઓવરહેડ વિના અત્યંત કાર્યક્ષમ કોડમાં કમ્પાઇલ થાય છે. એક સંપૂર્ણ ઉદાહરણ વેલિડેશન લાઇબ્રેરી છે. તમે લખી શકો છો:

validate(userSchema, userData);

રનટાઇમ પર, આમાં ફંક્શન કોલ અને વેલિડેશન લોજિકનું એક્ઝિક્યુશન સામેલ છે. શું થશે જો ભાષા, બિલ્ડ ટાઇમ પર, સ્કીમાનું વિશ્લેષણ કરી શકે અને અત્યંત વિશિષ્ટ, ઇનલાઇન વેલિડેશન કોડ જનરેટ કરી શકે, જે અંતિમ બંડલમાંથી સામાન્ય `validate` ફંક્શન કોલ અને સ્કીમા ઑબ્જેક્ટને દૂર કરે? આ હાલમાં માનકીકૃત રીતે કરવું અશક્ય છે. સમગ્ર `validate` ફંક્શન અને `userSchema` ઑબ્જેક્ટ ક્લાયન્ટને મોકલવા આવશ્યક છે, ભલે વેલિડેશન અલગ રીતે કરી શકાયું હોત અથવા પ્રી-કમ્પાઇલ કરી શકાયું હોત.

સમસ્યા 3: માનકીકૃત મેક્રોનો અભાવ

મેક્રો રસ્ટ, લિસ્પ અને સ્વિફ્ટ જેવી ભાષાઓમાં એક શક્તિશાળી સુવિધા છે. તે અનિવાર્યપણે કોડ છે જે કમ્પાઇલ સમયે કોડ લખે છે. જાવાસ્ક્રિપ્ટમાં, આપણે Babel પ્લગઇન્સ અથવા SWC ટ્રાન્સફોર્મ્સ જેવા ટૂલ્સનો ઉપયોગ કરીને મેક્રોનું અનુકરણ કરીએ છીએ. સૌથી સર્વવ્યાપક ઉદાહરણ JSX છે:

const element = <h1>Hello, World</h1>;

આ માન્ય જાવાસ્ક્રિપ્ટ નથી. એક બિલ્ડ ટૂલ તેને આમાં રૂપાંતરિત કરે છે:

const element = React.createElement('h1', null, 'Hello, World');

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

સોર્સ ફેઝ ઇમ્પોર્ટ્સનો પરિચય: એક પેરાડાઈમ શિફ્ટ

સોર્સ ફેઝ ઇમ્પોર્ટ્સ આ મર્યાદાઓનો સીધો જવાબ છે. આ પ્રસ્તાવ એક નવી ઇમ્પોર્ટ ડિક્લેરેશન સિન્ટેક્સ રજૂ કરે છે જે સ્પષ્ટપણે બિલ્ડ-ટાઇમ ડિપેન્ડન્સીઝને રનટાઇમ ડિપેન્ડન્સીઝથી અલગ કરે છે.

નવી સિન્ટેક્સ સરળ અને સહજ છે: import source.

import { MyType } from './types.js'; // એક માનક, રનટાઇમ ઇમ્પોર્ટ
import source { MyMacro } from './macros.js'; // એક નવું, સોર્સ ફેઝ ઇમ્પોર્ટ

મૂળભૂત ખ્યાલ: ફેઝ સેપરેશન (તબક્કાનું વિભાજન)

મુખ્ય વિચાર કોડ મૂલ્યાંકનના બે અલગ-અલગ તબક્કાઓને ઔપચારિક બનાવવાનો છે:

1. સોર્સ ફેઝ (બિલ્ડ ટાઇમ): આ તબક્કો સૌ પ્રથમ થાય છે, જે જાવાસ્ક્રિપ્ટ "હોસ્ટ" (જેમ કે બંડલર, Node.js અથવા Deno જેવું રનટાઇમ, અથવા બ્રાઉઝરનું ડેવલપમેન્ટ/બિલ્ડ એન્વાયર્નમેન્ટ) દ્વારા સંચાલિત થાય છે. આ તબક્કા દરમિયાન, હોસ્ટ import source ડિક્લેરેશન્સ શોધે છે. તે પછી આ મોડ્યુલ્સને એક ખાસ, અલગ વાતાવરણમાં લોડ અને એક્ઝિક્યુટ કરે છે. આ મોડ્યુલ્સ તેમને ઇમ્પોર્ટ કરતા મોડ્યુલ્સના સોર્સ કોડનું નિરીક્ષણ અને રૂપાંતર કરી શકે છે.
2. રનટાઇમ ફેઝ (એક્ઝિક્યુશન ટાઇમ): આ તે તબક્કો છે જેનાથી આપણે બધા પરિચિત છીએ. જાવાસ્ક્રિપ્ટ એન્જિન અંતિમ, સંભવિત રૂપાંતરિત કોડને એક્ઝિક્યુટ કરે છે. import source દ્વારા ઇમ્પોર્ટ કરાયેલા તમામ મોડ્યુલ્સ અને તેમનો ઉપયોગ કરતો કોડ સંપૂર્ણપણે જતો રહે છે; તેઓ રનટાઇમ મોડ્યુલ ગ્રાફમાં કોઈ નિશાન છોડતા નથી.

તેને ભાષાના સ્પષ્ટીકરણમાં સીધા જ બનેલા એક માનકીકૃત, સુરક્ષિત અને મોડ્યુલ-અવેર પ્રીપ્રોસેસર તરીકે વિચારો. તે C પ્રીપ્રોસેસરની જેમ માત્ર ટેક્સ્ટ સબસ્ટિટ્યુશન નથી; તે એક ઊંડાણપૂર્વક સંકલિત સિસ્ટમ છે જે જાવાસ્ક્રિપ્ટની રચના, જેમ કે એબ્સ્ટ્રેક્ટ સિન્ટેક્સ ટ્રીઝ (ASTs) સાથે કામ કરી શકે છે.

મુખ્ય ઉપયોગના કિસ્સાઓ અને વ્યવહારુ ઉદાહરણો

સોર્સ ફેઝ ઇમ્પોર્ટ્સની સાચી શક્તિ ત્યારે સ્પષ્ટ થાય છે જ્યારે આપણે જોઈએ છીએ કે તે કઈ સમસ્યાઓનું સુંદર રીતે નિરાકરણ લાવી શકે છે. ચાલો કેટલાક સૌથી પ્રભાવશાળી ઉપયોગના કિસ્સાઓનું અન્વેષણ કરીએ.

ઉપયોગ કેસ 1: નેટિવ, ઝીરો-કોસ્ટ ટાઇપ એનોટેશન્સ

આ પ્રસ્તાવ માટેના પ્રાથમિક પ્રેરકોમાંનું એક TypeScript અને Flow જેવી ટાઇપ સિસ્ટમ્સને જાવાસ્ક્રિપ્ટ ભાષામાં જ એક નેટિવ ઘર પૂરું પાડવાનું છે. હાલમાં, `import type { ... }` એ TypeScript-વિશિષ્ટ સુવિધા છે. સોર્સ ફેઝ ઇમ્પોર્ટ્સ સાથે, આ એક માનક ભાષાકીય રચના બની જાય છે.

વર્તમાન (TypeScript):

// types.ts
export interface User {
id: number;
name: string;
}

// app.ts
import type { User } from './types';
const user: User = { id: 1, name: 'Alice' };

ભવિષ્ય (માનક જાવાસ્ક્રિપ્ટ):

// types.js
export interface User { /* ... */ } // એમ માનીને કે ટાઇપ સિન્ટેક્સ પ્રસ્તાવ પણ અપનાવવામાં આવે છે

// app.js
import source { User } from './types.js';
const user: User = { id: 1, name: 'Alice' };

લાભ: import source સ્ટેટમેન્ટ કોઈપણ જાવાસ્ક્રિપ્ટ ટૂલ અથવા એન્જિનને સ્પષ્ટપણે જણાવે છે કે ./types.js ફક્ત બિલ્ડ-ટાઇમ ડિપેન્ડન્સી છે. રનટાઇમ એન્જિન તેને ક્યારેય મેળવવાનો કે પાર્સ કરવાનો પ્રયાસ કરશે નહીં. આ ટાઇપ ઇરેઝરના ખ્યાલને માનકીકૃત કરે છે, તેને ભાષાનો ઔપચારિક ભાગ બનાવે છે અને બંડલર્સ, લિંટર્સ અને અન્ય ટૂલ્સના કામને સરળ બનાવે છે.

ઉપયોગ કેસ 2: શક્તિશાળી અને હાઇજેનિક મેક્રો

મેક્રો સોર્સ ફેઝ ઇમ્પોર્ટ્સનો સૌથી પરિવર્તનકારી ઉપયોગ છે. તે ડેવલપર્સને જાવાસ્ક્રિપ્ટની સિન્ટેક્સને વિસ્તારવા અને સુરક્ષિત અને માનકીકૃત રીતે શક્તિશાળી, ડોમેન-વિશિષ્ટ ભાષાઓ (DSLs) બનાવવા દે છે.

ચાલો એક સરળ લોગિંગ મેક્રોની કલ્પના કરીએ જે બિલ્ડ સમયે આપમેળે ફાઇલ અને લાઇન નંબરનો સમાવેશ કરે છે.

મેક્રોની વ્યાખ્યા:

// macros.js
export function log(macroContext) {
// 'macroContext' કોલ સાઇટનું નિરીક્ષણ કરવા માટે APIs પ્રદાન કરશે
const callSite = macroContext.getCallSiteInfo(); // દા.ત., { file: 'app.js', line: 5 }
const messageArgument = macroContext.getArgument(0); // મેસેજ માટે AST મેળવો // console.log કોલ માટે નવું AST પરત કરો
return `console.log("[${callSite.file}:${callSite.line}]", ${messageArgument})`;
}

મેક્રોનો ઉપયોગ:

// app.js
import source { log } from './macros.js'; const value = 42;
log(`The value is: ${value}`);

કમ્પાઇલ થયેલો રનટાઇમ કોડ:

// app.js (સોર્સ ફેઝ પછી)
const value = 42;
console.log("[app.js:5]", `The value is: ${value}`);

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

ઉપયોગ કેસ 3: સંકલિત બિલ્ડ-ટાઇમ કોડ જનરેશન

ઘણી એપ્લિકેશન્સ અન્ય સ્રોતોમાંથી કોડ જનરેટ કરવા પર આધાર રાખે છે, જેમ કે GraphQL સ્કીમા, પ્રોટોકોલ બફર્સ ડેફિનેશન, અથવા YAML અથવા JSON જેવી સાદી ડેટા ફાઇલ.

કલ્પના કરો કે તમારી પાસે GraphQL સ્કીમા છે અને તમે તેના માટે ઓપ્ટિમાઇઝ્ડ ક્લાયન્ટ જનરેટ કરવા માંગો છો. આજે, આ માટે બાહ્ય CLI ટૂલ્સ અને જટિલ બિલ્ડ સેટઅપની જરૂર છે. સોર્સ ફેઝ ઇમ્પોર્ટ્સ સાથે, તે તમારા મોડ્યુલ ગ્રાફનો એક સંકલિત ભાગ બની શકે છે.

જનરેટર મોડ્યુલ:

// graphql-codegen.js
export function createClient(schemaText) {
// 1. schemaText ને પાર્સ કરો
// 2. ટાઇપ્ડ ક્લાયન્ટ માટે જાવાસ્ક્રિપ્ટ કોડ જનરેટ કરો
// 3. જનરેટ થયેલા કોડને સ્ટ્રિંગ તરીકે પરત કરો
const generatedCode = `
export const client = {
query: { /* ... જનરેટ થયેલી પદ્ધતિઓ ... */ }
};
`;
return generatedCode;
}

જનરેટરનો ઉપયોગ:

// app.js
// 1. ઇમ્પોર્ટ એસર્શન્સ (એક અલગ સુવિધા) નો ઉપયોગ કરીને સ્કીમાને ટેક્સ્ટ તરીકે ઇમ્પોર્ટ કરો
import schema from './api.graphql' with { type: 'text' }; // 2. સોર્સ ફેઝ ઇમ્પોર્ટનો ઉપયોગ કરીને કોડ જનરેટર ઇમ્પોર્ટ કરો
import source { createClient } from './graphql-codegen.js'; // 3. બિલ્ડ સમયે જનરેટર ચલાવો અને તેના આઉટપુટને ઇન્જેક્ટ કરો
export const { client } = createClient(schema);

લાભ: સમગ્ર પ્રક્રિયા ઘોષણાત્મક છે અને સોર્સ કોડનો ભાગ છે. બાહ્ય કોડ જનરેટર ચલાવવું હવે અલગ, મેન્યુઅલ પગલું નથી. જો `api.graphql` બદલાય છે, તો બિલ્ડ ટૂલ આપમેળે જાણે છે કે તેને `app.js` માટે સોર્સ ફેઝ ફરીથી ચલાવવાની જરૂર છે. આ ડેવલપમેન્ટ વર્કફ્લોને સરળ, વધુ મજબૂત અને ઓછી ભૂલ-સંભવિત બનાવે છે.

તે કેવી રીતે કાર્ય કરે છે: હોસ્ટ, સેન્ડબોક્સ અને ફેઝીસ

એ સમજવું અગત્યનું છે કે જાવાસ્ક્રિપ્ટ એન્જિન પોતે (જેમ કે Chrome અને Node.js માં V8) સોર્સ ફેઝને એક્ઝિક્યુટ કરતું નથી. જવાબદારી હોસ્ટ એન્વાયર્નમેન્ટ પર આવે છે.

હોસ્ટની ભૂમિકા

હોસ્ટ એ પ્રોગ્રામ છે જે જાવાસ્ક્રિપ્ટ કોડને કમ્પાઇલ અથવા રન કરી રહ્યો છે. આ હોઈ શકે છે:

• એક બંડલર જેમ કે Vite, Webpack, અથવા Parcel.
• એક રનટાઇમ જેમ કે Node.js અથવા Deno.
• એક બ્રાઉઝર પણ તેના DevTools માં એક્ઝિક્યુટ થયેલા કોડ માટે અથવા ડેવલપમેન્ટ સર્વર બિલ્ડ પ્રક્રિયા દરમિયાન હોસ્ટ તરીકે કાર્ય કરી શકે છે.

હોસ્ટ બે-તબક્કાની પ્રક્રિયાનું સંચાલન કરે છે:

1. તે કોડને પાર્સ કરે છે અને તમામ import source ડિક્લેરેશન્સ શોધે છે.
2. તે સોર્સ ફેઝ મોડ્યુલ્સને એક્ઝિક્યુટ કરવા માટે ખાસ કરીને એક અલગ, સેન્ડબોક્સ એન્વાયર્નમેન્ટ (જેને ઘણીવાર "Realm" કહેવાય છે) બનાવે છે.
3. તે આ સેન્ડબોક્સની અંદર ઇમ્પોર્ટ કરેલા સોર્સ મોડ્યુલ્સમાંથી કોડને એક્ઝિક્યુટ કરે છે. આ મોડ્યુલ્સને તેઓ જે કોડને રૂપાંતરિત કરી રહ્યા છે તેની સાથે ક્રિયાપ્રતિક્રિયા કરવા માટે વિશેષ APIs આપવામાં આવે છે (દા.ત., AST મેનિપ્યુલેશન APIs).
4. રૂપાંતરણો લાગુ કરવામાં આવે છે, જેના પરિણામે અંતિમ રનટાઇમ કોડ મળે છે.
5. આ અંતિમ કોડ પછી રનટાઇમ ફેઝ માટે નિયમિત જાવાસ્ક્રિપ્ટ એન્જિનને પસાર કરવામાં આવે છે.

સુરક્ષા અને સેન્ડબોક્સિંગ નિર્ણાયક છે

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

સોર્સ ફેઝ કોડ અત્યંત પ્રતિબંધિત સેન્ડબોક્સમાં ચાલે છે. ડિફૉલ્ટ રૂપે, તેની પાસે આની એક્સેસ નથી:

• સ્થાનિક ફાઇલસિસ્ટમ.
• નેટવર્ક વિનંતીઓ.
• રનટાઇમ ગ્લોબલ્સ જેમ કે window અથવા process.

ફાઇલ એક્સેસ જેવી કોઈપણ ક્ષમતાઓ હોસ્ટ એન્વાયર્નમેન્ટ દ્વારા સ્પષ્ટપણે આપવી પડશે, જે વપરાશકર્તાને બિલ્ડ-ટાઇમ સ્ક્રિપ્ટોને શું કરવાની મંજૂરી છે તેના પર સંપૂર્ણ નિયંત્રણ આપે છે. આ તેને પ્લગઇન્સ અને સ્ક્રિપ્ટોના વર્તમાન ઇકોસિસ્ટમ કરતાં ઘણું સુરક્ષિત બનાવે છે જેમને ઘણીવાર સિસ્ટમની સંપૂર્ણ એક્સેસ હોય છે.

જાવાસ્ક્રિપ્ટ ઇકોસિસ્ટમ પર વૈશ્વિક અસર

સોર્સ ફેઝ ઇમ્પોર્ટ્સનો પરિચય સમગ્ર વૈશ્વિક જાવાસ્ક્રિપ્ટ ઇકોસિસ્ટમમાં લહેરો મોકલશે, જે આપણે ટૂલ્સ, ફ્રેમવર્ક અને એપ્લિકેશન્સ કેવી રીતે બનાવીએ છીએ તેને મૂળભૂત રીતે બદલી નાખશે.

ફ્રેમવર્ક અને લાઇબ્રેરી લેખકો માટે

React, Svelte, Vue, અને Solid જેવા ફ્રેમવર્ક સોર્સ ફેઝ ઇમ્પોર્ટ્સનો લાભ લઈ શકે છે જેથી તેમના કમ્પાઇલર્સને ભાષાનો જ એક ભાગ બનાવી શકાય. Svelte કમ્પાઇલર, જે Svelte કમ્પોનન્ટ્સને ઓપ્ટિમાઇઝ્ડ વેનીલા જાવાસ્ક્રિપ્ટમાં ફેરવે છે, તેને મેક્રો તરીકે લાગુ કરી શકાય છે. JSX એક માનક મેક્રો બની શકે છે, જેનાથી દરેક ટૂલને ટ્રાન્સફોર્મનું પોતાનું કસ્ટમ અમલીકરણ હોવાની જરૂરિયાત દૂર થાય છે. CSS-in-JS લાઇબ્રેરીઓ બિલ્ડ સમયે તેમની બધી સ્ટાઇલ પાર્સિંગ અને સ્ટેટિક રૂલ જનરેશન કરી શકે છે, ન્યૂનતમ રનટાઇમ અથવા શૂન્ય રનટાઇમ પણ મોકલી શકે છે, જેનાથી નોંધપાત્ર પર્ફોર્મન્સ સુધારા થાય છે.

ટૂલિંગ ડેવલપર્સ માટે

Vite, Webpack, esbuild, અને અન્યના નિર્માતાઓ માટે, આ પ્રસ્તાવ એક શક્તિશાળી, માનકીકૃત એક્સ્ટેંશન પોઇન્ટ પ્રદાન કરે છે. ટૂલ્સ વચ્ચે અલગ-અલગ હોય તેવા જટિલ પ્લગઇન API પર આધાર રાખવાને બદલે, તેઓ સીધા જ ભાષાના પોતાના બિલ્ડ-ટાઇમ ફેઝમાં હૂક કરી શકે છે. આ વધુ એકીકૃત અને ઇન્ટરઓપરેબલ ટૂલિંગ ઇકોસિસ્ટમ તરફ દોરી શકે છે, જ્યાં એક ટૂલ માટે લખાયેલ મેક્રો બીજામાં સરળતાથી કામ કરે છે.

એપ્લિકેશન ડેવલપર્સ માટે

દરરોજ જાવાસ્ક્રિપ્ટ એપ્લિકેશન્સ લખતા લાખો ડેવલપર્સ માટે, ફાયદા અસંખ્ય છે:

• સરળ બિલ્ડ કન્ફિગરેશન્સ: TypeScript, JSX, અથવા કોડ જનરેશન જેવા સામાન્ય કાર્યો માટે પ્લગઇન્સની જટિલ શૃંખલાઓ પર ઓછી નિર્ભરતા.
• સુધારેલ પર્ફોર્મન્સ: સાચા ઝીરો-કોસ્ટ એબ્સ્ટ્રેક્શન્સ નાના બંડલ કદ અને ઝડપી રનટાઇમ એક્ઝિક્યુશન તરફ દોરી જશે.
• ઉન્નત ડેવલપર અનુભવ: ભાષામાં કસ્ટમ, ડોમેન-વિશિષ્ટ એક્સ્ટેન્શન્સ બનાવવાની ક્ષમતા અભિવ્યક્તિના નવા સ્તરોને અનલોક કરશે અને બોઇલરપ્લેટ ઘટાડશે.

વર્તમાન સ્થિતિ અને આગળનો માર્ગ

સોર્સ ફેઝ ઇમ્પોર્ટ્સ TC39, જાવાસ્ક્રિપ્ટને માનકીકૃત કરતી સમિતિ, દ્વારા વિકસાવવામાં આવી રહેલો એક પ્રસ્તાવ છે. TC39 પ્રક્રિયામાં ચાર મુખ્ય તબક્કાઓ છે, સ્ટેજ 1 (પ્રસ્તાવ) થી સ્ટેજ 4 (પૂર્ણ અને ભાષામાં સમાવેશ માટે તૈયાર).

2023ના અંત સુધીમાં, "સોર્સ ફેઝ ઇમ્પોર્ટ્સ" પ્રસ્તાવ (તેના સમકક્ષ, મેક્રો સાથે) સ્ટેજ 2 પર છે. આનો અર્થ એ છે કે સમિતિએ ડ્રાફ્ટ સ્વીકારી લીધો છે અને વિગતવાર સ્પષ્ટીકરણ પર સક્રિયપણે કામ કરી રહી છે. મુખ્ય સિન્ટેક્સ અને સિમેન્ટિક્સ મોટાભાગે નક્કી થઈ ગયા છે, અને આ તે તબક્કો છે જ્યાં પ્રતિસાદ આપવા માટે પ્રારંભિક અમલીકરણો અને પ્રયોગોને પ્રોત્સાહિત કરવામાં આવે છે.

આનો અર્થ એ છે કે તમે આજે તમારા બ્રાઉઝર અથવા Node.js પ્રોજેક્ટમાં import source નો ઉપયોગ કરી શકતા નથી. જોકે, અમે અપેક્ષા રાખી શકીએ છીએ કે પ્રસ્તાવ સ્ટેજ 3 તરફ પરિપક્વ થતાં નજીકના ભવિષ્યમાં અદ્યતન બિલ્ડ ટૂલ્સ અને ટ્રાન્સપાઇલર્સમાં પ્રાયોગિક સમર્થન દેખાશે. માહિતગાર રહેવાનો શ્રેષ્ઠ માર્ગ GitHub પર સત્તાવાર TC39 પ્રસ્તાવોને અનુસરવાનો છે.

નિષ્કર્ષ: ભવિષ્ય બિલ્ડ-ટાઇમ છે

સોર્સ ફેઝ ઇમ્પોર્ટ્સ ES મોડ્યુલ્સના પરિચય પછી જાવાસ્ક્રિપ્ટના ઇતિહાસમાં સૌથી મહત્વપૂર્ણ આર્કિટેક્ચરલ ફેરફારોમાંના એકનું પ્રતિનિધિત્વ કરે છે. બિલ્ડ-ટાઇમ અને રનટાઇમ વચ્ચે ઔપચારિક, માનકીકૃત વિભાજન બનાવીને, આ પ્રસ્તાવ ભાષામાં એક મૂળભૂત અંતરને સંબોધે છે. તે એવી ક્ષમતાઓ લાવે છે જેની ડેવલપર્સે લાંબા સમયથી ઇચ્છા રાખી છે—મેક્રો, કમ્પાઇલ-ટાઇમ મેટાપ્રોગ્રામિંગ, અને સાચા ઝીરો-કોસ્ટ એબ્સ્ટ્રેક્શન્સ—જેને કસ્ટમ, ખંડિત ટૂલિંગના ક્ષેત્રમાંથી બહાર કાઢીને જાવાસ્ક્રિપ્ટના મૂળમાં લાવે છે.

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