Merancang Dan Membangun Aplikasi Web Progresif Tanpa Kerangka Kerja (Bagian 3)

Kembali ke bagian pertama dari seri ini, kami menjelaskan mengapa proyek ini muncul. Yaitu keinginan untuk mempelajari bagaimana aplikasi web kecil dapat dibuat dalam vanilla JavaScript dan untuk membuat pengembang non-desain mengerjakan sedikit desainnya.

Di bagian kedua, kami mengambil beberapa desain awal dasar dan menyiapkan dan menjalankannya dengan beberapa pilihan perkakas dan teknologi. Kami membahas bagaimana dan mengapa bagian dari desain berubah dan konsekuensi dari perubahan tersebut.

Di bagian akhir ini, kita akan membahas tentang mengubah aplikasi web dasar menjadi Aplikasi Web Progresif (PWA) dan 'mengirim' aplikasi sebelum melihat pelajaran paling berharga yang dipetik dengan membuat aplikasi web sederhana Masuk/Keluar:

• Nilai yang sangat besar dari metode array JavaScript;
• Debug;
• Ketika Anda adalah satu-satunya pengembang, Anda adalah pengembang lainnya;
• Desain adalah pengembangan;
• Pemeliharaan dan masalah keamanan yang sedang berlangsung;
• Bekerja di proyek sampingan tanpa kehilangan pikiran, motivasi, atau keduanya;
• Pengiriman beberapa produk mengalahkan pengiriman tidak ada produk.

Jadi, sebelum melihat pelajaran, mari kita lihat bagaimana Anda mengubah aplikasi web dasar yang ditulis dalam HTML, CSS, dan JavaScript menjadi Aplikasi Web Progresif (PWA).

Dalam hal total waktu yang dihabiskan untuk membuat aplikasi web kecil ini, saya memperkirakan kemungkinannya sekitar dua hingga tiga minggu. Namun, karena dilakukan dalam potongan 30-60 menit di malam hari, sebenarnya butuh sekitar satu tahun dari komitmen pertama hingga ketika saya mengunggah apa yang saya anggap versi '1.0' pada Agustus 2018. Saat saya mendapatkan aplikasinya ' fitur lengkap', atau lebih sederhananya, pada tahap yang saya senangi, saya mengantisipasi dorongan terakhir yang besar. Anda tahu, saya tidak melakukan apa pun untuk membuat aplikasi menjadi Aplikasi Web Progresif. Ternyata, ini sebenarnya bagian termudah dari keseluruhan proses.

Membuat Aplikasi Web Progresif

Kabar baiknya adalah saat mengubah aplikasi kecil yang diberdayakan JavaScript menjadi 'Aplikasi Web Progresif', ada banyak alat untuk mempermudah hidup. Jika Anda mengingat kembali bagian pertama dari seri ini, Anda akan ingat bahwa menjadi Aplikasi Web Progresif berarti memenuhi serangkaian kriteria.

Untuk mengetahui bagaimana aplikasi web Anda mengukur, pemberhentian pertama Anda mungkin adalah alat Lighthouse dari Google Chrome. Anda dapat menemukan audit Progressive Web App di bawah tab 'Audit'.

Inilah yang dikatakan Lighthouse kepada saya ketika saya pertama kali menjalankan In/Out melaluinya.

Pada awalnya In/Out hanya mendapatkan skor ⁵⁵ ₁₀₀ untuk Progressive Web App. Namun, saya membawanya dari sana ke ¹⁰⁰ ₁₀₀ dalam waktu kurang dari satu jam!

Kebijaksanaan dalam meningkatkan skor itu tidak ada hubungannya dengan kemampuan saya. Itu hanya karena Lighthouse memberi tahu saya apa yang harus dilakukan!

Beberapa contoh langkah yang diperlukan: sertakan file manifest.json (pada dasarnya file JSON yang menyediakan metadata tentang aplikasi), tambahkan banyak tag meta di kepala, ganti gambar yang digariskan di CSS untuk gambar referensi URL standar, dan tambahkan banyak gambar layar beranda.

