React: Jelajahi mendorong pengguna untuk tidak mengirimkan mode DEV ke produksi

Untuk referensi: https://github.com/facebook/react/pull/8782

Untuk konteks, kami telah memperingatkan jika kami mendeteksi bahwa Anda telah mengecilkan versi DEV dari React: https://github.com/facebook/react/blob/8791325db03725ef4801fc58b35a3bb4486a8904/src/renderers/dom/ReactDOM.js#L91 -L98

Sejauh kami dapat menemukan heuristik serupa untuk memberi tahu pengguna, dan mungkin bahkan lebih agresif memunculkan dialog DOM, kami harus melakukannya.

Saya juga ingin memperjelas bahwa peringatan yang kami berikan dapat meningkatkan kinerja secara signifikan jika orang-orang memperhatikannya. Utas ini menjelaskan beberapa alasan mengapa sulit untuk menerapkan ini setelah fakta jika itu bukan default.

Saya juga ingin mengikuti saran dari satu console.warn jika renderToString dipanggil dalam mode dev. Jelas, dalam kebanyakan situasi renderToString dipanggil dalam simpul, di mana kita tidak dapat mengingatkan atau memunculkan dialog DOM.

Sayangnya, saya benar-benar ingin dapat mendeteksi tidak hanya jika NODE_ENV diatur ke production , tetapi juga jika process.env.NODE_ENV telah dikompilasi. Apakah ada yang tahu cara untuk melakukan itu?

Terima kasih atas utasnya @sebmarkbage dan saya mengakui kesulitan menerapkannya setelah fakta. Saya juga menghargai peringatan saat ini. Tampaknya beberapa pengembang mungkin tidak memeriksa keluaran konsol dari situs yang mereka gunakan sesering mungkin. Namun ini adalah langkah pertama yang baik.

Sejauh kami dapat menemukan heuristik serupa untuk memberi tahu pengguna, dan mungkin bahkan lebih agresif memunculkan dialog DOM, kami harus melakukannya.

Saya akan berterima kasih atas peningkatan heuristik yang digunakan untuk memberi tahu pengguna. Dialog DOM yang lebih agresif akan sangat membantu. Ini akan memastikan situs terus bekerja untuk pengguna akhir tetapi memberikan petunjuk aktif bahwa ada pengembang buah dengan kinerja rendah yang dapat dipilih.

Alternatifnya adalah kami menemukan cara untuk memperbaikinya pada level build-tool/ENV seperti yang disebutkan dalam posting asli. Itu akan menghindari injeksi DOM yang diperlukan.

Menyuntikkan pesan apa pun ke DOM tampaknya berbahaya dan agak terlalu berasumsi. Itu membuka kemungkinan pengguna akhir mendapatkan peringatan yang tidak terduga dan membingungkan yang tampaknya IMO tidak dapat diterima.

@thelarkinn mengusulkan agar kami mencoba menstandarisasi konfigurasi ENV yang diperlukan untuk memfasilitasi deteksi pesan seperti ini dengan lebih baik

Ini terasa seperti ruang yang ideal untuk mengatasi ini. Ini adalah masalah build dan harus, jika mungkin, ditangani oleh alat build.

Anekdot: Peringatan di konsol tidak terlihat (atau diabaikan) di masa lalu. Saya tidak memiliki angka yang sulit di sini, tetapi saya pikir peringatan berbasis konsol tidak cukup. Saya setuju dengan @addyosmani bahwa peringatan berbasis DOM akan sangat membantu.

@surma mungkin mereka harus menggunakan console.warn atau console.error untuk visibilitas yang lebih baik

Saya tidak melihat bagaimana dapat diterima dalam skenario apa pun untuk menyuntikkan konten ke dalam aplikasi hanya ketika sedang berjalan dalam produksi. Anda membuat asumsi besar bahwa pesan akan ditangkap sebelum aplikasi didorong ke pengguna sebenarnya, di mana pesan tersebut berpotensi merugikan UX secara besar-besaran.

Btw, kami akan menambahkan dukungan penanganan kesalahan yang lebih komprehensif di Fiber sehingga Anda dapat mengganti komponen yang mengalami kegagalan (kesalahan lempar) dengan tampilan kesalahan khusus. Bahkan dalam skenario default, kami kemungkinan besar akan menjadi sangat agresif, dan hapus saja komponen itu dari pohon jika terjadi kesalahan sehingga Anda tetap ingin memiliki UI kesalahan khusus untuk pengguna Anda.

Kami mungkin dapat memicu kesalahan seperti itu untuk peringatan ini.

Sejujurnya saya tidak berpikir bahwa console.{error,warn} lebih dari console.log akan mengubah apa pun. Seperti yang saya katakan, cerita itu anekdot.

Saya juga tidak mengatakan bahwa menampilkan dialog DOM adalah solusi _the_. Itu adalah sesuatu yang saya pribadi akan merasa nyaman. Jika tetap dalam mode dev memiliki dampak negatif, setidaknya pengguna akan tahu bahwa _something_ salah dan mungkin mulai menekan tombol "Bantuan" atau sesuatu.

Intinya: Saya pikir kerangka kerja perlu masuk ke wajah pengembang di beberapa titik. Saya ingin bertukar pikiran tentang hal ini untuk melihat langkah dan kompromi apa yang ingin diambil oleh pembuat kerangka kerja untuk mencegah orang menyebarkan dalam mode dev di masa depan.

Bagaimana jika React tidak berfungsi sama sekali kecuali Anda menyediakan lingkungan, terlepas dari apakah itu pengembangan atau prod? Dengan begitu ada pilihan sadar yang dibuat dengan satu atau lain cara.

Tentang pesan yang disuntikkan di DOM, itu bisa dinonaktifkan menggunakan global atau sesuatu. Bukan masalah besar IMO. Jika Anda menonaktifkannya, Anda agak mengakui bahwa Anda tahu apa yang Anda lakukan.

Masalah dengan pesan konsol adalah terkadang orang mencatat banyak hal, atau memiliki peringatan lain yang mereka abaikan, dan mudah untuk tidak melihat pesan konsol pertama yang melewati gulir...

Dengan env wajib, mau tidak mau boilerplates dll. Akan mengatur env var sehingga Anda bisa mulai menggunakannya, saya khawatir :/

Sejujurnya saya tidak berpikir bahwa console.{error,warn} over console.log akan mengubah apa pun.

Menurut Anda apakah ini masalah dengan pengembang yang tidak memeriksa konsol, atau konsol kelebihan beban dengan peringatan? Mungkinkah ini (sebagian) ditangani dengan pendekatan yang lebih umum mengenai pendidikan pengembang?

Saya juga tidak mengatakan bahwa menampilkan dialog DOM adalah solusinya. Itu adalah sesuatu yang saya pribadi akan merasa nyaman. Jika tetap dalam mode dev memiliki dampak negatif, setidaknya pengguna akan tahu bahwa ada sesuatu yang salah dan mungkin mulai menekan tombol "Bantuan" atau sesuatu.

Saya mengerti itu, tapi saya hanya mengatakan saya tidak berpikir itu solusi apalagi solusinya. Ada baiknya Anda merasa nyaman dengannya, tetapi saya pikir lebih baik berhati-hati dan berasumsi bahwa kebanyakan orang tidak ingin kesalahan tak terduga ditampilkan kepada pengguna mereka.

Intinya: Saya pikir kerangka kerja perlu masuk ke wajah pengembang di beberapa titik. Saya ingin bertukar pikiran tentang hal ini untuk melihat langkah dan kompromi apa yang ingin diambil oleh pembuat kerangka kerja untuk mencegah orang menyebarkan dalam mode dev di masa depan.

Saya untuk menghadapi pengembang, tetapi penting untuk melakukannya di tempat yang tepat. Bagi saya, itu adalah langkah pembuatan, bukan produksi.

Tentang pesan yang disuntikkan di DOM, itu bisa dinonaktifkan menggunakan global atau sesuatu. Bukan masalah besar IMO. Jika Anda menonaktifkannya, Anda agak mengakui bahwa Anda tahu apa yang Anda lakukan.

Mengaktifkannya secara default sama buruknya dengan tidak membuatnya dapat dikonfigurasi: perilaku default dapat mengakibatkan perilaku yang tidak diharapkan bagi pengguna akhir. Jika ada, itu harus dinonaktifkan secara default, tetapi itu mengalahkan seluruh tujuan karena pengembang hanya dapat memperbaiki masalah awal setelah mereka menyadarinya.

Masalah dengan pesan konsol adalah terkadang orang mencatat banyak hal, atau memiliki peringatan lain yang mereka abaikan, dan mudah untuk tidak melihat pesan konsol pertama yang melewati gulir...

Saya benar-benar mengerti itu, konsol bisa ramai dan mudah ketinggalan barang. Tapi itu penuh sesak karena alasan yang tepat yang saya perdebatkan: ini adalah tempat yang memberikan umpan balik atau kesalahan kepada pengembang. Ini keluar dari pengalaman pengguna, yang mana pesan yang disuntikkan tidak.

Masuk akal, saya mengerti alasannya.

Yah mungkin membuat hal itu muncul menggunakan pemformatan konsol setidaknya akan menjadi sesuatu.

Masalahnya hampir tidak ada yang melihat konsol dalam produksi. Anda dapat menggunakan font apa saja di sana dan orang tidak akan menyadarinya.

Namun jika kita membuatnya menampilkan pesan secara default dalam produksi sebagai perubahan yang melanggar (dalam 16 atau 17) maka akan sulit untuk dilewatkan. Maksud saya, itu akan terjadi saat pertama kali Anda mencoba menerapkannya (untuk pengguna baru), dan pengguna yang sudah ada harus membaca catatan rilis saat memperbarui ke jurusan baru. Jadi saya pikir itu bisa dilakukan selama kita sangat eksplisit tentangnya dan tidak mungkin melewatkan pesannya.

Masalahnya hampir tidak ada yang melihat konsol dalam produksi. Anda dapat menggunakan font apa saja di sana dan orang tidak akan menyadarinya.

Saya hanya bisa mengomentari pengalaman tim Chrome dengan ini, tapi saya setuju. Kebanyakan orang akan melihat pesan konsol selama alur kerja iterasi mereka, tetapi persentase yang jauh lebih kecil melihat peringatan di situs produksi dan lebih sedikit yang menindaklanjutinya.

Namun jika kita membuatnya menampilkan pesan secara default dalam produksi sebagai perubahan yang melanggar (dalam 16 atau 17) maka akan sulit untuk dilewatkan. Maksud saya, itu akan terjadi saat pertama kali Anda mencoba menerapkannya (untuk pengguna baru), dan pengguna yang sudah ada harus membaca catatan rilis saat memperbarui ke jurusan baru. Jadi saya pikir itu bisa dilakukan selama kita sangat eksplisit tentangnya dan tidak mungkin melewatkan pesannya.

Terima kasih telah terbuka untuk perubahan seperti itu @gaearon. Apa yang diperlukan untuk mendapatkan persetujuan dalam mencoba pesan secara default di rilis mendatang? 😄.

Saya setuju bahwa peringatan konsol bukanlah solusi & peringatan yang terlihat di halaman jauh lebih baik.

Peringatan yang terlihat di halaman dapat:

• Peringatkan dev bahwa situs dalam mode dev
• Tautan ke dokumen tentang manfaatnya, dan cara mengirim tanpa itu
• Tautan untuk menonaktifkan pesan selama ... Saya tidak tahu 2 jam?

Menonaktifkan pesan itu penting, karena mungkin mengganggu/menutupi sesuatu di halaman. Karena pengaturan ini akan disimpan di penyimpanan lokal, peringatan akan tetap muncul di server langsung karena asalnya berbeda.

Ya, cukup mengerikan jika pengguna nyata melihat pesan ini di situs langsung, tetapi rasanya seperti jenis masalah yang akan didorong untuk diperbaiki oleh pengembang, sedangkan beberapa tampaknya senang hidup dengan masalah kinerja mode pengembang.

Jika pertama kali saya melihat peringatan itu (masukkan ke DOM), sedang dalam produksi, saya akan cukup kesal. Peringatan harus terjadi sebelumnya.

@rtorr saran saya adalah itu terjadi setiap kali situs dalam mode dev, jadi itu harus dilihat sebelumnya kecuali saya kehilangan sesuatu?

@jakearchibald maaf atas kebingungannya, balasan saya tidak ditujukan pada Anda. Saya hanya ingin menunjukkan ke utas bahwa jika kita menggunakan solusi 'masukkan ke dalam dom', kita harus sangat berhati-hati dan memastikan pengguna tahu sebelum mereka mendorong sesuatu (entah bagaimana, saya tidak punya ide bagus di sini) .

Saya baru saja melihat beberapa dev melupakan pengaturan atau sesuatu dan manajemen panik. Apakah kemungkinan itu sepadan dengan konsekuensi memiliki mode dev dalam produksi?

Peringatan berbasis DOM yang harus saya nonaktifkan terus-menerus tidak apa-apa, itu harus mungkin untuk menonaktifkannya selamanya, dan mungkin tidak akan pernah ditampilkan sama sekali untuk localhost.

Suatu hal yang baru saja memukul saya jika mungkin untuk memiliki semacam bendera di browser yang harus Anda aktifkan untuk mengaktifkan devtools (mungkin overlay besar di dalamnya dengan "Apakah Anda seorang pengembang? [Ya/Tidak]" ) bahwa laman dapat mendeteksi dan hanya menampilkan peringatan untuk pengembang. Diucapkan dengan benar mungkin membantu dengan serangan XXS diri juga.

