কিভাবে পরমাণু স্থির প্রবাহ

Recoil প্রতিক্রিয়া জগতে পারমাণবিক মডেল প্রবর্তন. এর নতুন শক্তিগুলি একটি খাড়া শেখার বক্ররেখা এবং বিক্ষিপ্ত শিক্ষার সংস্থানগুলির মূল্যে এসেছে।

Jotai এবং Zedux পরে এই নতুন মডেলের বিভিন্ন দিককে সরলীকৃত করে, অনেক নতুন বৈশিষ্ট্য অফার করে এবং এই আশ্চর্যজনক নতুন দৃষ্টান্তের সীমা ঠেলে দেয়।

অন্যান্য নিবন্ধগুলি এই সরঞ্জামগুলির মধ্যে পার্থক্যগুলিতে ফোকাস করবে। এই নিবন্ধটি একটি বড় বৈশিষ্ট্যের উপর ফোকাস করবে যা 3 টির মধ্যে মিল রয়েছে:

তারা ফ্লাক্স ঠিক করেছে।

সুচিপত্র

• ফ্লাক্স
• নির্ভরতা গাছ
• সিঙ্গেলটন মডেল
• প্রাথমিক স্তরে ফিরে আসা
• ডিমিটারের আইন
• হিরোস
• জেডুক্স
• পারমাণবিক মডেল
• উপসংহার

ফ্লাক্স

আপনি যদি ফ্লাক্স না জানেন তবে এখানে একটি দ্রুত সারাংশ রয়েছে:

Redux ছাড়াও, সমস্ত Flux-ভিত্তিক লাইব্রেরি মূলত এই প্যাটার্ন অনুসরণ করে: একটি অ্যাপের একাধিক স্টোর রয়েছে। শুধুমাত্র একজন ডিসপ্যাচার আছে যার কাজ হল সঠিক ক্রমে সমস্ত দোকানে অ্যাকশন খাওয়ানো। এই "যথাযথ আদেশ" মানে দোকানের মধ্যে নির্ভরতাকে গতিশীলভাবে বাছাই করা।

উদাহরণস্বরূপ, একটি ই-কমার্স অ্যাপ সেটআপ নিন:

যখন ব্যবহারকারী তাদের কার্টে একটি কলা নিয়ে যান, তখন প্রোমোসস্টোরকে একটি কলা কুপন উপলব্ধ আছে কিনা তা দেখার জন্য একটি অনুরোধ পাঠানোর আগে কার্টস্টোরের অবস্থা আপডেট হওয়ার জন্য অপেক্ষা করতে হবে।

অথবা সম্ভবত কলা ব্যবহারকারীর এলাকায় পাঠানো যাবে না। কার্টস্টোর আপডেট করার আগে ইউজারস্টোর চেক করতে হবে। অথবা সম্ভবত কুপনগুলি সপ্তাহে একবার ব্যবহার করা যেতে পারে। কুপন অনুরোধ পাঠানোর আগে PromosStore-কে UserStore চেক করতে হবে।

ফ্লাক্স এই নির্ভরতা পছন্দ করে না। উত্তরাধিকার প্রতিক্রিয়া ডক্স থেকে:

একটি ফ্লাক্স অ্যাপ্লিকেশনের মধ্যে থাকা বস্তুগুলিকে অত্যন্ত দ্বিগুণ করা হয় এবং ডিমিটারের আইনকে অত্যন্ত দৃঢ়ভাবে মেনে চলে, এই নীতি যে একটি সিস্টেমের মধ্যে থাকা প্রতিটি বস্তুকে সিস্টেমের অন্যান্য বস্তু সম্পর্কে যতটা সম্ভব কম জানা উচিত।

এর পেছনের তত্ত্বটা শক্ত। 100%। সো... ফ্লাক্সের এই মাল্টি-স্টোর ফ্লেভারটি কেন মারা গেল?

নির্ভরতা গাছ

ভাল দেখা যাচ্ছে, বিচ্ছিন্ন রাষ্ট্রের পাত্রের মধ্যে নির্ভরতা অনিবার্য। প্রকৃতপক্ষে, কোড মডুলার এবং DRY রাখতে, আপনার ঘন ঘন অন্যান্য স্টোর ব্যবহার করা উচিত ।

