பணிபுரியும் ஒரு வடிவமைப்பாளருக்கு, ஒரு போர்ட்ஃபோலியோ தளம் ஒரு சங்கடமான இடைப்பட்ட நிலையில் உள்ளது. அது பார்ப்பதற்குத் துல்லியமாகவும், உடனடியாகத் திறக்கும் வேகத்துடனும் இருக்க வேண்டும், அதே சமயம் வருமானம் ஈட்டும் வேலை நேரங்களை (billable hours) பாதிக்காத வகையில் தற்போதைய நிலைக்கு ஏற்பவும் இருக்க வேண்டும். எனது பழைய அமைப்பானது Webflow-இல் இருந்தது, அது இழுத்து-போடும் (drag-and-drop) கட்டமைப்பிற்கும் தொழில்முறை வெளியீட்டிற்கும் இடையில் மற்ற கருவிகளை விட சிறப்பாகச் செயல்பட்டது. ஆனால், £300 ஆண்டு கட்டணத்துடன் புதுப்பித்தல் அறிவிப்பு வந்தபோது, நான் ஒரு கடினமான கேள்வியைக் கேட்க வேண்டியிருந்தது: நான் ஒரு மதிப்பிற்காகப் பணம் செலுத்துகிறேனா அல்லது வெறும் வசதிக்காகவா?

நான் அதை ஆரம்பத்திலிருந்து மீண்டும் உருவாக்கத் தீர்மானித்தேன். புதிய தொழில்நுட்பக் கட்டமைப்பு (stack) Astro மற்றும் Sanity ஆகும். இதனுடன் சிறிது காலம் பணியாற்றிய பிறகு, இதில் எது வேலை செய்தது, எது வேலை செய்யவில்லை மற்றும் நான் முன்பு பயன்படுத்திய கருவிகளுடன் ஒப்பிடும்போது இது எங்கு பொருந்துகிறது என்பதை இங்கே துல்லியமாகப் பார்ப்போம்.

போர்ட்ஃபோலியோவிற்கு ஏன் Astro?

பெரும்பாலான நவீன இணையக் கட்டமைப்புகள் (web frameworks) முதலில் JavaScript-ஐப் பயன்படுத்துகின்றன, பிறகு மற்ற விஷயங்களைக் கவனிக்கின்றன. Astro அந்த அனுமானத்தை மாற்றுகிறது. இது உருவாக்கத்தின் போது (build time) சாதாரண நிலையான HTML-ஐ உருவாக்குகிறது மற்றும் ஒரு குறிப்பிட்ட காம்போனென்ட் (component) தேவைப்படும்போது மட்டுமே பிரவுசருக்கு JavaScript-ஐ அனுப்புகிறது. இதை அவர்கள் islands architecture என்று அழைக்கிறார்கள், ஆனால் இதன் நடைமுறை முடிவு எளிமையானது: எனது போர்ட்ஃபோலியோ பக்கங்களின் அளவு மிகக் குறைவாகவே இருக்கும்.

ரூட்டிங் (Routing) கோப்பு அடிப்படையிலானது (file-based), எனவே ஒரு புதிய பக்கத்தை உருவாக்குவது ஒரு கோப்பை ஒரு ஃபோல்டரில் போடுவது போல எளிதானது. நீங்கள் React, Vue, அல்லது Svelte ஆகியவற்றைப் பயன்படுத்திய அனுபவம் இருந்தால், இதன் காம்போனென்ட் சிண்டாக்ஸ் (syntax) உங்களுக்குப் பரிச்சயமாக இருக்கும். ஒரு புதிய திட்ட ஆய்வை (project case study) சேர்க்க விரும்பும் போதெல்லாம் நான் ஒரு புதிய அணுகுமுறையைத் தேட வேண்டியதில்லை.