Peringatan berbasis DOM yang harus saya nonaktifkan terus-menerus tidak apa-apa, , harus dimungkinkan untuk menonaktifkannya selamanya

Peluncuran situs dengan mode dev juga tidak apa-apa. Mungkin pesan hanya perlu diberhentikan sekali sehari? Tetapi semakin lama periodenya, semakin besar kemungkinannya untuk ditayangkan secara langsung. Jika itu dapat dinonaktifkan selamanya, kami segera kembali ke tempat kami memulai.

Saya juga tidak berpikir simpul dom yang tidak diinginkan dalam produksi tidak masalah.

Saya pikir bagaimanapun, kita akan selalu memiliki kasus tepi. Jika masalah ini terjadi sepanjang waktu, maka mungkin pengiriman mode dev salah. Meskipun tidak ideal di dunia yang sempurna, tetapi jika kami menemukan mode prod ini penting sehingga kami bersedia memodifikasi aplikasi seseorang, mungkin itu harus default dan mode dev harus ikut serta.

@rtorr

Saya juga tidak berpikir simpul dom yang tidak diinginkan dalam produksi tidak masalah.

Mengapa? (Saya tidak mengatakan Anda salah, hanya ingin mendengar alasan Anda)

Mungkin menambahkan pengaturan untuk mendefinisikan Domain prod. Jika prod Domain tidak disetel maka kita selalu mendapatkan peringatan tentang mode DEV (dengan permintaan untuk mengatur URL Domain), jika sudah disetel maka kita hanya mendapatkan peringatan ketika URL cocok dengan domain prod. Kami bahkan dapat mengikat layanan apa pun yang ingin kami beri tahu devs

Saya senang ada diskusi yang membangun di sini. Ada dua solusi di sini yang saya lihat memecahkan masalah. Webpack dapat memaksa untuk menentukan NODE_ENV yang kemudian dapat digunakan oleh React untuk menghindari pengiriman DEV ke PROD dengan lebih mudah, tetapi itu akan menjadi perubahan besar pada Webpack. Saya sedang berbicara dengan Sean sekarang tentang seberapa layak hal seperti itu untuk Webpack 3. Menjaga agar React + Webpack stack pemula dan ramah kinerja adalah sesuatu yang saya tahu diperhatikan oleh kedua kubu.

Yang kedua (ide injeksi DOM) adalah sesuatu yang dapat dilakukan React dan seperti yang disebutkan Jake, seimbangkan UX dengan mengizinkan pesan ditampilkan sekali sehari atau ditutup. Ini adalah perubahan satu baris untuk memperbaiki masalah, maka Anda hanya perlu menerapkan ulang. Saya benar-benar berempati dengan tidak ingin manajemen panik.

Jika kita ingin mendapatkan lebih banyak situs React mengirimkan pengalaman yang jauh lebih cepat yang dikerjakan FB untuk mendorong sesuatu yang mungkin harus diberikan. Jika ada yang punya ide yang lebih baik, tolong sarankan mereka.

@jakearchibald

Mengapa? (Saya tidak mengatakan Anda salah, hanya ingin mendengar alasan Anda)

Kembali ke komentar saya di atas, kecuali kami dapat memberi tahu pengembang sebelumnya (yang tampaknya menjadi masalah sebenarnya untuk dipecahkan), saya merasa agak ekstrem untuk mendevaluasi produk seseorang dengan menampilkan peringatan kepada pengembang di halaman produksi mereka. Dalam banyak kasus, ini berpotensi lebih merusak produk daripada kinerja mode dev.

Apa pun yang kita lakukan, seseorang akan mengirimkan apa pun yang default ke dalam produksi, mengapa tidak membuat default produksi? Mengapa tidak meningkatkan mode dev ke titik di mana pengaruhnya tidak terlalu besar?

@rtorr https://twitter.com/sebmarkbage/status/820054247496503296

@jakearchibald ya, saya melihat kedua belah pihak memiliki masalah. Saya memiliki keyakinan dari orang-orang di utas ini untuk menghasilkan sesuatu yang baik, bahkan jika itu yang Anda usulkan. Kalian semua hebat FYI. Mungkin ekstrim adalah jawabannya.

Bisakah Anda tidak memasukkan peringatan simpul DOM jika pengguna menjalankan React dev tools sehingga pengguna biasa tidak mengalaminya?

@jakearchibald

Peluncuran situs dengan mode dev juga tidak apa-apa. Mungkin pesan hanya perlu diberhentikan sekali sehari? Tetapi semakin lama periodenya, semakin besar kemungkinannya untuk ditayangkan secara langsung. Jika itu dapat dinonaktifkan selamanya, kami segera kembali ke tempat kami memulai.

Ketika situs diluncurkan, seseorang mengambil keputusan bahwa itu "siap", jadi meskipun buruk, itu bukan malapetaka. Namun memiliki (mungkin, saya tidak tahu angka pastinya) ratusan ribu pengembang harus mengabaikan perusakan situs (Peringatan DOM harus diperlakukan seperti itu karena Anda tidak tahu bagaimana interaksinya dengan situs lainnya dan jika situs dapat digunakan dengan peringatan yang terlihat) peringatan lima atau bahkan hanya satu kali per hari adalah bencana. Sebagian besar pengembang memiliki rantai build yang diatur dengan benar (kustom, buat-reaksi-aplikasi, atau lainnya) dan tidak menggunakan sama sekali untuk peringatan itu, mereka harus dapat menghapusnya.

@dan-gamble Saya percaya pengembang yang tidak menggunakan React Dev Tools adalah target paling mendesak untuk peringatan ini.

@Pajn Berpotensi, saya tidak berpikir hanya karena Anda mengunduh ekstensi Chrome, itu secara otomatis membuat Anda sadar akan sakelar prod / dev

@dan-gamble Tidak, tentu saja tidak. Tetapi ada orang yang mengembangkan seluruh aplikasi tanpa itu yang menurut saya menunjukkan bahwa mereka tidak banyak menggunakan alat dev dan karena itu cenderung tidak melihat peringatan saat ini untuk kode yang diperkecil.

Saya biasanya tidak menambah diskusi yang panjang ketika saya merasa poinnya telah dibawa tetapi ini saya harus setuju dan ingin menekankan poin ini: Bereaksi dengan menyentuh DOM dan memperingatkan saya bahwa saya menggunakan versi dev akan menjadi kesalahan besar . Sejauh yang saya tahu tidak ada preseden untuk itu dalam kerangka kerja lain.

Bayangkan semua tutorial, semua taman bermain, semua proyek sampingan kecil yang menggunakan mode dev untuk mengajar React. Setiap situs pengujian kecil yang saya kumpulkan untuk menjelajahi sesuatu yang menyenangkan di React, atau mencoba mengisolasi kasus pengujian. Jika Bereaksi melalui peringatan di setiap situs ini yang harus saya nonaktifkan secara manual, saya akan sangat marah. Itu akan terasa seperti orang tua yang sombong dan secara aktif mendorong Anda untuk menggunakan React karena setiap kali Anda mencoba melakukan sesuatu yang baru, itu menampar Anda di pergelangan tangan.

Bahkan melakukannya setiap 2 jam ? Tidak terima kasih. Mengomel terus-menerus seperti ini tentu akan membuat pengguna enggan berkembang di React dan sejujurnya saya pikir itu akan mendorong orang menjauh untuk mengadopsi kerangka kerja lain. Mungkin itu yang diinginkan para pengembang Chrome?

Belum lagi fakta bahwa ya, ini entah bagaimana akan masuk ke produksi, dan itu sudah cukup sulit untuk meyakinkan tim tertentu untuk mengadopsi React dan itu hanya lebih banyak amunisi bagi mereka untuk melawannya.

Hal yang paling saya sukai dari React adalah ia tidak melakukan apa pun sampai Anda memanggil ReactDOM.render(...) dan ketika Anda melakukannya, ia hanya memasukkan barang ke dalam DOM tempat Anda menyuruhnya. Itulah mengapa perpustakaan ini sangat bagus, terisolasi, dan fungsional.

Apakah kami juga perlu mendeteksi jika orang mengirim bundel yang tidak diperkecil? Bagaimana jika mereka tidak melakukan caching saat seharusnya? Bagaimana jika mereka belum mengonfigurasi nginx secara optimal? Atau jangan gunakan shouldComponentUpdate saat seharusnya? Atau tidak perlu merender semuanya ketika tidak perlu?

Ada beberapa alasan untuk kinerja yang buruk dan menyalahkan mode dev React semata-mata adalah salah. Saat Anda menerapkan situs, Anda diharapkan memahami cara menerapkan situs yang dioptimalkan. Saya tidak mengatakan tidak ada hal yang dapat kami lakukan, tetapi alasan utama dari masalah ini adalah penulis benchmark tidak melakukan uji tuntas mereka dan kami tidak perlu membayar untuk itu. Kita perlu menemukan cara lain untuk memanggilnya.

Saya bermaksud menindaklanjuti dengan apa yang menurut saya merupakan solusi yang tepat: masukkan batasan semacam ini ke dalam alat. Memastikan bahwa webpack atau alat apa pun yang Anda gunakan untuk membangun situs Anda untuk produksi adalah tempat kami harus memaksakan pemeriksaan ini dan saya tidak setuju dengan segala jenis batasan yang ingin kami tempatkan dalam proses pembuatan.

Berkenaan dengan webpack yang memaksa pengaturan NODE_ENV (mungkin sudah ada masalah untuk ini di repo mereka), bukankah itu akan mempersulit penggunaan perpustakaan yang tidak bergantung pada pengaturan env?

Atau apakah gagasan itu akan mendeteksi penggunaan NODE_ENV dan memaksanya hanya jika kode menggunakannya?

Jangan terlalu terpaku pada hal "2 jam". Ini bisa menjadi periode waktu apa pun selama itu berhasil.

Selain itu, peristiwa penyimpanan lokal berarti hanya perlu ditutup sekali per asal. Jika Anda memiliki beberapa demo di satu halaman, mengabaikan satu akan mengabaikan yang lain.

Jika peringatan itu masuk ke siaran langsung, itu cukup keras untuk menjamin perbaikan cepat - yang menguntungkan pengguna. Jika kami khawatir tentang bagaimana React terlihat di depan umum, kami benar-benar ingin menghindari perlambatan yang tidak perlu seperti ini.

Tentu, ini tidak akan mendeteksi header caching yang buruk dll, ini tentang mendeteksi "mode dev" saja. Juga argumen "lereng licin" tidak membantu.

Saya tidak berpikir memindahkan masalah ke alat build itu berguna, karena Anda akan memiliki masalah yang sama jika pengembang menggunakan alat build yang berbeda, atau gagal memasukkannya ke mode produksi. Kerangka kerja mode dev sudah menghasilkan peringatan konsol, dan itu jelas tidak berfungsi.

Ini bukan hanya tentang tolok ukur, ini tentang situs web nyata, berjalan lambat untuk pengguna nyata, karena sakelar tidak diaktifkan.

@jakearchibald Terima kasih atas tanggapan rasional untuk tanggapan emosional saya. Saya pikir itu adalah poin yang valid bahwa ada banyak alasan sebuah situs mungkin lambat dengan React. Saya ingin melihat cara kami dapat menyarankan peningkatan kinerja yang lebih baik daripada pemeriksaan kasar untuk mode dev dan peringatan dalam browser. Jika kami memiliki alat untuk menganalisis aplikasi React dan memberikan saran serius untuk kinerja, dari segala hal seperti mode dev hingga terlalu banyak rendering, itu akan jauh lebih berguna. Alat generik seperti itu dapat dihubungkan ke saluran apa pun, baik itu webpack, browserify, dll.

Ini adalah hal utama yang ingin saya katakan: beberapa hari saya akan menggunakan mode React dev di 5-10 tempat berbeda, seperti jsbin, tutorial, dan bahkan membuat situs pengujian kecil dan membukanya dengan file:// protokol. Peringatan dalam browser yang dipaksakan bertentangan dengan pengembangan fleksibel semacam ini yang menjadi keunggulan web. Saya akan melihat peringatan ini di mana-mana karena saya belajar Bereaksi di seluruh domain di web.

Jika peringatan itu masuk ke siaran langsung, itu cukup keras untuk menjamin perbaikan cepat - yang menguntungkan pengguna. Jika kami khawatir tentang bagaimana React terlihat di depan umum, kami benar-benar ingin menghindari perlambatan yang tidak perlu seperti ini.

Bahkan membiarkan kemungkinan peringatan khusus pengembang ditampilkan kepada pengguna akhir tampaknya tidak dapat saya terima. Situs yang lambat adalah satu hal, tetapi pesan seperti ini dapat merusak kepercayaan pengguna, terutama untuk situs yang berfokus pada keamanan (apakah Anda akan senang jika situs perbankan Anda tiba-tiba menampilkan kesalahan samar?) Apakah Google akan baik-baik saja dengan semua situs mereka? pengguna tiba-tiba mendapatkan peringatan ini, meskipun hanya sesaat?

Selain itu, peristiwa penyimpanan lokal berarti hanya perlu ditutup sekali per asal. Jika Anda memiliki beberapa demo di satu halaman, mengabaikan satu akan mengabaikan yang lain.

Anda tidak dapat mengandalkan localStorage untuk menipu ini. Tidak ada jaminan bahwa localStorage (atau data persisten lokal lainnya) tidak akan dihapus pada interval apa pun.

edit : Juga, dengan hanya menampilkan kesalahan sekali setiap {INTERVAL} Anda sekarang telah membuatnya jauh lebih sulit untuk direproduksi dan di-debug karena tidak dapat direproduksi secara deterministik.

Ada 2 kasus yang harus diselesaikan:

• Cegah tolok ukur palsu, uji kinerja: Mudah dipecahkan dengan pesan konsol besar yang besar.
• Cegah pengiriman DEV ke lokasi produksi: Orang tidak membuka devtools di prod.

Argumen yang menentang menyentuh DOM cukup meyakinkan.

Jika ada peringatan konsol yang besar, mencolok, dan jelas, kemungkinan besar sebelum pengiriman ke produksi orang akan menggunakan versi dev dan melihat pesan konsol yang sangat jelas ini. Atau mungkin beberapa kode telah dikirim ke produksi, tetapi untuk proyek lain mereka akan menggunakan versi reaksi berikutnya dengan pesan konsol yang mustahil untuk dilewatkan ini. Mungkin mereka akan mengingat situs yang mereka kirim ke produksi dan memeriksa apakah DEV diaktifkan di sana.

Pesan konsol akan mendidik, seperti, siapa pun yang melakukan pengembangan React tahu bahwa ada sesuatu yang sangat penting tentang DEV, dan mereka melihatnya setiap kali mereka menggunakan React untuk pengembangan.

Saya ragu-ragu tentang https://github.com/facebook/react/pull/8782 karena orang umumnya tidak menyukai peringatan yang tidak dapat mereka singkirkan (lihat https://github.com/facebook/react/issues/ 3877), tetapi mempertimbangkan alternatif itu mungkin merupakan solusi yang dapat diterima.

Penasaran. Apakah penggunaan localStorage akan meminta undang-undang cookie UE di situs yang tidak tercakup olehnya?

Jika peringatan informatif selama pengembangan adalah ide yang bagus, lalu mengapa perpustakaan lain tidak melakukannya? Nah, salah satu alasannya adalah untuk masalah seperti ini. Jika orang lain ingin melakukan ini, haruskah mereka juga memunculkan UI serupa? Apakah Anda harus menutup semuanya?

Sepertinya saya akan ideal untuk memiliki sesuatu yang lebih sentral untuk menangani ini.

Mungkin Chrome dapat memiliki mode pengembangan? Perpustakaan dapat memberi tahu host bahwa mereka sedang dalam mode pengembangan dan kemudian Chrome dapat menambahkan lencana atau munculan untuk menunjukkannya.

Membuat saya berpikir ekstensi react devtools dapat dimanfaatkan untuk menampilkan pemberitahuan atau sesuatu yang jelas saat membuka halaman menggunakan reaksi dalam mode dev mungkin?

@sebmarkbage

Jika peringatan informatif selama pengembangan adalah ide yang bagus, lalu mengapa perpustakaan lain tidak melakukannya?

Saya kira seseorang harus menjadi yang pertama. Angular memiliki masalah yang sama, dengan hal-hal seperti http://code.gov diluncurkan dalam mode dev. Jika React mulai menangkap hal-hal ini di mana kerangka kerja lain tidak, saya akan mendorong mereka untuk membuat perubahan serupa.

Saya akan mendorong mereka untuk membuat perubahan serupa.

@jakearchibald apakah Anda menyarankan agar setiap kerangka kerja harus memberikan peringatannya sendiri? Saya tidak berpikir menetapkan standar untuk kerangka kerja/perpustakaan yang memberikan peringatan pengembangan mereka sendiri dalam produksi adalah ide yang bagus. Bukankah seharusnya kita mencoba menstandarisasi platform? Seperti yang disebutkan oleh @sebmarkbage

Mungkin Chrome dapat memiliki mode pengembangan? Perpustakaan dapat memberi tahu host bahwa mereka sedang dalam mode pengembangan dan kemudian Chrome dapat menambahkan lencana atau munculan untuk menunjukkannya.

Saya pikir ini adalah ide bagus. Preseden: Safari memiliki mode terpisah yang harus Anda aktifkan untuk mengakses DevTools. Jika Chrome melakukan hal yang sama maka itu juga dapat dengan aman menambahkan indikator untuk mode DEV dan API untuk memicunya. Indikator ini hanya akan terlihat oleh pengembang sehingga tidak mengganggu pengalaman pengguna.

Bukankah menunggu vendor browser untuk mengimplementasikan hal seperti itu akan memakan waktu?

@jide ya, tapi lebih penting untuk mengatasi masalah ini dengan benar daripada cepat. Juga, dapat diimplementasikan dalam satu browser sebelum mempertimbangkan upaya standardisasi (jika perlu).

@lelah

apakah Anda menyarankan agar setiap kerangka kerja harus memberikan peringatan mereka sendiri?

Mengingat bahwa setiap kerangka kerja menyediakan mode dev mereka sendiri (dan mode itu mungkin sangat berbeda di antara kerangka kerja), tampaknya sepenuhnya adil bahwa kerangka kerja harus mengimplementasikan peringatan dengan cara yang sama uniknya.

Peramban telah berusaha keras untuk menghindari memaparkan devtools ke halaman. Jika kita menjadikan devtools sebagai penghalang untuk masuk ke sini, kita akan kehilangan banyak pengguna yang tidak akan dilewatkan oleh peringatan DOM. Peringatan DOM tampaknya tidak hanya lebih sederhana, tetapi juga memiliki ketergantungan platform yang lebih sedikit, dan akan menjangkau lebih banyak pengembang. Lebih sederhana & lebih efektif terdengar seperti kemenangan.

@gaearon Di sisi Chrome DevTools, kami telah melakukan brainstorming "API pelanggaran" langsung yang dapat digunakan oleh pembuat platform & kerangka web untuk memberi sinyal peringatan penting. Ini akan disajikan di suatu tempat seperti penyegaran panel Audit yang akan datang. Kedengarannya mirip dengan permintaan Anda dan dapat digunakan untuk memicu peringatan pada deteksi mode DEV.

Untuk masalah khusus ini, Anda mungkin menginginkan sesuatu yang sedikit lebih keras dari yang kami rencanakan sebelumnya. Panel pelanggaran, mirip dengan pesan log konsol, mengharuskan Anda mengetahui bahwa panel akan memberikan wawasan. Mungkin ada ruang UX tambahan untuk sesuatu yang menampilkan hamparan halaman yang sangat terlihat di bagian bawah halaman yang dapat distandarisasi oleh kerangka kerja pada perpesanan. Looping di @paulirish dan @s3ththompson untuk pemikiran mereka setelah liburan akhir pekan.

Fwiw, tebakan saya adalah API ini tidak akan siap untuk beberapa bulan lagi. Saat itu, itu hanya akan tersedia di Canary pada awalnya dan kemudian 6-7 minggu kemudian mungkin membuatnya stabil.

Peringatan DOM tampaknya tidak hanya lebih sederhana, tetapi juga lebih efektif.

Saya setuju dengan Jake yang satu ini. Mari kita terus mengobrol tentang solusi DevTools, tetapi saya juga ingin mencari tahu apa yang mungkin dilakukan React sebagai fallback jika API tidak sesuai dengan kebutuhan Anda atau lebih jauh dari waktu ke waktu.

Mengingat bahwa setiap kerangka kerja menyediakan mode dev mereka sendiri (dan mode itu mungkin sangat berbeda di antara kerangka kerja), tampaknya sepenuhnya adil bahwa kerangka kerja harus mengimplementasikan peringatan dengan cara yang sama uniknya.

@jakearchibald Anda menyadari bahwa pengaturan bahwa standar berarti halaman yang menggunakan beberapa kerangka kerja (atau perpustakaan yang mengikuti dalam suite) dapat menghasilkan jumlah sewenang-wenang dari peringatan samar yang ditampilkan secara non-deterministik kepada pengguna akhir?

Peramban telah berusaha keras untuk menghindari memaparkan devtools ke halaman.

Dan saya yakin alasannya setidaknya sebagian karena pesan khusus pengembang tidak boleh diekspos ke pengguna akhir.

Peringatan DOM tampaknya tidak hanya lebih sederhana, tetapi juga lebih efektif.

Tidak ada yang memperdebatkan kesederhanaan atau keefektifan solusi. Ini akan berhasil , tetapi dengan mengorbankan pengalaman pengguna. Kecepatan bukan satu-satunya hal yang dapat berdampak negatif pada pengguna.

Fwiw, tebakan saya adalah API ini tidak akan siap untuk beberapa bulan lagi. Saat itu, itu hanya akan tersedia di Canary pada awalnya dan kemudian 6-7 minggu kemudian mungkin membuatnya stabil.

@addyosmani jika ini adalah solusi yang lebih baik, saya tidak melihat bagaimana itu akan menjadi masalah. Setiap perubahan pada React akan ada dalam rilis besar, yang menurut saya masih TBD sejauh waktu rilis berjalan.

Solusi yang diputuskan akan berpotensi mempengaruhi semua perkembangan di masa depan. Soal minggu vs bulan dalam konteks itu dapat diterima IMO.

Saya mengerti bahwa beberapa pengembang merasa diserang jika suatu kerangka kerja menyuntikkan sesuatu ke dalam DOM mereka yang tidak mereka taruh di sana sendiri. Tapi saya merasa seperti spanduk di bagian bawah halaman yang mengatakan "Situs ini dalam DevMode" akan menjadi solusi yang bagus untuk ini yang tidak berdampak besar pada pengalaman pengguna. Saya ingin memahami mengapa banyak orang berpikir sebaliknya.

@aweary : Jika situs "berfokus pada keamanan" pernah diluncurkan di DevMode, mereka tidak boleh dipercaya sampai mereka memperbaiki masalahnya. “DevMode” dapat mencakup semua jenis pintasan terkait keamanan seperti pemeriksaan CORS yang dinonaktifkan atau kode sumber template yang terbuka, dll. Jika situs berfokus pada keamanan, _harus_ ini tidak terjadi.

(Saya menyadari bahwa "DevMode" memiliki arti yang sangat spesifik dalam React, tetapi saya mencoba untuk mengasumsikan perspektif non-developer di sini)

@lelah

Anda menyadari bahwa pengaturan bahwa standar berarti halaman yang menggunakan beberapa kerangka kerja dapat menghasilkan jumlah sewenang-wenang dari peringatan samar yang ditampilkan secara non-deterministik kepada pengguna akhir?

Saya benar-benar menyadari itu. Halaman dengan banyak kerangka kerja dalam mode dev akan sangat merusak pengalaman pengguna tanpa alasan yang baik. Sepertinya Anda lebih suka itu tidak diperhatikan dan tidak diperbaiki. Saya lebih suka itu sangat buruk untuk non-pengembang (pesan terlihat yang ditargetkan pada pengembang) sehingga pengembang segera memperbaikinya, menciptakan pengalaman pengguna yang jauh lebih baik.

Kecepatan bukan satu-satunya hal yang dapat berdampak negatif pada pengguna.

Saya tidak melihat ada orang yang mengklaim sebaliknya? Saya cukup sedih dengan reaksi seperti ini

Sepertinya Anda lebih suka itu tidak diperhatikan dan tidak diperbaiki

@jakearchibald itu semacam kesimpulan yang aneh, saya tidak berpikir saya akan menghabiskan waktu luang saya di sini berbicara dengan Anda jika saya tidak ingin ini diperbaiki? Hanya karena saya tidak setuju dengan solusi Anda tidak berarti saya pasrah membiarkannya tidak terselesaikan. Itu benar-benar tidak adil.

Saya lebih suka itu sangat buruk untuk non-pengembang (pesan terlihat yang ditargetkan pada pengembang) sehingga pengembang segera memperbaikinya, menciptakan pengalaman pengguna yang jauh lebih baik.

Itulah yang menurut saya pada dasarnya tidak dapat diterima: Anda secara eksplisit menghukum pengguna terlebih dahulu.

Jika situs "berfokus pada keamanan" pernah diluncurkan di DevMode, mereka tidak boleh dipercaya sampai mereka memperbaiki masalahnya.

@surma dev mode secara inheren tidak aman, tetapi terlepas dari itu melangkahi batas untuk menganggap tidak apa-apa bagi Anda untuk mengomunikasikannya kepada pengguna.

Saya tidak berpikir solusi yang memerlukan pembukaan atau pengaktifan alat dev sudah cukup. Agar ini diperhatikan, perlu terlihat oleh QA, manajemen, dan mungkin pengguna akhir. Pengembang akan terlalu terbiasa melihat ini. Mirip dengan bagaimana konfigurasi ssl yang bermasalah disorot. Tidak perlu banyak tetapi cukup untuk terlihat bahwa seseorang akan menanyakannya dan kemudian memperbaikinya.

Menyuntikkan ke DOM bermasalah karena berbagai alasan. Ini sedikit lebih layak untuk React karena kami adalah pustaka DOM dan memiliki titik masuk DOM. Lebih sulit untuk perpustakaan yang tidak spesifik DOM dan mungkin berjalan di pekerja.

Satu hal yang mungkin dapat kami lakukan adalah mengubah favicon selama kami menyediakan cara untuk menimpanya secara eksplisit. Banyak situs sudah memiliki favicon terpisah untuk mode pengembangan.

Kita perlu mencari tahu pengalaman default untuk menangani kesalahan di React yang mungkin tidak dapat mempertahankan DOM di tempatnya. Implementasi default saat ini di master menghapus konten Bereaksi dari pohon jika ada kesalahan. Itu juga invasif.

