உங்களுக்குப் பிடிக்கும் என்பதற்காக மட்டுமே React Component-களைச் சேர்ப்பதை நிறுத்துங்கள்

இது அனைத்திற்கும் காரணமாக இருந்த Heading

தற்போது எல்லா இடங்களிலும் codebase-களில் ஒரு உரையாடல் நடக்கிறது. யாரோ ஒருவர் புதிய React component-ஐ முன்மொழிகிறார். அது எந்த பாதிப்பும் இல்லாதது போல் தோன்றுகிறது. ஆனால் பிறகு வேறொருவர் கேட்கிறார்: இது நமக்கு உண்மையிலேயே தேவையா? அதற்கான பதில் பெரும்பாலும் மக்களை ஆச்சரியப்படுத்துகிறது.

ஜூலை 14, 2026 அன்று DEV Community-யில் பதிவிடப்பட்ட ஒரு கட்டுரையில், ஒரு developer தங்கள் codebase-ல் நடந்த ஒரு architectural விவாதத்தை விவரித்தார். சில சக ஊழியர்கள் ஒரு புதிய Heading component-ஐ அறிமுகப்படுத்த விரும்பினர். அந்த code இதுபோல இருக்கும்:

<Heading level={3}>Profile Settings</Heading>

இது clean ஆக இருக்கிறது. இது semantic ஆக இருக்கிறது. இது organized ஆக உணர்த்துகிறது. ஆனால் ஒரு பிரச்சனை இருந்தது.

நம்மிடம் ஏற்கனவே மூன்று தீர்வுகள் உள்ளன

அணியால் ஏற்கனவே இதை எழுத முடிந்தது:

<h3>Profile Settings</h3>

மேலும் இது போன்ற நெகிழ்வுத்தன்மைக்காகவே உருவாக்கப்பட்ட ஏற்கனவே உள்ள Text component-ஐயும் அவர்கள் பயன்படுத்தலாம்:

<Text as="h3">Profile Settings</Text>

அப்படியென்றால் ஏன் நான்காவது வழியைச் சேர்க்க வேண்டும்? கேட்டபோது, கிடைத்த நேர்மையான பதில்: "நமக்கு தனியான heading component இருப்பது எனக்குப் பிடித்திருக்கிறது."

அது ஒரு மனிதக் காரணம். அது ஒரு தவறான காரணம் அல்ல. ஆனால் அது ஒரு engineering காரணம் அல்ல.

தனிப்பட்ட விருப்பம் ஒரு Design Principle அல்ல

Frontend அணிகள் abstraction-களை விரும்புகின்றன. சில நேரங்களில் கொஞ்சம் அதிகமாகவே. Wrapper-கள் மீண்டும் wrap செய்யப்படுகின்றன. அவற்றைச் சுற்றியுள்ள wrapper-கள் மீண்டும் wrap செய்யப்படுகின்றன. அசல் HTML அடையாளம் காண முடியாததாக மாறிவிடுகிறது.

நியாயப்படுத்தல்கள் பரிச்சயமானதாக ஒலிக்கின்றன: "இது பார்க்க cleaner ஆக இருக்கிறது." "மேலும் consistent ஆக உணர்த்துகிறது." "எனக்கு இது பிடித்துள்ளது."

இவை புரிந்துகொள்ளக்கூடியவை. இவற்றை தொடர்புபடுத்திப் பார்க்க முடிகிறது. ஆனால் இவை பலவீனமான engineering நியாயப்படுத்தல்கள். இதோ அதற்கான காரணம்: ஒவ்வொரு புதிய component-க்கும் ஒரு செலவு உள்ளது.

• எழுத வேண்டிய Documentation
• பராமரிக்க வேண்டிய Code
• தற்போதைய நிலையில் வைத்திருக்க வேண்டிய Test-கள்
• பயிற்சியளிக்க வேண்டிய புதிய developer-கள்
• விஷயங்கள் மாறும்போது அவசியமான Migration path-கள்
• அணியை குழப்பும் API overlap

