Penjelasan terperinci tentang mekanisme jam tangan dalam node.js_node.js

Hampir semua sistem binaan memilih untuk menggunakan mekanisme jam tangan untuk menyelesaikan masalah berulang kali menjana fail pasca binaan semasa proses pembangunan Walau bagaimanapun, di bawah mekanisme jam tangan, kami perlu bersabar mengubah suai kod untuk masa yang lama kodnya, kita kena minum teh sebelum menyegarkan. Di sini kami cuba meneroka mengapa jam tangan bukan peluru perak dan cuba mencari penyelesaian yang lebih baik untuk masalah ini.

Fakta jam tangan berdasarkan

Apabila fail diubah suai, kita boleh mengetahui pengubahsuaian fail yang mungkin disebabkan oleh pengubahsuaian, dan kemudian membina semula fail ini.

Biasanya untuk senario di mana fail A dibina ke dalam fail B, surat-menyurat ini sangat pasti. Tetapi dalam senario sebenar, proses pembinaan selalunya tidak semudah itu. Contohnya:

Fail A + Fail B (dirujuk oleh Fail A) -> Dalam senario ini, apabila fail B diubah suai, mungkin sukar untuk mencari fail mana yang perlu dijalankan semula tugas binaan, kerana mungkin terdapat banyak fail yang merujuk kepada fail B.

Melainkan kami membina pepohon pergantungan dan mengemas kini pepohon pergantungan setiap kali fail dikemas kini, dan mencetuskan binaan fail berdasarkan pepohon pergantungan baharu. Tetapi setiap pemalam perlu melaksanakan mekanisme ini dengan sendirinya, dan ia sangat terdedah kepada ralat. Jadi sebenarnya mekanisme jam tangan hanya menjalankan semula keseluruhan tugas. Oleh itu, apabila projek menjadi lebih besar dan lebih besar, mekanisme jam tangan akan menjadi lebih perlahan dan lebih perlahan (kerana semakin banyak fail perlu menjalankan semula keseluruhan proses, walaupun masa yang diperlukan untuk keseluruhan proses dikurangkan melalui caching).

Penyelesaian

src tersedia secara langsung

AlloyTeam & @ldjking, secara ringkasnya, jadikan src boleh dijalankan secara langsung, letakkan tugas pembinaan pada bahagian penyemak imbas, atau bahkan tidak dibina sama sekali Ia boleh diubah suai dan disegarkan dalam masa, yang mengurangkan penggunaan masa semasa pembangunan proses. Pembinaan luar talian hanya bertanggungjawab untuk isu pengoptimuman prestasi, bukan kecekapan pembangunan.

Wakil biasa termasuk LESS, React, dsb. Tetapi terdapat juga beberapa masalah:

Sukar untuk melaksanakan kaedah pembinaan yang elegan pada bahagian penyemak imbas, dan sukar untuk menyediakan fungsi yang berkuasa untuk mengurangkan lagi kos pembangunan kebanyakannya hanya boleh diperkenalkan dengan cara yang serupa dengan skrip.

Susunan pelaksanaan dalam mod pembangunan tidak semestinya sama dengan senario sebenar, yang mungkin membawa kepada pepijat yang tidak kelihatan Contohnya, apabila melaksanakan sebaris HTML, sebaris tidak segerak dalam mod pembangunan, manakala sebaris dalam mod keluaran adalah segerak, mengakibatkan tidak dapat dijelaskan. pepijat.
Prestasi kompilasi pelayar membimbangkan Contohnya, kelajuan kompilasi versi js sass hampir tidak dapat ditanggung.
Ia adalah perlu untuk mengekalkan dua set sistem pembinaan dalam talian dan luar talian, yang meningkatkan kos pembangunan alat.
Binaan dinamik pelayan tempatan

Satu fakta ialah: dengan sokongan spesifikasi yang munasabah, kami boleh mengesan kembali fail yang diminta oleh penyemak imbas ke fail kemasukan dalam proses pembinaan fail. Dengan cara ini kita boleh mencetuskan proses binaan secara dinamik.

Dengan menyediakan pelayan secara setempat, biarkan pelayan menangkap permintaan dan membinanya secara dinamik dalam pelayan. Selagi kita menjejak kembali ke fail masukan, kita boleh membuang fail masukan ke dalam saluran paip yang terdiri daripada pemalam gulp, dan output akan menjadi fail yang diperlukan oleh penyemak imbas.

Dengan cara ini kita dapat menyelesaikan semua masalah di atas.