କେବଳ ଆପଣଙ୍କୁ ପସନ୍ଦ ବୋଲି React Component ଯୋଡ଼ିବା ବନ୍ଦ କରନ୍ତୁ

ଯେଉଁ Heading ରୁ ଏସବୁ ଆରମ୍ଭ ହୋଇଥିଲା

ବର୍ତ୍ତମାନ ସବୁଆଡେ codebases ରେ ଏକ ବାର୍ତ୍ତାଳାପ ଚାଲିଛି। କେହି ଜଣେ ଏକ ନୂତନ React component ପ୍ରସ୍ତାବ ଦିଅନ୍ତି। ଏହା କ୍ଷତିକାରକ ନୁହେଁ ବୋଲି ମନେହୁଏ। କିନ୍ତୁ ତା'ପରେ ଆଉ କେହି ପଚାରନ୍ତି: କ'ଣ ଆମକୁ ପ୍ରକୃତରେ ଏହାର ଆବଶ୍ୟକତା ଅଛି? ଏହାର ଉତ୍ତର ପ୍ରାୟତଃ ଲୋକଙ୍କୁ ଆଶ୍ଚର୍ଯ୍ୟ କରିଥାଏ।

୧୪ ଜୁଲାଇ, ୨୦୨୬ ରେ ପ୍ରକାଶିତ ଏକ ଲେଖାରେ, DEV Community ର ଜଣେ developer ସେମାନଙ୍କ codebase ରୁ ଏକ ଆର୍କିଟେକଚରାଲ୍ ଆଲୋଚନା ବର୍ଣ୍ଣନା କରିଥିଲେ। କିଛି ସହକର୍ମୀ ଏକ ନୂତନ Heading component ଆରମ୍ଭ କରିବାକୁ ଚାହୁଁଥିଲେ। କୋଡ୍ ଏହିପରି ଦେଖାଯିବ:

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

ଏହା ପରିଷ୍କାର ଅଟେ। ଏହା semantic ଅଟେ। ଏହା ସଂଗଠିତ ଲାଗୁଛି। କିନ୍ତୁ ଏକ ସମସ୍ୟା ଥିଲା।

ଆମ ପାଖରେ ପୂର୍ବରୁ ତିନୋଟି ସମାଧାନ ଅଛି

ଟିମ୍ ପୂର୍ବରୁ ଲେଖିପାରୁଥିଲା:

<h3>Profile Settings</h3>

ଏବଂ ସେମାନେ ଠିକ୍ ଏହି ପ୍ରକାରର ନମନୀୟତା ପାଇଁ ନିର୍ମିତ ଏକ ବିଦ୍ୟମାନ Text component ମଧ୍ୟ ବ୍ୟବହାର କରିପାରିବେ:

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

ତେବେ ଏକ ଚତୁର୍ଥ ଉପାୟ କାହିଁକି ଯୋଡିବେ? ପଚାରିବାରୁ ଉତ୍ତରଟି ସଚ୍ଚୋଟ ଥିଲା: "ମୁଁ ପସନ୍ଦ କରେ ଯେ ଆମର ଏକ ଅଲଗା heading component ଅଛି।"

ସେଇଟା ଗୋଟେ ମାନବିକ କାରଣ। ଏହା ଖରାପ କାରଣ ନୁହେଁ। କିନ୍ତୁ ଏହା ଏକ ଇଞ୍ଜିନିୟରିଂ କାରଣ ନୁହେଁ।

ବ୍ୟକ୍ତିଗତ ପସନ୍ଦ କୌଣସି Design Principle ନୁହେଁ

Frontend ଟିମ୍ ଗୁଡିକ abstractions କୁ ଭଲ ପାଆନ୍ତି। ବେଳେବେଳେ ଟିକେ ଅଧିକ। Wrappers ଗୁଡିକ ଆବୃତ ହୁଏ। ସେଗୁଡିକ ଚାରିପାଖରେ ଥିବା Wrappers ଗୁଡିକ ପୁଣି ଆବୃତ ହୁଏ। ମୂଳ HTML ଅଚିହ୍ନା ହୋଇଯାଏ।