இருப்பினும், ஒரு சிக்கலான இணைய பயன்பாட்டை (web application) உருவாக்க நான் Astro-வைப் பயன்படுத்த மாட்டேன். நீங்கள் அங்கீகாரம் (authentication), உலகளாவிய நிலையை நிர்வகித்தல் (managing global state), அல்லது நிகழ்நேரத் தரவைக் கையாளுதல் போன்றவற்றைச் செய்ய முயன்றால், நீங்கள் இந்த கட்டமைப்போடு போராட வேண்டியிருக்கும். ஆனால், மார்க்கெட்டிங் தளங்கள், பிளாக்குகள் மற்றும் போர்ட்ஃபோலியோக்களுக்கு, இது எந்தத் இடையூறுமின்றிச் செயல்படுகிறது. பக்கங்கள் மிக வேகமாகத் தெரிவதற்குக் காரணம் அவை உண்மையில் வேகமாக இருப்பதேயாகும். ஒரு தலைப்பு அல்லது பத்தியை ரெண்டர் செய்யக் காத்திருக்கும் hydration overhead இதில் இல்லை.

WordPress-லிருந்து Sanity-க்கு மாறுதல்

இந்த மறுஉருவாக்கத்திற்கு முன்பு, எனது மாற்று வழி எப்போதும் Advanced Custom Fields உடன் கூடிய WordPress தான். ACF, WordPress-க்கு அதீத சக்திகளை வழங்குகிறது, ஆனால் நீங்கள் இன்னும் மற்றவர் உருவாக்கிய வீட்டிற்குள் தான் அமைப்புகளை மாற்றிக்கொண்டிருக்கிறீர்கள். Sanity இதற்கு நேர்மாறாகச் செயல்படுகிறது. உங்கள் உள்ளடக்க மாதிரி (content model) எப்படி இருக்க வேண்டும் என்பதைத் தீர்மானிக்கும் ஒரு ஸ்கீமாவை (schema) நீங்கள் குறியீட்டில் (code) எழுதுகிறீர்கள், மேலும் Sanity உங்கள் முடிவுகளுக்கு ஏற்ப எடிட்டிங் இடைமுகத்தை உருவாக்குகிறது.

மீண்டும் பயன்படுத்தக்கூடிய பிளாக்குகளைக் கொண்டு ஒரு எளிய பேஜ் பில்டரை உருவாக்க நான் அந்தத் கட்டுப்பாட்டைப் பயன்படுத்தினேன். நான் ஒரு hero section-ஐ ஒருமுறை வரையறுத்தேன். ஒரு testimonial carousel-ஐ ஒருமுறை வரையறுத்தேன். ஒரு card grid-ஐ ஒருமுறை வரையறுத்தேன். இப்போது புதிய குறியீடுகளை எழுதாமலோ அல்லது ஒரு பேஜ் டெம்ப்ளேட்டைத் தொடாமலோ, அந்த பிளாக்குகளை எந்த வரிசையிலும் அடுக்கி புதிய பக்கங்களை என்னால் உருவாக்க முடிகிறது.

மனநிலையில் உள்ள இந்த வேறுபாடு முக்கியமானது. WordPress-இல், நான் ஒரு பிளாக்காக இருக்க விரும்பும் ஒரு கருவியுடன் போராடிக்கொண்டிருப்பதாக அடிக்கடி உணர்ந்தேன். Sanity-இல், நான் ஒரு மென்பொருளை உருவாக்குவது போன்ற உணர்வு கிடைக்கிறது. உள்ளடக்கமானது ஸ்டைல் செய்யப்பட்ட HTML-ஆக இல்லாமல், சுத்தமான கட்டமைக்கப்பட்ட தரவாக (structured data) மாறுகிறது. எனது திட்ட விளக்கங்கள் எளிதில் மாற்றக்கூடிய பொருள்களாக (portable objects) உள்ளன; நான் விரும்பினால் அவற்றை ஒரு மொபைல் ஆப் அல்லது நியூஸ்லெட்டருக்கு எளிதாக அனுப்ப முடியும்.

சுத்தமான ஒரு டெப்ளாய்மென்ட் பணிப்பாய்வு (deployment workflow)

எனது பழைய WordPress பணிப்பாய்வு FTP பதிவேற்றங்கள், ஸ்டேஜிங் சப்-டொமைன்கள் மற்றும் மிக மோசமான நேரத்தில் எப்போதும் உடைந்து போகும் பிளகின் அப்டேட்கள் என ஒரு குழப்பமாக இருந்தது. ஒரு சிறிய எழுத்துப் பிழையைத் திருத்தி வெளியிடுவதற்கே நான் ஒரு மனரீதியான சரிபார்ப்புப் பட்டியலை வைத்திருக்க வேண்டியிருந்தது.