Membuat sejumlah gambar layar beranda, membuat file manifes, dan menambahkan banyak tag meta mungkin tampak seperti banyak yang harus dilakukan dalam waktu kurang dari satu jam, tetapi ada aplikasi web yang luar biasa untuk membantu Anda membangun aplikasi web. Betapa bagusnya itu! Saya menggunakan https://app-manifest.firebaseapp.com. Beri dia beberapa data tentang aplikasi dan logo Anda, tekan kirim dan itu memberi Anda file zip yang berisi semua yang Anda butuhkan! Dari sana, itu hanya waktu salin dan tempel.

Hal-hal yang saya tunda untuk beberapa waktu karena kurangnya pengetahuan, seperti Service Worker, juga ditambahkan dengan cukup mudah berkat banyak posting blog dan situs yang didedikasikan untuk service worker seperti https://serviceworke.rs. Dengan adanya pekerja layanan, itu berarti aplikasi dapat bekerja secara offline, fitur yang diperlukan dari Aplikasi Web Progresif.

Meskipun tidak sepenuhnya terkait dengan membuat aplikasi menjadi PWA, tab 'cakupan' di Chrome Dev Tools juga sangat berguna. Setelah begitu banyak iterasi sporadis pada desain dan kode selama berbulan-bulan, itu berguna untuk mendapatkan indikasi yang jelas di mana ada kode yang berlebihan. Saya menemukan beberapa fungsi lama mengotori basis kode yang saya lupakan begitu saja!

Singkatnya, setelah mengerjakan rekomendasi audit Lighthouse, saya merasa seperti hewan peliharaan guru:

Kenyataannya adalah mengambil aplikasi dan menjadikannya Aplikasi Web Progresif sebenarnya sangat mudah.

Dengan bagian akhir pengembangan yang disimpulkan, saya mengunggah aplikasi kecil ke sub-domain situs web saya dan hanya itu.

Retrospektif

Berbulan-bulan telah berlalu sejak memarkir pengembangan aplikasi web kecil saya.

Saya telah menggunakan aplikasi ini dengan santai selama berbulan-bulan sejak itu. Kenyataannya adalah banyak organisasi olahraga tim yang saya lakukan masih terjadi melalui pesan teks. Aplikasi ini, bagaimanapun, jelas lebih mudah daripada menuliskan siapa yang masuk dan keluar daripada menemukan secarik kertas setiap malam permainan.

Jadi, sebenarnya itu bukan layanan yang sangat diperlukan. Juga tidak menetapkan batasan apa pun untuk pengembangan atau desain. Saya juga tidak bisa memberi tahu Anda bahwa saya 100% senang dengan itu. Saya baru saja sampai pada titik saya senang untuk meninggalkannya.

Tapi itu tidak pernah menjadi inti dari latihan ini. Banyak hal yang saya ambil dari pengalaman. Berikut ini adalah apa yang saya anggap sebagai takeaways paling penting.

Desain Adalah Pengembangan

Pada awalnya, saya tidak cukup menghargai desain. Saya memulai proyek ini dengan keyakinan bahwa waktu yang saya habiskan untuk membuat sketsa dengan buku tulis dan pena atau dalam aplikasi Sketch, adalah waktu yang dapat dihabiskan dengan lebih baik dengan pengkodean. Namun, ternyata ketika saya langsung ke kode, saya sering hanya menjadi orang bodoh yang sibuk. Menjelajahi konsep terlebih dahulu dengan ketelitian serendah mungkin, menghemat lebih banyak waktu dalam jangka panjang.

Ada banyak kesempatan di awal di mana berjam-jam dihabiskan untuk membuat sesuatu bekerja dalam kode hanya untuk menyadari bahwa itu pada dasarnya cacat dari sudut pandang pengalaman pengguna.