ଯୁକ୍ତିଗୁଡ଼ିକ ପରିଚିତ ଲାଗେ: "ଏହା ପରିଷ୍କାର ଦେଖାଯାଉଛି।" "ଅଧିକ ସ୍ଥିର ଲାଗୁଛି।" "ମୁଁ ଏହାକୁ ପସନ୍ଦ କରେ।"

ଏଗୁଡ଼ିକ ବୁଝିହେବ। ସେଗୁଡ଼ିକ ସମ୍ବନ୍ଧିତ। କିନ୍ତୁ ସେଗୁଡ଼ିକ ଦୁର୍ବଳ ଇଞ୍ଜିନିୟରିଂ ଯୁକ୍ତି ଅଟେ। ଏହାର କାରଣ ଏଠାରେ ଅଛି: ପ୍ରତ୍ୟେକ ନୂତନ component ର କିଛି ମୂଲ୍ୟ ଦେବାକୁ ପଡେ।

• ଲେଖିବା ପାଇଁ Documentation
• ବଜାୟ ରଖିବା ପାଇଁ Code
• ଅଦ୍ୟତନ ରଖିବା ପାଇଁ Tests
• ତାଲିମ ଦେବା ପାଇଁ ନୂଆ developers
• ଜିନିଷଗୁଡ଼ିକ ପରିବର୍ତ୍ତନ ହେବାବେଳେ Migration paths
• API overlap ଯାହା ଟିମ୍ କୁ ଦ୍ୱନ୍ଦ୍ୱରେ ପକାଏ

ଏକ ସେୟାର୍ ହୋଇଥିବା codebase କାହାର ବ୍ୟକ୍ତିଗତ ସାଣ୍ଡବକ୍ସ ନୁହେଁ। ପ୍ରତ୍ୟେକ abstraction ଆପଣଙ୍କ ଟିମ୍ ର ଦୀର୍ଘକାଳୀନ ବୋଝର ଏକ ଅଂଶ ହୋଇଯାଏ। ସେହି ବୋଝ ପସନ୍ଦ ଅପେକ୍ଷା ଶକ୍ତିଶାଳୀ ଯୁକ୍ତିର ହକ୍ଦାର୍ ଅଟେ।

HTML ହେଉଛି ପୂର୍ବରୁ ଏକ ଯତ୍ନର ସହ ଡିଜାଇନ୍ ହୋଇଥିବା API

ଆମେ ବେଳେବେଳେ ଏହା ଭୁଲିଯାଉ। HTML ପ୍ରାଚୀନ ନୁହେଁ। ଏହା ଅଶୋଧିତ ନୁହେଁ। ଏହା ଏକ ଚିନ୍ତାଶୀଳ ଭାବରେ ଇଞ୍ଜିନିୟରିଂ ହୋଇଥିବା abstraction ଯାହା ଉପରେ ଆପଣ ନିର୍ମାଣ କରିପାରିବେ—କିନ୍ତୁ ସର୍ବଦା ବଦଳାଇ ପାରିବେ ନାହିଁ।

headings ନିଅନ୍ତୁ। native hierarchy ଆପଣଙ୍କୁ ପୂର୍ବରୁ ଦେଇଥାଏ:

• Semantic ଅର୍ଥ (h1, h3 ଅପେକ୍ଷା ଅଧିକ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ)
• Accessibility ସପୋର୍ଟ ନିର୍ମିତ
• ସ୍କ୍ରିନ୍ ରିଡର୍ କମ୍ପାଟିବିଲିଟି
• SEO ପ୍ରସଙ୍ଗ
• ଡକ୍ୟୁମେଣ୍ଟ୍ ଆଉଟଲାଇନ୍ ଗଠନ

ସେଥିରୁ କୌଣସିଟି ମଧ୍ୟ side effect ନୁହେଁ। ଏହା ମାନକରେ ଇଞ୍ଜିନିୟରିଂ କରାଯାଇଛି।

ଯେତେବେଳେ ଆପଣ ଏହାକୁ ଏହିପରି ଏକ custom component ରେ ଗୁଡ଼ାନ୍ତି:

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

