🎐 🤬 ♻️ हम एल्म अनुप्रयोगों में बहुत बड़े एमएसजी के साथ लड़ते हैं 📪 ✊🏻 💪🏽

एल्म आर्किटेक्चर के अनुसार, सभी एप्लिकेशन लॉजिक एक ही स्थान पर केंद्रित हैं। यह एक काफी सरल और सुविधाजनक तरीका है, लेकिन एप्लिकेशन की वृद्धि के साथ, आप 700 फ़ंक्शन की लंबाई के साथ update फ़ंक्शन देख सकते हैं, सौ बिल्डरों और Model साथ Msg , जो स्क्रीन पर फिट नहीं होता है।

इस तरह के कोड सीखना बहुत कठिन है और अक्सर बनाए रखते हैं। मैं एक बहुत ही सरल तकनीक का प्रदर्शन करना चाहूंगा जो आपके एप्लिकेशन में सार के स्तर को बेहतर बनाएगी।

आइए एक साधारण उदाहरण देखें।

सबसे पहले, केवल एक टेक्स्ट फ़ील्ड के साथ एक छोटा अनुप्रयोग बनाएं। पूर्ण कोड यहां पाया जा सकता है ।

 type alias Model = { name : String } view : Model -> Html Msg view model = div [] [ input [ placeholder "Name", value model.name, onInput ChangeName ] [] ] type Msg = ChangeName String update : Msg -> Model -> Model update msg model = case msg of ChangeName newName -> { model | name = newName }

एप्लिकेशन बढ़ रहा है, हम अंतिम नाम, "अपने बारे में" और "सहेजें" बटन जोड़ते हैं। यहाँ पर कमिट करें ।

 type alias Model = { name : String , surname : String , bio : String } view : Model -> Html Msg view model = div [] [ input [ placeholder "Name", value model.name, onInput ChangeName ] [] , br [] [] , input [ placeholder "Surname", value model.surname, onInput ChangeSurname ] [] , br [] [] , textarea [ placeholder "Bio", onInput ChangeBio, value model.bio ] [] , br [] [] , button [ onClick Save ] [ text "Save" ] ] type Msg = ChangeName String | ChangeSurname String | ChangeBio String | Save update : Msg -> Model -> Model update msg model = case msg of ChangeName newName -> { model | name = newName } ChangeSurname newSurname -> { model | surname = newSurname } ChangeBio newBio -> { model | bio = newBio } Save -> ...

कुछ भी उल्लेखनीय नहीं है, सब ठीक है।

लेकिन जटिलता नाटकीय रूप से बढ़ जाती है जब हम अपने पेज में एक और घटक जोड़ने का फैसला करते हैं जो मौजूदा एक - कुत्ते के लिए पूरी तरह से असंबंधित है। कमिट ।

 type Msg = ChangeName String | ChangeSurname String | ChangeBio String | Save | ChangeDogName String | ChangeBreed String | ChangeDogBio String | SaveDog update : Msg -> Model -> Model update msg model = case msg of ChangeName newName -> { model | name = newName } ChangeSurname newSurname -> { model | surname = newSurname } ChangeBio newBio -> { model | bio = newBio } Save -> ... ChangeDogName newName -> { model | dogName = newName } ChangeBreed newBreed -> { model | breed = newBreed } ChangeDogBio newBio -> { model | dogBio = newBio } SaveDog -> ...

पहले से ही इस स्तर पर, आप देख सकते हैं कि Msg में Msg दो "समूह" हैं। मेरे "प्रोग्रामेटिक फ्लेयर" से पता चलता है कि ऐसी चीजों को अमूर्त करने की आवश्यकता है। 5 और घटक दिखाई देने पर क्या होगा? उपकेंद्रों के बारे में क्या? इस कोड में नेविगेट करना लगभग असंभव होगा।

