Catatan Freelancer: Mengembangkan Aplikasi Asli Bereaksi Pertama

Penulis materi, terjemahan yang kami terbitkan, baru-baru ini merilis aplikasi mobile pertamanya yang ditulis dalam React Native. Kebetulan aplikasi ini juga merupakan proyek pertamanya, yang ia buat sebagai programmer freelance. Di sini dia akan berbicara tentang apa yang harus dia hadapi selama bekerja - dari inisialisasi proyek hingga publikasinya di App Store dan Google Play.

Mengapa saya memilih freelance?

Mei lalu, saya membuat satu proyek lepas yang bagus. Pada waktu itu, saya adalah seorang pengembang penuh pada startup di Stockholm. Ini adalah pekerjaan pemrograman saya yang pertama, saya tiba di sana setahun yang lalu (di sini saya membicarakan hal ini lebih terinci).

Musim panas semakin dekat, laju pekerjaan, sebelum itu gila, hari demi hari menjadi lebih tenang. Pernah ada minggu seperti itu ketika, dalam urutan prioritas, saya harus berurusan dengan dukungan teknis. Saya harus berurusan dengan beberapa kesalahan, saya sedikit bosan, pekerjaan itu tidak menyenangkan saya.

Ketika saya berada dalam suasana hati yang suram, ayah saya memberi tahu saya tentang niatnya untuk membuat aplikasi mobile untuk klien perusahaannya. Meskipun dia tahu bahwa saya sangat sibuk di tempat kerja, dan tidak berharap bahwa saya akan memberikan seluruh waktu saya untuk mengimplementasikan idenya, dia masih bertanya apakah saya ingin menjadi semacam konsultan dalam proyek baru ini. Saya kemudian merasa bahwa saya lapar akan pekerjaan mental yang menarik dan karena itu menjawab pertanyaannya dengan positif. Meskipun saya awalnya tidak merencanakan ini, dari konsultan saya, sebagai hasilnya, berubah menjadi pengembang aplikasi terkemuka.

Di sini Anda mungkin bertanya-tanya mengapa seseorang bahkan mungkin mencoba melakukan pengembangan ponsel setelah tidak bekerja sebagai pengembang web profesional selama setahun? Bukankah lebih bijaksana untuk terus mendapatkan pengalaman di ceruk yang dipilih, tumbuh secara profesional, dan membuat resume yang mengesankan?

Saya sepenuhnya setuju bahwa ini akan jauh lebih masuk akal. Tetapi saya adalah "pekerja multi-stasiun" yang putus asa yang memutuskan beberapa tahun yang lalu untuk membuat keputusan karir berdasarkan bukan pada strategi tertentu, tetapi pada preferensi saya sendiri. Saya memutuskan untuk melakukan apa yang membuat saya gembira. Dengan kata lain, resume saya sekarang terlihat sedemikian rupa sehingga hampir tidak dapat dibawa ke keadaan yang lebih tidak menentu.

Tentu saja, melakukan apa yang Anda sukai dan mengikuti strategi karier tidak harus merupakan fenomena yang saling eksklusif. Bahkan, saya sangat menyukai pekerjaan saya sebelumnya dan majikan saya. Kebetulan saya menemukan proyek lain, keinginan yang ternyata lebih kuat dari keinginan untuk melakukan apa yang saya lakukan sebelumnya.

Apa yang membuat proyek ini begitu menarik bagi saya? Apa yang membuatnya lebih menarik daripada mengerjakan produk yang berkembang pesat yang digunakan oleh ribuan perusahaan, sebagai bagian dari tim yang terdiri dari orang-orang terbaik yang pernah saya temui? Pertanyaan ini dapat dijawab dengan cara ini: ini adalah kebebasan, ini adalah tantangan yang telah memberi saya kebutuhan untuk menyelesaikan masalah yang sulit, dan ini adalah keinginan untuk pengembangan diri.

Mengapa diputuskan untuk menggunakan React Native?

Pada saat saya bergabung dengan proyek ini, klien saya sudah menerima beberapa penawaran dari agen digital lokal. Bahkan sebelum saya mempertimbangkan kemungkinan mengembangkan aplikasi secara mandiri, saya diminta dengan ramah untuk mengevaluasi proposal-proposal ini. Ketika saya melihat mereka, saya kagum dengan kualitas mereka yang rendah.

Salah satu agensi mengirimkan garis besar desain aplikasi, yang, selain terlihat tidak rapi, juga tidak cocok dengan identitas perusahaan yang tercermin di situs klien. Harga tinggi yang disarankan lainnya - baik untuk pengembangan maupun untuk dukungan proyek. Yang ketiga, tampaknya, mengirimkan proposal, tanpa benar-benar mempelajari persyaratan klien. Semua agen yang mengajukan proposal memiliki satu kesamaan: mereka akan membuat aplikasi menggunakan kerangka kerja hybrid Cordova.

Tapi itu belum semuanya. Meskipun Cordova adalah alat yang sepenuhnya gratis dan open source, salah satu agensi bahkan mencoba menyembunyikan informasi tentang teknologi spesifik apa yang digunakannya. Sebaliknya, perwakilan agensi berbicara tentang platform pengembangan aplikasi seluler "in-house" yang dibuat secara internal. Tampaknya kami berbicara tentang add-on kecil di atas Cordova, dibuat hanya untuk mengamankan hak eksklusif ke agensi ini untuk melayani aplikasi dan membuat kemungkinan transisi masa depan pelanggan ke pengembang lain menjadi sulit dan mahal. Secara umum, proposal yang diajukan tidak terlalu mengesankan.

Perlu dicatat bahwa saya tidak menentang kerangka hybrid. Saya selalu menggunakan aplikasi yang didasarkan pada mereka. Ini, misalnya, Gmail, Slack, Atom, Figma. Namun, kemudian saya telah mendengar tentang React Native selama beberapa waktu, tentang bagaimana perpustakaan ini memungkinkan Anda untuk membuat aplikasi mobile lintas platform menggunakan JavaScript yang bukan hybrid!

Dan sekarang apa? Apakah perlu, dalam beberapa cara yang rumit, untuk mendukung iOS dan Android ketika mengembangkan aplikasi JavaScript asli? Pertanyaan ini muncul karena ketika saya tertarik pada aplikasi seperti itu, ternyata aplikasi iOS ditulis menggunakan Objective-C atau Swift, dan Java atau Kotlin digunakan untuk mengembangkan aplikasi Android.

Tentu saja, tidak ada trik khusus di sini. Jadi saya punya satu pertanyaan lagi. Bagaimana Bereaksi aplikasi Asli dapat disebut aplikasi asli asli? Jika Anda menjawab pertanyaan ini secara singkat, ternyata semuanya ada di API. Butuh waktu lebih lama bagi saya untuk memahami hal ini daripada yang ingin saya akui, tetapi cara Bereaksi aplikasi Asli, yang disebut asli, bekerja dengan platform seluler, tidak terdiri dalam meluncurkan kode JavaScript atau menyusun kode seperti itu di kode asli. Masalahnya adalah aplikasi ini mengeksekusi permintaan API yang menampilkan komponen asli menggunakan Objective-C di iPhone dan Java di Android.

Jika Anda ingin mendapatkan pemahaman yang lebih dalam tentang dasar-dasar React Native - Saya merekomendasikan jawaban ini kepada Quora, ini adalah presentasi dengan React Conf, dan materi ini , yang menceritakan tentang rilis React Native.

Meskipun pada saat itu saya tidak tahu apa yang sebenarnya terjadi di isi dari aplikasi-aplikasi Asli Bereaksi, saya tahu bahwa pekerjaan aplikasi semacam itu dikurangi menjadi eksekusi kode asli. Ini adalah argumen utama saya untuk tidak memilih salah satu solusi berbasis Cordova yang ditawarkan oleh agensi. Saya pikir jika perusahaan membutuhkan aplikasi seluler, maka aplikasi ini harus asli. Jika seseorang membutuhkan aplikasi yang dibangun berdasarkan HTML / CSS / JS, maka akan lebih baik untuk menghabiskan uang hanya untuk meningkatkan kemampuan seluler aplikasi web-nya.

Ketika saya membagikan alasan ini dengan seorang klien, dia bertanya kepada saya tentang apakah saya mengenal seseorang yang dapat membuat aplikasi seperti itu. Saya menjawab bahwa saya tidak tahu. Kemudian mereka bertanya apakah saya bisa melakukannya sendiri. "Aku tidak bisa," jawabku. Namun, pada saat itu saya sudah tertarik dengan semua ini dan tidak bisa tidak bereksperimen dengan React Native, mengambil spesifikasi aplikasi sebagai dasar dari eksperimen saya.

Sebelum saya menyadarinya sendiri, saya dapat membuat dasar untuk aplikasi ini. Akibatnya, hanya beberapa minggu setelah percakapan itu, klien dan saya sepakat bahwa saya akan mengembangkan aplikasi untuknya.

Spesifikasi aplikasi

Sebelum kita masuk ke detail teknis, saya ingin berbicara sedikit tentang apa jenis aplikasi yang kita hadapi.

Klien untuk siapa aplikasi dikembangkan adalah sebuah perusahaan di Stockholm, yang bergerak dalam pengelolaan kantor bersama, rekan kerja. Dengan kata lain, kita berbicara tentang ruang kantor yang bisa disewa oleh berbagai perusahaan. Saat ini, klien saya memiliki sekitar 10 kantor yang ada di mana sekitar 400 perusahaan dengan 1.400 karyawan menyewa ruang. Ini adalah penyewa kantor dan target audiens aplikasi.


Area rekreasi di salah satu tempat kerja

Setelah membahas aplikasi masa depan dengan manajer proyek, saya berhasil menemukan beberapa persyaratan untuk proyek:

• Kemampuan untuk masuk, keluar dan mengatur ulang kata sandi. Harap dicatat bahwa semua akun pengguna dibuat oleh administrator dan aplikasi tidak mendukung pendaftaran dalam sistem. Karena itu, jika Anda memutuskan untuk mengunduh aplikasi ini, maka Anda tidak akan dapat menggunakannya.
• Lihat dan edit profil pengguna: nama, alamat email, kata sandi, avatar.
• Dukungan untuk pemberitahuan push.
• Bagian Beranda, yang dengannya pengguna dapat berkenalan dengan berita perusahaan secara keseluruhan, dan, khususnya, dengan berita tentang rekan kerja yang disewa oleh perusahaan.
• Bagian komunitas, di mana pengguna dapat melihat informasi tentang berbagai rekan kerja, hubungi manajer mereka dan melihat perusahaan mana yang terlibat dalam suatu rekan kerja tertentu.
• Bagian konferensi, yang dengannya Anda dapat memesan ruang rapat dan mengelola reservasi.
• Seleksi Bagian, di mana pengguna dapat menemukan diskon dan penawaran eksklusif.
• Pertama, Anda perlu membuat versi iOS, lalu tambahkan dukungan Android.
• Aplikasi berbasis web untuk administrator, yang memungkinkan Anda untuk mengelola informasi yang ditampilkan dalam aplikasi Asli Bereaksi. Meskipun di sini saya terutama akan berbicara tentang pengembangan front-end, saya pikir akan lebih tepat untuk menyebutkan bahwa bagian server dari aplikasi untuk administrator didasarkan pada Ruby on Rails, Postgres dan Heroku.

Anda mungkin memperhatikan bahwa proyek ini memiliki persyaratan yang agak sederhana. Mungkin, sesuatu dalam semangat ini dapat disebut sebagai contoh yang baik dari aplikasi pertama yang akan dikembangkan seseorang menggunakan seperangkat teknologi baru. Jika Anda tertarik untuk melihat apa yang akhirnya saya dapatkan (dan, secara sepintas, memutuskan apakah akan menghabiskan waktu membaca cerita tentang bagaimana tepatnya semua ini bekerja untuk saya), berikut adalah ikhtisar dari versi pertama aplikasi.


Versi pertama aplikasi

Masih membaca? Luar biasa, mari kita lanjutkan.

Belajar dari yang terbaik

Bayangkan Anda berjanji kepada teman-teman Anda untuk membangun rumah untuk mereka. Tetapi Anda tidak tahu bagaimana melakukannya. Anda bahkan tidak tahu harus mulai dari mana. Apa yang harus dilakukan pertama kali dalam situasi seperti itu? Jawabannya jelas: temukan seseorang yang bisa membangun rumah dan belajar darinya.

Sebenarnya, inilah yang saya coba lakukan. Dan saya sangat beruntung menemukan apa yang Anda butuhkan. Jadi, setelah hanya beberapa jam mencari bahan pelatihan React Native, saya menemukan di YouTube kursus video 13-bagian Harvard React Native. Setiap kuliah yang berlangsung 90-120 menit dikhususkan untuk topik yang terpisah. Akibatnya, saya dihadapkan dengan sekitar 23 jam materi pelatihan berkualitas tinggi.

Setelah menemukan kursus ini, saya langsung, seperti yang terobsesi, mulai belajar. Hasilnya, setelah beberapa minggu mengikuti kelas yang bisa saya habiskan di malam hari dan akhir pekan, saya menyelesaikan kursus ini dan menciptakan fondasi yang baik untuk aplikasi tersebut.

Sekarang saya dapat mengatakan bahwa kursus itu, tanpa keraguan, adalah yang terbaik yang berhasil saya temukan. Kelas-kelas yang ringkas dan dipersiapkan dengan baik, tentu saja, memainkan peran positif yang sangat besar di sekolah, tetapi saya tidak bisa tidak memperhatikan keterampilan guru. Saya akan menggambarkan gaya memimpin kelas-kelas ini dengan kata-kata berikut: kecepatan, kepraktisan ekstrem, fokus. Tidak ada air, tidak ada lelucon atau cerita yang tidak relevan dari kehidupan. Tidak seperti yang ditulis pelayanmu yang sederhana di sini ...

Dengan satu atau lain cara, ada perasaan bahwa begitu banyak informasi yang berguna dimasukkan ke dalam setiap kuliah sehingga akan dibutuhkan waktu dua kali lebih banyak untuk menyajikannya kepada banyak guru lain. Dengan kata lain, kursus ini sangat mirip dengan Harvard CS50 yang terkenal.

Akibatnya, jika Anda ingin menemukan pijakan untuk aplikasi React Native pertama Anda, saya merekomendasikan kursus ini untuk Anda. Meskipun di sini harus diperhatikan satu fitur. Kursus itu menggunakan toolkit Expo . Ini adalah alat yang luar biasa yang cocok untuk sebagian besar aplikasi sederhana, yang mengambil segala macam seluk beluk tentang bekerja dengan platform seluler. Tetapi jika Anda, seperti saya, ingin menciptakan dasar untuk sebuah proyek yang, lebih cepat daripada nanti, dapat berubah menjadi aplikasi yang agak besar dan kompleks, dan Anda, pada saat yang sama, menginginkan kebebasan penuh untuk bertindak, Anda mungkin lebih baik menginisialisasi proyek dengan Bereaksi Asli.

"Sumber pelatihan" kedua yang bisa saya gunakan adalah rekan-rekan saya. Untungnya, perusahaan tempat saya bekerja kemudian juga mulai mengembangkan proyek React Native. Walaupun saya sendiri tidak terlibat dalam proyek ini, saya belajar banyak, hanya berbicara dengan mereka yang mengerjakan proyek ini dan menganalisis kode mereka.

Sekarang kita telah membahas segala sesuatu yang terjadi dengan mengembangkan aplikasi React Native, saatnya untuk beralih ke masalah teknis.

Lingkungan pengembangan

Setelah menggunakan tim dari bentuk react-native init MyApp , saya membuat dasar aplikasi, salah satu tugas pertama yang dihadapi saya adalah pengembangan lingkungan pengembangan baru.

Jika Anda datang ke React Native-environment dari pengembangan web yang biasa, maka perlu dicatat bahwa banyak di sini akan terasa akrab bagi Anda. Bagi saya, ini berarti saya terus menggunakan Atom sebagai editor kode, iTerm sebagai terminal, dan GitUp sebagai antarmuka untuk bekerja dengan git. (Jika penggemar Vim membaca ini sekarang, saya menyarankan agar semua orang tetap tidak yakin.) Tapi, selain alat-alat di atas, saya membutuhkan sesuatu yang lain untuk mengembangkan aplikasi React Native.

Misalnya, saya harus terbiasa dengan emulator iOS. Sementara eksekusi, dengan alat baris perintah, dari perintah react-native run-ios , tampak sederhana, pada awal panggilan sederhana ke perintah ini tidak cukup bagi emulator untuk bekerja dengan baik. Karena paket npm baru ditambahkan ke proyek hampir setiap hari (dan kemudian, beberapa modul CocoaPod asli), saya, lebih dekat daripada yang saya inginkan, dipaksa untuk berkenalan dengan ritual yang tidak menyenangkan dalam membersihkan sumber daya Watchman dan cache Haste, menghapus folder node_modules, menginstal ulang modul dan mengatur ulang cache Metro Bundler. Untungnya, semua tugas ini dapat diselesaikan menggunakan perintah berikut:

 watchman watch-del-all && rm -rf tmp/haste-map-react-native-packager && rm -rf node_modules && yarn && npm start --reset-cache 

Dalam 9 dari 10 kasus, "tarian dengan rebana" seperti itu memungkinkan emulator untuk hidup kembali. Namun, kadang-kadang, ini pun tidak cukup. Kemudian saya harus mempelajari deskripsi pesan kesalahan pada GitHub dan membaca diskusi tentang StackOverflow.

Akar dari beberapa masalah lain adalah kenyataan bahwa untuk waktu yang lama saya berpikir bahwa untuk menyelesaikan beberapa masalah, perlu menjalankan Xcode. Dan percayalah, Anda akan berusaha untuk tetap di IDE rumah horor ini sesedikit mungkin.

Kisah serupa terjadi dengan peluncuran emulator dengan versi iPhone tertentu. Jika seseorang akan mengatakan kepada saya sebelumnya bahwa perintah di bawah ini memecahkan masalah ini langsung dari baris perintah, maka saya mungkin hidup sedikit lebih mudah di bulan-bulan pertama pengembangan Bereaksi saya.

 react-native run-ios --simulator='iPhone X' 

Contoh lain dari kesulitan membiasakan diri dengan lingkungan pengembangan baru termasuk proses tiga langkah mempersiapkan versi rilis aplikasi (untuk penempatan di App Store atau di beberapa lingkungan integrasi berkelanjutan, seperti Visual Studio App Center atau Firebase) dan proses transisi dari versi rilis ke versi, dimaksudkan untuk debugging (ke mode pengembangan). Mungkin banyak yang akan merasa jelas bahwa perubahan yang diperlukan untuk proyek dapat dibuat menggunakan editor teks apa pun. Bagaimanapun, ini hanyalah contoh dari beberapa hal kecil yang secara tak terduga berdampak besar pada alur kerja saya ketika bekerja dalam mode pengembangan.

Dan akhirnya, perlu beberapa waktu untuk terbiasa dengan kebutuhan untuk terus-menerus beralih di antara berbagai aplikasi macOS yang diperlukan untuk menyelesaikan tugas-tugas yang saya, ketika mengembangkan aplikasi web, biasanya diselesaikan menggunakan Chrome saja.

Untuk melihat apa yang ditulis kode JavaScript ke konsol dan menganalisis, untuk keperluan debugging, output HTML / CSS, saya beralih ke React Native Debugger . Untuk memantau status aplikasi, tindakan yang diajukan, permintaan API dan tanggapan yang diterima, saya menggunakan Reactotron . Meskipun saya menemukan kedua aplikasi ini sangat berguna, saya tidak bisa tidak memikirkan alur kerja yang biasa saya gunakan untuk membuat aplikasi Ember.js, ketika saya bisa menyelesaikan semua tugas ini di lingkungan yang sama di mana aplikasi saya dijalankan (menggunakan plugin Inspektur Ember untuk Chrome).

Navigasi

Mengatur navigasi / perutean tampaknya menjadi tugas yang sangat sulit untuk Bereaksi Asli. Selama keberadaan kerangka ini, banyak solusi berbeda untuk masalah ini telah muncul, tetapi masih ada sesuatu yang bisa disebut standar yang diakui secara universal. Saya memutuskan untuk menggunakan perpustakaan reaksi-navigasi, pilihan saya terutama dipengaruhi oleh fakta bahwa mereka berbicara tentang perpustakaan ini dalam kursus React Native yang saya lalui, serta fakta bahwa rekan-rekan saya menggunakannya.

Jika saya menginvestasikan waktu dalam studi yang cukup mendalam tentang masalah ini, saya bisa mengetahui yang berikut:

• Proyek navigasi reaksi memiliki sekitar 15.000 bintang di GitHub dan 86 masalah yang belum terselesaikan. Ini sepenuhnya didasarkan pada JavaScript dan fitur dokumentasi paling rinci di antara solusi navigasi yang pernah saya lihat.
• Perpustakaan reaksi-asli-navigasi mencetak sekitar 10.000 bintang, ternyata memiliki 162 masalah yang tidak terpecahkan. Namun, tidak hanya menggunakan JavaScript. Untuk bekerja dengannya, Anda perlu mengedit file asli.
• Repositori router-reaksi memiliki sekitar 35.000 bintang dan daftar 55 masalah luar biasa di GitHub. Benar, indikator ini tidak dapat dibandingkan secara langsung dengan proyek lain yang dijelaskan di sini, karena repositori ini mencakup paket yang dirancang tidak hanya untuk React Native, tetapi juga untuk React.
• Proyek navigasi asli memiliki sekitar 3.000 bintang dan 55 masalah yang belum terselesaikan. Mereka yang akan belajar dan menggunakannya harus mempertimbangkan bahwa itu masih dalam versi beta, tidak hanya menggunakan JavaScript, dan didukung oleh Airbnb (perusahaan ini memutuskan untuk meninggalkan React Native). )

Tetapi, walaupun mempertimbangkan hal di atas, saya mungkin akan tetap memilih navigasi-reaksi, karena saya tidak punya waktu untuk mencoba semua perpustakaan ini, seperti, misalnya, penulis laporan ini melakukannya. Dan akhirnya, seperti yang dikatakan dalam laporan ini, pilihan alat untuk mengatur navigasi adalah pertanyaan yang solusinya tidak bergantung pada alat mana yang bisa disebut yang terbaik, tetapi yang mana yang paling cocok dengan kebutuhan proyek tertentu.

Setelah bekerja dengan navigasi reaksi selama sekitar 9 bulan, saya harus mengatakan bahwa saya benar-benar tidak perlu mengeluh. Jika Anda membandingkan pustaka ini dengan pustaka router.js yang biasa digunakan di Ember.js , saya dapat mengatakan bahwa ini adalah sesuatu yang sama sekali baru.

Sangat mudah bagi saya untuk berurusan dengan tiga jenis alat navigasi navigasi utama. Ini adalah StackNavigator , TabNavigator dan DrawerNavigator . Jauh lebih sulit untuk memahami cara menggabungkan alat-alat ini untuk membuat sistem navigasi aplikasi yang saya butuhkan.

Sebagai contoh, fakta bahwa komponen DrawerNavigator harus menjadi elemen root dari sistem navigasi (satu langkah di atas komponen TabNavigation utama) benar-benar tidak jelas bagi saya. Jika sulit membayangkan, DrawerNavigator cara DrawerNavigator beraksi (dalam aplikasi nyata, semuanya bekerja jauh lebih lancar).


DrawerNavigator dari reaksi navigasi dalam aksi

Seperti yang Anda lihat, saya perlu membuka bilah navigasi samping dengan gesek, berada di layar aplikasi apa pun.

Saya menganggap bilah samping sebagai sesuatu yang sekunder dibandingkan dengan bilah navigasi utama yang terletak di bagian bawah aplikasi. Oleh karena itu, menurut saya DrawerNavigator harus ditempatkan di pohon rute (ditunjukkan di bawah) baik di bawah BottomTabNavigator utama, atau pada tingkat yang sama dengan elemen ini.

Namun, setelah saya sangat menderita, mencoba untuk memaksa sidebar ke tempat di mana ternyata tidak sesuai, saya menyadari bahwa, sesuai dengan fitur navigasi reaksi, DrawerNavigator harus ditempatkan satu langkah di atas BottomTabNavigator , yaitu, di root dari pohon navigasi. Saya berharap temuan saya ini membantu salah satu pembaca materi ini menghemat waktu yang seharusnya dihabiskan untuk membaca dokumentasi dan materi di GitHub.

Berikut tampilan pohon navigasi aplikasi. Di sini, sebagai elemen root, MainDraverNavigation digunakan.


Pohon navigasi terakhir dari versi pertama aplikasi

Di sini Anda mungkin bertanya-tanya mengapa, untuk bagian Komunitas dan Konferensi, Anda memerlukan StackNavigator dan TabNavigator . Tidak bisakah Anda meninggalkan lapisan StackNavigator dan langsung menuju TabNavigator ?

Masalahnya, saya membutuhkan masing-masing dari dua elemen TabNavigator untuk memiliki judul. Inilah mereka.


TabNavigator, judul

Di sini, sekali lagi, dugaan saya tidak cocok dengan perangkat navigasi reaksi. Saya berpikir bahwa MaterialTopTabNavigator harus menjadi komponen navigasi yang sepenuhnya normal, jadi saya memutuskan bahwa harus ada beberapa opsi bawaan dalam pengaturannya yang memungkinkan Anda untuk menetapkan judul. Ternyata, tidak ada yang seperti itu di sana, dan itulah sebabnya saya harus menggunakan StackNavigator sebagai lapisan perantara, menambahkan, sebagai hasilnya, tingkat kerumitan tambahan untuk infrastruktur aplikasi dan dipandu oleh pertimbangan “kosmetik” yang cantik.

Kurangnya navigasi reaksi, di samping itu, menyebabkan masalah yang jauh lebih serius. Secara khusus, mereka terdiri dari kebutuhan untuk mengatur pelipatan dan hilangnya gambar header selama pengguna menggulir daftar elemen yang diatur oleh FlatList . Karena judul bagian Beranda dan Seleksi ditampilkan dalam StackNavigator sama dengan daftar elemen mereka, masalah ini tidak akan sulit untuk dipecahkan dengan hanya membiarkan judul gulir bersama dengan sisa daftar.

Namun dalam kasus bagian Komunitas dan Konferensi, saya tidak dapat menemukan cara untuk menerapkan solusi yang sama, karena tajuk ditampilkan menggunakan elemen StackNavigator , dan daftar ditampilkan menggunakan elemen StackNavigator , satu langkah lebih tinggi di pohon navigasi. Akibatnya, saya menolak untuk menggulir judul, yang memperkenalkan heterogenitas yang tidak menyenangkan dalam aplikasi.


Menggulir di TabNavigator dan StackNavigator

Meskipun masalah yang dijelaskan dengan judul dalam emulator mensimulasikan Iphone X tampaknya tidak serius, pada layar kecil judul dapat menempati sekitar 20% dari ruang layar yang tersedia. Jika ada yang tahu cara mengatasi masalah ini, beri tahu saya.

Masalah yang sama dengan TabNavigator juga terasa di bagian Tujuan. Seperti yang akan ditunjukkan pada gambar berikut, di sebelah kanan, saya ingin meletakkan elemen TabNavigator lain pada tab Coworking Spaces untuk menampilkan tiga tab teratas, Info, Anggota, dan Kontak.

Ketika bekerja dengan TabNavigator sulit untuk menempatkan peragaan slide di bagian atas elemen tanpa harus menyulitkan keputusan dan tidak menyebabkan banyak masalah navigasi (terutama terkait dengan opsi navigasi). Jadi saya harus menggunakan paket JS yang disebut react-native-swiper untuk dapat bekerja dengan ketiga tab ini. Perlu dicatat bahwa solusi ini benar-benar cocok untuk saya jika aplikasinya tidak akan mengarah pada animasi tiba-tiba garis yang menekankan tajuk tab. Bagaimanapun, saya menganggap kerugian ini sebagai pembayaran yang adil untuk kesempatan untuk menghindari masalah dengan sistem navigasi alternatif.


Bandingkan TabNavigator dari reaksi-navigasi dengan react-asli-swiper (perhatikan perbedaan dalam animasi garis emas di bawah nama tab)

Berikut adalah kesimpulan yang saya buat setelah menerapkan subsistem navigasi aplikasi:

• Ada banyak solusi yang terdokumentasi dengan baik untuk mengatur navigasi di aplikasi Bereaksi Asli, di antaranya saya memilih navigasi reaksi. Ini paling sesuai dengan kebutuhan saya.
• Pustaka navigasi navigasi sangat menyederhanakan dimulainya pekerjaan pada suatu proyek jika pengembang tidak tahu banyak tentang bagaimana sistem navigasi platform seluler bekerja.
• Pustaka navigasi-reaksi memiliki beberapa fitur yang tidak intuitif (setidaknya untuk pengembang web), tetapi tidak ada yang tidak dapat dielakkan, meskipun tidak dengan cara yang paling efisien.

Layar splash

Dengan meluncurkan aplikasi baru di emulator yang dibuat dengan menggunakan perintah react-native init , terus-menerus memuatnya ketika Anda membuat perubahan, Anda sangat cepat menyadari bahwa aplikasi tersebut membutuhkan layar splash yang bagus (mereka juga disebut "layar splash").

Cara membuat splash screen ditulis dengan baik di sini , jadi saya tidak akan mengulangi kata-kata penulis bahan ini. Saya hanya akan berbicara tentang masalah yang saya temui, dan tentang yang tidak ada dalam panduan ini. Seperti inilah masalah ini:


Layar splash dengan masalah

Masalah ini muncul dalam kasus yang jarang terjadi di iOS, tetapi beberapa pengguna aplikasi mungkin akan menemui itu. Saya pertama kali menemukan masalah ini ketika saya bekerja di satu tempat, di mana saya tidak bisa menggunakan WiFi dan menghubungkan laptop saya ke Internet 4G melalui telepon. Pengguna iPhone tahu bahwa ketika ponsel mendistribusikan Internet, bilah statusnya berubah menjadi biru dan semakin tinggi. Ini "mematahkan" gambar pada layar splash saya ketika saya meluncurkan aplikasi di telepon. Masalah yang sama muncul saat menelepon.

Akibatnya, setelah mencari-cari beberapa waktu di repositori layar reaksi-asli-splash dan tidak menemukan sesuatu yang berguna di sana, saya memutuskan untuk mengabaikan masalah ini dengan sepenuhnya menyembunyikan bilah status sambil menunjukkan layar splash.

Ini sangat sederhana - cukup tambahkan kunci UIStatusBarHidden ke UIStatusBarHidden , tetapkan nilai logisnya true , dan kemudian, setelah memanggil SplashScreen.hide() , setel properti hidden dari komponen StatusBar Native StatusBar menjadi StatusBar .

Manajemen negara

Saya merasa bahwa selama dua tahun terakhir saya telah mendengar setiap hari tentang prioritas kesepakatan atas konfigurasi, prinsip dari Convention over Configuration (CoC). Jadi itu di pekerjaan saya sebelumnya. Dan ini tidak mengherankan, karena di sana, di server, kami menggunakan Ruby on Rails, dan pada klien - Ember.js - dua kerangka kerja, esensi yang sesuai dengan prinsip CoC sebaik mungkin. Saya pikir saya tahu apa artinya itu, tetapi proses mengeksplorasi manajemen negara bagian di React Native memberi saya pemahaman baru tentang prinsip ini.

Meskipun saya, dalam beberapa aplikasi yang sangat sederhana, bereksperimen dengan perpustakaan React dipengaruhi oleh prinsip ini, saya tidak pernah membuat sesuatu yang cukup besar berdasarkan itu yang akan memungkinkan saya untuk menghargai keuntungan menggunakan wadah negara seperti Redux atau MobX . Sebagian besar pengalaman saya mengelola keadaan aplikasi JS adalah dengan Ember Data (ini adalah sistem bawaan Ember untuk mengelola keadaan dan mengatur penyimpanan data yang persisten).

Karena perpustakaan Redux bagi saya tampaknya merupakan salah satu solusi terbaik untuk masalah manajemen negara yang telah saya dengar selama bertahun-tahun (dan yang telah dibahas dalam kursus React Native yang saya bahas), secara umum, saya tidak melihat ke arah pesaingnya. . Saya hanya ingin melengkapi aplikasi saya dengan yang terbaik dari sistem manajemen negara yang ada dan melakukannya tanpa terlalu banyak usaha.

Di Ember, 90% dari infrastruktur data ada di tangan programmer yang siap digunakan. Saya tidak curiga bahwa dalam proyek saya saat ini semuanya akan menjadi kebalikannya. Ternyata, tidak hanya Bereaksi, tetapi Redux, perpustakaan manajemen negara paling populer, tidak memberikan apa pun yang berguna untuk mempertahankan keadaan global. Pustaka ini sangat ringan sehingga programmer harus mengambil 90% dari kekhawatiran tentang bekerja dengan data di dalam aplikasi untuk menciptakan sistem manajemen negara yang layak.

Setelah saya, pengembang yang jauh kurang berpengalaman daripada sekarang, menemukan, hal yang paling sulit bagi saya adalah membiasakan diri dengan fungsi baru dan prinsip-prinsip kekebalan. Setelah saya memasang sejumlah besar pekerjaan yang perlu dilakukan untuk hanya mengunduh data dari server atau mengirimkannya ke server, semua ini datang bersama dalam bentuk 7 langkah yang cukup sederhana:

1. Tambahkan tiga konstanta ke file dengan konstanta: SOME_ACTION_REQUEST , SOME_ACTION_FAILED , SOME_ACTION_SUCCEEDED .
2. Tambahkan pembuat tindakan ke file tindakan.
3. Proses tiga tindakan dalam peredam yang sesuai, dan, jika perlu, tambahkan peredam baru ke sistem dan sertakan dalam peredam root.
4. Tambahkan pekerja ke saga yang cocok, dan, jika perlu, tambahkan saga baru ke sistem dan sertakan dalam saga root (saya menggunakan pustaka redux-saga untuk memproses tindakan asinkron).
5. Tambahkan fungsi untuk menangani permintaan API apa pun yang mungkin.
6. Memetakan data yang diperlukan dari keadaan ke properti di komponen Bereaksi yang sesuai.
7. Kirim tindakan SOME_ACTION_REQUEST dari komponen Bereaksi yang sesuai.

Redux dan redux-saga, tentu saja, memiliki fitur yang jauh lebih luas, tetapi mengingat apa yang saat ini saya minati, 7 langkah di atas adalah apa yang Redux bagi saya.

Sesi

Jadi, kami menyiapkan lingkungan pengembangan untuk aplikasi Asli Bereaksi, membuat pohon navigasi, menyiapkan infrastruktur manajemen negara. Apa yang akan baik untuk dilakukan pada langkah selanjutnya dari proyek? Bagi saya, pembuatan sistem otentikasi pengguna adalah jawaban yang sepenuhnya alami untuk pertanyaan ini. Jadi sekarang kita akan berbicara tentang sesi.

Jika Anda datang ke ranah Asli Bereaksi dari pengembangan web, maka Anda akan berurusan dengan sesi tanpa banyak kesulitan. Jika Anda bahkan sedikit akrab dengan konsep yang menjadi dasar penyimpanan LocalStorage , maka Anda hanya perlu tahu bahwa ketika bekerja dengan React Native, akses ke penyimpanan tersebut harus diganti dengan panggilan ke AsyncStorage . Ini adalah level abstraksi yang memungkinkan Anda untuk menyimpan data dalam format nilai kunci di antara sesi. Dengan kata lain, di sini Anda dapat menyimpan token otentikasi yang dihasilkan di server, dikirim ke klien setelah pengguna berhasil masuk ke sistem.

Daftar

Jika kita berbicara tentang bekerja dengan daftar, saya merasa bahwa dalam React Native masalah ini diselesaikan dengan cukup baik. Secara umum, dapat dicatat bahwa pengembang memiliki tiga kemungkinan. Jika bekerja dengan daftar statis, data yang disajikan tidak berubah, maka ScrollView kemungkinan besar akan memiliki cukup banyak. , , , , FlatList . , , , , SectionList .

, , FlatList . , , , , , . .

▍

FlatList , refreshControl . , , , , . , React Native , . — RefreshControl . , .


RefreshControl

, , , refreshControl , RefreshControl , , . , , :

• , , . , handleRefresh() .
• , , « » ( ).

— .

, , , , . , , , GitHub.

, refreshControl onEndReached ( ) fetching . , - , false true , — , , 250 , RefreshControl , .

, setTimeout() fetching 350 . . , , setTimeout — , , handleRefresh() handleLoadMore() — refreshing loadingMore . , , , , - .

, onRefresh refreshing refreshControl . , refreshControl , , , , .

▍

, . — , , Load More , , , , .


FlatList. , , 2, onEndReached , 2-

, onEndReached . .

onEndReachedThreshold , FlatList , , onEndReached . .

100 , , 10 , 1, onEndReachedThreshold , , onEndReached , , 90-. 2, , 2- , — 80- , .

, , , , FlatList . , , , , handleLoadMore() , onEndReached , , — 10 .

, , loadingMore , , handleLoadMore() , , , !loadingMore . , , .

▍

ListLoadingComponent FlatList , , ListHeaderComponent , ListEmptyComponent ListFooterComponent , , - , , , .

, render() .

▍

, , , . , , .

, scrollToOffset FlatList , , . , . ref FlatList :

 <FlatList ref={(ref) => { this.newsListRef = ref; }} ... /> 

, . ScrollToOffset handleScrollToTop() , , , react-navigation, , :

 componentDidMount() { this.props.navigation.setParams({   scrollToTop: this.handleScrollToTop, }); } handleScrollToTop = () => { this.newsListRef.ScrollToOffset({   x: 0, y: 0, animated: true, }); }; 

, react-navigation 3 ref , BottomTabNavigator .

, , . , , 4G- ( , , 3G), , , , , .

, , , , , , , . . , , , , .

, , . 7 , image , , ( , ).

▍

, , . react-native-image-picker , Cloudinary Carrierwawe Rails-.

, Node-API Cloudinary react-native-fetch-blob . , , , , , .

, , react-native-fetch-blob, . , react-native-fetch-blob , API JS FormData . , react-native-fetch-blob rn-fetch-blob , .

▍

, React Native Image style , source resizeMode . , , - , , , .

, , , . , , , . . Avatar react-native-elements.

, Image . , - , .

, , . .


react-native-slideshow

react-native-slideshow , , . , , , , , , .

▍

7 , , . , — , , . , - . .

, , -, , , , - ( — ), , , , Facebook . , .

, , React Native-. , . — react-native-loading-placeholder , , , . — react-native-linear-gradient , . , , , , , , , , .


react-native-loading-placeholder react-native-linear-gradient

▍

— . , React Native Image . , - CachedImage react-native-cached-image .

npm- Image , , , CachedImage . Reactotron , , .

, , , . , , Cloudinary, 95% , , 4%. .

, . CachedImage activityIndicatorProps={{ animating: false }} , .

▍

React Native - Picker . - , ( - ), JS-, . , react-native-picker-select , <select> iOS Android .

JS-, React Native- ( lodash , ), , , , . , , - . , .

▍

react-native-calendars Wix. :

• iOS , . , , , -, — .
• React Native — DatePickerIOS DatePickerAndroid , , .
• , , , Apple Google.

, . , , — .


react-native-calendars react-native-picker-select

▍

— , .
SaaS-, . SOAP, API Conference. , , , , .

, , , 5 . - , JavaScript Date UTC, , . , , , , , - . « », — .

, , moment-js , React Native, timezone , :

 const timeSthlmAfterFive = moment().isAfter(moment.tz('17:00:00', 'HH:mm:ss', 'Europe/Stockholm'), 'second'); 

, , , . React Native -, , , , , , font-face CSS.

. , . , 10 -. react-native-vector-icons .

, ,

CI/CD, DevOps- -, .

( ) , - . , . GitHub- . , :

• . , , .
• , - , , .

. , , , , , , push-. , , , , .

Visual Studio App Center (VSAC). Chain React 2017 . , , , DevOps-, . , , , , push-, Codepush . -. , , , , iOS, Android. , - , , , , , - .


Visual Studio App Center ( )

« », — , . , (API — ). , , , , -, (, , ).

? Microsoft, , VSAC « ». , , Codepush ( React Native-) HockeyApp ( ), - . , «developers, developers, developers, developers» .

, VSAC , - Fastlane , BuddyBuild Firebase ? , , , VSAC , , , . , , ? , VSAC, , .

VSAC. , , , .

, , , VSAC Apple Developers (Apple, , , ). , , , .

, VSAC, , , CI/CD- .

Android

, iOS- , Android . Android Studio Android React Native Platform . , Platform.select() . - , , , Platform.OS .

, , Google Play , App Store. Mengapa , App Store Apple.

Apple

, -, React Native, . , Apple. , , , , , .


Apple

, — « ». -, , iOS-, , , , .

— Apple. , , , . Dun & Bradstreet, Apple, . , , , Apple (, , Apple , — ).

, Apple , , — , -. . , — ?

, .

, , Apple Developer . .

. . provisioning-, iOS-, , Apple .p12 push-, dSym-. , , , .

Apple, 50% 24 , 90% — 48 . , , — , , Apple-.

, . «Metadata Rejected». , - . , 5 ( App Store Review Guidelines ), .

, , , — . , , , , , . , — , () .

iOS, . , , , . , , . . , , .

Ringkasan

, React Native- . React Native-. -. , : . .

, , , , . , , — , .

, - , . . , , , 8 . . .

, . , , - .

, , , 6-7 , . , , , :

• , (iOS Android), , , .
• JavaScript. , , Ember.js.
• React.js, , React-, . , JS-/.
• , Redux.
• DevOps .
• , .
• UI/UX.
• , , , , , , , , .

JS- , Flutter , NativeScript , Objective-C, Swift, Java Kotlin, React Native .

, -, , React Native , , , . , React Native — , . React Native .

Pembaca yang budiman! ?