ফ্লাক্সে, এই নির্ভরতাগুলি উড়তে থাকা অবস্থায় তৈরি হয়:

 // This example uses Facebook's own `flux` library PromosStore.dispatchToken = dispatcher.register(payload => { if (payload.actionType === 'add-to-cart') { // wait for CartStore to update first: dispatcher.waitFor([CartStore.dispatchToken]) // now send the request sendPromosRequest(UserStore.userId, CartStore.items).then(promos => { dispatcher.dispatch({ actionType: 'promos-fetched', promos }) }) } if (payload.actionType === 'promos-fetched') { PromosStore.setPromos(payload.promos) } }) CartStore.dispatchToken = dispatcher.register(payload => { if (payload.actionType === 'add-to-cart') { // wait for UserStore to update first: dispatcher.waitFor([UserStore.dispatchToken]) if (UserStore.canBuy(payload.item)) { CartStore.addItem(payload.item) } } })

এই উদাহরণটি দেখায় কিভাবে নির্ভরতাগুলি সরাসরি স্টোরগুলির মধ্যে ঘোষণা করা হয় না - বরং, তারা প্রতি-কর্মের ভিত্তিতে একত্রিত হয়। এই অনানুষ্ঠানিক নির্ভরতা খুঁজে পেতে বাস্তবায়ন কোড মাধ্যমে খনন প্রয়োজন.

এটি একটি খুব সহজ উদাহরণ! কিন্তু আপনি ইতিমধ্যে দেখতে পাচ্ছেন কিভাবে হেলটার-স্কেলটার ফ্লাক্স অনুভব করে। পার্শ্ব প্রতিক্রিয়া, নির্বাচন অপারেশন, এবং রাষ্ট্র আপডেট সব একসঙ্গে cobbled হয়. এই colocation আসলে চমৎকার ধরনের হতে পারে. কিন্তু কিছু অনানুষ্ঠানিক নির্ভরতা মিশ্রিত করুন, রেসিপিটি তিনগুণ করুন এবং কিছু বয়লারপ্লেটে পরিবেশন করুন এবং আপনি দেখতে পাবেন যে ফ্লাক্স দ্রুত ভেঙে যাবে।

অন্যান্য ফ্লাক্স বাস্তবায়ন যেমন Flummox এবং Reflux বয়লারপ্লেট এবং ডিবাগিং অভিজ্ঞতা উন্নত করেছে। যদিও খুব ব্যবহারযোগ্য, নির্ভরতা ব্যবস্থাপনা ছিল একটি বিরক্তিকর সমস্যা যা সমস্ত ফ্লাক্স বাস্তবায়নকে জর্জরিত করেছিল। অন্য দোকান ব্যবহার কুশ্রী অনুভূত. গভীরভাবে বাসা বাঁধা নির্ভরতা গাছ অনুসরণ করা কঠিন ছিল।

এই ই-কমার্স অ্যাপে একদিন OrderHistory, ShippingCalculator, DeliveryEstimate, BananasHoarded ইত্যাদির জন্য স্টোর থাকতে পারে। একটি বড় অ্যাপে সহজেই শত শত স্টোর থাকতে পারে। আপনি কীভাবে প্রতিটি দোকানে নির্ভরতা আপ-টু-ডেট রাখবেন? আপনি কিভাবে পার্শ্ব প্রতিক্রিয়া ট্র্যাক করবেন? বিশুদ্ধতা সম্পর্কে কি? ডিবাগিং সম্পর্কে কি? কলা কি সত্যিই বেরি?

ফ্লাক্স দ্বারা প্রবর্তিত প্রোগ্রামিং নীতিগুলির জন্য, একমুখী ডেটা প্রবাহ একটি বিজয়ী ছিল, কিন্তু, আপাতত, ডিমিটারের আইন ছিল না।

সিঙ্গেলটন মডেল

আমরা সবাই জানি কিভাবে Redux দিন বাঁচাতে গর্জে উঠেছিল। এটি একটি সিঙ্গলটন মডেলের পক্ষে একাধিক স্টোরের ধারণাকে বাদ দিয়েছে। এখন সবকিছুই "নির্ভরতা" ছাড়াই অন্য সবকিছু অ্যাক্সেস করতে পারে।

Reducers খাঁটি, তাই একাধিক স্টেট স্লাইস নিয়ে কাজ করা সমস্ত যুক্তি অবশ্যই দোকানের বাইরে যেতে হবে। সম্প্রদায় পার্শ্ব প্রতিক্রিয়া এবং প্রাপ্ত রাষ্ট্র পরিচালনার জন্য মান তৈরি করেছে। Redux স্টোরগুলি সুন্দরভাবে ডিবাগযোগ্য। একমাত্র প্রধান ফ্লাক্স ফ্লা যা রেডক্স মূলত ঠিক করতে ব্যর্থ হয়েছিল সেটি হল এর বয়লারপ্লেট।