Jika kami memiliki cara untuk mendeteksi bahwa Anda tidak dalam mode pengembangan, kami dapat memicu mode kesalahan itu. Kami benar-benar membutuhkan cara yang solid untuk memilih mode pengembangan secara permanen.

Mirip dengan bagaimana konfigurasi ssl yang bermasalah disorot.

Ini adalah jenis hal yang menurut saya akan sempurna. Pengguna sudah terbiasa dengan browser yang menyediakan informasi keamanan tentang situs yang mereka kunjungi, informasi kinerja bukanlah lompatan besar dari sana. Plus, itu akan konsisten untuk semua kerangka kerja/pustaka yang melaporkan potensi masalah kinerja dan tidak akan secara langsung mengganggu alur kerja pengguna. 👍

Saya suka ide favicon: Terlihat, berfungsi tanpa devtools atau ekstensi, terlihat oleh semua orang, tidak membahayakan pengguna, dapat dianimasikan untuk menarik perhatian, cukup mengganggu untuk membuat dev ingin menghilang.

Bagaimana dengan membuat keikutsertaan mode DEV?
Kami berbuat salah di sisi "UX yang baik", karena DX yang buruk lebih mudah diperhatikan (dan IMHO untuk masalah seperti ini, pengguna harus "menang" karena mereka tidak dapat memilih, sementara pengembang bisa).
Saya yakin beberapa kerangka kerja sudah melakukan ini (seperti Relay jika saya ingat dengan benar).

Usulan tentang cara menerapkannya:

• aktifkan mode pengembangan hanya jika NODE_ENV secara eksplisit diatur ke development
• aktifkan mode pengembangan jika __DEV__ global adalah === true
• ekspor modul alat debug untuk diaktifkan di userland

Yang pertama tampaknya yang terbaik karena dua lainnya mungkin dikodekan tanpa pelindung (seperti pernyataan if(NODE_ENV === 'development') ) dan dengan demikian tetap dikirim ke produksi.

@mattecapu Lihat komentar kedua saya tentang. https://twitter.com/sebmarkbage/status/820047144677584896

Jika ada cara serupa untuk memaksa pengembang memulai dengan menjalankan dalam mode DEV maka tidak masalah apa defaultnya. Tapi sangat buruk jika Anda tertinggal.

Ada banyak hal untuk dikomentari di sini, dan saya memiliki pemikiran, tetapi saya ingin mempertimbangkan secara khusus hanya pertanyaan tentang cara menonaktifkan peringatan dev.

Saya bukan penggemar berat tombol yang menonaktifkan peringatan DOM untuk jangka waktu tertentu di satu browser tertentu. Seperti yang ditunjukkan oleh @jlongster , sangat merepotkan bagi para pengembang jika itu sering terjadi. Tetapi yang lebih penting bagi saya, ini memperkenalkan variabilitas khusus browser dalam perilaku, yang dapat dengan mudah menyebabkan "tetapi berfungsi dengan baik di mesin saya" bug yang tidak dapat direproduksi.

Saya lebih suka parameter yang dikirim untuk merender yang mencantumkan domain yang dianggap sebagai kotak dev, dengan nilai default ["localhost", "127.0.0.1"] . Ini akan terlihat seperti ini:

