Bereaksi Asli dari perspektif pengembang seluler

Artikel ini ditujukan untuk pengembang iOS dan android yang sudah cukup berpengalaman di bidangnya dan melirik React Native.

Ketika saya pertama kali belajar tentang React Native, saya menganggapnya sebagai kesempatan bagi pengembang web untuk menginvasi wilayah saya ( benar-benar mustahil! ) Dan pada saat yang sama merusak produk crash-free-60-fps yang berfungsi dengan baik. Dan begitulah yang terjadi. Akhirnya Kisah sebenarnya ternyata lebih panjang.

Bantahan

JavaScript dalam aplikasi seluler? Hanya beberapa perpustakaan dengan penggunaan JavaScriptCore di iOS yang muncul di benak saya (perpustakaan yang sama ini menyumbang 90% dari kerusakan aplikasi yang digunakannya) dan aplikasi hibrida dari "model lama" (well, itu atas)

Aplikasi hibrida menunjukkan harapan hingga saat Anda mencobanya, setelah itu Anda mulai melarikan diri darinya dan sejauh mungkin.

Mengingat upaya yang gagal untuk mempelajari Xamarin 3 tahun yang lalu, saya segera meninggalkan ide menggunakan React Native.

Perlu dicatat bahwa saya selalu senang melihat cara-cara baru dalam menulis aplikasi asli (dari ObjC ke Swift, dari Java ke Kotlin, dari Eclipse ke Android Studio). Saya telah terlibat dalam pengembangan iOS dan android sebagai hobi dan profesional selama bertahun-tahun. Setelah beralih ke bahasa baru (dalam OS yang sama) atau IDE, saya jarang kembali ke yang sebelumnya. Tampaknya Bereaksi Asli adalah langkah logis berikutnya, langkah baru berikutnya. Atau itu langkah mundur?

Amarah

Mengapa saya harus mengajarkan versi yang disederhanakan ketika saya sudah tahu bagaimana melakukan ini "nyata"?!
Saya masih harus menemukan jawaban untuk pertanyaan ini ketika perusahaan menetapkan tugas untuk mendesain ulang sepenuhnya salah satu aplikasi (pada saat itu hanya tersedia di iOS) dan merilisnya di android.

Bagaimana melakukan dua hal sekaligus dan menulis lebih sedikit kode? Saran seperti: klien tipis, perpustakaan C dengan panggilan dari kode Swift / Kotlin, React Native?

React Native tampak cukup menjanjikan karena kemampuan membuat perpustakaan dan kemudian menggunakannya segera pada tiga platform (iOS / android / web).

Penawaran

Menjanjikan siapa pun, tetapi tidak untukku. Saya tentu saja tidak senang dengan giliran ini. Saya merasa bahwa saya berada di puncak kemampuan untuk mengembangkan iOS dan android dan kemudian saya diminta untuk membuang semua pengetahuan ini, seolah-olah saya adalah lulusan baru dan memiliki 0. Saya bahkan ragu bahwa dengan React Native Anda dapat membuat produk yang berkualitas.

Depresi

Keraguan itu masuk akal. Masalah utama adalah:

• jumlah tetes yang layak dalam inti React Native;
• metode yang hanya bekerja pada satu platform (dermaga menunjukkan bahwa mereka bekerja di mana-mana);
• deskripsi tidak lengkap. Lihat saja dermaga dari kolektor Asli Bereaksi .

Masalah tersembunyi utama: blok internal di kepala saya, yang mencegah saya melihat plus di balik banyak minus.

Penerimaan

Dan tentu saja, React Native tidak hanya merugikan. Ada banyak hal baik, ini ditulis lebih mudah dan bekerja di luar kotak lebih baik daripada yang sama pada platform tertentu.

Jika kita membuang masalah yang sudah jelas, seperti crash dan dok yang sedikit, berikut adalah contoh dari apa yang harus saya hadapi:

Javascript

Tidak heran. Ini adalah hal pertama yang berjalan beriringan melalui darah, keringat dan air mata.
Ketika saya mulai mengingat pengalaman saya sebelumnya sebagai pengembang frontend (saya terlibat dalam situs web sebelum aplikasi seluler), saya mulai dengan sindrom Vietnam: Johnny, JavaScript mengelilingi kita!

Jika Anda memutuskan untuk menulis aplikasi pada React Native, maka saya sarankan mengambil salah satu kursus JS terbaru. Mereka tidak harus Bereaksi atau Bereaksi Asli.

Selama beberapa tahun terakhir, dengan merilis standar ES6, ES7, dan ES8, cara Anda menulis kode telah banyak berubah.

Dan dia menjadi sangat pribadi .

Pemeriksaan statis

Pada bulan-bulan pertama, penganalisa statis, yang ada dalam semua bahasa seluler asli, sangat kurang.

Ada berbagai utilitas yang memperlancar ketidakhadirannya, melakukan bagian dari fungsi

Elemen tata letak

Tantangan terbesar di sini adalah untuk pengembang iOS pemula.

Tantangan ini adalah kurangnya editor antarmuka visual.

Semuanya dilakukan dalam kode menggunakan markup JSX . Secara teknis, markup ini opsional, membantu melihat hierarki komponen. Pengembang Android akan merasa nyaman, memperhatikan kesamaan dengan XML.

Pada saat yang sama ada pandangan yang jelas tentang pandangan dan potensi untuk digunakan kembali.

Di iOS, ada satu atau yang lain, tergantung pada metode mana yang harus dipilih (tata letak dalam kode atau dalam pembangun Antarmuka). Ya, kedua masalah ini dapat diselesaikan, tetapi Anda harus menulis sejumlah kode yang layak.

Bereaksi Asli tidak memiliki masalah ini.
Di Android, omong-omong, itu juga tidak ada.
Tetapi para ahli Android akan menghargai cara parameter ditransfer dari komponen eksternal ke internal langsung di markup.

Tampilan dasar di sini adalah analog dari LinearLayout (android) dan UIStackView (iOS) dengan campuran konstanta pada saat yang sama. Cara yang cukup sederhana (dibandingkan dengan constrates) elemen penentuan posisi.

UIViewController dan Aktivitas

Bereaksi Asli tidak memiliki satu atau yang lain.
Tentu saja mereka ada di bawah tenda. Berinteraksi langsung dengan mereka tidak akan berhasil. Ya, ini tidak perlu.

Siklus hidup semua komponen React Native benar-benar berbeda dari iOS dan Android, sulit untuk menggambar paralel. Jika Anda fokus pada perbedaan dari sistem asli, maka:

• Elemen UI sendiri mengubah status / tampilan saat mengubah parameter input;
• di android tidak perlu menyulap onSaveInstantState . Bereaksi Asli melakukan semua ini untuk kita;
• di iOS tidak ada metode yang secara langsung melaporkan secara eksplisit saat layar aplikasi muncul / sembunyikan.

Waktu Pembuatan / Reload Langsung / Reload Panas

Kecepatan hebat dicapai karena rakitan tambahan - hanya modul yang dimodifikasi yang dibangun kembali, dan bukan keseluruhan bundel.

Semua perubahan dalam kode JS terlihat langsung di simulator. Sangat mempercepat pembangunan!

Kurangnya fungsionalitas asli di JS

Di bagian JS dari React Native, tidak semua yang Anda butuhkan ada di luar kotak.

Anda dapat menulis bagian asli di kedua platform, membuat pembungkus JS dan menyebutnya seperti sisa kode. Tidak ada yang rumit.

Ada sejumlah besar modul siap pakai yang ditulis oleh pengembang pihak ketiga.

Semua modul terhubung melalui npm (analog CocoaPods untuk iOS dan Gradle untuk android), yang memiliki kode asli dengan fungsionalitas yang diperlukan.

Tautan universal dan mendalam

Fungsi ini diterapkan oleh Facebook.
Ini bekerja dengan baik dan konsisten.

Memproses Maksud Pihak Ketiga

Sebagai kasus khusus dari paragraf sebelumnya.

Masalah terbesar pada android adalah menangani Intent selain deeplink dalam suatu aplikasi.
Tentu saja itu tergantung pada Intent dan apa yang perlu dilakukan ketika diterima.

Anda dapat menulis artikel terpisah tentang topik ini. Titik awal adalah menambahkan metode createReactActivityDelegate ke MainActivity.

Performa

Cukup mudah untuk mendapatkan 60 FPS saat menggulir daftar panjang dengan sel kompleks.
Kinerja semua yang lain (misalnya, menekan tombol, mencetak teks dalam bidang) lebih rendah. Itu terlihat selama perubahan status animasi dalam sejumlah besar elemen. Ini bisa dengan mudah ditangani. Bagian yang baik dalam dokumentasi Menggunakan Driver Asli untuk Animasi .

Dan Anda tidak bisa mendapatkan kontrol gerakan yang normal dan hubungannya dengan animasi di luar kotak.

Ketidakstabilan

Seringkali proyek hanya berhenti membangun, misalnya setelah:

• Bereaksi pembaruan kernel Asli (termasuk ketika memperbarui versi minor);
• pembaruan modul npm;
• Pembaruan Xcode;
• Pembaruan CocoaPods (masalah permanen dengan ini);
• seperti itu saja. Ya, itu juga terjadi.

Untungnya, sebagian besar masalah ini diperbaiki dengan cukup cepat. Anda dapat menambahkan skrip yang membersihkan semua cache di mana-mana, dan menjalankannya ketika terjadi kesalahan. Membantu memecahkan 98% masalah aneh yang muncul entah dari mana. Dengan pengecualian CocoaPods, semuanya menyedihkan.

Ketidakstabilan ketergantungan pihak ketiga

Masalah terbesar pada iOS adalah dan adalah keinginan luas dari modul npm untuk menggunakan metode swizzling .

Banyak modul asli dihubungkan oleh binari. Memahami bahwa beberapa modul independen svizlyat metode yang sama tidak begitu sederhana.

Majelis berlangsung dalam beberapa tahap dan pada masing-masing dari mereka ada yang salah.

Ketidakstabilan saat memperbarui dependensi pihak ketiga

Beberapa modul npm tergantung pada modul npm lainnya, dan seterusnya. Jika dua modul terikat ke versi berbeda dari modul ketiga, maka kami segera mendapatkan peringatan saat memasang, dalam kasus terbaik. Dan dalam kasus terburuk, tidak ada peringatan, tetapi tidak ada yang berhasil.

Masalah serupa jika modul npm mengandalkan modul Android asli dengan versi yang berbeda.

Setelah membersihkan cache, versi baru dapat memuat dengan diam-diam. Sepertinya dia tidak melakukan apa-apa, tetapi berhenti bekerja.

Pengujian Unit dan UI

Mekanisme pengujian yang sangat mudah melalui perpustakaan Jest, hadir dengan React Native. Analisis cakupan tes yang mudah - menunjukkan garis mana dalam fungsi yang diuji belum pernah dipanggil.

Ada perpustakaan untuk pengujian UI. Sejauh ini, sebenarnya, saya tidak harus menggunakannya.

Kesimpulan

Setelah 13 bulan bekerja dengan React Native, saya dapat dengan yakin mengatakan:

• ini cocok untuk sebagian besar aplikasi di mana Anda hanya perlu mendapatkan daftar dari server, menunjukkan daftar, menampilkan tampilan detail dari item daftar, mengirim perubahan ke server;
• semua hal di atas dicapai dengan kode yang lebih sedikit;
• sekarang ini adalah pilihan "default" saya untuk proyek baru yang menghubungi saya, karena lihat paragraf sebelumnya;
• tidak cocok untuk proyek yang ke luar negeri "mengirim permintaan - menerima respons", beberapa contoh: editor foto, pemutar, bekerja dengan Bluetooth, AI, ML, sosial. utusan jaringan;
• Proyek lanjutan dapat dilakukan pada React Native, tetapi Anda masih harus menulis banyak kode asli, sehingga intinya tidak lagi valid;
• Bereaksi Asli telah datang dan tidak akan pergi ke mana pun, ini harus diperhitungkan;
• permintaan pengembang seluler asli akan sedikit menurun, masuknya pengembang seluler asli baru akan jauh lebih menurun. Mengapa lihat di bawah;
• seseorang biasanya mengikuti cara paling sederhana, dan tidak perlu mencoba jika 95% dari aplikasi dapat dilakukan dengan menghabiskan 20% dari upaya (dibandingkan dengan pengembangan asli) untuk belajar;
• sebagai konsekuensi dari tiga poin sebelumnya: kesenjangan antara permintaan dan penawaran pengembang ponsel asli akan menjadi lebih besar. Mereka yang benar-benar tidak dapat melakukannya tanpa mereka akan merasa lebih sulit untuk menemukan mereka. Dan ini menyedihkan.

Kata terakhir untuk seseorang yang segera mulai menulis tentang Bereaksi Asli dan karena alasan tertentu memutuskan untuk membaca artikel ini, bahkan sampai akhir.

Jika Anda pikir Anda memahami topik dan Anda melakukannya dengan baik, silakan, silakan coba sendiri sebagai pengembang asli.