RTK পরে রেডাক্সের কুখ্যাত বয়লারপ্লেটকে সরলীকৃত করে। তারপর জুস্ট্যান্ড কিছু ডিবাগিং পাওয়ার খরচে কিছু ফ্লাফ সরিয়ে ফেলে। এই সমস্ত সরঞ্জাম প্রতিক্রিয়া জগতে অত্যন্ত জনপ্রিয় হয়ে উঠেছে।

মডুলার অবস্থার সাথে, নির্ভরতা গাছগুলি প্রাকৃতিকভাবে এত জটিল হয়ে ওঠে যে আমরা ভাবতে পারি সেরা সমাধানটি হল, "আমার ধারণা এটি করবেন না।"

এবং এটা কাজ করে! এই নতুন সিঙ্গেলটন পদ্ধতি এখনও বেশিরভাগ অ্যাপের জন্য যথেষ্ট ভাল কাজ করে। ফ্লাক্স নীতিগুলি এতটাই দৃঢ় ছিল যে কেবল নির্ভরতা দূর করা দুঃস্বপ্ন এটিকে স্থির করেছিল।

নাকি করেছে?

প্রাথমিক স্তরে ফিরে আসা

সিঙ্গলটন পদ্ধতির সাফল্য প্রশ্ন জাগিয়েছে, ফ্লাক্স প্রথম স্থানে কী পেয়েছিল? কেন আমরা কখনো একাধিক দোকান চাই?

আমাকে এই বিষয়ে কিছু আলোকপাত করার অনুমতি দিন।

কারণ # 1: স্বায়ত্তশাসন

একাধিক দোকান সহ, রাজ্যের টুকরোগুলি তাদের নিজস্ব স্বায়ত্তশাসিত, মডুলার পাত্রে বিভক্ত হয়ে যায়। এই দোকানগুলি বিচ্ছিন্নভাবে পরীক্ষা করা যেতে পারে। এগুলি অ্যাপ এবং প্যাকেজের মধ্যে সহজেই ভাগ করা যায়।

কারণ #2: কোড স্প্লিটিং

এই স্বায়ত্তশাসিত দোকানগুলি পৃথক কোড খণ্ডে বিভক্ত করা যেতে পারে। একটি ব্রাউজারে, তারা অলস-লোড হতে পারে এবং ফ্লাইতে প্লাগ ইন করতে পারে।

Redux এর রিডুসারগুলি কোড-বিভক্ত করাও মোটামুটি সহজ। replaceReducer কে ধন্যবাদ, একমাত্র অতিরিক্ত পদক্ষেপ হল নতুন সম্মিলিত রিডুসার তৈরি করা। যাইহোক, পার্শ্ব প্রতিক্রিয়া এবং মিডলওয়্যার জড়িত থাকলে আরও পদক্ষেপের প্রয়োজন হতে পারে।

কারণ #3: প্রমিত আদিম

সিঙ্গেলটন মডেলের সাথে, আপনার নিজের সাথে একটি বাহ্যিক মডিউলের অভ্যন্তরীণ অবস্থাকে কীভাবে একীভূত করা যায় তা জানা কঠিন। রেডক্স সম্প্রদায় এটি সমাধান করার প্রয়াস হিসাবে হাঁসের প্যাটার্ন চালু করেছে। এবং এটি কাজ করে, সামান্য বয়লারপ্লেটের খরচে।

একাধিক স্টোরের সাথে, একটি বহিরাগত মডিউল কেবল একটি দোকানকে প্রকাশ করতে পারে। উদাহরণস্বরূপ, একটি ফর্ম লাইব্রেরি একটি ফর্মস্টোর রপ্তানি করতে পারে। এর সুবিধা হল যে স্ট্যান্ডার্ডটি "অফিসিয়াল" এর অর্থ হল লোকেরা তাদের নিজস্ব পদ্ধতি তৈরি করার সম্ভাবনা কম। এটি আরও শক্তিশালী, একীভূত সম্প্রদায় এবং প্যাকেজ ইকোসিস্টেমের দিকে পরিচালিত করে।

কারণ #4: মাপযোগ্যতা

সিঙ্গলটন মডেল আশ্চর্যজনকভাবে পারফরম্যান্স। Redux তা প্রমাণ করেছে। যাইহোক, এর নির্বাচন মডেল বিশেষ করে একটি হার্ড উপরের সীমা আছে. আমি এই রিসিলেক্ট আলোচনায় এই বিষয়ে কিছু চিন্তা লিখেছি। একটি বড়, ব্যয়বহুল নির্বাচক গাছ সত্যিই টেনে আনতে শুরু করতে পারে, এমনকি ক্যাশিংয়ের উপর সর্বাধিক নিয়ন্ত্রণ নেওয়ার পরেও।

অন্যদিকে, একাধিক স্টোরের সাথে, বেশিরভাগ রাষ্ট্রীয় আপডেটগুলি রাজ্য গাছের একটি ছোট অংশে বিচ্ছিন্ন। তারা সিস্টেমে অন্য কিছু স্পর্শ করে না। এটি সিঙ্গলটন পদ্ধতির বাইরে অনেক বেশি মাপযোগ্য - আসলে, একাধিক স্টোরের সাথে, ব্যবহারকারীর মেশিনে মেমরির সীমাবদ্ধতা আঘাত করার আগে CPU সীমাবদ্ধতাগুলি আঘাত করা খুব কঠিন।

কারণ #5: ধ্বংস

রেডাক্সে রাষ্ট্র ধ্বংস করা খুব কঠিন নয়। কোড-বিভক্ত করার উদাহরণের মতো, এটির রিডুসার শ্রেণিবিন্যাসের একটি অংশ সরাতে শুধুমাত্র কয়েকটি অতিরিক্ত পদক্ষেপের প্রয়োজন। তবে একাধিক স্টোরের সাথে এটি এখনও সহজ - তাত্ত্বিকভাবে, আপনি কেবল প্রেরক থেকে স্টোরটি আলাদা করতে পারেন এবং এটিকে আবর্জনা সংগ্রহ করার অনুমতি দিতে পারেন।

কারণ #6: কোলোকেশন

এটি একটি বড় যা রেডক্স, জুস্ট্যান্ড এবং সাধারণভাবে সিঙ্গেলটন মডেলগুলি ভালভাবে পরিচালনা করে না। পার্শ্ব প্রতিক্রিয়া রাষ্ট্র থেকে পৃথক করা হয় তারা যোগাযোগ. নির্বাচন যুক্তি সবকিছু থেকে পৃথক করা হয়. যদিও মাল্টি-স্টোর ফ্লাক্স সম্ভবত খুব কোলোকেটেড ছিল, রেডাক্স বিপরীত চরমে গিয়েছিল।

একাধিক স্বায়ত্তশাসিত স্টোরের সাথে, এই জিনিসগুলি স্বাভাবিকভাবেই একসাথে যায়। সত্যিই, ফ্লাক্সের কেবলমাত্র কয়েকটি মানদণ্ডের অভাব ছিল যা সবকিছুকে গব্লেডিগুকের হেল্টার-স্কেলটার হজ-পজ হয়ে উঠতে বাধা দেয় (দুঃখিত)।

কারণ সারাংশ

এখন, আপনি যদি ওজি ফ্লাক্স লাইব্রেরি জানেন তবে আপনি জানেন যে এটি আসলে এই সমস্তটিতে দুর্দান্ত ছিল না। প্রেরণকারী এখনও একটি বিশ্বব্যাপী পদ্ধতি গ্রহণ করে - প্রতিটি দোকানে প্রতিটি কাজ প্রেরণ করে৷ অনানুষ্ঠানিক/অন্তর্নিহিত নির্ভরতা সহ পুরো জিনিসটিও কোড বিভাজন এবং ধ্বংসকে নিখুঁত থেকে কম করেছে।

তবুও, ফ্লাক্স এর জন্য প্রচুর দুর্দান্ত বৈশিষ্ট্য ছিল। এছাড়াও মাল্টিপল-স্টোর পদ্ধতিতে ইনভারশন অফ কন্ট্রোল এবং ফ্র্যাক্টাল (ওরফে স্থানীয়) স্টেট ম্যানেজমেন্টের মতো আরও বেশি বৈশিষ্ট্যের সম্ভাবনা রয়েছে।

ফ্লাক্স হয়ত একজন সত্যিকারের শক্তিশালী রাষ্ট্র ব্যবস্থাপক হয়ে উঠতে পারত যদি কেউ তাদের দেবী ডেমিটারের নাম না রাখত। আমি সিরিয়াস! ... ঠিক আছে, আমি না. কিন্তু এখন আপনি এটি উল্লেখ করেছেন, সম্ভবত ডিমিটারের আইনটি আরও ঘনিষ্ঠভাবে দেখার যোগ্য:

ডিমিটারের আইন

এই তথাকথিত "আইন" আসলে কি? উইকিপিডিয়া থেকে:

• প্রতিটি ইউনিটের অন্যান্য ইউনিট সম্পর্কে শুধুমাত্র সীমিত জ্ঞান থাকা উচিত: শুধুমাত্র ইউনিটগুলি বর্তমান ইউনিটের সাথে "ঘনিষ্ঠভাবে" সম্পর্কিত।
• প্রতিটি ইউনিট শুধুমাত্র তার বন্ধুদের সাথে কথা বলা উচিত; অপরিচিতদের সাথে কথা বলবেন না।

এই আইনটি অবজেক্ট-ওরিয়েন্টেড প্রোগ্রামিংকে মাথায় রেখে ডিজাইন করা হয়েছিল, তবে এটি প্রতিক্রিয়া রাজ্য পরিচালনা সহ অনেক ক্ষেত্রে প্রয়োগ করা যেতে পারে।

মূল ধারণা হল একটি দোকান থেকে প্রতিরোধ করা:

• শক্তভাবে নিজেকে অন্য দোকানের বাস্তবায়ন বিবরণের সাথে সংযুক্ত করা।
• স্টোর ব্যবহার করা যা সম্পর্কে জানার প্রয়োজন নেই ।
• স্পষ্টভাবে সেই দোকানের উপর নির্ভরতা ঘোষণা না করে অন্য কোনো দোকান ব্যবহার করা।

কলার পরিভাষায়, একটি কলার অন্য কলার খোসা উচিত নয় এবং অন্য গাছের একটি কলার সাথে কথা বলা উচিত নয়। যাইহোক, এটি অন্য গাছের সাথে কথা বলতে পারে যদি দুটি গাছ প্রথমে একটি কলা ফোন লাইন ধরে রাখে।

এটি উদ্বেগের বিচ্ছেদকে উৎসাহিত করে এবং আপনার কোডটিকে মডুলার, শুষ্ক এবং সলিড থাকতে সাহায্য করে। কঠিন তত্ত্ব! তাহলে কি ফ্লাক্স অনুপস্থিত ছিল?