Pendapat saya sekarang adalah bahwa kertas dan pensil adalah alat perencanaan, desain, dan pengkodean terbaik. Setiap masalah penting yang dihadapi pada prinsipnya diselesaikan dengan kertas dan pensil; editor teks hanyalah sarana untuk mengeksekusi solusi. Tanpa sesuatu yang masuk akal di atas kertas, tidak ada peluang untuk bekerja dalam kode.

Hal berikutnya yang saya pelajari untuk menghargai, dan saya tidak tahu mengapa butuh waktu lama untuk memahaminya, adalah bahwa desain itu berulang. Saya secara tidak sadar membeli mitos Desainer dengan huruf kapital "D". Seseorang melayang-layang, memegang pensil mekanik mereka di tepi lurus, liris tentang tipografi dan menyeruput flat white (dengan susu kedelai, tentu saja) sebelum dengan santai melahirkan kesempurnaan visual yang sepenuhnya terbentuk ke dunia.

Ini, tidak berbeda dengan gagasan programmer 'jenius', adalah mitos. Jika Anda baru dalam desain tetapi mencoba tangan Anda, saya sarankan Anda tidak terpaku pada ide pertama yang mengganggu kegembiraan Anda. Sangat murah untuk mencoba variasi, jadi terimalah kemungkinan itu. Tak satu pun dari hal-hal yang saya suka tentang desain In/Out ada di desain pertama.

Saya percaya itu adalah novelis, Michael Crichton, yang menciptakan pepatah, "Buku tidak ditulis - mereka ditulis ulang". Terimalah bahwa setiap proses kreatif pada dasarnya sama. Sadarilah bahwa mempercayai proses mengurangi kecemasan dan latihan akan memperbaiki pemahaman dan penilaian estetika Anda.

Anda Adalah Pengembang Lain Di Proyek Anda

Saya tidak yakin apakah ini khusus untuk proyek yang hanya dikerjakan secara sporadis tetapi saya membuat asumsi bodoh berikut:

“Saya tidak perlu mendokumentasikan semua ini karena ini hanya saya, dan jelas saya akan memahaminya karena saya yang menulisnya.”

Tidak ada yang bisa lebih jauh dari kebenaran!

Ada malam ketika, selama 30 menit saya harus mengerjakan proyek, saya tidak melakukan apa pun selain mencoba memahami fungsi yang telah saya tulis enam bulan lalu. Alasan utama re-orientasi kode memakan waktu begitu lama adalah kurangnya komentar berkualitas dan variabel serta argumen fungsi yang diberi nama buruk.

Saya sangat rajin mengomentari kode dalam pekerjaan saya, selalu berhati-hati bahwa orang lain mungkin perlu memahami apa yang saya tulis. Namun, dalam hal ini, saya adalah orang lain itu. Apakah Anda benar-benar berpikir Anda akan mengingat cara kerja blok kode yang Anda tulis dalam waktu enam bulan? Anda tidak akan. Percayalah pada saya dalam hal ini, luangkan waktu dan komentari hal itu!

Saya telah membaca posting blog yang berjudul, Penyorot sintaks Anda salah tentang pentingnya komentar. Premis dasarnya adalah bahwa penyorot sintaks tidak boleh menghilangkan komentar, mereka harus menjadi hal yang paling penting. Saya cenderung setuju dan jika saya tidak segera menemukan tema editor kode yang menggores gatal itu, saya mungkin harus menyesuaikannya sendiri untuk tujuan itu!

Men-debug

Ketika Anda menemukan bug dan Anda telah menulis semua kode, tidak adil untuk menyarankan bahwa kesalahan tersebut kemungkinan berasal dari keyboard dan kursi. Namun, sebelum mengasumsikan itu, saya sarankan Anda menguji asumsi Anda yang paling dasar sekalipun. Misalnya, saya ingat menghabiskan lebih dari dua jam untuk memperbaiki masalah yang saya duga disebabkan oleh kode saya; di iOS saya tidak bisa mendapatkan kotak input saya untuk menerima entri teks. Saya tidak ingat mengapa itu tidak menghentikan saya sebelumnya, tetapi saya ingat frustrasi saya dengan masalah ini.