புதிய பணிப்பாய்வு மிகவும் சுருக்கமானது:

  • நான் உள்ளூர் அளவில் (locally) மாற்றங்களைச் செய்கிறேன் மற்றும் அவற்றை உடனடியாகப் பார்க்கிறேன்.
  • குறியீடு சரியாக இருக்கும்போது GitHub-இல் கமிட் (commit) செய்கிறேன்.
  • Vercel அந்தத் தகவலைப் பெற்று தானாகவே தளத்தைப் பதிவேற்றுகிறது (deploys).

அங்கே FTP கிளையண்ட் இல்லை. சிங்க் (sync) செய்ய வேண்டிய ஸ்டேஜிங் டேட்டாபேஸ் இல்லை. Repository தான் உண்மையான ஆதாரம் (source of truth).

உள்ளடக்கமும் அதே வழியில் செயல்படுகிறது. நான் Sanity-க்குள் ஒரு பதிவை வெளியிடும்போது அல்லது புதுப்பிக்கும்போது, ஒரு webhook Vercel-இடம் தளத்தை மீண்டும் உருவாக்கச் சொல்கிறது. நிலையான பக்கங்கள் புதிய உள்ளடக்கத்துடன் மீண்டும் உருவாகின்றன, மேலும் நான் ஒரு சர்வரைத் தொடாமலேயே CDN புதுப்பிக்கப்படுகிறது. பிளகின் டேட்டாபேஸ் மைக்ரேஷன் சரியாக வேலை செய்ததா என்று பிரார்த்தனை செய்யாமலோ அல்லது மேனுவலாக நகலெடுக்காமலோ அனைத்தும் தானாகவே சரியாக இருக்கும்.

டோக்கன்கள் (tokens) மூலம் வடிவமைப்பையும் குறியீட்டையும் இணைத்தல்

இந்த மறுஉருவாக்கத்தில் நான் கண்டறிந்த அமைதியான முன்னேற்றங்களில் ஒன்று முறையான டோக்கன் அமைப்பை (token system) அமைத்தது ஆகும். தளத்தில் உள்ள ஒவ்வொரு நிறம், டைப் ஸ்கேல் (type scale) மற்றும் இடைவெளி மதிப்பு ஆகியவற்றையும் வைத்திருக்கும் ஒரு ஒற்றை JSON கோப்பை நான் வைத்திருக்கிறேன். அந்த கோப்பு தான் முதன்மையானது.

அதே மதிப்புகளை நேரடியாக Figma-விற்குள் கொண்டு வர நான் Token Studio-வைப் பயன்படுத்துகிறேன். எனது டிசைன் ஃபைலில் surface-default என்று இருந்தால், அது குறியீடு பயன்படுத்தும் அதே எண்ணையே குறிக்கிறது. ஒரு சிறிய ஸ்கிரிப்ட் உருவாக்கத்தின் போது JSON-ஐ CSS custom properties-ஆக மாற்றுகிறது, எனவே எனது ஸ்டைல்ஷீட்கள் (stylesheets) ஹார்ட்கோட் செய்யப்பட்ட (hardcoded) hex குறியீடுகளுக்குப் பதிலாக --color-surface-default போன்ற மாறிகளைப் பயன்படுத்துகின்றன.

நடைமுறையில் இது ஏன் முக்கியம் என்பதைப் பார்ப்போம். எனது பிராண்ட் சிவப்பு நிறம் மொபைல் திரைகளில் சற்று அதிகமாக இருப்பதாக நான் உணர்ந்தால், JSON கோப்பில் உள்ள ஒரு மதிப்பை மட்டும் மாற்றினால் போதும். Figma லைப்ரரி புதுப்பிக்கப்படும். CSS புதுப்பிக்கப்படும். தளத்தின் அனைத்து இடங்களிலும் உள்ள மாற்றங்களும் தானாகவே புதுப்பிக்கப்படும். நான் grep செய்ய வேண்டிய அவசியமில்லை.