React.render(<App/>, 
  myDiv,
  () => { console.log('finished render!'), 
  { devDomains: ["localhost", "devbox.mycorp.com"] }
);

Jika domain saat ini ada dalam daftar, maka peringatan dev tidak pernah muncul. Jika tidak, itu benar. Di bawah rezim ini:

• Menggunakan dev build di mesin lokal Anda menggunakan localhost atau 127.0.0.1 : Tidak ada peringatan pengembang, dan tidak perlu tindakan pengembang.
• Menggunakan dev build di mesin dev menggunakan nama Host lain : Anda mendapatkan peringatan DOM hingga Anda menambahkan nama domain ke daftar yang diteruskan ke render . Setelah itu, Anda tidak pernah mendapatkan peringatan DOM.
• Menggunakan dev build pada mesin prod : Anda mendapatkan peringatan DOM sampai Anda mengganti React ke versi prod.

Satu hal yang membuat saya khawatir tentang solusi ini adalah bahwa hal itu mungkin menyebabkan pengembang meninggalkan daftar semua domain server dev mereka dalam kode, dan kode itu dapat diproduksi. Bagi perusahaan yang menganggap domain server dev mereka sebagai rahasia, itu akan menjadi masalah. Pikiran?

@aickin masalah dengan pendekatan itu adalah mengharuskan pengguna untuk mengetahui konfigurasi dan, pada gilirannya, masalah yang dipecahkannya. Masalahnya adalah orang-orang tidak menyadari perbedaan dev/prod sejak awal.

Sunting : tidak apa-apa, saya mengerti, masih ada peringatan DOM dalam pengembangan.

Lingkungan sisi server memperbaikinya dengan menampilkan halaman kesalahan "khusus" yang menyertakan detail debug dan juga memberi tahu Anda untuk tidak menayangkannya dalam produksi.

Karena kami berencana untuk membuat React "gagal cepat" dan melepas tampilan kecuali Anda memberikan batas kesalahan khusus, kami mungkin juga menambahkan batas kesalahan "kotak merah" default dalam pengembangan yang bertindak sebagai halaman pendidikan.

Kemudian, pertama kali pengguna memiliki bug dalam produksi, mereka akan melihat pesan kesalahan verbose khusus. Ini bisa menjadi kesempatan untuk mengedukasi tentang pembangunan DEV.

Tapi saya merasa seperti spanduk di bagian bawah halaman yang mengatakan "Situs ini dalam DevMode" akan menjadi solusi yang bagus untuk ini yang tidak berdampak besar pada pengalaman pengguna. Saya ingin memahami mengapa banyak orang berpikir sebaliknya.

Sebagian besar pengguna tidak menyukai aplikasi web jika mereka tahu bahwa itu adalah aplikasi web, mengapa? Karena mentalitas web yang sebelumnya umum adalah bahwa ketika muncul di layar itu selesai, tidak peduli seberapa buruk perilakunya dan pengguna telah mengetahui bahwa web itu buruk. Namun sangat mungkin untuk membuat UX yang hebat di web, tetapi untuk melakukan itu saya harus memiliki DOM. Jika seseorang menyuntikkan spanduk acak di tempat yang sewenang-wenang, elemen yang salah dapat mulai menggulir, atau dapat menyebabkan seluruh layar mengecat ulang pada gulir atau dapat mengganggu misalnya gerakan seret atau yang lainnya. Intinya, selama spanduk itu naik saya tidak bisa berkembang karena saya tidak tahu bahwa pengalamannya sama ketika spanduk itu hilang.

Sebagai solusi kerangka kerja, saya sangat menyukai ide favicon, tidak menghambat pengembangan, tidak terlihat aneh bagi pengguna, tidak mungkin menghancurkan UX tetapi akan diperhatikan. Namun, itu benar-benar hanya berfungsi untuk satu perpustakaan atau kerangka kerja pada saat itu dan tidak berfungsi sama sekali untuk perpustakaan yang berjalan di pekerja. Solusi sebenarnya adalah cara yang baik untuk melakukan ini melalui browser yang dapat mendukung banyak kerangka kerja dan pustaka dan dapat diakses dari semua konteks.

Solusi lain yang mendukung banyak kerangka kerja dan lib dan lebih jelas, tetapi memang memerlukan permintaan izin, adalah dengan menampilkan pemberitahuan browser.

Ini idenya: perbarui dokumen memulai di beranda reaksi untuk mendorong aplikasi buat reaksi lebih banyak. Dan tekankan pentingnya npm build di dokumen tersebut. Kami tidak membutuhkan peringatan DOM, kami membutuhkan kesadaran.

Saya pikir @ropilz menyentuh ini sebelumnya di utas dengan komentar "_..we bahkan dapat mengikat layanan apa pun yang ingin kami beri tahu devs.._", tetapi mungkin tidak diperhatikan (atau tidak diakui).

Seperti yang saya pahami, masalah mendasar yang dipecahkan di sini adalah

• entah bagaimana mengingatkan _developers_ ketika produksi _end-users_ mengalami situs yang berjalan dalam mode dev
• kami tidak dapat mengandalkan para pengembang yang melihat pesan console.log (atau bahkan peringatan DOM dalam hal ini) dalam produksi, _kecuali_ para pengembang tersebut secara aktif menggunakan situs produksi itu sendiri (atau kami mengandalkan pengguna akhir, QA/ tim dukungan dll. untuk melaporkan peringatan ini kembali ke pengembang)
• ada argumen UX (valid) _against_ yang menunjukkan kepada pengguna akhir peringatan terlihat DOM yang ditujukan untuk pemirsa pengembang.

Bagaimana jika ada sesuatu yang analog dengan CSP report-uri , untuk kerangka kerja untuk mengirim peringatan mode dev, daripada menunjukkan peringatan in-situ di situs di mana mereka akan terlihat oleh pengguna akhir?

Tentunya ada beberapa hal yang harus diperhatikan, seperti:

1. Pelaporan seperti itu idealnya AKTIF secara default, tetapi report-uri defaultnya seperti apa? (apakah kita mengharapkan setiap kerangka kerja untuk meng-host layanan gratis mereka sendiri, mirip dengan https://report-uri.io? (ini _may_ mungkin untuk kerangka kerja besar yang disponsori perusahaan seperti React & Angular; tetapi tentu saja tidak praktis untuk kerangka kerja sumber terbuka yang lebih kecil seperti Preact, Vue, dll.)
2. Setelah peringatan dilaporkan, bagaimana pemilik/pengembang situs diberi tahu? (mungkin cara yang baik bagi non-pengembang untuk terlibat dengan proyek, dengan menjadi sukarelawan untuk memantau laporan ini dan membantu melacak/memberi tahu pengelola?)

Saya sepenuhnya mengakui bahwa saran ini hanyalah gelembung pikiran, dan saya belum mempertimbangkan seberapa praktis ini atau bagaimana cara kerjanya; tetapi saya ingin mengangkatnya karena bagi saya tampaknya tantangan 'melaporkan masalah produksi' telah diselesaikan sebagian untuk pelaporan CSP/HPKP, dan mungkin kita bisa mengeksplorasi sesuatu yang serupa di sini?

Sangat penting untuk mundur selangkah dan menyadari bahwa React adalah sebuah framework. Anda tidak boleh :

• Ubah DOM untuk menyajikan sesuatu secara visual hanya sebagai pengingat bagi pengembang . Tidak ada cara ini bekerja dengan baik di luar kotak kecuali Anda memahami dan mengembangkan sesuatu yang dapat bekerja di semua lingkungan tanpa menghalangi pengembang dan kehilangan kepercayaan pengguna mereka jika itu muncul dalam produksi (jika pengalaman saya adalah indikasi ini akan terjadi cukup sering dan banyak yang tidak dapat menerapkan perbaikan cepat untuk mematikannya).

• Ubah faviconnya. Favicon di-cache secara mengganggu, digunakan untuk bookmark, ikon aplikasi web yang disimpan di perangkat seluler jika yang lain tidak ditentukan, dll. Ini berisiko penyebaran produksi secara tidak sengaja (atau sengaja) ke mode dev menghapus logo merek.

• Pemberitahuan peramban. Ketika Anda sedang dilihat, Anda mungkin sedang dilihat oleh pengguna. Munculnya pemberitahuan akan meminta izin browser dan muncul hal-hal aneh yang tidak akan dipahami pengguna. Asumsi bahwa ini sebagian besar akan dilihat oleh pengembang, menurut pengalaman saya, persis terbalik dan mungkin merusak kepercayaan bagi pengguna.

Bukan tugas React untuk mengasuh pengembang. Saya mengusulkan baik:

1. Jadikan mode pengembangan ikut serta. Ketika pengembang menyadari bahwa mereka tidak dapat men-debug sesuatu, mereka akan mencari cara mengaktifkannya (yang perlu didokumentasikan di mana saja ). Tidak, bukan tugas React untuk memberitahu mereka untuk mematikannya. masalah mereka.

2. Serahkan pada pesan console.log sederhana (dan ini harus dapat dinonaktifkan). Biarkan pengembang menemukannya dan menanganinya. Jika tidak, ya sudah. Anda tidak dapat menjangkau setiap organisasi dan membuat mereka melakukan sesuatu dengan benar. Hanya saja tidak terukur.

Saya harus tidak setuju dengan menyentuh DOM untuk menampilkan peringatan. Kelihatannya mudah dan sederhana untuk React karena ini adalah pustaka DOM, tetapi bayangkan jika semua pustaka harus menampilkan peringatannya sendiri di DOM. Ini akan menjadi kekacauan total.

Ada begitu banyak perpustakaan yang digunakan pengembang yang mungkin memiliki mode dev mereka sendiri. Saya pikir pengaturan process.env.NODE_ENV ke production sudah menjadi standar umum dalam bundling modul untuk browser. Inilah yang perlu kita tingkatkan kesadarannya.

Saya setuju bahwa React docs tidak secara jelas menunjukkan bahwa ada perbedaan antara dev dan produksi. Saat Anda membuka dokumen, Anda harus melalui Panduan Lanjutan untuk membaca perbedaan antara pembangunan dev dan produksi. Judulnya Mengoptimalkan Performa , sesuatu yang pasti tidak akan dilihat oleh pemula karena mereka menggunakan React karena mereka mendengar bahwa itu cepat. Saya pikir dokumen dapat ditingkatkan untuk memiliki dokumen lain berjudul "Menggunakan Bereaksi dalam Produksi" atau serupa di bagian Mulai Cepat .

Pemula biasanya tidak membaca Panduan Lanjutan tetapi mereka akan membuka beberapa tautan di Mulai Cepat jika judulnya cukup jelas dan terlihat penting. Saya tahu saya melakukannya karena itulah yang saya lakukan ketika saya mulai belajar React. Saya tidak membaca panduan memulai, tetapi saya membaca beberapa halaman di bagian Mulai Cepat.

Pendekatan lain yang bisa kita ambil adalah menunjukkan peringatan di konsol ketika React digunakan dalam mode dev dengan tautan untuk memperbaiki titik itu ke dokumen. Membuka konsol di produksi untuk pengembang tidak biasa, tetapi di env lokal saat mengembangkan mereka pasti akan membuka konsol. Dengan cara ini ketika berkembang secara lokal, mereka akan sadar bahwa mereka perlu melakukan sesuatu sebelum menerbitkan ke produksi.

http://code.gov diluncurkan meskipun ada peringatan konsol. Hal seperti inilah yang harus kita cegah. (Situs itu Angular, tetapi hal yang sama berlaku untuk Bereaksi)

Inilah masalah code.gov jika ada yang ingin menghubungi mereka (atau mengirim PR): https://github.com/presidential-innovation-fellows/code-gov-web/issues/221

Angular 2 is running in the development mode. Call enableProdMode() to enable the production mode.

Saya belum pernah menggunakan Angular 2 sebelumnya (yang membuat saya pemula dalam hal ini). Reaksi awal saya setelah saya melihat peringatan itu adalah saya hanya mencoba menelepon enableProdMode() . Ini tidak bekerja. Saya pikir pesan konsol untuk kasus Angular dapat ditingkatkan. Alih-alih mengandalkan sihir, mereka harus menunjuk ke dokumen.

Membuka dokumen Angular, saya tidak melihat apa pun tentang pembuatan produksi. Saya pikir ini adalah masalah untuk Angular dan Bereaksi. Mereka berdua menggunakan mode dev, tetapi mereka tidak memberi tahu orang-orang sebelumnya di dokumen tentang cara menonaktifkannya. Itulah mengapa meningkatkan dokumen bisa sangat membantu dalam mendidik pengembang

Saya tidak menentang menampilkan peringatan pengguna ketika pengembang membuat "kesalahan", tetapi menyuntikkan beberapa elemen DOM acak hanya mengganggu. Saya suka bagaimana browser menangani masalah HTTPS di mana browser telah mendedikasikan UI untuk menunjukkan bahwa situs tersebut tidak aman. Kami tidak memilikinya untuk status terkait kinerja. Mengingat meningkatnya kekhawatiran tentang kinerja web secara umum, saya tidak mengerti mengapa vendor browser tidak menemukan cara untuk memberi tahu pengguna bahwa situs yang mereka kunjungi menyebalkan.

Ini harus ditangani di tingkat perkakas, jadi mungkin webpack dan Babel dapat memberi tahu pengembang tentang manfaat menyetel NODE_ENV.

@pveyes Setuju, saya telah membuat poin yang sama ke tim Angular.

@matthewp ada masalah yang jauh lebih lama tentang ini https://github.com/presidential-innovation-fellows/code-gov-web/issues/129 dan tim Angular telah menghubungi mereka secara langsung dan memberi mereka perbaikan - sepertinya ada sedikit keinginan untuk menerapkannya. Pertanyaannya adalah, apakah peringatan DOM akan membuat perbaikan ini lebih mendesak, atau telah mencegahnya diluncurkan dalam mode dev untuk memulai?

Pertanyaannya adalah, apakah peringatan DOM akan membuat perbaikan ini lebih mendesak, atau telah mencegahnya diluncurkan dalam mode dev untuk memulai?

Kemungkinan besar mereka akan melihat peringatan dalam pengembangan, Google cara menonaktifkannya, dan menonaktifkannya. Kemudian menyebarkannya dalam mode dev tanpa menyadarinya di masa depan karena mereka lupa. Selama pengembangan, Anda ingin terlihat seperti produksi sehingga Anda tidak dapat memasukkan DOM secara acak. Anda tidak dapat memiliki QA atau sistem pementasan melihat ini baik karena tidak akan menjadi indikasi produksi.

Jadi Anda berakhir dengan sekelompok kode sampah yang menonaktifkan hal ini yang mengacaukan UX situs. Ini tidak seperti insinyur asli yang menonaktifkannya selama pengembangan harus ingat juga; mereka bahkan mungkin telah pindah sebelum mulai berproduksi.

Saya tidak yakin bagaimana proses penyebaran bekerja di code.gov tetapi jika itu seperti apa yang saya alami sebagai kontraktor pemerintah daripada penyebaran mode pengembangan yang tidak disengaja ke dalam produksi akan:

1. Memaksa rollback penuh dari seluruh penerapan (beberapa di antaranya membutuhkan waktu 6 bulan untuk mendapatkan persetujuan dan menggabungkan semuanya, mulai dari perubahan UI hingga pembaruan perangkat lunak server), kemungkinan pada hari berikutnya, kemudian Anda mendapatkan rapat dan dokumen tindak lanjut mengenai apa yang terjadi dan menjadwalkan jendela penerapan baru (Anda akan ditanya, berulang kali, apakah skrip atau layanan DB atau apa pun semuanya dalam mode dev karena satu peringatan di UI). Saya telah melihat ini terjadi untuk hal-hal yang sangat kecil. Terkadang Anda bisa mendapatkan pengecualian tetapi YMMV.

2. Itu akan diperhatikan oleh pengguna, itu akan diperbaiki tetapi karena kemungkinan tidak memengaruhi fungsi tidak akan diperbarui hingga jendela penerapan berikutnya. Jadi semua pengguna bisa melihatnya selama berminggu-minggu atau berbulan-bulan.

Setidaknya itu pengalaman saya. Intinya adalah, bahkan jika intrusi DOM diketahui segera setelah penerapan, Anda tidak tahu seperti apa infrastruktur/proses mereka dan itu mungkin bukan sesuatu yang dapat mereka perbaiki segera (walaupun mereka seharusnya bisa).

Pesan peringatan akan lebih terlihat ketika #7360 (kotak kuning) digabungkan. Kami juga dapat menambahkan pesan ke kotak kuning (sebut saja "React Development Mode Warnings"?).

Membuka dokumen Angular, saya tidak melihat apa pun tentang pembuatan produksi. Saya pikir ini adalah masalah untuk Angular dan Bereaksi. Mereka berdua menggunakan mode dev, tetapi mereka tidak memberi tahu orang-orang sebelumnya di dokumen tentang cara menonaktifkannya. Itulah mengapa meningkatkan dokumen bisa sangat membantu dalam mendidik pengembang

Itu tepat di halaman Instalasi:

https://facebook.github.io/react/docs/installation.html#development -and-production-versions

Dan tentang Mengoptimalkan Kinerja:

https://facebook.github.io/react/docs/optimizing-performance.html#use -the-production-build

Saya tidak berpikir adil untuk mengatakan bahwa dokumen tidak terbuka tentang hal itu.

Saat Anda membuka dokumen, Anda harus melalui Panduan Lanjutan untuk membaca perbedaan antara pembangunan dev dan produksi. Judulnya Mengoptimalkan Performa, sesuatu yang pasti tidak akan dilihat oleh pemula karena mereka menggunakan React karena mereka mendengar bahwa itu cepat. Saya pikir dokumen dapat ditingkatkan untuk memiliki dokumen lain berjudul "Menggunakan Bereaksi dalam Produksi" atau serupa di bagian Mulai Cepat.

Itu ada di sana, di halaman pertama (Instalasi):

https://facebook.github.io/react/docs/installation.html#development -and-production-versions

Kamu benar. Maaf, buruk saya. Saya berasumsi bahwa build produksi berada di bagian yang berbeda jadi saya tidak mencari di sana dan mencari judul yang relevan di sidebar (dan menemukan halaman Pengoptimalan Kinerja). Aku seharusnya tahu lebih baik.

Saya bukan pemula dalam React, itulah sebabnya ketika saya membuka dokumen untuk memverifikasi asumsi saya - bahwa React docs tidak terbuka tentang prod vs dev - saya tidak membuka dokumen Instalasi

Jangan khawatir. Jika tidak cukup terlihat saya terbuka untuk saran untuk penempatan yang lebih baik. Misalnya kita bisa membuat halaman khusus untuk itu ( Deploying to Production ).

Jangan lupa bahwa masalah ini adalah masalah penting untuk dipecahkan tetapi bukan masalah yang paling penting untuk disorot. Saya juga tidak yakin itu akan cukup bahkan jika disorot di halaman paling depan karena orang akan melihatnya dan menelusuri, melupakannya, dan berpikir "Saya tahu apa yang saya lakukan". Jadi saya tidak akan terlalu fokus pada dokumen.

Satu-satunya cara nyata untuk mengatasinya adalah dengan mendeteksi dan memberi tahu.

@KrisSiegel Favicon yang di-cache adalah poin yang bagus. Saya ingin tahu apakah kita harus menggantinya setelah satu atau dua detik dan kemudian membaliknya kembali sebentar setiap beberapa detik. Dengan begitu, masalah caching dan bookmark sangat kecil kemungkinannya untuk menghitung waktu pada saat ikon diganti.

Saya pikir manipulasi JS ke favicon tidak di-cache tapi mungkin saya salah.

Saya berpendapat bahwa tempat yang tepat untuk mengaitkan ini bukanlah Chrome atau Firefox, melainkan webpack, Browserify, atau Rollup.

Membangun apa yang dimaksudkan sebagai bundel produksi untuk React tetapi tanpa mengaktifkan mode produksi hanya itu – kesalahan build. Saya pikir alasan tidak ada kesepakatan tentang bagaimana menyajikan ini saat run time mencerminkan ini bukan masalah yang harus ditangani saat run time.

@taion saya setuju. Saya pikir ini pasti termasuk dalam alat build, bukan di DOM.

Saya pikir itu harus menjadi tempat alat build untuk membuat asumsi bahwa node env harus disetel ke produksi untuk kode produksi. Ini mungkin tidak diperlukan untuk semua proyek, tetapi saya pikir itu adalah asumsi yang bagus.

Jika npm run build dijalankan di terminal, dan env tidak disetel ke produksi, maka Anda akan mendapatkan peringatan merah di terminal bersama dengan output default: env is not set to production, some scripts may be in development mode

Saat ini saya tidak mendapatkan peringatan seperti itu dari webpack.

Sunting: klarifikasi tambahan

Atau cukup atur NODE_ENV untuk Anda, sungguh.

Jika peringatan konsol tidak berfungsi, saya tidak yakin peringatan build akan berfungsi.

Build harus mengonfigurasi sesuatu untuk Anda, atau gagal jika salah dikonfigurasi untuk produksi. Setidaknya untuk React, _is_ ini adalah flag waktu pembuatan.

@jakearchibald Saya yakin itu masih akan diabaikan oleh beberapa orang, tetapi setidaknya peringatan akan ditampilkan kepada mereka ketika mereka membangunnya, alih-alih tidak terlihat karena peringatan itu disembunyikan di konsol browser yang mungkin tidak pernah mereka buka dalam produksi . Yang terpenting, ini memberi petunjuk kepada mereka yang kurang berpengalaman tentang apa yang harus mereka lakukan untuk membuat produksi kode siap.

Sementara banyak pengembang akan memperbarui perpustakaan, biasanya tidak memperbarui webpack dan alat yang lebih umum, karena banyak orang berasumsi bahwa itu hanya berfungsi, dan mungkin sulit untuk memperbarui webpack dan rekan.

Membangun apa yang dimaksudkan sebagai bundel produksi untuk React tetapi tanpa mengaktifkan mode produksi hanya itu – kesalahan build.

Menggunakan versi paket React dari CDN juga merupakan konfigurasi yang didukung , tetapi tidak ada langkah build sama sekali dalam alur kerja itu. Oleh karena itu, solusi untuk masalah ini yang hanya berfokus pada build akan mengabaikan kasus penggunaan CDN.

Sejujurnya saya tidak yakin bagaimana perasaan saya tentang itu; Saya dapat melihat argumen yang mendukung dan menentang peringatan dev untuk penggunaan React CDN.

@taion Sebagai seseorang yang mendukung solusi build-only, menurut Anda apakah ini kasus penggunaan yang penting untuk dibahas?

Apa yang orang lain pikirkan?

Saya pikir dokumentasi di sana cukup jelas bahwa Anda harus menggunakan bundel .min.js untuk produksi. Mungkin bisa menggunakan huruf tebal, ukuran font yang lebih besar, sesuatu seperti itu. Tetapi jika seseorang menggunakan bundel React yang tidak diminifikasi dalam produksi untuk situs web mereka, mereka tetap memiliki masalah lain.

Saya pikir dokumentasi di sana cukup jelas bahwa Anda harus menggunakan bundel .min.js untuk produksi.

Setuju, tetapi halaman ini juga cukup jelas tentang cara mengonfigurasi alat build Anda untuk produksi jika Anda menyertakan React sebagai paket npm. Saya pikir inti dari masalah ini adalah mencoba menciptakan lubang kesuksesan bagi orang-orang yang tidak membaca halaman dokumentasi itu dengan cermat.

Sepertinya Anda mungkin tidak setuju, dan Anda berpikir bahwa menggunakan dev build dari CDN bukanlah kasus penting untuk dicegah dengan peringatan dev yang lebih agresif. Apakah itu ringkasan yang adil dari posisi Anda, atau apakah saya melewatkan beberapa nuansa?

Saya pikir konfigurasi CDN+dev lebih jelas salah, karena mengharuskan pengguna untuk menggunakan build React yang tidak diminifikasi. Lebih sulit untuk gagal dengan cara ini karena beban pengetahuan yang diperlukan untuk _hanya menggunakan build yang diperkecil_ lebih rendah.

Konfigurasi di mana Anda _think_ hal-hal siap produksi karena Anda telah menjalankan minifikasi di webpack atau Browserify tetapi sebenarnya Anda tidak melakukannya karena Anda tidak menyetel NODE_ENV – Anda tidak bisa mendapatkannya melalui bundel CDN.

Saya pikir tab React pada Chrome Developer Tools cukup untuk memberi tahu Jika kita berada di DEV Mode .

Saya pikir perlu dicatat bahwa ada beberapa preseden untuk kerangka kerja yang menyuntikkan elemen DOM ke halaman dalam mode dev:

http://symfony.com/blog/new-in-symfony-2-8-redesigned-web-debug-toolbar

Meskipun sejauh yang saya tahu, saya rasa ini tidak aktif secara default.

Mengikuti diskusi di atas tampaknya ada tujuan umum untuk mencapai solusi sempurna yang memenuhi semua kendala tetapi dengan andal menghentikan semua orang dari berjalan dalam mode dev ketika seharusnya tidak. OP menyatakan bahwa perlu ada pertukaran antara pengalaman potensial untuk pengembang dan pengguna, dan saya pikir ini adalah kasusnya.

Untuk mencoba menyatakan kembali masalahnya sedikit:

• Jumlah situs React yang tidak nol membuatnya berproduksi tanpa mode pengembangan dinonaktifkan
• Kami ingin mengurangi jumlah ini
• Kami tidak ingin mengganggu pengembang Bereaksi
• Kami tidak ingin menunda pendatang baru di React
• Kami tidak ingin pengguna akhir situs yang dibangun di React melihat peringatan pengembang samar
• Kami tidak ingin merusak situs karena adanya elemen DOM asing

Mengingat ini, saya pikir langkah pertama yang layak adalah untuk Bereaksi dalam mode dev untuk mengumumkan bahwa itu dalam mode dev melalui console.warn atau console.info dengan instruksi untuk memastikan ini dinonaktifkan untuk produksi penyebaran.

Tentu, ini tidak akan menarik semua orang tetapi _ini adalah awal yang baik_ yang akan mengurangi jumlah orang yang secara tidak sengaja mengirim ke produksi dan tidak menutup pintu untuk perbaikan di masa mendatang.

Mengingat ini, saya pikir langkah pertama yang layak adalah React dalam mode dev mengumumkan bahwa itu dalam mode dev melalui console.warn atau console.info dengan instruksi untuk memastikan ini dinonaktifkan untuk penyebaran produksi.

Tidak salah untuk berada dalam mode pengembangan meskipun ketika Anda sedang ... berkembang. Heuristik apa lagi yang bisa kita gunakan?

Juga, mengingat bahwa tidak ada yang membaca konsol pada produksi, saya ingin tahu apakah kita dapat memasukkan batas waktu agar dapat dicatat jika Anda menggunakan solusi pelaporan kerusakan.

Tidak salah untuk berada dalam mode pengembangan meskipun ketika Anda sedang ... berkembang. Heuristik apa lagi yang bisa kita gunakan?

Saya pikir itu harus mirip dengan pemberitahuan React DevTools saat ini

Pesan informasi yang mengingatkan Anda bahwa Anda berada dalam mode dev dan mode dev harus dinonaktifkan untuk situs produksi. Ini (dalam teori) seharusnya membuat lebih banyak pengembang sadar bahwa ada perbedaan dan beberapa tindakan perlu diambil untuk mempersiapkan penggunaan produksi.

Seperti yang Anda katakan, hampir tidak ada yang akan melihat peringatan konsol dalam produksi aktual - dan pada saat itu sudah agak terlambat.

Maaf terdengar seperti rekaman macet, tetapi peringatan konsol tampaknya tidak berfungsi. Misalnya https://code.gov.

Maaf terdengar seperti rekaman macet, tetapi peringatan konsol tampaknya tidak berfungsi. Misalnya https://code.gov.

Sebuah counter-instance tunggal menunjukkan bahwa itu tidak sempurna - tetapi saya tidak berpikir pendekatan apa pun akan sempurna.

Jika peringatan konsol mampu meningkatkan kesadaran dan mengurangi jumlah orang yang salah menjalankan mode dev padahal seharusnya tidak, maka ini sepertinya langkah ke arah yang benar. Sempurna adalah musuh kebaikan.

@jakearchibald

Ya, tetapi jika alat pembuatan code.gov diatur dengan kait di sini, maka _would_ telah mencegah masalah yang Anda amati, setidaknya dalam konteks Bereaksi yang menggunakan kait waktu pembangunan untuk ini. Mereka menggunakan webpack.

Saya tidak mengatakan bahwa webpack harus mengeluarkan peringatan build. Saya mengatakan bahwa perbaikan yang tepat adalah bahwa baik webpack menetapkan process.NODE_ENV untuk Anda, atau webpack itu gagal membangun secara default jika Anda mencoba membuat build produksi tanpa konfigurasi produksi yang sesuai.

Ingin cepat menanggapi poin sebelumnya dari @addyosmani tentang "pelanggaran" DevTools. Kami membuat prototipe yang menunjukkan indikasi kesalahan tertentu yang lebih kuat di Chrome DevTools, tetapi pekerjaan ini masih cukup awal, dan saya cenderung setuju dengan @jakearchibald bahwa menampilkan peringatan (meskipun lebih menakutkan daripada console.warn ) tidak solusi yang cukup baik.

Bagaimana dengan default Bereaksi ke mode produksi dan mengaktifkan mode pengembangan jika dan hanya jika NODE_ENV == 'development' atau nama host adalah localhost / 127.0.0.1 ? Sebagian besar pengembang akan mendapatkan perilaku yang benar di luar kotak dan akan selalu ada cara untuk memaksa mode pengembangan secara manual jika Anda benar-benar membutuhkannya.

Tampaknya kurang ideal untuk tetap memukul cabang itu dengan kondisi yang mungkin cukup rumit (karena Anda tidak hanya harus gagal di Node) sepanjang waktu.

BTW, -p (mode "produksi", yang juga memungkinkan minifikasi dengan pengaturan default) di webpack 2 set NODE_ENV untuk pengguna: https://webpack.js.org/guides/production-build /#simpul -variabel-lingkungan.

Ini tampaknya cukup masuk akal bagi saya, dan seharusnya mencegah masalah ini untuk hampir semua orang yang menggunakan webpack. Mengapa desakan untuk menangani semua ini saat dijalankan?

BTW, -p (mode "produksi", yang juga memungkinkan minifikasi dengan pengaturan default) di webpack 2 set NODE_ENV untuk pengguna: https://webpack.js.org/guides/production-build/#node -environment-variable.

Ya. Kami sadar akan hal ini. @TheLarkInn dari Webpack core dapat mengonfirmasi dengan pasti, tetapi pemahaman saya adalah bahwa -p tidak banyak digunakan di atm komunitas Webpack. Masalah mendasar di sini juga adalah jika ada solusi yang ikut serta, mirip dengan status quo saat ini dengan peringatan console.log, kami tidak akan melihat perubahan nyata bagi pengguna React. Kami ingin memberi orang perubahan yang lebih baik dalam mengirimkan barang 'cepat'.

Perlu disebutkan secara sepintas bahwa kurangnya kemampuan untuk dengan mudah mendeteksi lingkungan DEV dan PROD di Webpack (-p tidak mencukupi) juga menyebabkan kami kesulitan di https://github.com/webpack/webpack/issues/3216 .

Saya mengatakan bahwa perbaikan yang tepat adalah webpack menyetel process.NODE_ENV untuk Anda, atau webpack itu gagal membangun secara default jika Anda mencoba membuat build produksi tanpa konfigurasi produksi yang sesuai.

Saya siap untuk mengejar ini, tetapi ini akan menjadi perubahan besar untuk Webpack dari apa yang saya tahu. Saya pribadi merasa seperti solusi runtime yang melibatkan pesan overlay yang jelas _only_ ditampilkan menggunakan beberapa heuristik cerdas (localhost, DevTools open dll) akan mencakup kita secara memadai.

Yang mengatakan, saat kami terus berputar kembali ke proses Webpack.NODE_ENV item, saya ingin tahu apakah @sokra atau @TheLarkInn punya pendapat tentang yang satu ini.

Pemahaman saya berbeda dengan pemahaman Anda – saya percaya bahwa -p adalah cara de facto yang sebagian besar pengguna non-ahli webpack menyiapkan build produksi.

Bahkan paket terkemuka menggunakan -p untuk menghasilkan build produksi:
https://github.com/ReactTraining/react-router/blob/5e69b23a369b7dbcb9afc6cdca9bf2dcf07ad432/package.json#L23
https://github.com/react-bootstrap/react-bootstrap/blob/61be58cfdda5e428d8fb11d55bf743661bb3f0b1/tools/dist/build.js#L10

Sangat jarang untuk secara langsung mengonfigurasi plugin Uglify di webpack, jadi tanpa -p , orang akan menggunakan build yang tidak diperkecil, dalam hal ini mereka memiliki masalah yang lebih besar.

Saya pribadi merasa seperti solusi runtime yang melibatkan pesan overlay yang jelas hanya ditampilkan menggunakan beberapa heuristik cerdas (localhost, DevTools open dll) akan mencakup kita secara memadai.

Saya merasa seperti ini telah ditembak jatuh beberapa kali ("Tidak dapat diterima untuk kerangka kerja untuk menyuntikkan sesuatu ke dalam DOM") tanpa benar-benar menghargai skenario _only_ di mana ini akan terjadi.

Saya setuju dengan Anda bahwa harus mengatasi pesan permanen dan hal-hal tak terduga di DOM terus-menerus selama pengembangan tidak dapat diterima. Apa yang kami sarankan di sini, adalah pesan yang ditampilkan jika dan _only_ jika DevMode disebarkan ke produksi (masukkan heuristik!). Sejumlah pemeriksaan dan pesan konsol yang berubah-ubah dapat dibuat ke dalam perkakas, CI, dan ekstensi browser untuk mencegah hal itu terjadi.

Tetapi sebagai upaya terakhir yang gagal, saya pikir spanduk yang terlihat di layar adalah solusi yang baik dan tepat.

ditampilkan jika dan hanya jika DevMode dikerahkan ke produksi (masukkan heuristik!)

Jadi pengembang tidak akan pernah melihat pesan ini, menyebarkan (mungkin secara tidak sengaja) mode dev ke dalam produksi dan tiba-tiba mereka melihat HTML baru ini ditampilkan di aplikasi mereka untuk dilihat semua pengguna?

Itu lebih terdengar seperti hukuman bagiku. Jika Anda belum memahami mode dev dan Anda menerapkan menggunakan versi baru dari React dengan pesan ini, maka Anda akan mendapatkan kejutan dan pengguna Anda di aplikasi web pada saat itu juga dapat melihatnya. Saya gagal melihat bagaimana ini membantu siapa pun selain mempermalukan pengembang atau perusahaan. Tentu, mungkin itu akan membuat mereka memperbaikinya, tetapi biaya itu menurut saya terlalu tinggi dan kurang empati.

Tetapi sebagai upaya terakhir yang gagal, saya pikir spanduk yang terlihat di layar adalah solusi yang baik dan tepat.

Masalah dengan solusi ini adalah terlalu idealis dan ketika Anda mengembangkan kerangka kerja, Anda harus fokus pada kenyataan bahwa perusahaan lain mungkin tidak memiliki kebijakan penerapan terbaik atau bahkan QA terbaik (jika ada).

Ya, jika seseorang menyebarkan ke mode dev dalam produksi, mereka harus dapat melihatnya dan mengubahnya dengan cepat. Sayangnya, terutama di luar industri teknologi, hal ini tidak mungkin atau tidak mudah . Mayoritas orang berkomentar di sini? Kemungkinan perusahaan mereka memiliki proses penyebaran yang dapat mengatasi skenario ini dengan baik. Google, Facebook, PlayStation, dll; semua perusahaan teknologi ini dapat menangani masalah ini dengan baik tetapi ini tidak mewakili sebagian besar pengguna yang menggunakan React, bukan? (sebenarnya, apakah kami memiliki statistik mengenai penggunaan React? Akan berguna!)

Ya, ya, perusahaan dan pemerintah ini harus mengubah proses dan kebijakan penyebaran mereka, dll. Tetapi kenyataannya adalah ini: sebagian besar perusahaan memiliki proses penyebaran omong kosong dan omong kosong untuk QA yang tidak ada.

Mari kita ambil dua skenario yang saya alami secara pribadi.

Pertama , saat bekerja di pemerintahan, tergantung pada cabang dan departemen, Anda mungkin memiliki satu penempatan setiap 3-6 bulan. Penerapan ini menggulung sebanyak mungkin hal dan jika ada bagian dari seluruh penerapan yang gagal, semuanya dapat dibatalkan. Jadi kami menggunakan perangkat lunak yang disebut OWF yang, jika Anda tidak terbiasa, seperti iSocial yang menampilkan beberapa aplikasi web dalam satu aplikasi web menggunakan iframe (kotor, saya tahu, tapi tetap bersama saya di sini). Ada langkah konfigurasi manual dalam penerapan beberapa aplikasi kami yang gagal yang menyebabkan kesalahan 404 dan 500 ditampilkan di beberapa iframe alih-alih aplikasi yang dimaksud.

Karena pengembang biasanya tidak memiliki akses ke sistem yang dikerahkan ke dalamnya, butuh berjam-jam sebelum kami menemukan masalah apa pun. Pada saat itu kami harus meminta bos kami untuk menelepon bos orang lain untuk menelepon bos mereka untuk memberi tahu mereka bahwa itu tidak memengaruhi hal lain sehingga mereka tidak akan membatalkan seluruh penempatan. Kemudian kami memiliki banyak dokumen dan dokumentasi untuk diisi sebelum kami dapat meminta siapa pun untuk mengulang beberapa konfigurasi beberapa hari kemudian. Sementara itu aplikasi duduk, tidak dapat berfungsi, selama seluruh periode waktu itu.

Kedua , ketika saya bekerja di bidang keuangan, kami melakukan penyebaran yang secara tidak sengaja menyertakan nama pengembang sebagai pengganti tata letak item yang sebenarnya di situs web (saya yakin dia sedang menguji sesuatu?). Bagaimanapun, itu segera diketahui tetapi untuk memperbaikinya, kami harus mendapatkan kontrol perubahan darurat yang memakan waktu hingga hari itu. Jadi pelanggan mereka harus melihat spanduk bodoh ini selama hampir 8 jam penuh sebelum diperbaiki.

Maksud saya adalah: perlu sangat hati-hati saat menyuntikkan elemen arbitrer ke dalam DOM yang tidak diletakkan oleh pengembang di sana. Terutama jika kita berbicara tentang hanya menampilkannya dalam beberapa skenario, maka pertama kali seseorang melihatnya, mereka akan mencari cara untuk menonaktifkannya dengan cepat sehingga mereka tidak perlu diganggu lagi.

@KrisSiegel

Jika Anda belum memahami mode dev dan Anda menerapkan menggunakan versi baru dari React dengan pesan ini, maka Anda akan mendapatkan kejutan dan pengguna Anda di aplikasi web pada saat itu juga dapat melihatnya.

Saya ingin tahu apakah pemikiran Anda tentang pendekatan ini berbeda jika pesan hanya ditampilkan saat DevTools terbuka (yaitu sesuatu yang kemungkinannya kecil untuk dilihat oleh pengguna produksi yang bukan pengembang). Secara efektif merupakan perluasan dari strategi console.log saat ini yang telah digunakan React saat ini.

Saya ingin tahu apakah pemikiran Anda tentang pendekatan ini berbeda jika pesan hanya ditampilkan saat DevTools terbuka (yaitu sesuatu yang kemungkinannya kecil untuk dilihat oleh pengguna produksi yang bukan pengembang). Secara efektif merupakan perluasan dari strategi console.log saat ini yang telah digunakan React saat ini.

Jika Anda memiliki alat dev terbuka maka Anda mungkin melihat pesan console.log sehingga perubahan DOM tampak seperti kerumitan yang tidak perlu untuk dikelola plus itu berlebihan. Anda selalu dapat membuat pesan konsol React lebih besar/lebih menarik. Mungkin logo ASCII React. Sesuatu untuk menarik perhatian seseorang jika mereka kebetulan masuk ke sana.

Pada akhirnya meskipun saya pikir seseorang akan mengalami ini, tanyakan di Stackoverflow cara menonaktifkan peringatan, seseorang akan memposting kode yang menunjukkan kepada mereka bagaimana melakukannya, maka orang hanya akan menonaktifkannya jika mereka mengalaminya. Alat pembuatan sangat banyak dan banyak orang yang saya ajak bicara di masa lalu menganggapnya membingungkan atau sulit (rilis Babel 6 adalah waktu yang "menyenangkan"). Anda akan bertemu dengan banyak orang yang tidak pernah menggunakannya dengan benar.

Setidaknya itulah pengalaman saya \_(ツ)_/¯

Wah, akhirnya sampai ke dasar thread. Oke. Saya telah melakukan brainstorming ini sedikit.

Webpack dapat memaksa untuk menentukan NODE_ENV yang kemudian dapat digunakan oleh React untuk menghindari pengiriman DEV ke PROD dengan lebih mudah, tetapi itu akan menjadi perubahan besar pada Webpack. Saya sedang berbicara dengan Sean sekarang tentang seberapa layak hal seperti itu untuk Webpack 3. Menjaga agar React + Webpack stack pemula dan ramah kinerja adalah sesuatu yang saya tahu diperhatikan oleh kedua kubu.

Ini terasa seperti favorit saya sejauh ini tetapi saya belum 100% terjual.

1. Jadi dapat menegakkan bahwa ENV diteruskan setiap kali ada yang menjalankan webpack. Pesan kesalahan yang membantu menyatakan bahwa Anda harus menyediakan variabel env untuk menjalankan webpack.

Namun ini memberikan titik bouncing yang signifikan bagi pengguna. Tidak semua orang menulis untuk prod atau dev env atau bahkan tahu apa itu env. Saya akan mengangkat masalah di webpack/webpack untuk mendapatkan umpan balik tentang ini, karena firasat saya adalah bahwa tidak semua orang akan menginginkan ini dan apakah saya setuju atau tidak, kita harus mempertimbangkan pushback.

1. <something in-between 1 and 3 I haven't figured out yet>

2. Solusi webpacky adalah membuat plugin mandiri yang dapat terhubung ke siklus hidup kompiler, memeriksa apakah kode sedang dihapus, atau jika ENV tidak disediakan, dan memancarkan peringatan ramah atau kesalahan pilihan Anda.

Namun saya dapat membayangkan responsnya adalah "Tetapi pengguna tidak akan pernah tahu bagaimana melakukannya, dll." Demikian CRA, demikianlah isu ini sekarang.

Kita bisa membuat pola resolver baru yang akan memeriksa package.json React (atau fw apa pun yang membutuhkannya) untuk sesuatu seperti di bawah ini:

"webpack": {
  "plugin": "ReactEnviornmentPlugin"
}

yang secara otomatis akan diterapkan ke konfigurasi kompiler pengguna tanpa mereka perlu tahu atau peduli.

Sekali lagi hanya benar-benar brainstorming.

@TheLarkInn Saya pikir perilaku -p saat ini di webpack 2 sudah cukup, bukan? Satu-satunya kasus kegagalan adalah jika seseorang mengatur UglifyJsPlugin sendiri dan lupa melakukannya DefinePlugin , tetapi itu sepertinya kasus yang jauh lebih kecil kemungkinannya.

@taion Ya/Tidak

-p hanya menerapkan "perlakuan" produksi ke kode Anda, namun kami tidak membuat asumsi tentang dan/atau memiliki pengetahuan tentang apa yang diatur untuk NODE_ENV . Inilah yang memunculkan kebutuhan orang untuk menggunakan DefinePlugin() .

Tapi saya pikir itu adalah area "_reasonable_" terdekat dengan _guess_ atau _imply_ bahwa pengguna menjalankan kode mereka dalam ENV produksi. Itu akan menjadi satu area yang kami ingin pastikan komunitas dan tim baik-baik saja.

@TheLarkInn Saya percaya ini berubah di v2: https://webpack.js.org/guides/production-build/#node -environment-variable

Ah maaf itu benar aku salah. Namun itu tidak sering digunakan karena orang menginginkan kontrol yang lebih halus atas apa yang mereka optimalkan. (Seperti yang disebutkan @addyosmani )

Apakah itu benar-benar umum? Ketika saya memulai dengan webpack, -p jelas tampak seperti cara yang harus dilakukan. Seperti yang saya rujuk di atas, bahkan perpustakaan dengan banyak alasan untuk menerapkan tweak lebih lanjut masih menggunakan -p .

Kita bisa membuat pola resolver baru yang akan memeriksa package.json React (atau fw apa pun yang membutuhkannya) untuk sesuatu seperti di bawah ini:

"paket web": {
"plugin": "ReactEnviornmentPlugin"
}
yang secara otomatis akan diterapkan ke konfigurasi kompiler pengguna tanpa mereka perlu tahu atau peduli.

@TheLarkInn jika saya membaca ini dengan benar, untuk memicu pola resolver, package.json aplikasi perlu menentukan ReactEnvironmentPlugin secara manual, bukan? Atau apakah saya salah memahami proposal? :)

Saya dapat membayangkan beberapa keajaiban resolusi di Webpack yang mendeteksi sebuah proyek menggunakan React dan melakukan peralihan lingkungan yang tepat untuk mereka, tetapi kedengarannya seperti penggabungan erat dari pengoptimalan khusus kerangka kerja ke bundler dan mungkin tidak seperti yang diinginkan.

Lebih sedikit yang akan mendeteksi reaksi, dan lebih banyak lagi yang akan mendeteksi bidang deskripsi modul js menyertakan bidang webpack dengan plugin. Tapi Anda benar, itu sangat erat dan juga bukan ide favorit saya.

Saya tidak berpikir ini benar-benar memberi Anda jaminan apa pun kecuali webpack memiliki konsep mode "produksi" untuk mengetahui cara mengonfigurasi React - dan ini tampaknya berlebihan mengingat, seperti yang dibahas di atas, -p sudah melakukan yang benar hal, dan itulah yang biasanya akan dicapai pengguna saat membuat build produksi yang diperkecil dengan webpack.

Kami telah membicarakan hal ini lebih banyak dan saya pikir ada solusi yang masuk akal.

Kami telah lama mempertimbangkan untuk mengaktifkan "kotak peringatan" untuk Bereaksi peringatan dalam pengembangan. Anda dapat melihat demo di sini (PR: https://github.com/facebook/react/pull/7360). Itu hanya muncul ketika Anda memiliki peringatan tetapi itu sangat umum selama pengembangan (dan harus selalu diperbaiki), jadi mungkin siapa pun yang menghabiskan lebih dari lima menit mengembangkan aplikasi akan melihat dialog dan menyadari bahwa itu ada.

Setelah perubahan ini, akan lebih sulit untuk tidak menyadari mode pengembangan. Anda mungkin akan mencari "cara menghapus dialog peringatan" dan belajar tentang membangun untuk produksi. Jika tidak, Anda kemungkinan akan mendapatkan beberapa peringatan yang diterapkan di beberapa titik, dan pengguna Anda akan melihatnya. Saya pikir dalam hal ini orang tidak akan menyalahkan React semata karena kami tidak hanya menunjukkan kotak itu menjengkelkan—kami hanya melakukan apa yang seharusnya dilakukan oleh mode pengembangan.

(Omong-omong, kami telah menggunakan kotak peringatan serupa dalam pengembangan di Facebook untuk waktu yang lama sehingga sesuai dengan bagaimana kami ingin React digunakan.)

Saya sangat senang melihat proposal itu, @gaearon! Ini semua yang saya impikan;)

Sebagai tambahan: Mungkin ada baiknya mempertimbangkan untuk memiliki tautan langsung di dalam kotak agar tidak mengharuskan pengembang ke Google untuk cara menghilangkannya.

Ya, poin yang bagus. Kami akan menambahkan sesuatu.

@gaearon Saya menemukan solusi itu sangat menjengkelkan; Saya tidak akan pernah ingin peringatan menyerang DOM bahkan selama pengembangan. Itu tidak memiliki tujuan untuk pengembang umum dan kemungkinan akan dinonaktifkan sepenuhnya oleh sebagian besar. Alat pengembang menampilkan peringatan karena suatu alasan, mereka tidak perlu ditemukan.

Saya juga merasa terganggu bahwa solusi DOM terus muncul tanpa bantahan terhadap argumen saya sebelumnya yang menentangnya. Jika poin saya diabaikan maka baiklah, ini bukan repositori saya jadi itu cukup adil, tetapi mengecewakan melihat argumen yang sama muncul, orang-orang memposting menentangnya, orang-orang tampaknya mendukung poin karena tidak pernah ada argumen yang menentang mereka , lalu mereka langsung muncul kembali. Bilas, ulangi.

Meskipun saya setuju bahwa ini benar tentang sebagian besar peringatan, peringatan Bereaksi secara khusus menunjukkan bug dalam kode Anda. Mereka bukan hanya saran.

Dialog mudah untuk diabaikan dan peringatan individu mudah untuk ditunda (jika Anda tidak mempedulikannya untuk sementara waktu) tetapi mereka perlu diperbaiki.

Sebagai perbandingan, inilah tampilan dialog di basis kode Facebook:

Ribuan insinyur tidak memiliki masalah dengannya dan lebih produktif berkatnya, jadi kami pikir ini adalah default yang masuk akal. Untuk lebih jelasnya, versi open source akan lebih sedikit berteriak:

Jika Anda memiliki saran tentang perubahan gaya, silakan beri komentar di https://github.com/facebook/react/pull/7360.

Menambahkan apa yang Dan katakan, saya sedang membangun di atas #7360 untuk menghubungkan ke aliran logger kesalahan kami yang baru saja ditambahkan. Saat ini saya sedang mencoba beberapa gaya pemberitahuan roti panggang yang sedikit kurang mengganggu. Saya akan segera memposting beberapa tangkapan layar dan/atau Plnkr untuk umpan balik.

Apakah peringatan ini akan menyertakan peringatan "kode dev yang diperkecil"? Itu akan menyelesaikan banyak hal dengan cukup rapi jika demikian.

Saya tidak mengerti mengapa itu juga tidak dapat digunakan untuk tujuan itu.

@gaearon

Meskipun saya setuju bahwa ini benar tentang sebagian besar peringatan, peringatan Bereaksi secara khusus menunjukkan bug dalam kode Anda. Mereka bukan hanya saran.

Itu seharusnya kesalahan atau pengecualian IMO. Mengapa mereka tidak? Pengecualian memaksa hal-hal untuk diperbaiki tetapi peringatan yang dapat diabaikan tidak.

Ribuan insinyur tidak memiliki masalah dengannya dan lebih produktif berkatnya, jadi kami pikir ini adalah default yang masuk akal.

Saya menyebutkan ini di poin sebelumnya tetapi saya kira para insinyur itu kemungkinan lebih baik daripada 90% orang yang akan menggunakan versi open source. Saya menemukan kebalikan dari default yang masuk akal. Ada alasan mengapa alat pengembangan memiliki peringatan; menciptakan kembali mereka tidak masuk akal bagi saya. Itu akan dinonaktifkan dan tidak pernah terlihat lagi.

Sepertinya React mencoba melakukan terlalu banyak IMO.

Ketika saya melakukan kontrak pemerintah, kami memiliki perpustakaan umum yang harus digunakan semua ujung depan. Itu akan mengambil kesalahan di konsol dan menampilkannya sebagai roti panggang yang muncul. Tidak hanya itu disebarkan ke produksi beberapa kali oleh banyak tim, tetapi banyak pengembang melihatnya sekali kemudian bertanya bagaimana cara menonaktifkannya secara permanen. Saya melihat ini sebagai lebih dari sama.

Kami telah lama mempertimbangkan untuk mengaktifkan "kotak peringatan" untuk peringatan Bereaksi dalam pengembangan. Anda dapat melihat demo di sini (PR: #7360). Itu hanya muncul ketika Anda memiliki peringatan tetapi itu sangat umum selama pengembangan (dan harus selalu diperbaiki), jadi mungkin siapa pun yang menghabiskan lebih dari lima menit mengembangkan aplikasi akan melihat dialog dan menyadari bahwa itu ada.

Saya sangat suka #7360, @gaearon. Sangat menggembirakan mendengar dukungan untuk menyoroti kebutuhan untuk beralih ke PROD untuk penerapan di kotak peringatan baru. Ini bagus dan visual.

Menambahkan apa yang Dan katakan, saya sedang membangun di atas #7360 untuk menghubungkan ke aliran logger kesalahan kami yang baru saja ditambahkan. Saat ini saya sedang mencoba beberapa gaya pemberitahuan roti panggang yang sedikit kurang mengganggu. Saya akan segera memposting beberapa tangkapan layar dan/atau Plnkr untuk umpan balik.

@bvaughn Menantikan untuk melihat lebih banyak iterasi Anda :)

Untuk orang-orang yang merasa pendekatan kotak peringatan mungkin terlalu mengganggu, perpustakaan lain (misalnya VueJS) sudah menampilkan overlay DOM selama alur kerja dev/iterasi Anda untuk mendorong perbaikan bug atau jalur lambat:

Pengalaman saya sendiri adalah bahwa meskipun ini merupakan ketidaknyamanan kecil, pesan-pesan ini lebih jelas daripada yang mungkin Anda lihat di konsol. Saya merasa Dan benar bahwa itu setidaknya akan lebih menekankan pada mode dev bukan menjadi sesuatu yang harus Anda terapkan ke prod dan mudah-mudahan akan mengarah ke lebih banyak situs yang mengirimkan "mode lebih cepat" ke pengguna akhir mereka.

Setelah perubahan ini, akan lebih sulit untuk tidak menyadari mode pengembangan. Anda mungkin akan mencari "cara menghapus dialog peringatan" dan belajar tentang membangun untuk produksi. Jika tidak, Anda kemungkinan akan mendapatkan beberapa peringatan yang diterapkan di beberapa titik, dan pengguna Anda akan melihatnya. Saya pikir dalam hal ini orang tidak akan menyalahkan React semata karena kami tidak hanya menunjukkan kotak itu menjengkelkan—kami hanya melakukan apa yang seharusnya dilakukan oleh mode pengembangan.

Itu seharusnya kesalahan atau pengecualian IMO. Mengapa mereka tidak? Pengecualian memaksa hal-hal untuk diperbaiki tetapi peringatan yang dapat diabaikan tidak.

Sementara mereka harus diperbaiki, saya mungkin memiliki masalah yang lebih mendesak. Misalnya apakah saya sering membuat prototipe/mengolok-olok UI dan saat melakukan itu saya menulis kode cepat dan biasanya di bawah standar yang dapat diperingatkan oleh React. Meskipun saya ingin memperbaiki peringatan itu, saya tidak terlalu peduli sampai saya tahu bahwa saya tidak akan membuang semua kode setidaknya dalam satu jam ke depan. Memaksa orang untuk memperbaikinya secara instan akan secara drastis memperlambat pengembangan eksperimental.

Untuk orang-orang yang merasa pendekatan kotak peringatan mungkin terlalu mengganggu, perpustakaan lain (misalnya VueJS) sudah menampilkan overlay DOM selama alur kerja dev/iterasi Anda untuk mendorong perbaikan bug atau jalur lambat:

tangkapan layar 24-01-2017 pukul 10 57 11 pagi

Apakah Anda yakin itu dari Vue sendiri? Ini terlihat sangat mirip dengan kesalahan pembuatan webpack yang ditampilkan dengan hamparan kesalahan dari webpack-hot-middleware . Jika ini masalahnya, ini agak berbeda karena ini adalah alat pembangunan waktu-pengembangan yang menambahkan overlay daripada kerangka kerja frontend tujuan umum.

Secara umum saya mendukung overlay peringatan, tetapi saya pikir itu harus berisi teks penjelasan di atasnya yang mengatakan apa itu, mengapa itu ada, dan itu dapat & harus dinonaktifkan sebagai bagian dari mematikan mode dev. Di belakang expando jika itu agak panjang - tetapi sepertinya tempat yang bagus untuk menyampaikan pesan.

Saya takut pembaruan seperti 15.2.0 dengan overlay. benjolan kecil dan tiba-tiba Anda memiliki 100-an peringatan tentang props yang diteruskan ke node DOM. kesalahan mungkin, tapi saya tidak berpikir peringatan penyusutan termasuk dalam ruang yang mengganggu

kesalahan mungkin, tapi saya tidak berpikir peringatan penyusutan termasuk dalam ruang yang mengganggu

Saya tidak tahu apakah ini telah dikomunikasikan dengan sangat jelas sebelumnya, tetapi gagasan tentang peringatan kotak kuning (#7360) bukanlah untuk menampilkan _all_ warnings (penghentian atau lainnya). Sebaliknya, peringatan tertentu yang dianggap tim _sangat penting_ akan disorot dengan cara ini. Sisanya mungkin akan tetap berada di konsol.

Setidaknya itulah yang saya ambil dari percakapan saya dan Tom tentang fitur ini satu atau dua minggu yang lalu.

Peringatan prop di 15.2 juga merupakan kesalahan IMO dan bukan indikasi MO normal kami. Kami ingin memiliki cara untuk mengontrol level peringatan dengan versi minor untuk menghindarinya.

Alasan utama tim kami tidak menggunakan build produksi adalah karena kami tidak dapat menjalankan pengujian unit JS, karena utilitas pengujian tidak disertakan.

Pertama, terima kasih lagi kepada tim React ( @sebmarkbage , @gaearon , @tomocchino dan lainnya) untuk mendiskusikan masalah ini dengan kami dan sangat terbuka untuk berbicara dengan kami tentang kinerja & seluler di BlinkOn dan sinkronisasi lainnya kuartal ini.

Pemeriksaan status

Per @aweary di https://github.com/facebook/react/pull/7360 , solusi Kotak Kuning untuk masalah khusus ini telah ditunda hingga pekerjaan V16 prio tinggi React selesai tetapi masih harus dilakukan. https://github.com/facebook/fbjs/pull/165 perlu mendarat dan diimplementasikan di Fiber. API publik yang baik untuk mengekspos kait juga perlu dibuat. Akan menjaga jariku

Masalah ini tampaknya masih lazim

Beberapa aplikasi produksi yang muncul di meja saya masih mengirimkan mode DEV ke produksi. Kita dapat melihat string debug When deploying React apps to production dalam build mereka di sini:

https://cdnjs.cloudflare.com/ajax/libs/react/15.3.1/react.js (tombraider.com)
https://shared.reliclink.com/dlls/vendor-f3e016f6037eb107ffc0.live-shared.min.js (dawnofwar.com)
https://d1xx3pvec9nqb7.cloudfront.net/media/js/thread.af65c1a02d15.js (thread.com)
http://www.sothebys.com/etc/designs/redesigns/sothebys/redesignlibs.min.js (sothebys.com)

Saya masih berpandangan bahwa pra-Kotak Kuning pindah ke logging peringatan mode DEV ke konsol untuk hal di atas mungkin berdampak. Saran Sebastian untuk melemparkan kesalahan konsol sehingga pelaporan kerusakan mungkin mengambilnya juga merupakan sesuatu yang saya rasa perlu dipertimbangkan.

Apa lagi yang bisa kita lakukan untuk memindahkan jarum ke sini?

Advokasi yang lebih baik? Saya senang berkomitmen untuk terus mengadvokasi orang-orang yang tidak mengirimkan mode DEV ke produksi, tetapi ingin melihat apakah kami dapat mendapatkan solusi resmi pasca V16 :)

Dalam jangka pendek, sepertinya create-react-app berada di tempat yang baik untuk membantu proyek baru menghindari masalah ini.

Perbaikan pada dokumen instalasi

Untuk semua orang, apakah akan ada dukungan untuk https://facebook.github.io/react/docs/installation.html termasuk pemanggilan yang jelas dan terlihat di bawah judul Installing React yang mengingatkan orang-orang untuk memperhatikan mode DEV di produksi?

Sebagai pengguna, saya tidak merasa ada insentif besar bagi saya untuk membaca https://facebook.github.io/react/docs/installation.html#development -and-production-versions pada pandangan pertama sebaliknya.

Pikiran?

Alasan utama tim kami tidak menggunakan build produksi adalah karena kami tidak dapat menjalankan pengujian unit JS, karena utilitas pengujian tidak disertakan.

Saya bingung tentang ini. Apakah Anda menjalankan tes di situs web produksi? Jika tidak, apa yang mencegah Anda menggunakan produksi di situs web produksi, dan pengembangan dalam pengembangan?

Untuk semua orang, apakah akan ada dukungan untuk https://facebook.github.io/react/docs/installation.html termasuk keterangan yang jelas dan terlihat di bawah judul Instalasi Bereaksi yang mengingatkan orang-orang untuk memperhatikan mode DEV dalam produksi?

Tentu. Mau kirim PR?

Tentu. Mau kirim PR?

Lebih dari senang.

Mungkin kata tentang benchmark akan menyenangkan juga untuk membantu mendidik mereka yang membandingkan kinerja dengan reaksi dalam mode dev ?

Membuat saya berpikir ekstensi react devtools dapat dimanfaatkan untuk menampilkan pemberitahuan atau sesuatu yang jelas saat membuka halaman menggunakan reaksi dalam mode dev mungkin?

Aku suka ide ini! Saya mengumpulkan satu set ikon yang diusulkan untuk devtools (lihat facebook/react-devtools/pull/652).

Kita perlu memutuskan bagaimana mendeteksi dev vs prod React dengan cara yang mundur dan aman di masa depan, tetapi saya telah menambahkannya ke agenda rapat hari Senin.

Kami telah melakukan beberapa langkah yang wajar untuk mengatasi masalah ini:

• React DevTools (dengan ~700 ribu pengguna) sekarang menampilkan ikon merah khas untuk build pengembangan. Ini membantu orang belajar tentang perbedaan antara versi lebih awal. Ini juga menciptakan beberapa tekanan rekan, karena pengembang memperhatikan ini di situs yang mereka kunjungi, dan melaporkan kepada orang-orang yang mengerjakannya. Kami telah melihat beberapa situs besar memperbaiki masalah ini dalam beberapa hari setelah peluncuran ini.

• Pemberitahuan di React DevTools tertaut ke situs web kami tempat kami menerbitkan instruksi untuk membuat build produksi untuk semua bundler utama . Kami juga membuatnya lebih menonjol di halaman instalasi .

• Create React App terus mendapatkan popularitas. Ini mengajarkan perbedaan ini lebih awal dengan perintah terpisah. Ini juga menampilkan pemberitahuan permanen tentang mode pengembangan di terminal.

• React 16 Beta 1 (dan rilis selanjutnya) dikirimkan dengan react.development.js dan react.production.min.js sebagai nama file untuk memperjelas bahwa build yang tidak diperkecil tidak boleh digunakan dalam produksi.

Saya pikir di masa depan kita mungkin mencari lebih banyak cara untuk memecahkan masalah ini, tetapi untuk saat ini saya merasa kita dapat bergerak maju tanpa tindakan yang lebih drastis, dan melihat apakah itu membantu. Terima kasih untuk semua orang atas diskusinya.