ஒரு பகிரப்பட்ட codebase என்பது யாருடைய தனிப்பட்ட sandbox-ம் அல்ல. ஒவ்வொரு abstraction-ம் உங்கள் அணியின் நீண்ட கால சுமையின் ஒரு பகுதியாக மாறுகிறது. அந்த சுமைக்கு வெறும் விருப்பத்தை விட வலுவான நியாயப்படுத்தல் தகுதியானது.

HTML ஏற்கனவே கவனமாக வடிவமைக்கப்பட்ட ஒரு API ஆகும்

இதை நாம் சில நேரங்களில் மறந்துவிடுகிறோம். HTML என்பது பழமையானது அல்ல. அது கச்சாப் பொருள் அல்ல. அது சிந்தனையுடன் வடிவமைக்கப்பட்ட ஒரு abstraction, நீங்கள் அதன் மேல் உருவாக்கலாம்—ஆனால் எப்போதும் அதை மாற்றிவிட முடியாது.

heading-களை எடுத்துக்கொள்ளுங்கள். Native hierarchy ஏற்கனவே உங்களுக்கு இவற்றைக் கொடுக்கிறது:

• Semantic அர்த்தம் (h1 என்பது h3-ஐ விட முக்கியமானது)
• உள்ளமைக்கப்பட்ட Accessibility support
• Screen reader பொருந்தக்கூடிய தன்மை
• SEO சூழல்
• Document outline அமைப்பு

அதில் எதுவுமே ஒரு side effect அல்ல. அது standard-டில் கட்டமைக்கப்பட்டுள்ளது.

இதை நீங்கள் இப்படி ஒரு custom component-டில் wrap செய்யும்போது:

<Heading level={1}>Dashboard</Heading>
<Heading level={2}>Analytics</Heading>
<Heading level={3}>Revenue</Heading>

பெரும்பாலான நேரங்களில் நீங்கள் output-ஐ மேம்படுத்தவில்லை. நீங்கள் syntax-ஐ மட்டுமே மாற்றுகிறீர்கள். நடத்தை (behavior) மாறாமல் syntax-ஐ மாற்றுவது அதற்கான செலவுக்கு எப்போதாவதுதான் தகுதியானதாக இருக்கும்.

எல்லாவற்றையும் மாற்றும் ஒரு விதி

இந்த முடிவுகளை வழிநடத்த வேண்டிய principle இதோ: Syntax-ஐ abstract செய்யாதீர்கள். Behavior-ஐ abstract செய்யுங்கள்.

அவ்வளவுதான். அந்த ஒரு வேறுபாடு பெரும்பாலான தேவையற்ற விவாதங்களை அழித்துவிடுகிறது.

ஒரு மோசமான abstraction, native HTML-ஐ மிக நெருக்கமாக பிரதிபலிக்கிறது:

<Heading level={3}>Title</Heading>

இது ஏன் மோசமானது? ஏனெனில் இது பெரும்பாலும் h3-ஐயே பிரதிபலிக்கிறது. இது புதிதாக எதையும் சேர்க்கவில்லை.

ஒரு நல்ல abstraction உண்மையான behavior-ஐ சேர்க்கிறது:

<Text variant="muted" size="small" truncate>
  Description
</Text>

இது மையப்படுத்துகிறது:

• Design token mapping-ஐ
• Text truncation logic-ஐ
• Theme consistency-ஐ
• Responsive behavior-ஐ

அதுவே மதிப்பு. abstraction-க்கான செலவுக்கு அதுவே தகுதியானது.

One Concept Should Own One API

codebase-களில் குழப்பம் வேகமாகப் பரவுகிறது. அதற்கான சரியான ஒரு தொடக்கப்புள்ளி இதோ:

<Heading level={3}>Profile</Heading>
<Text as="h3">Profile</Text>
<h3>Profile</h3>

ஒரே விஷயத்தை எழுதுவதற்கு மூன்று வழிகள். இப்போது ஒவ்வொரு pull request-ம் ஒரு style விவாதமாக மாறுகிறது. "நாம் Heading-ஐப் பயன்படுத்த வேண்டுமா, Text-ஐயா அல்லது native h3-ஐயா?" யாருக்கும் உண்மையாகத் தெரியாது.

நல்ல systems தேர்வுகளைக் குறைக்கின்றன. ஒரு பயனுள்ள principle: One concept, one API. HTML ஏற்கனவே semantics-ஐக் கையாளுகிறது என்றால், அது semantics-ஐக் கொண்டிருக்கட்டும். உங்கள் Text component typography-யைக் கொண்டிருந்தால், அது typography-யைக் கொண்டிருக்கட்டும். தெளிவான பிரிப்பு. தெளிவான உரிமை.

Composition Beats Abstraction

Feature-களின் ஒவ்வொரு இணைப்பிற்கும் ஒரு wrapper-ஐ உருவாக்குவதற்கு பதிலாக, composition-க்கு முன்னுரிமை கொடுங்கள்.

இதைத் தவிர்க்கவும்:

<Heading level={2}>Billing Settings</Heading>

இதை விரும்பவும்:

<h2>
  <Text variant="secondary">
    Billing Settings
  </Text>
</h2>

உங்களுக்குக் கிடைப்பது:

• Native HTML semantics (h2 என்பது இன்னும் h2-ன் அர்த்தத்தையே குறிக்கிறது)
• மறுபயன்பாட்டிற்குரிய typography token-கள் (Text variant styling-ஐக் கையாளுகிறது)
• தெளிவான பொறுப்பு (அமைப்பிற்கு h2, தோற்றத்திற்கு Text)
• Overlapping API-கள் இல்லை
• எந்த தெளிவற்ற தன்மையும் இல்லை

Composition மிகவும் நெகிழ்வானது மற்றும் abstraction-ன் மற்றொரு அடுக்கை விட குறைவான குழப்பத்தையே சேர்க்கிறது.

நீங்கள் உருவாக்குவதற்கு முன் கேட்க வேண்டிய ஐந்து கேள்விகள்

ஒரு புதிய component-ஐ முன்மொழிவதற்கு முன், உங்களையே கேட்டுக்கொள்ளுங்கள்:

1. இது உண்மையில் எந்தப் பிரச்சனையைத் தீர்க்கிறது? "பார்க்க cleaner ஆக இருக்கிறது" அல்லது "எனக்கு இது இப்படிப் பிடித்துள்ளது" என்பதல்ல. அளவிடக்கூடிய ஏதாவது, "accessible hierarchy-யை கட்டாயப்படுத்துகிறது" அல்லது "font size முரண்பாட்டைத் தடுக்கிறது" என்பது போல.

2. HTML ஏற்கனவே இதைத் தீர்க்கிறதா? ஆம் எனில்: நீங்கள் ஏன் அதை மாற்ற வேண்டும்? அந்த சுமைக்கு தீவிரமான நியாயப்படுத்தல் தேவை.

3. இது சிக்கலைக் குறைக்கிறதா? அல்லது அது சிக்கலை சுழற்றி, ஒரு component-க்கு உள்ளே மறைக்கிறதா?

4. இது API overlap-ஐ அறிமுகப்படுத்துகிறதா? ஒரே விஷயத்தைச் செய்வதற்கான Overlapping வழிகள், முரண்பாடான codebase-களை உருவாக்குகின்றன. அது ஒரு செலவு, ஒரு feature அல்ல.

5. இது behavior-ஐச் சேர்க்கிறதா? Component behavior-ஐச் சேர்க்காமல் syntax-ஐ மட்டுமே மாற்றினால், அது அநேகமாக இருக்கக்கூடாது.