ଅଧିକାଂଶ କ୍ଷେତ୍ରରେ ଆପଣ ଆଉଟପୁଟରେ ଉନ୍ନତି କରୁନାହାଁନ୍ତି। ଆପଣ କେବଳ syntax ପରିବର୍ତ୍ତନ କରୁଛନ୍ତି। ଏବଂ ଆଚରଣ ପରିବର୍ତ୍ତନ ନକରି syntax ପରିବର୍ତ୍ତନ କରିବା କ୍ୱଚିତ୍ ମୂଲ୍ୟବାନ ଅଟେ।

ଗୋଟିଏ ନିୟମ ଯାହା ସବୁକିଛି ବଦଳାଇଦିଏ

ଏଠାରେ ସେହି ନୀତି ଅଛି ଯାହା ଏହି ନିଷ୍ପତ୍ତିଗୁଡ଼ିକୁ ମାର୍ଗଦର୍ଶନ କରିବା ଉଚିତ୍: syntax କୁ abstract କରନ୍ତୁ ନାହିଁ। ଆଚରଣକୁ abstract କରନ୍ତୁ।

ବସ୍ ଏତିକି। ସେହି ଗୋଟିଏ ପାର୍ଥକ୍ୟ ଅଧିକାଂଶ ଅନାବଶ୍ୟକ ବିତର୍କକୁ ଶେଷ କରେ।

ଏକ ଖରାପ abstraction ଦେଶୀ HTML କୁ ବହୁତ ନିକଟରୁ ଦର୍ଶାଏ:

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

ଏହା କାହିଁକି ଖରାପ? କାରଣ ଏହା ପ୍ରାୟତଃ h3 କୁ ପ୍ରତିଫଳିତ କରେ। ଏହା ନୂଆ କିଛି ଯୋଡେ ନାହିଁ।

ଏକ ଭଲ abstraction ପ୍ରକୃତ ଆଚରଣ ଯୋଡେ:

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

ଏହା କେନ୍ଦ୍ରୀଭୂତ କରେ:

• ଡିଜାଇନ୍ ଟୋକନ୍ ମ୍ୟାପିଂ
• Text truncation ଲଜିକ୍
• Theme ସ୍ଥିରତା
• ପ୍ରତିକ୍ରିୟାଶୀଳ ଆଚରଣ

ସେଇଟା ମୂଲ୍ୟବାନ। ତାହା abstraction ମୂଲ୍ୟର ଯୋଗ୍ୟ।

ଗୋଟିଏ Concept ର ଗୋଟିଏ API ରହିବା ଉଚିତ୍

codebases ରେ ଦ୍ୱନ୍ଦ୍ୱ ଶୀଘ୍ର ବ୍ୟାପିଯାଏ। ଏଠାରେ ଏକ ଉପଯୁକ୍ତ ପ୍ରଜନନ ସ୍ଥାନ ଅଛି:

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

ସମାନ ଜିନିଷ ଲେଖିବା ପାଇଁ ତିନୋଟି ଉପାୟ। ବର୍ତ୍ତମାନ ପ୍ରତ୍ୟେକ pull request ଏକ style ବିତର୍କରେ ପରିଣତ ହୁଏ। "ଆମେ Heading କିମ୍ବା Text କିମ୍ବା native h3 ବ୍ୟବହାର କରିବା ଉଚିତ କି?" ପ୍ରକୃତରେ କେହି ଜାଣନ୍ତି ନାହିଁ।

ଭଲ ସିଷ୍ଟମ୍ ବିକଳ୍ପକୁ ହ୍ରାସ କରେ। ଏକ ଉପଯୋଗୀ ନୀତି: ଗୋଟିଏ concept, ଗୋଟିଏ API। ଯଦି HTML ପୂର୍ବରୁ semantics କୁ ପରିଚାଳନା କରେ, ତେବେ ଏହାକୁ semantics ର ଅଧିକାରୀ ହେବାକୁ ଦିଅନ୍ତୁ। ଯଦି ଆପଣଙ୍କର Text component ର typography ର ଅଧିକାର ଅଛି, ତେବେ ଏହାକୁ typography ର ମାଲିକ ହେବାକୁ ଦିଅନ୍ତୁ। ସ୍ପଷ୍ଟ ପୃଥକୀକରଣ। ସ୍ପଷ୍ଟ ମାଲିକାନା।

Composition Abstraction କୁ ପରାସ୍ତ କରେ

ବୈଶିଷ୍ଟ୍ୟଗୁଡିକର ପ୍ରତ୍ୟେକ ମିଶ୍ରଣ ପାଇଁ ଏକ wrapper ସୃଷ୍ଟି କରିବା ପରିବର୍ତ୍ତେ, composition କୁ ପସନ୍ଦ କରନ୍ତୁ।

ଏହାକୁ ଏଡ଼ାନ୍ତୁ:

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

ଏହାକୁ ପସନ୍ଦ କରନ୍ତୁ:

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

ଆପଣ ପାଆନ୍ତି:

• Native HTML semantics (h2 ର ଅର୍ଥ ଏବେ ବି ସେଇଆ ଯାହା h2 ର ଅର୍ଥ)
• ପୁନଃବ୍ୟବହାର ଯୋଗ୍ୟ typography ଟୋକନ୍ (Text variant ଷ୍ଟାଇଲିଂ ପରିଚାଳନା କରେ)
• ସ୍ପଷ୍ଟ ଦାୟିତ୍ୱ (ଗଠନ ପାଇଁ h2, ଦେଖାଯିବା ପାଇଁ Text)
• କୌଣସି overlapping APIs ନାହିଁ
• କୌଣସି ଅସ୍ପଷ୍ଟତା ନାହିଁ

Abstraction ର ଅନ୍ୟ ଏକ ସ୍ତର ଅପେକ୍ଷା Composition ଅଧିକ ନମନୀୟ ଏବଂ କମ୍ ଦ୍ୱନ୍ଦ୍ୱ ଯୋଡେ।

ନିର୍ମାଣ କରିବା ପୂର୍ବରୁ ପାଞ୍ଚଟି ପ୍ରଶ୍ନ

ଏକ ନୂତନ component ପ୍ରସ୍ତାବ ଦେବା ପୂର୍ବରୁ, ନିଜକୁ ପଚାରନ୍ତୁ:

୧. ଏହା ପ୍ରକୃତରେ କେଉଁ ସମସ୍ୟାର ସମାଧାନ କରେ? "ପରିଷ୍କାର ଦେଖାଯାଉଛି" କିମ୍ବା "ମୁଁ ଏହି ଉପାୟକୁ ପସନ୍ଦ କରେ" ନୁହେଁ। ମାପଯୋଗ୍ୟ କିଛି, ଯେପରିକି "ପହଞ୍ଚଯୋଗ୍ୟ ହାଇରାର୍କି ଲାଗୁ କରେ" କିମ୍ବା "font size ଅସଙ୍ଗତିକୁ ରୋକିଥାଏ।"

୨. HTML କ'ଣ ପୂର୍ବରୁ ଏହାର ସମାଧାନ କରୁଛି? ଯଦି ହଁ: ଆପଣ ଏହାକୁ କାହିଁକି ବଦଳାଇବେ? ସେହି ବୋଝ ପାଇଁ ଏକ ଗମ୍ଭୀର ଯୁକ୍ତି ଦରକାର।

୩. ଏହା କ'ଣ ଜଟିଳତାକୁ ହ୍ରାସ କରେ? କିମ୍ବା ଏହା କେବଳ ଜଟିଳତାକୁ ଏପଟ ସେପଟ କରେ ଏବଂ ଏହାକୁ ଏକ component ଭିତରେ ଲୁଚାଇଦିଏ?

୪. ଏହା କ'ଣ API overlap ଆଣିଥାଏ? ସମାନ ଜିନିଷ କରିବା ପାଇଁ Overlapping ଉପାୟଗୁଡିକ ଅସଙ୍ଗତ codebases ସୃଷ୍ଟି କରେ। ସେଇଟା ଗୋଟେ ମୂଲ୍ୟ, feature ନୁହେଁ।

୫. ଏହା କ'ଣ ଆଚରଣ ଯୋଡିଥାଏ? ଯଦି component କେବଳ ଆଚରଣ ନ ଯୋଡି syntax ପରିବର୍ତ୍ତନ କରେ, ତେବେ ବୋଧହୁଏ ଏହା ରହିବା ଉଚିତ୍ ନୁହେଁ।

