Opini publik telah menerjemahkan Bootstrap ke dalam kategori kerangka kerja legendaris di masa lalu, tetapi masih layak untuk ditonton. Bootstrap 4 adalah navigator yang sangat baik untuk tata letak yang aman, dan yang paling penting, sampel pendekatan HTML over JS untuk membuat aplikasi web, sepenuhnya mengungkapkan kemampuan HTML yang ada untuk deskripsi deklaratif dari antarmuka pengguna.
Dan bagaimana kode framework JavaScript berkembang juga berguna untuk memiliki ide. Arsitektur plugin jQuery masih digunakan, tetapi dari versi 4 dibungkus oleh Rollup dalam paket kelas ES6 yang ditransformasikan menggunakan Babel6 . jQuery mungkin tidak akan segera sama sekali - lebih lanjut tentang itu nanti - tetapi untuk sekarang, pada contoh membuat plugin BsMultiSelect Anda sendiri, pada tumpukan yang sama dengan Boostrap 4 , fitur pengembangan kerangka kerja akan terungkap.
Mengapa " setiap programmer harus menulis sendiri ... "
" Meningkatkan rampasan hanya yang baik ." Kebutuhan untuk memahami apa yang didapat Bootstrap baru adalah transfer komponen-komponennya ke stack baru, dan seberapa mudah sekarang untuk membuat komponen-komponen tingkat tinggi. Segalanya tampak sederhana: gabungkan .form-control , .badge , dan .dropdown-menu dan Anda dapat dengan mudah mendapatkan ...
Konflik arsitektur dari ambang pintu
Plugin BsMultiSelect yang dihasilkan tidak secara langsung menggunakan kode JS bootstrap.js , tetapi menggunakan dependensinya, popper.js (kerangka kerja pop-up vanilla). Ini karena komponen dropdown dari bootstrap.js perlu menemukan apa yang disebut elemen sakelar selama inisialisasi di DOM (dalam kasus tertentu itu adalah tombol yang membuka menu), jika tidak menemukannya, ia crash dengan kesalahan (karena saya membuat langsung dari js maka saya punya "tombol" tentu saja tidak). Kesimpulan: komponen yang dipertajam di bawah "HTML over JS" tidak dapat (atau tidak menguntungkan) dibuat langsung dari JS. Kesimpulan nomor dua: Anda perlu memprogram komponen khusus sehingga di bawah komponen "HTML over JS", selalu ada komponen yang lebih ringan dari "pure JS". Saya punya MulitSelect.js ini sepenuhnya dibersihkan tidak hanya dari kode tetapi juga gaya Bootstrap. MulitSelect.js memainkan peran yang sama untuk BsMulitSelect.js, seperti halnya popper.js untuk dropdown.js.
Dua kata tentang popper.js
Perpustakaan hebat - satu fungsi. DropDown.js mengulangi tetapi menyediakan antarmuka yang sepenuhnya terbatas untuk itu (sekali lagi, karena dalam "HTML over JS" seluruh API tidak diperlukan). Popper memiliki masalah terbuka lebih dari yang kita inginkan. Saya kecewa bahwa di bawah IE11 menerbitkan acara yang tidak suka di bawah Chrome .
Tentang transisi dari IIFE ke kelas
Boilerplate plugin jQuery standar adalah untuk mendefinisikan fungsi konstruktor di dalam IIFE . Sekarang ini adalah kelas di dalam IIFE. Pembukaan: cara fungsional lama untuk melakukan metode pribadi bertentangan dengan lambda ES6, sehingga mereka "ditinggalkan" di Bootstrap. Semua metode bersifat publik, sedangkan metode pseudo-privat diawali dengan _ i.e. garis bawah. Saya mengerti bahwa saya salah, tetapi saya mengikuti konvensi saya - "metode publik dengan huruf kapital". Dalam segala hal lainnya, BsMultiSelect menciptakan adopsi perjanjian DropDown.js "standar", yaitu Saya ingin mewakilinya sebagai sejenis daging dengan daging.
Namun, perbedaan lain, karena ada rollup, saya tekan file .. import $ from 'jquery' import AddToJQueryPrototype from './AddToJQueryPrototype' import MultiSelect from './MultiSelect'
Perjanjian baru: plugin harus menerbitkan Konstruktor - agar tidak kehilangan konstruktor di dalam IIFE. Ya, satu IIFE harus tetap - tidak ada yang menghapus tugas mendefinisikan jendela, dependensi $ dan Popper (untuk mereka yang "tidak dapat masuk ke modul") dengan cara standar.
Konfigurasi Eslint dan Stylelint Linter
Saya tidak merasa berkewajiban untuk mengikuti aturan kejam untuk styling kode Bootstrap. Tentunya mereka menulis dalam lingkungan yang membantu mereka dalam mengatur ruang dan untuk kontrol sumber yang ketat sangat baik, tetapi sulit bagi saya untuk mendengarkan setiap detik kesedihan dari orang-orang di VS Code. Saat menulis plugin Anda sendiri, aturan bisa dan harus sangat santai.
Eslint, stylelint mungkin tidak keluar terlalu sering, tetapi tidak ada keinginan untuk melihat aturan baru. Dalam semua aspek, pencapaian ini lebih membuatku jengkel.
Kode dan rollup organisasi
Kode redistributable bootstrap ES6 dikemas dengan rollup dalam dua versi: standstrone bootstrap.js dan bundle bootstrap.bundle.js - yang terakhir termasuk popper.js.
Penulis rollup.config.js memiliki naluri asing bagi saya. Semua transformasi konfigurasi ini melalui push dan pop, tergantung pada versi mandiri atau bundel yang diperlukan, terlihat rumit dan menakutkan, untungnya untuk menulis plugin Anda hanya perlu satu jenis bundel "mandiri" dan saya tidak perlu membuktikan bahwa saya dapat melakukan yang lebih baik.
Versi Bootstrap mandiri juga ditunjukkan di bidang utama paket yaitu dependensi npm diselesaikan ke file yang sama yang dimuat pengguna melalui <script> . Ini bukan solusi yang ambigu, tetapi plugin BsMultiSelect saya telah mengikuti jalur yang sama. Dalam hal ini, babel helpers dapat dimasukkan dalam plugin , terlepas dari kenyataan bahwa mereka juga termasuk dalam bootsrap.js. Duplikasi entah bagaimana tidak benar ...
Yang menarik adalah bahwa Bootstrap memiliki konfigurasi paralel di bawah jspm - pemuat modul ES peramban asli dan bidang utamanya sudah bersih kode remoted, 12 komponen yang tidak dibundel, tetapi disimpan secara terpisah di direktori js / dist. Di sini, setiap file termasuk babel helper. Jspm sekarang berada di persimpangan jalan, jadi dengan membuat BsMultiselect Abaikan saja.
Namun menarik untuk bertanya kepada para pecinta, apakah jspm akan mengangkat semua 12 kali pembantu pembantu yang diduplikasi ke browser?
Sejumlah besar rollup telah ditemukan - paketnya dapat dibaca, tidak seperti webpack.
Bootsrap 4 menggunakan Babel 6 dan plugin BsMultiSelect Babel 7
BsMultiSelect dengan mudah dimigrasikan ke Babel 7 beta menggunakan rollup-babel-plugin yang diperbarui (juga dalam versi beta). Sebaiknya pindah ke Babel 7 sekarang karena @babel/preset-env (konfigurasi transpiler "di mana browser kode akan dijalankan"). Dengan menggunakan Internet saja, menjadi sangat sulit untuk memahami bagaimana preset ES6 bekerja, mereka mengalami evolusi yang panjang dan banyak konfigurasi yang ketinggalan zaman telah terakumulasi. Lebih baik bertaruh Babel 7 + @babel/preset-env segera
Namun demikian, kesalahan beta babel tidak harus menunggu lama: [... nodeList] di-tanspile di nodeList.concat (). Saya tidak mengerti untuk waktu yang lama, menerjemahkan kode menjadi panggilan jquery (ini masih perlu, tetapi lebih lanjut tentang itu nanti) menyelesaikan masalah. Tanyakan: "Mengapa sama sekali Babel jika Anda tidak berurusan dengannya?", Jawabannya: "impor dan lambda."
Aspek praktis
Bootstrap 4 dan plugin-nya (seperti kode js apa pun) memiliki dua opsi untuk memuat ke dalam browser: melalui skrip / gaya (membuat "halaman"), dan melalui simpul perakitan / webpack (membuat "aplikasi", jadi saya akan melanjutkan dua ini pada prinsipnya, situasi yang sangat berbeda dan menunjukkan: "halaman" dan "aplikasi").
Untuk halaman dan aplikasi, "file distribusi" Bootstrap yang sama akan digunakan. Ini bukan solusi yang jelas dan bukan satu-satunya (sebagai contoh, kode yang berbeda digunakan untuk jspm dan untuk tes mocha ), tetapi ketika membuat plugin Anda sendiri, tidak ada yang tersisa untuk dilakukan kecuali mengikuti konvensi ini, berharap untuk optimalitasnya.
Menemukan keseimbangan antara memenuhi dua kebutuhan menggunakan kode yang sama untuk dua opsi unduhan yang berbeda: "halaman" dan "aplikasi" adalah tugas arsitektur utama yang dihadapi pengembang plug-in.
Lagipula, plugin Bootstrap juga dapat dibuat ad hoc , tepat di aplikasi Anda. Dalam hal ini, Anda dapat menulis kode plug-in dengan semua kesenangan: polyphiles dan akses ke variabel SASS dari skema. Namun, ketika mengandalkan penggunaan kembali, perlu untuk mentransfer plugin ke paket npm sendiri, kesenangan di atas masuk ke dalam kategori masalah: Anda kehilangan akses ke variabel SASS dan Anda perlu mengingat pencipta "halaman" yang menghubungkan plugin melalui skrip (di mana polyfiles saya?).
Akses ke SASS Bootstrap 4 Variabel Gaya
Saya ingin menulis kelas / penyeleksi Bootstrap css untuk menulis plugin. Dalam hal ini, saat menyesuaikan tema Bootstrap, Anda dapat mengharapkan plugin untuk beradaptasi tanpa upaya tambahan.
Untuk plugin yang diterbitkan sendiri, tidak ada akses ke variabel SASS.
Kelas / penyeleksi css yang ada - tidak mencakup semua gaya yang diperlukan untuk BsMutliSelect, misalnya, Anda memerlukan min-height ul.form-control untuk ul.form-control , ketika di bootstrap.css hanya ada pemilih css dengan ketinggian untuk input.form-control - Anda tidak dapat menerapkannya untuk ul . Kelas / penyeleksi lain yang ada membawa banyak gaya berlebihan: bagaimana jika Anda ingin menetapkan, misalnya, warna dari .form-control ke elemen tanpa menetapkan kelas .form-control ? Ini tidak akan berfungsi karena tidak ada kelas seperti .input-color di mana variabel $ input-color akan diterbitkan "secara terpisah" dari semuanya.
Lebih lanjut, tidak mungkin untuk mengikuti keputusan tim Bootstrap: mereka tidak memiliki masalah seperti itu, jika mereka perlu - mereka membuat kelas / pemilih CSS dengan variabel yang diinginkan dan beroperasi di atasnya. Jika Anda ingin berdebat, Anda harus menjelaskan dengan Mark Otto , di tim BS ada tingkat pengambilan keputusan yang sangat tinggi, bahkan untuk perubahan kosmetik pada pemilih CSS, jika permintaan termasuk dalam kategori "penawaran".
Saya mengusulkan solusi berikut.
Untuk halaman (meningkatkan plug-in melalui script ) Anda harus memasang dengan tidak dapat diaksesnya variabel. Tetapi tidak perlu menawarkan untuk berurusan dengan CSS - variabel yang tidak dapat diakses dapat ditawarkan untuk dikustomisasi melalui parameter js, karena jumlahnya tidak banyak (dan tidak semuanya diubah oleh skema apa pun). Untuk BsMultiSelect, yang bermasalah adalah: warna dinonaktifkan, warna input, bayangan kontrol terfokus (dll. Hanya 10 gaya, kebanyakan dari mereka jarang mengubah skema) ...
Pertama, ini adalah deklarasi semua gaya yang menjadi dasar pengaya ... $("select[multiple='multiple']").bsMultiSelect({ selectedPanelDefMinHeight: 'calc(2.25rem + 2px)',
Tetapi untuk aplikasi yang menggunakan SASS dan kolektor, Anda dapat menawarkan untuk menyalin BsMultiSelect.scss ke diri Anda sendiri, dan memperbaiki jalur ke _variables.scss Anda di dalamnya. Dengan demikian, plugin akan "menerima" variabel variabel.
Semua melalui CSS ... $("select[multiple='multiple']").bsMultiSelect({ useCss: true });
Kedua metode ini ditulis secara eksplisit dalam kode JS saya, melalui dua "adapter". BsMultiSelect sebenarnya adalah dua plugin dalam satu. Satu yang bekerja dengan gaya melalui variabel js, yang lain mendelegasikan pekerjaan css ini.
Pada saat yang sama, saya harus mengatakan secara langsung bahwa bekerja dengan CSS mungkin diperlukan bahkan jika transfer gaya khusus melalui parameter JS digunakan, hanya karena penulis skema biasanya melakukan pekerjaan mereka dengan sangat kasar. Atau aneh. Misalnya, skema Skethy karena alasan tertentu memutuskan bahwa menu tidak memerlukan efek hover. Fitur harus diajukan.
Tetapi dengan contoh samar, saya harap Anda dapat melihat bagaimana plug-in beradaptasi dengan sirkuit yang berat relatif mudah (perlu untuk membebani nilai-nilai hanya tiga gaya melalui parameter js).
adaptasi ke skema melalui js $("select[multiple='multiple']").bsMultiSelect({ selectedPanelFocusBoxShadow:"0px 0px 0px 0.2rem rgba(51,51,51,0.25)", selectedPanelFocusBorderColor:"#333", selectedPanelDisabledBackgroundColor: "#f7f7f9" });
Ini adalah maksimum yang dapat dicapai dengan menggunakan kelas CSS "standar" .bage , .form-control , .close , dll. Hampir semuanya disesuaikan dengan skema, tetapi tidak semuanya.
Sangat disayangkan, tentu saja, bahwa Anda tidak dapat melepaskan diri dari tiga parameter ini, tidak semua variabel gaya skema dapat diakses melalui penyeleksi / kelas css (saya bohong, Anda dapat pergi jika Anda dapat menyalin BsMultiSelect.scss ke diri Anda sendiri dan membawa variabel rangkaian ke sana, tetapi ini tidak sepenuhnya memuaskan , seperti semua keputusan yang dimulai dengan kata "salin ke diri sendiri").
Klik di sini: https://dashboardcode.imtqy.com/BsMultiSelect/indexsketchy.html
Polyfill
Dalam skenario "Saya menulis plugin ad hoc di dalam aplikasi" - Anda akan menggunakan @babel/polyfill tanpa masalah, dan menambal DOM polyfill.io karena di dalam aplikasi Anda sudah ada di sana.
Ketika sebuah plugin dipindahkan ke modul npm eksternal, semua kegembiraan menghilang karena pengguna Bootstrap belum memutuskan untuk menyenangkan daftar panjang polyfill yang diperlukan dalam dokumentasi.
Solusi: semua yang babel tidak akan transpos tetapi akan pergi ke polifile, mencegahnya melakukan ini, menggertakkan giginya, untuk mengubahnya menjadi panggilan jQuery (misalnya, Node.closest dalam $ .closest) Pendekatan ini diadopsi dalam Bootstrap 4 itu sendiri dan jelas itu adalah perjuangan melawan pembengkakan. Kejutan jQuery adalah sebuah polyfill.
Saya setuju bahwa pemrograman dengan Babel dengan memperhatikan CanIUse.com dan MDN.com tidak menyenangkan. Dan kodenya canggung (bagi saya).
Di sini perlu untuk menyoroti situasi dari atas lagi. Bootstrap menggunakan dua pustaka jQuery dan popper.js. Popper.js adalah kerangka kerja vanila ganda, tidak memiliki babel, jQuery, atau polyfill eksternal, dengan sendirinya. JQuery dikemas oleh grunt yang sudah menggunakan babel, tetapi entah bagaimana secara ajaib tanpa polyfill dan helper-nya. Plugin Bootstrap pihak ketiga (seperti BsMultiSelct) menggunakan Babel 7. Produk Anda mungkin masih menggunakan yang lain. Tidak ada platform polifil tunggal, duplikasi kode ganda diharapkan, ada empat implementasi yang paling dekat yang dimuat ke dalam browser. Tapi tidak ada yang bisa dilakukan tentang itu.
Jika Anda tetap menggunakan polyfiles saat membuat plugin Anda sendiri, Anda harus ingat bahwa jika aplikasi memiliki skrip inline (mis. <script>$( function() {/*..*/}) </script> ) lalu Anda hanya perlu mengunduh polyfiles secara sinkron (jika tidak kode inline dapat memulai eksekusi lebih awal dari saat plugin dimuat). Yaitu misalnya webpack-polyfill-injector ( injector polyphil terkaya yang saya kenal) saya perlu mengendalikannya sehingga tidak memutuskan untuk memuat polifil secara tidak sinkron (perilaku default).
Tidak ada jQuery
jQuery terasa agak beracun, bersaing dengan dan mengaburkan Babel / ES6, tetapi tidak selamanya. Ada cabang v4-whithout-jquery , sudah ada dalam permintaan pool, ia berencana untuk merilis bootstrap-nojquery c versi 4.3 . Sebelumnya, namespace acara disebut masalah terbesar menolak jquery, meskipun jelas bahwa Anda dapat menulis tanpa itu (BsMultiSelect melakukannya tanpa). Rupanya diputuskan.
Juga diumumkan bahwa dari versi 4.3 akan dimungkinkan untuk memuat komponen asli ke dalam browser secara terpisah (hanya untuk skenario "aplikasi"). Akankah komponen asli kemudian menjadi "seperti BsMultiSelect "? Tidak. Jika tim BS membutuhkan beberapa variabel SASS, mereka akan membuat kelas CSS / penyeleksi untuk diri mereka sendiri dan akan beroperasi pada mereka dari JS ("CSS fungsional"). Pembuat fitur khusus tidak tersedia.
Kemungkinan transisi dari sass ke post-css https://github.com/twbs/bootstrap/projects/11 dalam versi ke-5 pada dasarnya tidak mengubah apa pun. Atau ubah semuanya: "JS over HTML".
Bootstrap 5 harus mengatur rekomendasi tentang cara mengintegrasikan ke dalam Babel polyfiles, dan bagaimana menambal DOM. Di sini ramalannya kurang lebih jelas: majelis yang sama sekali berbeda akan ditawarkan kepada pembuat halaman dan pembuat aplikasi.
Ringkasan
Saat Anda menulis komponen Bootstrap 4 di Babel menggunakan metode ad hoc tanpa berpikir tentang penggunaan kembali, yang berarti polifile, dan dari mana mendapatkan variabel gaya, Anda tidak tahu tentang kesedihan.
Tetapi jika Anda menjadikan plugin sebagai paket npm yang terpisah - dan dengan keinginan untuk membuat keputusan dengan semangat Bootstrap 4 sendiri, kesenangan menjadi lebih sedikit, Anda berpikir lebih sering dan lebih lama. Anda mungkin harus segera memutuskan siapa pengguna Anda dan menawarkan bangunan yang berbeda, satu untuk mereka yang akan membangun aplikasi dalam bundel, yang lain untuk menulis halaman, yaitu memuat skrip plugin.