Ternyata itu karena, masih belum diperbaiki, bug di Safari. Ternyata di Safari jika Anda memiliki:

 * { user-select: none; }

Di lembar gaya Anda, kotak input tidak akan menerima input apa pun. Anda dapat menyiasatinya dengan:

 * { user-select: none; } input[type] { user-select: text; }

Yang merupakan pendekatan yang saya ambil dalam reset CSS "App Reset" saya. Namun, bagian yang benar-benar membuat frustrasi dari ini adalah saya telah mempelajari ini dan kemudian melupakannya. Ketika saya akhirnya memeriksa pelacakan bug WebKit saat memecahkan masalah, saya menemukan bahwa saya telah menulis solusi di utas laporan bug lebih dari setahun yang lalu lengkap dengan pengurangan!

Ingin Membangun Dengan Data? Pelajari Metode Array JavaScript

Mungkin satu-satunya kemajuan terbesar yang diambil keterampilan JavaScript saya dengan menjalani latihan pembuatan aplikasi ini adalah membiasakan diri dengan metode JavaScript Array. Saya sekarang menggunakannya setiap hari untuk semua iterasi dan kebutuhan manipulasi data saya. Saya tidak bisa cukup menekankan betapa bergunanya metode seperti map() , filter() , every() , findIndex() , find() dan reduce() . Anda dapat memecahkan hampir semua masalah data dengan mereka. Jika Anda belum memilikinya di gudang senjata Anda, bookmark https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array sekarang dan gali segera setelah Anda bisa. Run-down saya sendiri dari metode array favorit saya didokumentasikan di sini.

ES6 telah memperkenalkan penghemat waktu lain untuk memanipulasi array, seperti Set , Rest dan Spread . Manjakan saya saat saya membagikan satu contoh; dulu ada banyak kesalahan jika Anda ingin menghapus duplikat bahkan dari array datar sederhana. Tidak lagi.

Pertimbangkan contoh sederhana dari Array dengan entri duplikat, "Mr Pink":

 let myArray = [ "Mr Orange", "Mr Pink", "Mr Brown", "Mr White", "Mr Blue", "Mr Pink" ];

Untuk menghilangkan duplikat dengan ES6 JavaScript, Anda sekarang dapat melakukan:

 let deDuped = [...new Set(myArray)]; // deDuped logs ["Mr Orange", "Mr Pink", "Mr Brown", "Mr White", "Mr Blue"]

Sesuatu yang dulu membutuhkan solusi manual atau meraih perpustakaan sekarang dimasukkan ke dalam bahasa. Memang, pada Array pendek seperti itu mungkin tidak terdengar seperti masalah besar tetapi bayangkan berapa banyak waktu yang dihemat ketika melihat array dengan ratusan entri dan duplikat.

Pemeliharaan dan Keamanan

Apa pun yang Anda buat yang menggunakan NPM, meskipun hanya untuk alat pembuatan, memiliki kemungkinan rentan terhadap masalah keamanan. GitHub melakukan pekerjaan yang baik untuk membuat Anda mengetahui potensi masalah tetapi masih ada beberapa beban pemeliharaan.

Untuk sesuatu yang hanya merupakan proyek sampingan, ini bisa menjadi sedikit menyusahkan di bulan-bulan dan tahun-tahun berikutnya setelah perkembangan aktif.

Kenyataannya adalah bahwa setiap kali Anda memperbarui dependensi untuk memperbaiki masalah keamanan, Anda memperkenalkan kemungkinan merusak build Anda.

Selama berbulan-bulan, package.json saya terlihat seperti ini:

 { "dependencies": { "gulp": "^3.9.1", "postcss": "^6.0.22", "postcss-assets": "^5.0.0" }, "name": "In Out", "version": "1.0.0", "description": "simple utility to see who's in and who's out", "main": "index.js", "author": "Ben Frain", "license": "MIT", "devDependencies": { "autoprefixer": "^8.5.1", "browser-sync": "^2.24.6", "cssnano": "^4.0.4", "del": "^3.0.0", "gulp-htmlmin": "^4.0.0", "gulp-postcss": "^7.0.1", "gulp-sourcemaps": "^2.6.4", "gulp-typescript": "^4.0.2", "gulp-uglify": "^3.0.1", "postcss-color-function": "^4.0.1", "postcss-import": "^11.1.0", "postcss-mixins": "^6.2.0", "postcss-nested": "^3.0.0", "postcss-simple-vars": "^4.1.0", "typescript": "^2.8.3" } }

Dan pada Juni 2019, saya mendapatkan peringatan ini dari GitHub:

Tidak ada yang terkait dengan plugin yang saya gunakan secara langsung, semuanya adalah sub-dependensi dari alat build yang saya gunakan. Begitulah pedang bermata dua dari paket JavaScript. Dalam hal aplikasi itu sendiri, tidak ada masalah dengan In/Out; yang tidak menggunakan dependensi proyek apa pun. Tetapi karena kodenya ada di GitHub, saya merasa berkewajiban untuk mencoba dan memperbaiki semuanya.

Dimungkinkan untuk memperbarui paket secara manual, dengan beberapa perubahan pilihan pada package.json. Namun, baik Benang dan NPM memiliki perintah pembaruan sendiri. Saya memilih untuk menjalankan yarn upgrade-interactive yang memberi Anda cara sederhana untuk memperbarui berbagai hal dari terminal.

Tampaknya cukup mudah, bahkan ada tombol berwarna kecil untuk memberi tahu Anda pembaruan mana yang paling penting.

Anda dapat menambahkan flag --latest untuk memperbarui ke versi utama terbaru dari dependensi, bukan hanya versi patch terbaru. Untuk satu sen…

Masalahnya adalah, segala sesuatunya bergerak cepat di dunia paket JavaScript, jadi memperbarui beberapa paket ke versi terbaru dan kemudian mencoba membangun menghasilkan ini:

Karena itu, saya memutar kembali file package.json saya dan mencoba lagi kali ini tanpa flag --latest . Itu memecahkan masalah keamanan saya. Bukan yang paling menyenangkan yang saya alami pada Senin malam meskipun saya akan jujur.

Itu menyentuh bagian penting dari proyek sampingan mana pun. Bersikaplah realistis dengan harapan Anda.

Proyek Sampingan

Saya tidak tahu apakah Anda sama, tetapi saya menemukan bahwa optimisme dan kegembiraan yang membuat saya memulai proyek dan jika ada yang berhasil, rasa malu dan rasa bersalah membuat saya menyelesaikannya.

Bohong untuk mengatakan bahwa pengalaman membuat aplikasi kecil ini di waktu luang saya sangat menyenangkan. Ada saat-saat aku berharap aku tidak pernah membuka mulut tentang hal itu kepada siapa pun. Tapi sekarang sudah selesai, saya 100% yakin itu sepadan dengan waktu yang diinvestasikan.

Meskipun demikian, mungkin untuk mengurangi frustrasi dengan proyek sampingan seperti itu dengan bersikap realistis tentang berapa lama waktu yang dibutuhkan untuk memahami dan memecahkan masalah yang Anda hadapi. Hanya punya waktu 30 menit semalam, beberapa malam dalam seminggu? Anda masih dapat menyelesaikan proyek sampingan; hanya saja, jangan merasa tidak puas jika langkah Anda terasa dingin. Jika hal-hal tidak dapat menikmati perhatian penuh Anda, bersiaplah untuk kecepatan yang lebih lambat dan lebih stabil dari biasanya. Itu benar, entah itu coding, menyelesaikan kursus, belajar juggling atau menulis serangkaian artikel mengapa butuh waktu lama untuk menulis aplikasi web kecil!

Pengaturan Tujuan Sederhana

Anda tidak memerlukan proses yang mewah untuk menetapkan tujuan. Tetapi mungkin membantu untuk memecah hal-hal menjadi tugas-tugas kecil/pendek. Hal-hal sederhana seperti 'tulis CSS untuk menu drop-down' dapat dicapai dengan sempurna dalam ruang waktu yang terbatas. Sedangkan 'meneliti dan menerapkan pola desain untuk pengelolaan negara' mungkin tidak. Hancurkan semuanya. Kemudian, seperti Lego, potongan-potongan kecil itu menyatu.

