Dekomposisi proyek untuk frontend

Mari kita bicara tentang apa yang sudah Anda ketahui.

Ini adalah artikel pertama saya tentang Habré dan saya bukan seorang penulis. Tetapi melihat Frontend 2018: hasil tahun ini , tangan meraih keagungan dan mulai menulis.

Setiap tugas yang sulit terdiri dari yang sederhana. Kemampuan untuk melakukan dekomposisi dengan benar adalah suatu keharusan .

Saya akan memimpin diskusi tentang contoh sebagian besar proyek dari pengalaman pribadi.

Saya yakin Anda akan berkata, " Tapi kami tidak memilikinya sama sekali dan bereaksi cepat, logis, dan dapat dibaca, menghasilkan gaya menggunakan js bukanlah semacam add-on, itu modis, tetapi pengembang front-end tidak diperlukan, karena penyedia back-end kami Feofan membuat formulir yang sangat baik di php "tapi tetap saja.

Penunjukan
G1. Para genius yang bisa, adalah pengecualian, kasus luar biasa istimewa.
M *. Pikiran itu

Ini tidak bisa dibaca

Jadi mari kita mulai!

M1. Kode dubbing buruk.

M2. Anda harus selalu berpikir 100 langkah ke depan.

Misalnya, pada awal proyek, kami memperhitungkan keadaannya setelah 5 tahun.

Jelas, memulai jejaring sosial, kita dapat langsung mengatakan bahwa selain versi web akan ada aplikasi mobile, aplikasi desktop. Dari sini ...

M3. Bagian server harus ditulis hanya sekali. (M1)

Dan karena kami memiliki versi web, seluler, desktop, maka ...

M4. Sisi server berhubungan dengan data.

Sisi server tidak boleh memutuskan tombol mana yang akan digambar dan warna apa yang seharusnya.

Templat surat atau file html yang [bisa] dimuat ketika halaman dimuat untuk pengindeksan oleh mesin pencari juga bekerja dengan data. Sayangnya, Anda harus memanipulasi html di sana (karena persyaratan pengindeksan, misalnya), tetapi ini adalah masalah lain.

Bahkan, seseorang dapat mentransfer set file awal (html, js, css) dan data. Yaitu dan di sini bagian belakang tidak terlibat dalam tata letak.

Di sini gangguan pertama dari proyek terjadi: bagian server terputus. Saya tidak akan berdebat dalam bahasa apa ini ditulis, bagaimana arsitekturnya diatur (saya ingat MVC). Ini bukan urusan saya untuk ...

M5. Setiap orang harus melakukan hal mereka sendiri.

Tumpukan penuh mencakup beberapa proyek, dan di sini Anda dapat dan tentu saja akan berdebat dengan hal ini, tetapi merujuk pada (M2) posisi saya di sini terbentuk: lebih murah untuk memiliki dua profesional di bidang Anda daripada menulis ulang proyek dalam setahun. Tentu saja, ada orang-orang genius (G1) yang mengikuti di mana-mana, tetapi ada unit-unit seperti itu, yang berarti Anda tidak dapat mengambilnya dalam argumen "As It Should Be".

Saya juga akan chip dari pie ini cabang Designer, Usability dan co.

Memahami dengan benar, vendor front-end yang normal dapat secara mandiri menyebarkan tonggak sejarah, berfokus pada satu juta analog dan imajinasinya, tetapi kita berbicara tentang proyek serius menurut (M2), jadi jangan menyanjung diri sendiri :) (G1)

Kami memiliki data (api, semua metode yang diperlukan, dll., Dll.), Kami memiliki tata letak - dan mari kita mulai.

Mengingat realitas modern - saya akan memperkenalkan cabang lain. Sayangnya, tetapi sebagian besar vendor front-end modern tidak tahu cara bekerja dengan tata letak, atau tidak tahu js. Saya melakukan sejumlah besar wawancara dan aneh untuk mengamati. Oleh karena itu, bagian depan dapat dibagi menjadi "desainer tata letak" dan "desainer non-tata letak ??".

