Reka bentuk yang didorong oleh domain dengan React

Terdapat panduan yang sangat sedikit tentang cara mengatur aplikasi front-end di dunia React. (Hanya gerakkan fail sehingga ia "terasa betul," lol). Sebenarnya kita boleh melakukan yang lebih baik. Mari kita lihat satu corak yang mungkin anda pertimbangkan untuk menggunakan arkitek laman web anda.

Pada mulanya, anda mungkin membahagikan kod antara /komponen dan /folder kontena. Ini berfungsi untuk laman web kecil tetapi anda akan mendapati diri anda mencari sesuatu yang lebih mantap apabila berskala ke laman web yang lebih besar. Nasib baik, dekad penyelidikan ke dalam reka bentuk sistem telah memberi kita banyak corak untuk meneroka untuk mewujudkan seni bina berskala.

Salah satu daripada mereka adalah reka bentuk yang didorong oleh domain , dan ia telah mendapat populariti sejak beberapa tahun kebelakangan. Mari kita meneroka bagaimana kita boleh menggunakannya di React-Land.

Primer mengenai reka bentuk yang didorong oleh domain

Reka bentuk yang didorong oleh domain (DDD) adalah amalan menguruskan kerumitan aplikasi perisian dengan mengaitkan model data asas mereka kepada logik domain . Itulah yang menyegarkan, jadi mari kita memecahkannya lebih jauh.

Domain adalah ontologi, yang bermaksud bagaimana keadaan dikumpulkan di dunia. Sebagai contoh, perkataan joist mempunyai sambungan yang sangat spesifik ke domain pembinaan bangunan. Satu lagi perkataan, seperti Mike , boleh tergolong dalam pelbagai domain, seperti domain nama -nama alkitabiah (pendek untuk Michael), atau dalam domain politik kerana ia berkaitan dengan abjad fonetik NATO.

Apabila reka bentuk didorong domain , ini bermakna kita meletakkan model domain kita (contohnya kad bermain dalam domain poker) dalam konteks (contohnya kumpulan kontekstual, seperti permainan) untuk membantu menguruskan kerumitan.

Mengatur laman web DDD

Reka bentuk yang didorong oleh domain khusus untuk mengendalikan kerumitan tapak yang semakin meningkat kerana mereka menambah lebih banyak model. Ia tidak masuk akal untuk laman web dengan satu model. Sebaik sahaja anda mendapat kira -kira empat model, itulah masa yang baik untuk mula melihat mengikat model anda ke pelbagai konteks . Ini bukan peraturan yang sukar dan cepat, jadi jangan merasa seperti anda harus memasuki pelbagai konteks, tetapi sebaik sahaja anda mendapat di atas empat model, kumpulan kontekstual akan mula muncul.

Mulakan dengan mengatur domain anda

Mari kita gunakan Twitter sebagai tapak contoh kami untuk disusun. Salah satu cara untuk memisahkan domain di Twitter adalah untuk memisahkan model kami di antara platform blog yang menguasai tweet dan unsur-unsur interaksi yang membolehkan mikro-blog untuk menyebarkan dan berkembang.

Adakah ini satu -satunya cara untuk memisahkan kebimbangan di Twitter? Pasti tidak! Satu aspek utama DDD ialah tidak ada cara yang betul untuk membuat domain . Terdapat banyak cara untuk memisahkan konteks yang dibatasi oleh aplikasi, jadi jangan terlalu fokus pada seni bina yang telah kami pilih. Sebaliknya, gunakan ini sebagai batu loncatan untuk memahami bagaimana kita boleh memohon DDD kepada organisasi kod depan kami.

Yang mengatakan, kod kami kini akan berstruktur untuk kelihatan seperti ini (dengan mengandaikan anda bermula dengan sesuatu seperti create-react-app):

 Twitter/
├── App.css
├── App.js
├── App.test.js
├── blog/
└── interaksi/

Tentukan komponen dan bekas di setiap domain

Sekarang kita mempunyai struktur folder asas kami, sudah tiba masanya untuk menambah beberapa komponen sebenar! Melihat gambarajah UML domain kami di atas, ia berguna untuk memulakan dengan bekas yang mengambil data pada halaman dan komponen tertentu yang menganjurkan templat yang mengarang halaman tersebut. Memperluas pada aplikasi kami, kami kini mempunyai struktur berikut (menghilangkan fail ujian kami yang disertakan untuk kesederhanaan):

 Twitter/
├── App.css
├── App.js
├── App.test.js
├── blog/
│ ├── homepage.js
│ ├── tweetcard.js
│ ├── tweetdialog.js
│ ├── tweetlist.js
│ ├── tweetlistitem.js
│ ├── userpage.js
│ └── usercard.js
└── interaksi/
    ├── ikutbutton.js
    ├── likeButton.js
    └── Sharebutton.js