क्या हम अमूर्तता की इस अतिरिक्त परत का परिचय दे सकते हैं? बेशक !

 type Msg = HoomanEvent HoomanMsg | DoggoEvent DoggoMsg type HoomanMsg = ChangeHoomanName String | ChangeHoomanSurname String | ChangeHoomanBio String | SaveHooman type DoggoMsg = ChangeDogName String | ChangeDogBreed String | ChangeDogBio String | SaveDog update : Msg -> Model -> Model update msg model = case msg of HoomanEvent hoomanMsg -> updateHooman hoomanMsg model DoggoEvent doggoMsg -> updateDoggo doggoMsg model updateHooman : HoomanMsg -> Model -> Model updateHooman msg model = case msg of ChangeHoomanName newName -> { model | name = newName } -- Code skipped -- updateDoggo : DoggoMsg -> Model -> Model -- Code skipped -- view : Model -> Html Msg view model = div [] [ h3 [] [ text "Hooman" ] , input [ placeholder "Name", value model.name, onInput (HoomanEvent << ChangeHoomanName) ] [] , -- Code skipped -- , button [ onClick (HoomanEvent SaveHooman) ] [ text "Save" ] , h3 [] [ text "Doggo" ] , input [ placeholder "Name", value model.dogName, onInput (DoggoEvent << ChangeDogName) ] [] , -- Code skipped -- ]

एल्म प्रकार प्रणाली का उपयोग करते हुए, हमने अपने संदेशों को दो प्रकारों में विभाजित किया है: मानव और कुत्ते। अब इस कोड को दर्ज करने की दहलीज बहुत आसान हो जाएगी। जैसे ही कुछ डेवलपर को घटकों में से किसी एक में कुछ बदलने की आवश्यकता होती है, वह तुरंत उस प्रकार की संरचना द्वारा निर्धारित करने में सक्षम होगा जो कोड के कुछ हिस्सों की जरूरत है। कुत्ते की जानकारी प्रतिधारण में तर्क जोड़ने की आवश्यकता है? संदेशों को देखें और उन पर खोज शुरू करें।

कल्पना करें कि आपका कोड एक विशाल संदर्भ है। आप उन जानकारियों की खोज कैसे करेंगे, जिनमें आपकी रुचि है सामग्री की तालिका (Msg और मॉडल) द्वारा। क्या आपके लिए अनुभागों और उपखंडों में विभाजित किए बिना सामग्री की तालिका को नेविगेट करना आसान होगा? शायद ही।

निष्कर्ष

यह एक अत्यंत सरल तकनीक है जिसका उपयोग कहीं भी किया जा सकता है और मौजूदा कोड में एम्बेड करना बहुत आसान है। मौजूदा एप्लिकेशन को फिर से भरना पूरी तरह से दर्द रहित होगा, स्थैतिक टाइपिंग और हमारे पसंदीदा एल्म कंपाइलर के लिए धन्यवाद।

आपके समय का केवल एक घंटा (हमने अपनी परियोजना पर प्रत्येक एप्लिकेशन पर 20 मिनट से कम समय बिताया) के बाद, आप अपने कोड की पठनीयता में काफी सुधार कर सकते हैं और भविष्य में इसे कैसे लिखा जाए, इसके लिए मानक निर्धारित किया है। उस कोड को नहीं जो त्रुटियों को ठीक करना आसान है, अच्छा है, लेकिन वह जो त्रुटियों को रोकता है और एक उदाहरण सेट करता है कि कोड को कैसे लिखा जाना चाहिए।

वास्तव में उसी तकनीक को Model लागू किया जा सकता है, जो आवश्यक प्रकारों में आवश्यक जानकारी को उजागर करता है। उदाहरण के लिए, हमारे उदाहरण में, मॉडल को केवल दो प्रकारों में विभाजित किया जा सकता है: Doggo और Doggo , मॉडल में फ़ील्ड की संख्या को दो तक कम करना।

भगवान एल्म प्रकार प्रणाली को बचाते हैं।

यदि आप अंतर देखना चाहते हैं तो कोड के साथ PS रिपॉजिटरी यहां मिल सकती है

हम एल्म अनुप्रयोगों में बहुत बड़े एमएसजी के साथ लड़ते हैं

निष्कर्ष

More articles: