একটি দ্রষ্টব্য হিসাবে: আমি রেডাক্সের জন্য ডকগুলি পড়েছি (বাওবাবও খুব), এবং আমি গুগলিং এবং পরীক্ষার ন্যায্য অংশটি করেছি।
কেন এত জোরালো পরামর্শ দেওয়া হচ্ছে যে একটি রেডাক্স অ্যাপ্লিকেশনটিতে কেবল একটি স্টোর রয়েছে?
আমি একাধিক স্টোর সেটআপ বনাম একটি একক-স্টোর সেটআপের উপকারিতা / বিষয়গুলি বুঝতে পারি ( এই বিষয়ে এসও-তে অনেকগুলি প্রশ্নোত্তর রয়েছে )।
আইএমও, এই আর্কিটেকচারাল সিদ্ধান্তটি অ্যাপ্লিকেশন বিকাশকারীদের তাদের প্রকল্পগুলির প্রয়োজনের উপর নির্ভর করে। তবে কেন এটি রেডাক্সের পক্ষে প্রায় বাধ্যতামূলক শোনার পর্যায়ে ( যদিও কোনও কিছুই আমাদের একাধিক দোকান তৈরি করা থেকে বিরত করছে না ) পরামর্শ দেওয়া হচ্ছে?
সম্পাদনা: একক দোকানে রূপান্তর করার পরে প্রতিক্রিয়া
অনেকে জটিল এসপিএ কী বিবেচনা করবেন তা নিয়ে রিডুএক্সের সাথে কয়েক মাস কাজ করার পরে, আমি বলতে পারি যে একক স্টোর কাঠামোটি কাজ করার জন্য খাঁটি আনন্দ হয়েছে।
কয়েকটি পয়েন্ট যা অন্যদেরকে বুঝতে সহায়তা করে যে কেন একক দোকান বনাম অনেকগুলি স্টোর বহু, অনেকগুলি ব্যবহারের ক্ষেত্রে শঙ্কিত প্রশ্ন:
- এটি নির্ভরযোগ্য : আমরা অ্যাপ্লিকেশন স্থিতিটি খনন করতে এবং প্রসঙ্গে-প্রাসঙ্গিক তথ্য পেতে নির্বাচকদের ব্যবহার করি use আমরা জানি যে সমস্ত প্রয়োজনীয় ডেটা একটি একক দোকানে। রাষ্ট্রের সমস্যাগুলি কোথায় হতে পারে সে সম্পর্কে এটি সমস্ত প্রশ্ন এড়িয়ে চলে।
- এটি দ্রুত : আমাদের স্টোরটিতে এখন আরও প্রায় 100 টির বেশি হ্রাসকারী রয়েছে। এমনকি সেই গণনায়, কেবলমাত্র কয়েকটি মুদ্রক যেকোন প্রদত্ত প্রেরণের ডেটা প্রক্রিয়া করে, অন্যরা কেবল পূর্বের অবস্থাটি ফিরিয়ে দেয়। একটি বিশাল / জটিল স্টোর ( হ্রাসকারীদের এনবিআর ) আর্গুমেন্টটি বেশ ধীর। কমপক্ষে আমরা সেখান থেকে কোনও পারফরম্যান্স সমস্যা দেখিনি।
- ডিবাগিং বন্ধুত্বপূর্ণ : সামগ্রিকভাবে রিডেক্সকে ব্যবহার করার পক্ষে এটি একটি অত্যন্ত দৃ argument় বিশ্বাস, যদিও এটি একক দোকান বনাম একাধিক স্টোরের জন্যও যায়। কোনও অ্যাপ তৈরি করার সময় আপনার প্রক্রিয়াতে রাষ্ট্রীয় ত্রুটি থাকতে বাধ্য ( প্রোগ্রামার ভুল ), এটি স্বাভাবিক। পিআইটিএ হ'ল এই ত্রুটিগুলি ডিবাগ করতে কয়েক ঘন্টা সময় নেয়। একক স্টোর ( এবং রিডেক্স-লগার ) এর জন্য আমরা কোনও প্রদত্ত রাষ্ট্রীয় ইস্যুতে কয়েক মিনিটের বেশি সময় ব্যয় করিনি বলে ধন্যবাদ ।
কয়েক পয়েন্টার
কীভাবে এটির কাঠামোগত করবেন তা স্থির করার সময় আপনার রিডেক্স স্টোর তৈরির সত্যিকারের চ্যালেঞ্জ । প্রথমত, কারণ রাস্তাটি কাঠামো পরিবর্তন করা কেবল একটি বড় ব্যথা। দ্বিতীয়ত, কারণ এটি আপনি কীভাবে ব্যবহার করবেন এবং যে কোনও প্রক্রিয়াটির জন্য আপনার অ্যাপ্লিকেশন ডেটা অনুসন্ধান করছেন তা মূলত নির্ধারণ করে। কোনও স্টোরকে কীভাবে গঠন করা যায় সে সম্পর্কে অনেক পরামর্শ রয়েছে। আমাদের ক্ষেত্রে আমরা নিম্নলিখিতটি আদর্শ হিসাবে পেয়েছি:
{
apis: { // data from various services
api1: {},
api2: {},
...
},
components: {} // UI state data for each widget, component, you name it
session: {} // session-specific information
}আশা করি এই মতামত অন্যদের সহায়তা করবে।
2 সম্পাদনা করুন - সহায়ক স্টোর সরঞ্জাম
আপনারা যারা ভাবছেন যে কীভাবে কোনও একক স্টোরকে "সহজেই" পরিচালনা করবেন , যা দ্রুত জটিল হয়ে উঠতে পারে। এমন একটি সরঞ্জাম রয়েছে যা আপনার স্টোরের কাঠামোগত নির্ভরতা / যুক্তি আলাদা করতে সহায়তা করে।
নেই Normalizr যা স্কিমা উপর ভিত্তি করে আপনার ডেটা normalizes। এরপরে এটি আপনার ডেটা নিয়ে কাজ করতে এবং idঅভিধানের মতো আপনার ডেটার অন্যান্য অংশগুলি আনার জন্য একটি ইন্টারফেস সরবরাহ করে ।
নরমালিজারকে সে সময় না জানার সাথে আমি একই লাইনের সাথে কিছু তৈরি করেছি। রিলেশনাল-জসন একটি স্কিমা নেয় এবং একটি সারণী-ভিত্তিক ইন্টারফেস ( ডাটাবেসের মতো কিছুটা ) ফেরত দেয় । রিলেশনাল-জসনের সুবিধা হ'ল আপনার ডেটা স্ট্রাকচারটি গতিশীলভাবে আপনার উপাত্তের অন্যান্য অংশগুলিকে রেফারেন্স করে ( প্রয়োজনীয়ভাবে, আপনি সাধারণ জেএস বস্তুর মতো আপনার দিকটি কোনও দিকনির্দেশ করতে পারেন )। এটি নরমালিজারের মতো পরিপক্ক নয়, তবে আমি উত্পাদন সহ এটি কয়েক মাস ধরে সফলভাবে ব্যবহার করছি।