Hey guys! it would be nice if the Russian-speaking audience would watch my content too 🪨

Maybe Ramz and I should make a joint content (in English or in Russian?). Sorry, I don't know Uzbek yet😅 We could record a podcast or get together in Discord as a group and do some networking with you 😎 I have extensive experience in backend development, mobile and a bit of frontend, managed fullstack projects and design - we will have something to talk about, share experience🙌

😦 O’zbekistonda bitta yaxshi ishlidigan servis bormi?

Bir nechi kun UzMobile dan e-sim bilan muammo bo’votti, shunchaki antenna yo’q bo’lib qovotti. Manga telefon qilib tushibomayapti.

Podderjkasiga telefon qilib ko’rila…tili tanlaganizdan keyin ham “Barakalli Million” haqida 2-ta tilda 4 daqiqa tinmastan robot gapiradi. Eshitib turishga majbursiz, muammo shundaki… 🤣

Bazida telefoni robot qo’yib qo’yadi, boshidan telefon qilasiz va boshidan eshitasiz. 😢

Bugun MahmoodKabob ga buyurtma qoldirdim, avtomat ravishda Payme bilan to’lovga havola yuborilmidi, birinchi menejer telefon qiladi. Muammo shundaki, menejer manga 20 daqiqadan keyin telefon qildi 😱 Buyurtma esimdan chiqiboldi.

MahmoodKabob oldin yaxshi ishlagan, nimagadir PuzzleBot-ga o’tqazishdi…yaxshi ishlavotgan narsani.

Hop, mayli. Ungacha “Яндекс Еда” dan ovqat zakaz qildim. Zakaz boshqa joyga bordi, pulim kuydi. Mayli, KFC zakaz qilarman. Keldi zakaz, faqat to’liq emas. 😩

Yandex Taxi haqida gapirmimanam.

Tizim yo’q, sifat yo’q. Dasturchilani aybi yo’q, shunchaki tadbirkorlar biznes tizimini eblashmadi. Chunaman, balki qiyin, lekin asabga teyadi.

Mayli, shunaqa oddiy muammolar bo’lsin. Hammamiz sog’miz, uyimiz bor.

Lekin baribir surishga harakat qilaman 😏

👨‍💻 Man eng yaxshiko’rgan dokumental film:

AlphaGo suniy intellekt Fan Hui “Go” jaxon chempionini yutganini haqida.

Bu Oktyabr 2015 yilda bo’lgan, adashmasam u payt ChatGPT
ham va unga o’xshagan LLM yo’q edi.

Ikkinchi marta ko’rmoqchiman.

Agar vaqtiz bo’lsa, ishlavotganizda ham ko’rishga kotta maslahat beraman.

Havola (Ingliz tilida)

Bram Moolenaar, 👩‍💻 yaratuvchisi, 3 Avgustda 2023 yilda (62 yoshda) vafot etdi.

https://en.m.wikipedia.org/wiki/Bram_Moolenaar

Reducer yaxshiroq chunishga qaror qildim! To'g'risi, borligini sababini xech chumaganman 😬

- Nimaga side effect qilish mumkin emas reducer ichida?
- Nima uchun o'zi reducer kere?
- Reducer shuncha boilerplate kodi bilan foydasi nima?

https://react.dev/learn/extracting-state-logic-into-a-reducer

Yangi react docs-dagi maqola zo'r chuntiriberdi, ichidi mashqlariga gap yo'q! 🔥 Manimcha bitta kotta komponenti refactor qilishim mumkin.

Lekin bitta mashqdagi narsani unchali chunmadim va balki @Toshkentov_U chuntiriberadilar 👇

Mashqda drafts feature qo'shish kere edi, man qilgan solution: xech qanqa public props-larni o'zgartirmadim, komponentlar (App) drafts haqida bilishmidi va message-dan foydalanishi davom etishadi.

To'g'ri, boshidan initial state-ga draft qo'shish kere, manga o'zimga bu narsa yoqmadi, lekin...

react.dev dagi solution: message -> messages array-ga aylantirish va App komponenti refactor qilish. Bilmadim.

Kimda vaqt bo'lganda react.dev dagi reducer mashqlarini qilib ko'rishga maslahat beraman va tepadagi fikri haqida o'ylab koring...

🤖 GPT-4 fikri

Both solutions, the one from react.dev and your solution, address the problem at hand effectively, but they do it in slightly different ways. Let's discuss the key differences and their implications:

1. State Structure:
- react.dev solution: Uses a messages object to keep track of all messages, including drafts, for each contact. The selectedId is used to index into this object to retrieve the current message.
- Your solution: Uses a combination of the message field for the currently selected contact's message and a drafts object to store the draft messages for all contacts.

2. State Duplication:
- In your solution, there's some level of data duplication because the message for the currently selected contact is both in the message field and in the drafts object. This introduces the potential for inconsistencies if not handled carefully.

3. Component Independence:
- Your solution ensures that the components remain unaware of the drafts. This encapsulation makes the components simpler but comes at the cost of increased complexity in the reducer logic.

4. Scalability and Maintenance:
- react.dev solution: As the number of features grow (e.g., adding message history, attachments, etc.), having a unified structure like messages can make it easier to extend because you're always working with a consistent data model.
- Your solution: While keeping the components unaware of the drafts can be seen as an advantage, it can become a limitation if you need to add features that require components to be aware of the drafts or other aspects of messaging. The duplication also poses a risk for potential bugs if not handled carefully.

Which is more correct?
- There's no absolute "correctness" in design; it depends on the context. Both solutions address the core problem. The react.dev solution is more streamlined in terms of state structure, while yours focuses on component encapsulation.

Which is more scalable?
- The react.dev solution seems more scalable due to the uniformity of the messages structure. It's easier to extend a single, consistent structure than to manage parallel structures.

Which is more maintainable?
- The react.dev solution is slightly more maintainable due to the lack of data duplication. Maintenance becomes simpler when there's a single source of truth for a given piece of data.

Conclusion:
While both solutions are viable, the react.dev solution has a slight edge in terms of scalability and maintainability due to its uniform state structure and absence of data duplication. Your solution emphasizes component encapsulation, which can be advantageous in certain contexts but introduces added complexity in the reducer. Consider the future features and needs of the application to determine the best fit for your context.

Manimcha react.dev-ga yutqazdim 😦