ভাল, আন্তঃ-স্টোর নির্ভরতা একটি ভাল, মডুলার সিস্টেমের একটি প্রাকৃতিক অংশ। যদি একটি দোকানের অন্য নির্ভরতা যোগ করার প্রয়োজন হয়, তাহলে এটি করা উচিত এবং যতটা সম্ভব স্পষ্টভাবে করা উচিত। এখানে আবার সেই ফ্লাক্স কোডের কিছু রয়েছে:

 PromosStore.dispatchToken = dispatcher.register(payload => { if (payload.actionType === 'add-to-cart') { // wait for CartStore to update first: dispatcher.waitFor([CartStore.dispatchToken]) // now send the request sendPromosRequest(UserStore.userId, CartStore.items).then(promos => { dispatcher.dispatch({ actionType: 'promos-fetched', promos }) }) } if (payload.actionType === 'promos-fetched') { PromosStore.setPromos(payload.promos) } })

PromosStore-এর একাধিক নির্ভরতা বিভিন্ন উপায়ে ঘোষণা করা হয়েছে - এটি অপেক্ষা করে এবং CartStore থেকে পড়ে এবং এটি UserStore থেকে পড়ে। এই নির্ভরতাগুলি আবিষ্কার করার একমাত্র উপায় হল PromosStore এর বাস্তবায়নে স্টোরগুলি সন্ধান করা।

দেব সরঞ্জামগুলি এই নির্ভরতাগুলিকে আরও আবিষ্কারযোগ্য করতে সহায়তা করতে পারে না। অন্য কথায়, নির্ভরতাগুলি খুব অন্তর্নিহিত।

যদিও এটি একটি খুব সহজ এবং কল্পিত উদাহরণ, এটি ব্যাখ্যা করে কিভাবে ফ্লাক্স ডিমিটারের আইনের ভুল ব্যাখ্যা করেছে। যদিও আমি নিশ্চিত যে এটি বেশিরভাগই ফ্লাক্স বাস্তবায়নকে ছোট রাখার ইচ্ছা থেকে জন্ম নিয়েছে (বাস্তব নির্ভরতা ব্যবস্থাপনা একটি জটিল কাজ!), এখানেই ফ্লাক্স কম পড়েছিল।

এই গল্পের নায়কদের থেকে ভিন্ন:

হিরোস

2020 সালে, রিকোয়েল দৃশ্যে হোঁচট খেয়ে এসেছিল। প্রথমে একটু আনাড়ি হলেও, এটি আমাদের একটি নতুন প্যাটার্ন শিখিয়েছে যা ফ্লাক্সের একাধিক-স্টোর পদ্ধতিকে পুনরুজ্জীবিত করেছে।

একমুখী তথ্য প্রবাহ স্টোর থেকে নিজেই নির্ভরতা গ্রাফে সরানো হয়েছে। দোকানগুলোকে এখন পরমাণু বলা হতো। পরমাণু সঠিকভাবে স্বায়ত্তশাসিত এবং কোড-বিভাজনযোগ্য ছিল। তাদের সাসপেন্স সমর্থন এবং হাইড্রেশনের মতো নতুন ক্ষমতা ছিল। এবং সবচেয়ে গুরুত্বপূর্ণ, পরমাণু আনুষ্ঠানিকভাবে তাদের নির্ভরতা ঘোষণা করে।

পারমাণবিক মডেলের জন্ম হয়েছিল।

 // a Recoil atom const greetingAtom = atom({ key: 'greeting', default: 'Hello, World!', })

রিকোয়েল একটি স্ফীত কোডবেস, মেমরি লিক, খারাপ কর্মক্ষমতা, ধীরগতির বিকাশ এবং অস্থির বৈশিষ্ট্যগুলির সাথে লড়াই করেছে - সবচেয়ে উল্লেখযোগ্যভাবে পার্শ্ব প্রতিক্রিয়া। এটি ধীরে ধীরে এর মধ্যে কিছুকে আয়রন করবে, কিন্তু ইতিমধ্যে, অন্যান্য লাইব্রেরিগুলি রিকোয়েলের ধারণাগুলি নিয়েছিল এবং তাদের সাথে দৌড়েছিল।

জোতাই ঘটনাস্থলে ছুটে যান এবং দ্রুত একটি অনুসারী লাভ করেন।

 // a Jotai atom const greetingAtom = atom('Hello, World!')

Recoil এর আকারের একটি ক্ষুদ্র ভগ্নাংশ হওয়ার পাশাপাশি, জোতাই তার দুর্বলম্যাপ-ভিত্তিক পদ্ধতির কারণে আরও ভাল পারফরম্যান্স, মসৃণ API এবং কোনও মেমরি লিক না দেওয়ার প্রস্তাব দিয়েছে।

যাইহোক, এটি কিছু শক্তির খরচে এসেছে - WeakMap পদ্ধতির ক্যাশে নিয়ন্ত্রণকে কঠিন করে তোলে এবং একাধিক উইন্ডো বা অন্যান্য অঞ্চলের মধ্যে ভাগ করা প্রায় অসম্ভব। এবং স্ট্রিং কীগুলির অভাব, মসৃণ থাকাকালীন, ডিবাগিংকে দুঃস্বপ্ন করে তোলে। বেশির ভাগ অ্যাপের সেইগুলি আবার যোগ করা উচিত, যা জোতাইয়ের মসৃণতাকে মারাত্মকভাবে কলঙ্কিত করে।

 // a (better?) Jotai atom const greetingAtom = atom('Hello, World!') greetingAtom.debugLabel = 'greeting'

কয়েকটি সম্মানজনক উল্লেখ হল Reatom এবং Nanostores । এই লাইব্রেরিগুলি পারমাণবিক মডেলের পিছনে আরও তত্ত্ব অনুসন্ধান করেছে এবং এর আকার এবং গতি সীমাতে ঠেলে দেওয়ার চেষ্টা করেছে।

পারমাণবিক মডেল দ্রুত এবং স্কেল খুব ভাল. কিন্তু খুব সম্প্রতি পর্যন্ত, কিছু উদ্বেগ ছিল যে কোনও পারমাণবিক লাইব্রেরি খুব ভালভাবে সমাধান করেনি:

• শেখার বক্ররেখা. পরমাণু ভিন্ন । কিভাবে আমরা এই ধারণাগুলোকে রিঅ্যাক্ট ডেভের জন্য সহজলভ্য করতে পারি?

  
  

• দেব এক্স এবং ডিবাগিং। আমরা কিভাবে পরমাণু আবিষ্কারযোগ্য করতে পারি? আপনি কীভাবে আপডেটগুলি ট্র্যাক করবেন বা ভাল অনুশীলনগুলি প্রয়োগ করবেন?

  
  

• বিদ্যমান কোডবেসের জন্য ক্রমবর্ধমান স্থানান্তর। আপনি কিভাবে বহিরাগত দোকান অ্যাক্সেস করবেন? আপনি কিভাবে বিদ্যমান যুক্তি অক্ষত রাখবেন? কিভাবে আপনি একটি সম্পূর্ণ পুনর্লিখন এড়াবেন?

  
  

• প্লাগইন। কিভাবে আমরা পারমাণবিক মডেল এক্সটেনসিবল করতে পারি? এটি প্রতিটি সম্ভাব্য পরিস্থিতি পরিচালনা করতে পারে ?

  
  

• ইনজেকশন নির্ভরতা. পরমাণু স্বাভাবিকভাবেই নির্ভরতাকে সংজ্ঞায়িত করে, কিন্তু পরীক্ষার সময় বা বিভিন্ন পরিবেশে সেগুলি কি অদলবদল করা যায়?

  
  

• ডিমিটারের আইন। আমরা কিভাবে বাস্তবায়নের বিবরণ লুকাবো এবং বিক্ষিপ্ত আপডেট রোধ করব?

আমি এখানেই এসেছি। দেখুন, আমি অন্য একটি পারমাণবিক গ্রন্থাগারের মূল স্রষ্টা:

জেডুক্স

Zedux অবশেষে দৃশ্যে প্রবেশ কয়েক সপ্তাহ আগে. নিউ ইয়র্কের একটি ফিনটেক কোম্পানি দ্বারা তৈরি করা হয়েছে - যে কোম্পানির জন্য আমি কাজ করি - Zedux শুধুমাত্র দ্রুত এবং মাপযোগ্য হওয়ার জন্য ডিজাইন করা হয়নি, বরং একটি মসৃণ বিকাশ এবং ডিবাগিং অভিজ্ঞতা প্রদান করার জন্যও তৈরি করা হয়েছে৷

 // a Zedux atom const greetingAtom = atom('greeting', 'Hello, World!')

আমি এখানে Zedux এর বৈশিষ্ট্যগুলি সম্পর্কে গভীরে যাব না - যেমন আমি বলেছি, এই নিবন্ধটি এই পারমাণবিক লাইব্রেরির মধ্যে পার্থক্যগুলিতে ফোকাস করবে না।

এটা বলাই যথেষ্ট যে Zedux উপরের সমস্ত উদ্বেগের সমাধান করে। উদাহরণ স্বরূপ, এটিই প্রথম পারমাণবিক লাইব্রেরি যা প্রকৃত নিয়ন্ত্রণের ইনভার্সন অফার করে এবং বাস্তবায়নের বিবরণ লুকানোর জন্য পরমাণু রপ্তানির প্রস্তাব দিয়ে ডিমিটারের আইনে আমাদেরকে পূর্ণ-বৃত্তে ফিরিয়ে আনতে প্রথম।

ফ্লাক্সের শেষ মতাদর্শগুলি অবশেষে পুনরুজ্জীবিত হয়েছে - কেবল পুনরুজ্জীবিত নয়, উন্নত হয়েছে! - পারমাণবিক মডেলের জন্য ধন্যবাদ।

তাহলে পারমাণবিক মডেল ঠিক কি ?

পারমাণবিক মডেল

এই পারমাণবিক লাইব্রেরিগুলির অনেক পার্থক্য রয়েছে - এমনকি "পারমাণবিক" মানে কী তার বিভিন্ন সংজ্ঞা রয়েছে। সাধারণ ঐকমত্য হল যে পরমাণুগুলি ছোট, বিচ্ছিন্ন, স্বায়ত্তশাসিত রাষ্ট্রীয় পাত্রে একটি নির্দেশিত অ্যাসাইক্লিক গ্রাফের মাধ্যমে প্রতিক্রিয়াশীলভাবে আপডেট হয়।

আমি জানি, আমি জানি, এটা জটিল শোনাচ্ছে, কিন্তু কলা দিয়ে ব্যাখ্যা করা পর্যন্ত অপেক্ষা করুন।

ঠাট্টা করছি! এটা আসলে সত্যিই সহজ:

গ্রাফের মাধ্যমে রিকোচেট আপডেট করে। এটাই!

বিন্দু হল, বাস্তবায়ন বা শব্দার্থবিদ্যা নির্বিশেষে, এই সমস্ত পারমাণবিক লাইব্রেরিগুলি একাধিক স্টোরের ধারণাকে পুনরুজ্জীবিত করেছে এবং সেগুলিকে কেবল ব্যবহারযোগ্যই নয়, কাজ করার জন্য একটি সত্যিকারের আনন্দ করেছে।

একাধিক স্টোর চাওয়ার জন্য আমি যে 6টি কারণ দিয়েছি তা হল পারমাণবিক মডেলটি এত শক্তিশালী হওয়ার কারণগুলি:

1. স্বায়ত্তশাসন - পরমাণু পরীক্ষা করা যেতে পারে এবং সম্পূর্ণরূপে বিচ্ছিন্নভাবে ব্যবহার করা যেতে পারে।
2. কোড স্প্লিটিং - একটি পরমাণু আমদানি করুন এবং এটি ব্যবহার করুন! কোন অতিরিক্ত বিবেচনার প্রয়োজন নেই.
3. প্রমিত আদিম - যে কোনো কিছু স্বয়ংক্রিয় একীকরণের জন্য একটি পরমাণু প্রকাশ করতে পারে।
4. পরিমাপযোগ্যতা - আপডেটগুলি রাষ্ট্রীয় গাছের একটি ছোট অংশকে প্রভাবিত করে।
5. ধ্বংস - কেবল একটি পরমাণু ব্যবহার বন্ধ করুন এবং এর সমস্ত অবস্থা আবর্জনা সংগ্রহ করা হয়।
6. Colocation - পরমাণু স্বাভাবিকভাবেই তাদের নিজস্ব অবস্থা, পার্শ্ব প্রতিক্রিয়া এবং আপডেট যুক্তি সংজ্ঞায়িত করে।

সাধারণ API এবং স্কেলেবিলিটি একাই পারমাণবিক লাইব্রেরিগুলিকে প্রতিটি প্রতিক্রিয়া অ্যাপের জন্য একটি দুর্দান্ত পছন্দ করে তোলে। রেডাক্সের চেয়ে বেশি শক্তি এবং কম বয়লারপ্লেট? এটা কি স্বপ্ন?

উপসংহার

কি যাত্রা! রিঅ্যাক্ট স্টেট ম্যানেজমেন্টের জগত কখনই বিস্মিত হয় না, এবং আমি খুব আনন্দিত যে আমি একটি যাত্রা শুরু করেছি।

আমরা শুধু শুরু করছি. পরমাণু নিয়ে নতুনত্বের অনেক জায়গা আছে। Zedux তৈরি এবং ব্যবহার করে বছর অতিবাহিত করার পরে, আমি দেখেছি যে পারমাণবিক মডেল কতটা শক্তিশালী হতে পারে। আসলে, এর শক্তি হল এর অ্যাকিলিস হিল:

যখন devs পরমাণুগুলি অন্বেষণ করে, তারা প্রায়শই সম্ভাবনাগুলির এত গভীরে খনন করে যে তারা "এই পাগল জটিল শক্তির দিকে তাকান" বলে ফিরে আসে, "দেখুন কিভাবে সহজ এবং মার্জিতভাবে পরমাণু এই সমস্যার সমাধান করে।" আমি এই পরিবর্তন করতে এখানে আছি.

পারমাণবিক মডেল এবং এর পিছনের তত্ত্বটি এমনভাবে শেখানো হয়নি যা বেশিরভাগ প্রতিক্রিয়া বিকাশকারীদের কাছে পৌঁছানো যায়। একভাবে, এ পর্যন্ত পরমাণুর প্রতিক্রিয়া জগতের অভিজ্ঞতা ফ্লাক্সের বিপরীত:

এই নিবন্ধটি পরমাণু লাইব্রেরিগুলি কীভাবে কাজ করে এবং আপনি কেন একটি ব্যবহার করতে চান তা বুঝতে প্রতিক্রিয়া devsকে সহায়তা করার জন্য আমি তৈরি করছি শেখার সংস্থানগুলির একটি সিরিজের মধ্যে এই নিবন্ধটি দ্বিতীয়। প্রথম নিবন্ধটি দেখুন - স্কেলেবিলিটি: দ্য লস্ট লেভেল অফ রিঅ্যাক্ট স্টেট ম্যানেজমেন্ট ।

এটি 10 বছর সময় নিয়েছে, কিন্তু Flux দ্বারা প্রবর্তিত কঠিন CS তত্ত্ব অবশেষে পারমাণবিক মডেলের জন্য একটি বড় উপায়ে প্রতিক্রিয়া অ্যাপগুলিকে প্রভাবিত করছে৷ এবং এটি আগামী বছর ধরে চলতে থাকবে।