Kami masih menyimpan fail aplikasi kami untuk memulakan React kepada tag HTML peringkat akar kami. Dengan domain kami, kami mula membina bekas kami (seperti laman utama dan pengguna) dan komponen (seperti TweetCard dan TweetListItem). Sebagai alternatif, kita dapat menyusun lagi model dalam domain kita untuk kelihatan seperti itu:

 Twitter/
└── blog/
    ├── Pengguna/
    │ ├── homepage.js
    │ ├── usercard.js
    │ └── userpage.js
    └── Tweet/
        ├── TweetCard.js
        ├── tweetdialog.js
        ├── Tweetlist.js
        └── tweetlistitem.js

Tetapi memandangkan saiz permohonan itu tidak perlu pada tahap ini.

Tambahkan pembantu, jika diperlukan

Ketika kami membina permohonan kami, kami akan terus meningkat dalam kerumitan. Untuk menangani ini, kami mempunyai dua kaedah untuk memisahkan kebimbangan dan menarik logik dari templat komponen kami: penyampai dan utiliti. Penyampai menolak semua logik persembahan visual dari templat untuk memastikan lapisan pandangan bersih dan mudah. Utiliti mengumpul fungsi bersama untuk semua logik lain di bahagian depan yang tidak berkaitan dengan templat. Mari kita periksa ini sedikit lebih dekat.

Bersihkan templat dengan penyampai

Fikirkan profil Twitter. Apa jenis elemen yang anda lihat di sini di akaun saya?

Terdapat maklumat yang berkaitan secara langsung dengan pengguna saya: Nama, Handle, Deskripsi, Lokasi, Laman Web, Hari Lahir, Tarikh Mula. Terdapat juga pertuduhan persatuan antara model lain - berapa banyak pengguna lain yang mengikuti saya? Berapa banyak pengguna lain yang saya ikuti? Terdapat logik tambahan yang tidak ditangkap di halaman, seperti tweet saya, balasan, muat naik media, dan kandungan yang saya suka. Untuk menangkap semua logik presentasi ini dengan sewajarnya, kami boleh menambah fail tambahan dalam pokok fail kami untuk mengasingkan corak penyampai kami dari komponen JSX:

 Twitter/
└── blog/
    ├── Pengguna/
    │ ├── usercard.js
    │ ├── usercard.presenter.js

Tolak logik ke dalam utiliti

Logik penyampaian tertentu adalah sangat asas bahawa ia boleh berguna di seluruh aplikasi tanpa mengira sama ada ia digunakan dalam rendering. Pemformatan mata wang, pengesahan, dan pemformatan timestamp adalah semua kes penggunaan di mana kita boleh mendapat manfaat daripada fungsi utiliti terpencil di seluruh aplikasi kami. Di mana mereka tinggal? Oleh kerana mereka merangkumi domain, utiliti boleh berada dalam folder mereka sendiri:

 Twitter/
    ├── App.css
    ├── App.js
    ├── App.test.js
    ├── blog/
    │ ├── homepage.js
    │ ├── tweetcard.js
    │ ├── tweetdialog.js
    │ ├── tweetlist.js
    │ ├── tweetlistitem.js
    │ ├── usercard.js
    │ ├── usercard.presenterjs
    │ └── userpage.js
    ├── interaksi/
    │ ├── ikutbutton.js
    │ ├── likeButton.js
    │ └── Sharebutton.js
    └── menggunakan/
         ├── Mata wang.js
         ├── time.js
         └── Pengesahan.js

Tidak ada cara yang salah untuk mengatur aplikasi anda!

Akhirnya, pilihannya adalah milik anda. Ini hanya satu contoh untuk pelbagai cara anda boleh mengatur permohonan anda. Reka bentuk yang didorong oleh domain adalah alat yang berharga kerana ia memisahkan logik perniagaan dengan cara yang bermakna, mewujudkan perbezaan yang lebih jelas untuk kepakaran domain di kalangan pemaju, dan menyediakan peraturan untuk menganjurkan dan mengukur kod anda dengan mudah.

Tetapi jika anda mencari alternatif kepada kekacauan tradisional struktur fail aplikasi React, lihatlah reka bentuk yang didorong oleh domain. Ia mungkin hanya perkara itu.

Akhir sekali, jika anda menyukai kandungan semacam ini dan ingin mengetahui lebih lanjut mengenai Front-End, Pembangunan Antara Muka Pengguna, dan Reka Bentuk dan Penyelidikan UX (dianjurkan oleh pengalaman anda dalam industri), saya menjalankan surat berita percuma yang mungkin anda ingin periksa.

Atas ialah kandungan terperinci Reka bentuk yang didorong oleh domain dengan React. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!