ଉପସଂହାର

ପ୍ରତ୍ୟେକ ପୁନରାବୃତ୍ତି pattern ଏକ component ପାଇଁ ଯୋଗ୍ୟ ନୁହେଁ। ପ୍ରତ୍ୟେକ HTML element ପାଇଁ ଏକ React wrapper ର ଆବଶ୍ୟକତା ନାହିଁ। ଏବଂ ପ୍ରତ୍ୟେକ ପସନ୍ଦ ଏକ shared abstraction ହେବାକୁ ଯୋଗ୍ୟ ନୁହେଁ। ଯେଉଁ ପ୍ରଶ୍ନଟି ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ: ଏହି abstraction କ'ଣ ନୂତନ ସାମର୍ଥ୍ୟ ସୃଷ୍ଟି କରୁଛି, ନା କେବଳ ନୂତନ syntax? ଏହାର ସଚ୍ଚୋଟତାର ସହ ଉତ୍ତର ଦିଅନ୍ତୁ, ଏବଂ ଆପଣ ନିଜ codebase କୁ ବର୍ଷ ବର୍ଷର ଜଟିଳତାରୁ ରକ୍ଷା କରିବେ ଯାହାର ପ୍ରକୃତରେ କାହାକୁ ଆବଶ୍ୟକତା ନାହିଁ।

ଗୁଣ

• ଯେତେବେଳେ components ପ୍ରକୃତ ସମସ୍ୟାର ସମାଧାନ କରନ୍ତି, ନିଷ୍ପତ୍ତି ନେବା ପାଇଁ ମାପଯୋଗ୍ୟ ମାନଦଣ୍ଡ ପ୍ରଦାନ କରେ
• native HTML elements ର accessibility ଏବଂ semantic ମୂଲ୍ୟ ସଂରକ୍ଷଣ କରେ
• ସମାନ କାର୍ଯ୍ୟ ସମ୍ପନ୍ନ କରିବା ପାଇଁ ଏକାଧିକ ଉପାୟ ଦ୍ୱାରା ହେଉଥିବା ଟିମ୍ ର ଦ୍ୱନ୍ଦ୍ୱ ହ୍ରାସ କରେ
• କେବଳ syntax ପରିବର୍ତ୍ତନ କରିବା ପରିବର୍ତ୍ତେ ନୂତନ ଆଚରଣ ଯୋଡିବା ଉପରେ component ସୃଷ୍ଟି ଉପରେ ଧ୍ୟାନ କେନ୍ଦ୍ରୀଭୂତ କରେ
• composition କୁ ଉତ୍ସାହିତ କରେ, ଯାହା wrapper abstractions ଠାରୁ ଅଧିକ ନମନୀୟ ଅଟେ
• codebases କୁ ଅନାବଶ୍ୟକ components ର ସ୍ତର ତଳେ ପୋତି ହେବାରୁ ରୋକିବାରେ ସାହାଯ୍ୟ କରେ

ଦୋଷ

• ଯେଉଁ Developers ମାନେ custom abstractions ତିଆରି କରିବାକୁ ପସନ୍ଦ କରନ୍ତି, ସେମାନଙ୍କୁ ଏହି ଆଭିମୁଖ୍ୟ ସୀମିତ ଲାଗିପାରେ
• ପୂର୍ବରୁ ଅନେକ custom components ଥିବା Codebases ଗୁଡିକ ଉଲ୍ଲେଖନୀୟ refactoring କାର୍ଯ୍ୟର ସମ୍ମୁଖୀନ ହୁଅନ୍ତି
• "ଆଚରଣ" ବନାମ "syntax" ଭାବରେ କ'ଣ ଗଣାଯାଏ ତାହା ନିର୍ଦ୍ଧାରଣ କରିବା ପାଇଁ କ୍ରମାଗତ ଟିମ୍ ଆଲୋଚନା ଏବଂ ସମ୍ମତି ଆବଶ୍ୟକ
• Composition patterns ବେଳେବେଳେ hierarchical component structures ଅପେକ୍ଷା କମ୍ ସଂଗଠିତ ଲାଗେ

ସତର୍କତା

ଏହି ଲେଖାଟି ଏକ ପ୍ରକାଶିତ ଉତ୍ସରୁ ଆର୍କିଟେକଚରାଲ୍ ନୀତି ବ୍ୟାଖ୍ୟା କରେ। କୋଡ୍ ଉଦାହରଣଗୁଡିକ ଦୃଷ୍ଟାନ୍ତମୂଳକ ଅଟେ ଏବଂ ପ୍ଲେସହୋଲ୍ଡର JSX syntax ବ୍ୟବହାର କରେ। ନିଜ codebase ରେ ଏହି ନୀତିଗୁଡ଼ିକ ପ୍ରୟୋଗ କରିବା ପୂର୍ବରୁ, ମୂଳ ଉତ୍ସ ବିରୁଦ୍ଧରେ ଦାବିଗୁଡିକ ଯାଞ୍ଚ କରନ୍ତୁ ଏବଂ ଆପଣଙ୍କ ଟିମ୍ ର ନିର୍ଦ୍ଦିଷ୍ଟ ପ୍ରସଙ୍ଗ ଏବଂ ବିଦ୍ୟମାନ ପ୍ୟାଟର୍ଣ୍ଣ ସହିତ ମାର୍ଗଦର୍ଶନକୁ ଖାପ ଖୁଆନ୍ତୁ। ପ୍ରତ୍ୟେକ ଟିମ୍ ର ପରିସ୍ଥିତି ଭିନ୍ନ; ଜଣକ ପାଇଁ ଯାହା କାମ କରେ, ଅନ୍ୟ ଜଣକ ପାଇଁ adjustment ଆବଶ୍ୟକ ହୋଇପାରେ। ଏକତରଫା ଭାବରେ ନିୟମ ପ୍ରୟୋଗ କରିବା ପରିବର୍ତ୍ତେ ଆପଣଙ୍କ ଟିମ୍ ସହିତ ସର୍ବଦା ଆର୍କିଟେକଚରାଲ୍ ନିଷ୍ପତ୍ତି ବିଷୟରେ ଆଲୋଚନା କରନ୍ତୁ।

ପ୍ରାୟତଃ ପଚରାଯାଉଥିବା ପ୍ରଶ୍ନ

ମୁଁ କେତେବେଳେ HTML ବ୍ୟବହାର କରିବା ପରିବର୍ତ୍ତେ ଏକ custom component ତିଆରି କରିବା ଉଚିତ୍? — ଯେତେବେଳେ ସେମାନେ design ଟୋକନ୍, responsive ଲଜିକ୍ କିମ୍ବା centralized ଷ୍ଟାଇଲିଂ ଭଳି ଆଚରଣ ଯୋଡନ୍ତି ସେତେବେଳେ components ତିଆରି କରନ୍ତୁ। ଯଦି component କେବଳ ଲଜିକ୍ ନ ଯୋଡି syntax ପରିବର୍ତ୍ତନ କରେ, native HTML କିମ୍ବା composition ସାଧାରଣତଃ ଭଲ କାମ କରେ।

ଭଲ ଏବଂ ଖରାପ abstractions ମଧ୍ୟରେ ପାର୍ଥକ୍ୟ ମୁଁ କିପରି ଜାଣିବି? — ପଚାରନ୍ତୁ: ଏହି component କ'ଣ ଏପରି ଏକ ସମସ୍ୟାର ସମାଧାନ କରୁଛି ଯାହା HTML ପୂର୍ବରୁ ସମାଧାନ କରୁନାହିଁ? ଏହା କ'ଣ ଆଚରଣ କିମ୍ବା ଲଜିକ୍ କୁ କେନ୍ଦ୍ରୀଭୂତ କରୁଛି? ଯଦି ହଁ, ଏହା ବୋଧହୁଏ ଭଲ ଅଟେ। ଯଦି ଏହା କେବଳ ସାମର୍ଥ୍ୟ ଯୋଡିବା ବିନା HTML କୁ ଗୁଡ଼ାଏ, ତେବେ ଏହା ବୋଧହୁଏ ଅନାବଶ୍ୟକ।