முடிவுரை

திரும்பத் திரும்ப வரும் ஒவ்வொரு pattern-க்கும் ஒரு component தகுதியானது அல்ல. ஒவ்வொரு HTML element-க்கும் ஒரு React wrapper தேவையில்லை. மேலும் ஒவ்வொரு விருப்பமும் பகிரப்பட்ட ஒரு abstraction ஆக மாறத் தகுதியானது அல்ல. முக்கியமான கேள்வி: இந்த abstraction புதிய திறனை உருவாக்குகிறதா அல்லது வெறும் புதிய syntax-ஐ மட்டுமா? அதற்கு நேர்மையாகப் பதிலளியுங்கள், நீங்கள் உங்கள் codebase-ஐ யாருக்கும் தேவையில்லாத பல ஆண்டுகால சிக்கலிலிருந்து பாதுகாப்பீர்கள்.

நன்மைகள்

• component-கள் எப்போது உண்மையான பிரச்சனைகளைத் தீர்க்கின்றன என்பதை முடிவெடுப்பதற்கான அளவிடக்கூடிய அளவுகோல்களை வழங்குகிறது
• native HTML element-களின் accessibility மற்றும் semantic மதிப்பை பாதுகாக்கிறது
• ஒரே பணியைச் செய்வதற்கு பல வழிகள் இருப்பதால் ஏற்படும் அணியின் குழப்பத்தைக் குறைக்கிறது
• வெறும் syntax-ஐ மாற்றுவதற்குப் பதிலாக, புதிய behavior-ஐச் சேர்ப்பதில் component உருவாக்கத்தை மையப்படுத்துகிறது
• wrapper abstraction-களை விட நெகிழ்வான composition-ஐ ஊக்குவிக்கிறது
• தேவையற்ற component-களின் அடுக்குகளுக்கு அடியில் codebase-கள் புதைக்கப்படுவதைத் தடுக்க உதவுகிறது

குறைபாடுகள்

• Custom abstraction-களை உருவாக்குவதை விரும்பும் developer-களுக்கு இந்த அணுகுமுறை வரம்புக்குட்பட்டதாகத் தோன்றலாம்
• ஏற்கனவே பல custom component-களைக் கொண்ட codebase-கள், குறிப்பிடத்தக்க refactoring வேலையை எதிர்கொள்கின்றன
• எது "behavior" மற்றும் எது "syntax" எனத் தீர்மானிப்பதற்கு, அணியின் தொடர்ச்சியான விவாதமும் ஒப்புதலும் தேவை
• Composition pattern-கள் சில நேரங்களில் hierarchical component அமைப்புகளை விட குறைவான ஒழுங்கமைப்பு கொண்டதாக உணரப்படுகின்றன

எச்சரிக்கை

இந்தக் கட்டுரை ஒரு வெளியிடப்பட்ட மூலத்திலிருந்து architectural principles-ஐ விளக்குகிறது. code உதாரணங்கள் விளக்கமளிக்கக்கூடியவை மற்றும் placeholder JSX syntax-ஐப் பயன்படுத்துகின்றன. இந்த principles-ஐ உங்கள் சொந்த codebase-ல் பயன்படுத்துவதற்கு முன், அசல் மூலத்திற்கு எதிராக கூற்றுகளைச் சரிபார்த்து, உங்கள் அணியின் குறிப்பிட்ட சூழலுக்கும் ஏற்கனவே உள்ள pattern-களுக்கும் வழிகாட்டுதலை மாற்றியமைக்கவும். ஒவ்வொரு அணியின் சூழ்நிலையும் வேறுபட்டது; ஒருவருக்கு வேலை செய்வது மற்றொருவருக்கு மாற்றியமைக்கப்பட வேண்டியிருக்கலாம். விதிகளை தன்னிச்சையாகப் பயன்படுத்துவதற்குப் பதிலாக, architectural முடிவுகளை எப்போதும் உங்கள் அணியுடன் விவாதிக்கவும்.

அடிக்கடி கேட்கப்படும் கேள்விகள்

HTML-ஐப் பயன்படுத்துவதற்குப் பதிலாக, நான் எப்போது ஒரு custom component-ஐ உருவாக்க வேண்டும்? — Design token-கள், responsive logic அல்லது மையப்படுத்தப்பட்ட styling போன்ற behavior-ஐச் சேர்க்கும்போது component-களை உருவாக்கவும். Component logic-ஐச் சேர்க்காமல் syntax-ஐ மட்டுமே மாற்றினால், native HTML அல்லது composition பொதுவாக சிறப்பாகச் செயல்படும்.

நல்ல மற்றும் மோசமான abstraction-களுக்கு இடையிலான வித்தியாசத்தை நான் எப்படி அறிந்துகொள்வது? — கேளுங்கள்: HTML ஏற்கனவே தீர்க்காத ஒரு பிரச்சனையை இந்த component தீர்க்கிறதா? இது behavior-ஐயோ அல்லது logic-ஐயோ மையப்படுத்துகிறதா? ஆம் எனில், இது அநேகமாக நல்லது. இது திறனைச் சேர்க்காமல் HTML-ஐ wrap மட்டும் செய்தால், இது அநேகமாக தேவையற்றது.

என் அணியிடம் ஏற்கனவே பல custom component-கள் இருந்தால் என்ன செய்வது? — எந்த component-கள் உண்மையான behavior-ஐச் சேர்க்கின்றன மற்றும் எவை HTML syntax-ஐ மட்டும் wrap செய்கின்றன என்பதை அடையாளம் காண்பதன் மூலம் தொடங்குங்கள். உண்மையான பிரச்சனைகளைத் தீர்ப்பவற்றை வைத்துக் கொள்ளுங்கள். வெறும் syntax-ஐ மட்டும் கொண்ட wrapper-களுக்கு, படிப்படியாக native HTML அல்லது composition-க்கு migrate ஆகுங்கள்.

wrapper component-களை விட composition ஏன் சிறந்தது? — Composition native HTML semantics-ஐப் பாதுகாக்கிறது, design token-களைத் தெளிவாக மறுபயன்பாடு செய்கிறது மற்றும் separation of concerns-ஐப் பராமரிக்கிறது. ஒரு wrapper அனுமதிப்பதில் கட்டுண்டு கிடப்பதை விட, சிறிய கவனம் செலுத்தப்பட்ட பகுதிகளை நீங்கள் இணைப்பதால் இது மிகவும் நெகிழ்வானது.

Design system consistency-யின் நிலை என்ன? — Design system-கள் wrapper-களை உருவாக்குவதற்குப் பதிலாக, behavior மற்றும் design token-களை (colors, fonts, spacing) வரையறுக்க வேண்டும். அந்த token-களை native element-கள் அல்லது குறைந்தபட்ச abstraction-களுடன் developer-கள் compose செய்யட்டும்.

இந்த அணுகுமுறையை என் அணிக்கு நான் எப்படி விளக்குவது? — இதை ஏற்கனவே உள்ளவற்றின் விமர்சனமாக இல்லாமல், எதிர்கால component-களுக்கான முடிவெடுக்கும் கட்டமைப்பாக (decision framework) அமைக்கவும். ஒவ்வொரு component-ம் கொண்டுள்ள செலவுகளில் கவனம் செலுத்துங்கள்: documentation, testing மற்றும் maintenance. ஒரு புதிய component-ஐச் சேர்ப்பதை நியாயப்படுத்தும் வகையான behavior எது என்பதில் ஒத்த கருத்துக்கு வாருங்கள்.

Tag-கள்

#react #frontend #architecture #components #webdev #designsystems #abstraction #codemaintenance