M6. Pengembangan harus dalam lebih dari satu file

Katakan padaku, jelas? Ya tentu saja!

M7. Bagian depan dibagi menjadi 2 bagian: bagian yang berfungsi dengan data, dan bagian yang menampilkannya.

Kita mungkin tidak memiliki bagian ini atau itu. Misalnya: menjadi hanya tampilan (halaman statis) atau hanya data (skrip di konsol, dll.).

Di sini saya menyarankan abstrak dan presentasi: Anda adalah orang pizzeria. Anda menerima panggilan, mengeluarkan keju dengan indah dan membawanya ke pembeli. Logika menunjukkan bahwa Anda tidak terlalu efektif (M1). Tetapi jika 2 orang lagi akan bekerja dengan Anda, itu akan jauh lebih keren! Satu menerima panggilan (bekerja dengan data), yang kedua mengambil kembali (presentasi), yang ketiga menjabarkan keju dengan indah :) (stylization dari presentasi)

Sudah saya mendengar "CEP" dari 2012, "jelas", tapi mari kita lagi ...

M8. JS bekerja dengan data.

Dia memanggil backend, menerima pesanan dan tidak masalah baginya bagaimana keju diletakkan di sana. Mungkin pizza sama sekali tidak ada, mungkin dia hanya melakukan survei pizza tahun ini?

M9. Representasi HTML

Menampilkan pizza ke klien, dan juga menerima umpan balik (uang, ulasan) dan meneruskannya ke administrator (JS).

M10. CSS - gaya presentasi

Lekukan di antara dua irisan keju.

Perhatikan bahwa administrator di telepon tidak mengatakan bagaimana menumpuk keju, dan pizza tidak mengandung seseorang yang berbicara di telepon. Setiap upaya untuk memanipulasi gaya menggunakan js, atau memanipulasi js menggunakan html pada awalnya merupakan tambahan, itu awalnya buruk. Kelas dan penanganan acara diciptakan karena suatu alasan.

Anda dapat mengikuti kelas: pepperoni, salami, tetapi tidak dalam kompetensi Anda untuk memutuskan bagaimana cara meletakkan keju pepperoni.

Anda dapat meletakkan bind: jika Anda ditendang, tidak membayar, beri tahu administrator. Tetapi jangan mendorong administrator dalam pizza. Dia sendirian, dan ada banyak pizza! Jika Anda memiliki pizza sebanyak operator, maka M1.

Jadi, yang bertanggung jawab atas js, css, html - kami telah menemukannya.

Sekarang Anda dapat mengajukan seluruh cabang pertanyaan: cara memasak pizza, bagaimana cara mengantarnya lebih cepat dan nyaman, dan bagaimana berbicara dengan pelanggan di telepon.

Saya ingin mendefinisikan kata " Komponen " yang sekarang modis. Bahkan, bahkan tombol biasa sudah menjadi "Komponen", tetapi saya akan mendefinisikan kembali ini dengan contoh yang jelas. Tombol adalah tombol, dan komponen:

1. Posting pratinjau
2. Komentar
3. Pratinjau file
4. Voting pada habr
5. Blok "lowongan"
6. Teks html dari posting, ulasan, webinar
dll.

M11. Sebuah komponen harus terlihat sama di mana-mana.

Di mana pun Anda memposting pratinjau posting, pada halaman mana Anda membukanya, itu akan terlihat sama. Aturan tiga warna. Semuanya harus dikenali oleh pengguna.

Modifikasi - perubahan yang dipaksakan, jika perlu. Dibuat menggunakan css.

Atau apakah itu komponen lain

(Misalnya, pratinjau pos di kolom kanan mungkin berbeda dari pratinjau pos di bagian bawah halaman).

M12. Komponen terdiri dari [html], [js], [css].

Masing-masing bagian adalah opsional.