ଯଦି ମୋ ଟିମ୍ ପାଖରେ ପୂର୍ବରୁ ଅନେକଗୁଡ଼ିଏ custom components ଥାଏ ତେବେ କ'ଣ ହେବ? — କେଉଁ components ପ୍ରକୃତ ଆଚରଣ ଯୋଡେ ଏବଂ କେଉଁଗୁଡ଼ିକ କେବଳ HTML syntax କୁ ଆବୃତ କରେ ତାହା ଚିହ୍ନଟ କରିବା ଆରମ୍ଭ କରନ୍ତୁ। ପ୍ରକୃତ ସମସ୍ୟାର ସମାଧାନ କରୁଥିବା ଗୁଡ଼ିକୁ ରଖନ୍ତୁ। କେବଳ syntax-ବାଲା wrappers ପାଇଁ, ଧୀରେ ଧୀରେ native HTML କିମ୍ବା composition କୁ ମାଇଗ୍ରେଟ୍ କରନ୍ତୁ।

wrapper components ଠାରୁ composition କାହିଁକି ଭଲ? — Composition ଦେଶୀ HTML semantics କୁ ସଂରକ୍ଷଣ କରେ, design ଟୋକନ୍ ଗୁଡିକୁ ସ୍ପଷ୍ଟ ଭାବରେ ପୁନଃବ୍ୟବହାର କରେ ଏବଂ ସମସ୍ୟାଗୁଡ଼ିକର ପୃଥକୀକରଣ ବଜାୟ ରଖେ। ଏହା ଅଧିକ ନମନୀୟ ମଧ୍ୟ ଅଟେ କାରଣ ଏକ wrapper ଯାହା ଅନୁମତି ଦିଏ ସେଥିରେ ତାଲା ପଡିବା ପରିବର୍ତ୍ତେ ଆପଣ ଛୋଟ ଧ୍ୟାନ କେନ୍ଦ୍ରିତ ଖଣ୍ଡଗୁଡ଼ିକୁ ଏକାଠି କରନ୍ତି।

ଡିଜାଇନ୍ ସିଷ୍ଟମ୍ ସ୍ଥିରତା ବିଷୟରେ କ'ଣ? — ଡିଜାଇନ୍ ସିଷ୍ଟମ୍ ଗୁଡିକ wrappers ତିଆରି କରିବା ପରିବର୍ତ୍ତେ ଆଚରଣ ଏବଂ ଡିଜାଇନ୍ ଟୋକନ୍ (ରଙ୍ଗ, ଫଣ୍ଟ୍, ସ୍ପେସିଂ) ବ୍ୟାଖ୍ୟା କରିବା ଉଚିତ୍। Developers ମାନଙ୍କୁ ସେହି ଟୋକନ୍ ଗୁଡ଼ିକୁ ଦେଶୀ ଉପାଦାନ କିମ୍ବା ସର୍ବନିମ୍ନ abstractions ସହିତ ରଚନା କରିବାକୁ ଦିଅନ୍ତୁ।

ମୁଁ ମୋ ଟିମ୍ କୁ ଏହି ଆଭିମୁଖ୍ୟ କିପରି ବୁଝାଇବି? — ବିଦ୍ୟମାନଗୁଡ଼ିକର ସମାଲୋଚନା ନୁହେଁ, ବରଂ ଭବିଷ୍ୟତର components ପାଇଁ ଏହାକୁ ଏକ ନିଷ୍ପତ୍ତିର ଢାଞ୍ଚା ଭାବରେ ରଖନ୍ତୁ। ପ୍ରତ୍ୟେକ component ବହନ କରୁଥିବା ମୂଲ୍ୟ ଉପରେ ଧ୍ୟାନ ଦିଅନ୍ତୁ: ଦସ୍ତାବେଜ, ପରୀକ୍ଷା, ଏବଂ ରକ୍ଷଣାବେକ୍ଷଣ। ଏକ ନୂତନ component ଯୋଡିବାକୁ କେଉଁ ପ୍ରକାରର ଆଚରଣ ଯଥାର୍ଥ କରେ ସେଥିରେ ସହମତ ହୁଅନ୍ତୁ।

ଟ୍ୟାଗ୍

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