Memikirkan proses ini sebagai pemecahan masalah yang lebih besar, saya teringat kutipan Bill Gates yang terkenal:

“Kebanyakan orang melebih-lebihkan apa yang bisa mereka lakukan dalam satu tahun dan meremehkan apa yang bisa mereka lakukan dalam sepuluh tahun.”

Ini dari seorang pria yang membantu membasmi Polio. Bill tahu barang-barangnya. Dengarkan Bill kalian semua.

Mengirim Sesuatu Lebih Baik Daripada Tidak Mengirim Apa-apa

Sebelum 'mengirim' aplikasi web ini, saya meninjau kodenya dan sangat kecewa.

Meskipun saya telah memulai perjalanan ini dari titik kenaifan dan pengalaman yang sama sekali, saya telah membuat beberapa pilihan yang layak ketika sampai pada bagaimana saya bisa merancang (jika Anda mau memaafkan istilah yang begitu besar) kodenya. Saya telah meneliti dan menerapkan pola desain dan menikmati semua yang ditawarkan pola itu. Sayangnya, ketika saya semakin putus asa untuk menyelesaikan proyek, saya gagal mempertahankan disiplin. Kode yang ada adalah pendekatan campur aduk yang nyata dan penuh dengan inefisiensi.

Dalam beberapa bulan sejak saya menyadari bahwa kekurangan itu tidak terlalu penting. Tidak juga.

Saya penggemar kutipan ini dari Helmuth von Moltke.

“Tidak ada rencana operasi yang meluas dengan kepastian di luar kontak pertama dengan kekuatan musuh utama.”

Itu telah diparafrasekan sebagai:

“Tidak ada rencana yang bertahan dari kontak pertama dengan musuh”.

Mungkin kita bisa mempersempitnya lebih jauh dan hanya pergi dengan "sialan terjadi"?

Saya dapat menduga bahwa saya menerima apa yang dikirimkan melalui analogi berikut.

Jika seorang teman mengumumkan bahwa mereka akan mencoba dan menjalankan maraton pertama mereka, mereka yang melewati garis finis adalah yang terpenting — saya tidak akan mencaci-maki mereka pada waktu finis mereka.

Saya tidak berangkat untuk menulis aplikasi web terbaik . Tugas yang saya tetapkan sendiri hanyalah merancang dan membuatnya.

Lebih khusus lagi, dari perspektif pengembangan, saya ingin mempelajari dasar-dasar bagaimana aplikasi web dibangun. Dari sudut pandang desain, saya ingin mencoba dan menyelesaikan beberapa masalah desain (walaupun sederhana). Membuat aplikasi kecil ini memenuhi tantangan tersebut dan beberapa tantangan lainnya. JavaScript untuk seluruh aplikasi hanya 5KB (gzip). Ukuran file kecil yang sulit saya dapatkan dengan kerangka kerja apa pun. Kecuali mungkin Svelte.

Jika Anda menetapkan tantangan seperti ini pada diri Anda sendiri, dan berharap pada titik tertentu untuk 'mengirimkan' sesuatu, tulis di awal mengapa Anda melakukannya. Jauhkan alasan-alasan di garis depan pikiran Anda dan dibimbing oleh mereka. Semuanya pada akhirnya semacam kompromi. Jangan biarkan cita-cita yang tinggi melumpuhkan Anda dari menyelesaikan apa yang Anda mulai lakukan.

Ringkasan

Secara keseluruhan, karena sudah setahun sejak saya mengerjakan In/Out, perasaan saya terbagi menjadi tiga area: hal-hal yang saya sesali, hal-hal yang ingin saya tingkatkan/perbaiki, dan kemungkinan-kemungkinan di masa depan.

Hal yang Saya Sesali