M13. Terlepas dari jumlah instance dari komponen yang sama, gayanya harus didaftarkan hanya sekali

Misalnya, pratinjau pos di sebelah kanan, pratinjau pos di bawah ini, pratinjau pos dalam pemberitahuan, dan gaya terdaftar hanya sekali.

M14. Hanya pangkalan yang harus didaftarkan dalam komponen js

Misalnya, penangan acara saat mengklik tombol, data yang diperlukan untuk ditampilkan. Segala sesuatu yang lain harus dibagikan.

M15. Suatu komponen dapat terdiri dari komponen

Misalnya, daftar posting.

M16. Gaya diambil dalam file terpisah

File-file ini di-cache, di samping itu, tidak akan ada godaan untuk menuliskannya secara inline, yang berarti menggandakan.

M17. Gaya komponen harus mengikat hanya melalui kelas induk

Halaman situs mana pun seperti banyak kotak dengan ukuran berbeda, yang seperti boneka bersarang yang saling menempel.

Kotak adalah komponen.

Anda memiliki kotak dengan kotak dan barang. Anda tidak perlu memikirkan cara mendeskripsikan bagian dalam kotak bersarang. Jelaskan hanya ini.

Di sini mereka menemukan banyak sepeda, tetapi tuan-tuan, tidak akan ada masalah dengan nama, segera setelah Anda menentukan set komponen untuk diri Anda sendiri. Jika Anda membuka VKontakte dan menghitung jumlah komponen di sana, Anda menghitung 30 buah. (Jangan mengandalkan facebook, hanya ada rasa sakit).

Tidak dapat menampilkan 30 nama kelas? Dan memang benar, tidak ada yang muncul dengan:

M18. Orang lain akan membaca kode Anda.

Jadi nama alami adalah nama terbaik

Sebagai contoh

1. posting-daftar
2. daftar komentar
3. daftar berita
4. post-preview
5. komentar-pratinjau
6. pratinjau berita
7. post-detail
8. komentar-detail
9. berita-detail

Sangat sulit, ya? Dan hal utama tidak dapat dipahami dan sulit untuk dipertahankan

Dan tentang "baca orang lain" juga berhenti berlangganan:

M19. Html, js, css harus disimpan secara terpisah!

Jika Anda perlu menggabungkan keduanya, buatlah solusi yang berbeda dari menulisnya dalam satu file. Bereaksi adalah yang paling menjijikkan dalam hal keterbacaan yang pernah saya lihat!

Halaman pada "Kotak" dibagi, bagaimana menyimpan file - dibahas. Apa lagi

M20. Hampir tidak ada kasus khusus

Dan jika itu terjadi, maka besok manajer Anda akan datang ke tempat kerja dan mengatakan bahwa "perlu untuk memodifikasi implementasi atas permintaan pelanggan." Selesaikan tugas seluas mungkin.

Misalnya, di tempat kerja kami, kami, terlepas dari proyeknya, segera memisahkan beberapa tugas: kalender, formulir input, pop-up, menu isi yang berbeda, melihat file, dan widget lain yang berinteraksi dengan pengguna. Jadi bisa dikatakan, "karakter-fungsi"

M21. Penulisan gaya membutuhkan dekomposisi

Dunia tidak hanya memberi kita KURANG yang indah, SASS.

Proyek Anda memiliki serangkaian font, warna, bayangan, hampir semua proyek serius memiliki skema warna, jadi ketika menulis gaya, semua ini diparameterisasi. Dan berikut ini yang penting

M22. Jika Anda ingin mengubah warna font (dll.), Maka Anda hanya perlu mengedit di satu tempat

Sebagai penutup, saya ingin menyebutkan satu masalah penting.

M23. Perumusan masalah yang benar mengarah pada solusi yang benar.

Mungkin nanti tidak akan ada css-in-js, facebook dan sesuatu yang tidak boleh disebut.

Semoga hari kalian menyenangkan!