Seperti yang telah disinggung, saya kecewa karena tidak terpaku pada apa yang saya anggap sebagai metode yang lebih elegan untuk mengubah status aplikasi dan merendernya ke DOM. Pola pengamat, seperti yang dibahas di bagian kedua dari seri ini, yang memecahkan begitu banyak masalah dengan cara yang dapat diprediksi, akhirnya dikesampingkan karena 'pengiriman' proyek menjadi prioritas.

Saya merasa malu dengan kode saya pada awalnya tetapi pada bulan-bulan berikutnya, saya menjadi lebih filosofis. Jika saya tidak menggunakan lebih banyak teknik pejalan kaki di kemudian hari, ada kemungkinan yang sangat nyata bahwa proyek tersebut tidak akan pernah selesai. Mengeluarkan sesuatu ke dunia yang perlu ditingkatkan masih terasa lebih baik daripada tidak pernah dilahirkan ke dunia sama sekali.

Meningkatkan Masuk/Keluar

Selain memilih markup semantik, saya tidak menyediakan aksesibilitas. Ketika saya membangun In/Out saya yakin dengan aksesibilitas halaman web standar tetapi tidak cukup berpengetahuan untuk menangani aplikasi. Saya telah melakukan lebih banyak pekerjaan/penelitian di bidang itu sekarang, jadi saya akan senang meluangkan waktu untuk melakukan pekerjaan yang layak untuk membuat aplikasi ini lebih mudah diakses.

Implementasi desain yang direvisi dari fungsionalitas 'Tambah Orang' dilakukan dengan tergesa-gesa. Ini bukan bencana, hanya sedikit lebih kasar dari yang saya inginkan. Akan menyenangkan untuk membuatnya lebih licin.

Saya juga tidak mempertimbangkan layar yang lebih besar. Akan menarik untuk mempertimbangkan tantangan desain untuk membuatnya bekerja pada ukuran yang lebih besar, lebih dari sekadar membuatnya menjadi tabung konten.

Kemungkinan

Menggunakan localStorage bekerja untuk kebutuhan saya yang sederhana tetapi akan menyenangkan untuk memiliki penyimpanan data yang 'tepat' sehingga tidak perlu khawatir tentang mencadangkan data. Menambahkan kemampuan masuk juga akan membuka kemungkinan berbagi organisasi game dengan individu lain. Atau mungkin setiap pemain hanya bisa menandai apakah mereka bermain sendiri? Sungguh menakjubkan betapa banyak jalan untuk dijelajahi yang dapat Anda bayangkan dari awal yang sederhana dan sederhana.

SwiftUI untuk pengembangan aplikasi iOS juga menarik. Untuk seseorang yang hanya pernah bekerja dengan bahasa web, pada pandangan pertama, SwiftUI terlihat seperti sesuatu yang sekarang berani saya coba. Saya mungkin akan mencoba membangun kembali In/Out dengan SwiftUI — hanya untuk memiliki sesuatu yang spesifik untuk dibangun dan membandingkan pengalaman dan hasil pengembangan.

Jadi, inilah saatnya untuk menyelesaikan semuanya dan memberi Anda versi TL;DR dari semua ini.

Jika Anda ingin mempelajari cara kerja sesuatu di web, saya sarankan untuk melewatkan abstraksi. Singkirkan kerangka kerja, apakah itu CSS atau JavaScript sampai Anda benar-benar mengerti apa itu dong untuk Anda.

Desain itu berulang, rangkul proses itu.

Selesaikan masalah dalam media fidelitas terendah yang Anda inginkan. Jangan pergi ke kode jika Anda dapat menguji ide di Sketch. Jangan menggambarnya di Sketch jika Anda bisa menggunakan pena dan kertas. Tulis logikanya dulu. Kemudian tulis dalam kode.

Bersikaplah realistis tetapi jangan pernah putus asa. Mengembangkan kebiasaan mengurangi sesuatu hanya selama 30 menit sehari dapat membuahkan hasil. Fakta itu benar apa pun bentuk pencarian Anda.