Projektowanie i budowanie progresywnej aplikacji internetowej bez frameworka (część 3)

W pierwszej części tej serii wyjaśniliśmy, dlaczego powstał ten projekt. Mianowicie chęć nauczenia się, jak mała aplikacja internetowa może być stworzona w waniliowym JavaScript i nakłonienie programisty, który nie jest projektantem, do pracy nad swoim projektem.

W części drugiej wzięliśmy kilka podstawowych początkowych projektów i uruchomiliśmy wszystko z pewnym wyborem narzędzi i technologii. Omówiliśmy, jak i dlaczego zmieniły się części projektu oraz konsekwencje tych zmian.

W tej końcowej części omówimy przekształcenie podstawowej aplikacji internetowej w progresywną aplikację internetową (PWA) i „wysyłkę” aplikacji, zanim przyjrzymy się najbardziej wartościowym lekcjom wyciągniętym z prostej aplikacji internetowej In/Out:

• Ogromna wartość metod tablicowych JavaScript;
• Debugowanie;
• Kiedy jesteś jedynym programistą, jesteś drugim programistą;
• Projektowanie to rozwój;
• Bieżąca konserwacja i kwestie bezpieczeństwa;
• Praca nad projektami pobocznymi bez utraty rozumu, motywacji lub obu;
• Wysyłka jakiegoś produktu jest lepsza niż wysyłka braku produktu.

Tak więc, zanim przyjrzymy się wyciągniętym wnioskom, przyjrzyjmy się, jak przekształcić podstawową aplikację internetową napisaną w HTML, CSS i JavaScript w progresywną aplikację internetową (PWA).

Jeśli chodzi o łączny czas spędzony na tworzeniu tej małej aplikacji internetowej, przypuszczam, że będzie to prawdopodobnie około dwóch do trzech tygodni. Jednak, ponieważ robiono to w porwanych 30-60-minutowych kawałkach wieczorami, w rzeczywistości zajęło to około roku od pierwszego zatwierdzenia do przesłania tego, co uważam za wersję „1.0” w sierpniu 2018 r. Ponieważ dostałem aplikację „ funkcja zakończona”, a mówiąc prościej, na etapie, z którego byłem zadowolony, spodziewałem się dużego, końcowego impulsu. Widzisz, nie zrobiłem nic, aby przekształcić aplikację w progresywną aplikację internetową. Okazuje się, że to była najłatwiejsza część całego procesu.

Tworzenie progresywnej aplikacji internetowej

Dobrą wiadomością jest to, że jeśli chodzi o przekształcenie małej aplikacji opartej na JavaScript w „progresywną aplikację internetową”, istnieje mnóstwo narzędzi ułatwiających życie. Jeśli cofniesz się do pierwszej części tej serii, przypomnisz sobie, że bycie progresywną aplikacją internetową oznacza spełnienie szeregu kryteriów.

Aby sprawdzić, jak mierzy Twoja aplikacja internetowa, Twoim pierwszym przystankiem powinny być prawdopodobnie narzędzia Lighthouse w Google Chrome. Audyt Progressive Web App znajdziesz w zakładce „Audyty”.

To właśnie powiedział mi Lighthouse, kiedy po raz pierwszy wszedłem/wyszedłem przez niego.

Na początku In/Out otrzymywało tylko ⁵⁵ ⁄ ₁₀₀ punktów za progresywną aplikację internetową. Jednak stamtąd wziąłem to do ¹⁰⁰ ⁄ ₁₀₀ w niecałą godzinę!

Celowość poprawienia tego wyniku miała niewiele wspólnego z moimi umiejętnościami. To po prostu dlatego, że Lighthouse powiedział mi dokładnie, co należy zrobić!

Kilka przykładów wymaganych kroków: dołącz plik manifest.json (zasadniczo plik JSON zawierający metadane dotyczące aplikacji), dodaj całą masę metatagów w nagłówku, zamień obrazy, które były wbudowane w CSS na standardowe obrazy z odnośnikami URL, i dodaj kilka obrazów na ekranie głównym.

Tworzenie wielu obrazów ekranu głównego, tworzenie pliku manifestu i dodawanie wielu metatagów może wydawać się dużo do zrobienia w mniej niż godzinę, ale istnieją wspaniałe aplikacje internetowe, które pomagają w tworzeniu aplikacji internetowych. Jakie to miłe! Użyłem https://app-manifest.firebaseapp.com. Podaj mu trochę danych o swojej aplikacji i logo, kliknij Prześlij, a otrzymasz plik zip zawierający wszystko, czego potrzebujesz! Od tego momentu pozostaje tylko czas na kopiowanie i wklejanie.

Rzeczy, które odłożyłem na jakiś czas z powodu braku wiedzy, takie jak Service Worker, również zostały dodane dość łatwo dzięki licznym wpisom na blogu i witrynom poświęconym pracownikom usług, takim jak https://serviceworke.rs. Dzięki pracownikowi serwisu oznaczało to, że aplikacja może działać w trybie offline, co jest wymaganą funkcją progresywnej aplikacji internetowej.

Chociaż nie jest to ściśle związane z tworzeniem aplikacji PWA, bardzo przydatna była również zakładka „zasięg” w narzędziach Chrome Dev. Po tak wielu sporadycznych iteracjach w projekcie i kodzie przez wiele miesięcy, przydatne było uzyskanie jasnego wskazania, gdzie występuje nadmiarowy kod. Znalazłem kilka starych funkcji zaśmiecających kod, o których po prostu zapomniałem!

Krótko mówiąc, po zapoznaniu się z zaleceniami audytu Lighthouse poczułem się jak zwierzak nauczyciela:

W rzeczywistości przekształcenie aplikacji w progresywną aplikację internetową było w rzeczywistości niezwykle proste.

Po zakończeniu tego ostatniego etapu rozwoju przesłałem małą aplikację do subdomeny mojej witryny i to było to.

Z mocą wsteczną

Minęły miesiące od zaparkowania mojej małej aplikacji webowej.

Od miesięcy korzystałem z aplikacji przypadkowo. Rzeczywistość jest taka, że ​​duża część organizacji sportów zespołowych, którą nadal zajmuję, odbywa się za pośrednictwem wiadomości tekstowych. Aplikacja jest jednak zdecydowanie łatwiejsza niż spisywanie, kto wchodzi i wychodzi, niż znajdowanie skrawka papieru każdego wieczoru w grze.

Tak więc prawda jest taka, że ​​nie jest to usługa niezbędna. Nie stawia też żadnych poprzeczek dla rozwoju ani projektowania. Nie mogę powiedzieć, że jestem z niego w 100% zadowolony. Właśnie dotarłem do punktu, w którym z radością go porzuciłem.

Ale to nigdy nie było celem ćwiczenia. Wiele wyniosłem z tego doświadczenia. Poniżej znajdują się to, co uważam za najważniejsze dania na wynos.

Projekt to rozwój

Na początku nie doceniałem dostatecznie designu. Zacząłem ten projekt wierząc, że mój czas spędzony na szkicowaniu za pomocą bloczka i pióra lub w aplikacji Sketch, był czasem, który można lepiej spędzić na kodowaniu. Okazuje się jednak, że kiedy od razu przechodziłem do kodowania, często byłem po prostu zajętym głupcem. Odkrywanie koncepcji w pierwszej kolejności przy możliwie najniższej wierności, na dłuższą metę zaoszczędziło znacznie więcej czasu.

Na początku było wiele okazji, w których spędzano godziny, aby coś działało w kodzie, tylko po to, by zdać sobie sprawę, że jest to fundamentalnie wadliwe z punktu widzenia doświadczenia użytkownika.

Moim zdaniem papier i ołówek to najlepsze narzędzia do planowania, projektowania i kodowania. Każdy poważny problem rozwiązywany był głównie za pomocą papieru i ołówka; edytor tekstu jest jedynie środkiem do wykonania rozwiązania. Bez czegoś, co ma sens na papierze, nie ma szans na pracę w kodzie.

Następną rzeczą, którą nauczyłem się doceniać i nie wiem, dlaczego zajęło mi tak dużo czasu, jest to, że projektowanie jest iteracyjne. Podświadomie wpadłem w mit Projektanta przez duże „D”. Ktoś miota się wokół, trzymając mechaniczny ołówek za proste krawędzie, woskując lirycznie kroje pisma i popijając płaską biel (oczywiście z mlekiem sojowym), zanim przypadkowo narodzi się na świat w pełni ukształtowana wizualna doskonałość.

To, podobnie jak pojęcie „genialnego” programisty, jest mitem. Jeśli jesteś nowy w projektowaniu, ale próbujesz swoich sił, sugeruję, abyś nie czepiał się pierwszego pomysłu, który wzbudza Twoje podekscytowanie. Tak tanie jest wypróbowywanie różnych odmian, więc skorzystaj z tej możliwości. Żadna z rzeczy, które lubię w projekcie In/Out, nie było w pierwszych projektach.

Uważam, że to pisarz Michael Crichton ukuł maksymę: „Książki nie są pisane — są przepisywane”. Zaakceptuj, że każdy proces twórczy jest zasadniczo taki sam. Miej świadomość, że zaufanie do procesu zmniejsza niepokój, a praktyka udoskonali twoje estetyczne zrozumienie i osąd.

Jesteś drugim deweloperem w swoim projekcie

Nie jestem pewien, czy dotyczy to projektów, nad którymi pracuje się tylko sporadycznie, ale przyjąłem następujące nierozważne założenie:

„Nie muszę tego dokumentować, ponieważ to tylko ja, i oczywiście zrozumiem to, ponieważ to napisałem”.

Nic nie może być dalej od prawdy!

Były wieczory, kiedy przez 30 minut, które musiałem pracować nad projektem, nie robiłem nic poza próbą zrozumienia funkcji, którą napisałem sześć miesięcy temu. Głównymi przyczynami, dla których reorientacja kodu trwała tak długo, był brak wysokiej jakości komentarzy oraz źle nazwane zmienne i argumenty funkcji.

Jestem bardzo sumienny w komentowaniu kodu w mojej codziennej pracy, zawsze świadomy, że ktoś inny może potrzebować, aby zrozumieć to, co piszę. Jednak w tym przypadku byłem tym kimś innym. Czy naprawdę myślisz, że będziesz pamiętać, jak działa blok kodu, który napisałeś za sześć miesięcy? Nie będziesz. Zaufaj mi, poświęć trochę czasu i skomentuj to!

Od tamtego czasu przeczytałem wpis na blogu zatytułowany, Twój podświetlacz składni myli się w kwestii ważności komentarzy. Podstawowym założeniem jest to, że wyróżnienia składni nie powinny zanikać komentarzy, powinny być najważniejszą rzeczą. Jestem skłonny się zgodzić i jeśli wkrótce nie znajdę motywu edytora kodu, który drapie ten swędzenie, być może będę musiał sam dostosować go do tego celu!

Debugowanie

Kiedy trafisz na błędy i napiszesz cały kod, nie jest niesprawiedliwe sugerowanie, że błąd prawdopodobnie pochodzi między klawiaturą a krzesłem. Jednak zanim to założysz, sugerowałbym przetestowanie nawet najbardziej podstawowych założeń. Na przykład pamiętam, że zajęło mi ponad dwie godziny, aby naprawić problem, który zakładałem, że był spowodowany przez mój kod; w iOS po prostu nie mogłem uzyskać pola wprowadzania, aby zaakceptować wpisywanie tekstu. Nie pamiętam, dlaczego wcześniej mnie to nie powstrzymało, ale pamiętam moją frustrację związaną z tym problemem.

Okazuje się, że było to spowodowane błędem Safari, który nie został jeszcze naprawiony. Okazuje się, że w Safari, jeśli masz:

 * { user-select: none; }

W twoim arkuszu stylów pola wejściowe nie przyjmą żadnych danych wejściowych. Możesz to obejść za pomocą:

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

Takie podejście przyjmuję podczas resetowania CSS „App Reset”. Jednak naprawdę frustrujące było to, że już się tego nauczyłem, a potem o tym zapomniałem. Kiedy w końcu zabrałem się za sprawdzanie śledzenia błędów WebKit podczas rozwiązywania problemu, odkryłem, że ponad rok temu napisałem obejście w wątku zgłaszania błędów wraz z redukcją!

Chcesz budować z danymi? Naucz się metod tablic JavaScript

Być może największym postępem, jaki dokonałem w moich umiejętnościach w zakresie JavaScriptu, wykonując to ćwiczenie budowania aplikacji, było zapoznanie się z metodami JavaScript Array. Obecnie używam ich codziennie do wszystkich moich potrzeb związanych z iteracją i manipulacją danymi. Nie mogę wystarczająco podkreślić, jak przydatne są metody, takie jak map() , filter() , every() , findIndex() , find() i Reduce( reduce() . Za ich pomocą możesz rozwiązać praktycznie każdy problem z danymi. Jeśli nie masz ich jeszcze w swoim arsenale, dodaj teraz zakładkę https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array i zaglądaj, gdy tylko będziesz w stanie. Tutaj udokumentowane jest moje własne zestawienie moich ulubionych metod tablicowych.

ES6 wprowadził inne oszczędzające czas przy manipulowaniu tablicami, takie jak Set , Rest i Spread . Rozpieszczaj mnie, gdy dzielę się jednym przykładem; Kiedyś było mnóstwo bzdur, jeśli chciałeś usunąć duplikaty nawet z prostej płaskiej tablicy. Nigdy więcej.

Rozważ ten prosty przykład tablicy ze zduplikowanym wpisem „Pan Pink”:

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

Aby pozbyć się duplikatów za pomocą JavaScript ES6, możesz teraz po prostu zrobić:

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

Coś, co kiedyś wymagało ręcznego przetoczenia rozwiązania lub sięgnięcia po bibliotekę, jest teraz wypiekane w języku. Trzeba przyznać, że na takiej krótkiej tablicy, która może nie brzmieć jak wielka sprawa, ale wyobraź sobie, ile czasu zaoszczędzisz patrząc na tablice z setkami wpisów i duplikatów.

Konserwacja i bezpieczeństwo

Wszystko, co tworzysz, co wykorzystuje NPM, nawet jeśli chodzi tylko o narzędzia do kompilacji, niesie ze sobą możliwość bycia podatnym na problemy z bezpieczeństwem. GitHub wykonuje dobrą robotę, informując Cię o potencjalnych problemach, ale nadal istnieje pewne obciążenie związane z utrzymaniem.

Dla czegoś, co jest zwykłym projektem pobocznym, może to być trochę uciążliwe w miesiącach i latach następujących po aktywnym rozwoju.

W rzeczywistości za każdym razem, gdy aktualizujesz zależności, aby naprawić problem z bezpieczeństwem, wprowadzasz możliwość zepsucia swojej kompilacji.

Przez wiele miesięcy mój package.json wyglądał tak:

 { "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" } }

A do czerwca 2019 otrzymywałem te ostrzeżenia z GitHub:

Żadna nie była związana z wtyczkami, których używałem bezpośrednio, wszystkie były podrzędnymi zależnościami narzędzi do budowania, których używałem. Taki jest obosieczny miecz pakietów JavaScript. Jeśli chodzi o samą aplikację, nie było problemu z wejściem/wyjściem; który nie używał żadnej z zależności projektu. Ale ponieważ kod był na GitHub, czułem się zobowiązany do próby naprawienia rzeczy.

Możliwe jest ręczne aktualizowanie pakietów, z kilkoma wybranymi zmianami w pliku package.json. Jednak zarówno Yarn, jak i NPM mają własne polecenia aktualizacji. Zdecydowałem się uruchomić yarn upgrade-interactive która zapewnia prosty sposób aktualizowania rzeczy z terminala.

Wydaje się dość proste, jest nawet mały kolorowy klawisz, który informuje, które aktualizacje są najważniejsze.

Możesz dodać flagę --latest , aby zaktualizować do najnowszej głównej wersji zależności, a nie tylko do najnowszej załatanej wersji. Za grosz…

Problem polega na tym, że w świecie pakietów JavaScript wszystko toczy się szybko, więc zaktualizowanie kilku pakietów do najnowszej wersji, a następnie próba kompilacji, skutkowała tym:

W związku z tym wycofałem plik package.json i tym razem spróbowałem ponownie bez flagi --latest . To rozwiązało moje problemy z bezpieczeństwem. Nie jest to najlepsza zabawa, jaką miałem w poniedziałkowy wieczór, chociaż będę szczery.

To dotyka ważnej części każdego projektu pobocznego. Realistyczne podejście do Twoich oczekiwań.

Projekty poboczne

Nie wiem, czy jesteś taki sam, ale stwierdziłem, że zawrotny optymizm i podekscytowanie sprawiają, że zaczynam projekty, a jeśli już, to zażenowanie i poczucie winy sprawiają, że je kończę.

Skłamałbym, gdybym powiedział, że doświadczenie tworzenia tej malutkiej aplikacji w wolnym czasie było zabawne. Były sytuacje, w których żałowałam, że nigdy przed nikim nie otworzyłam na to ust. Ale teraz to się skończyło, jestem w 100% przekonany, że warto było zainwestować czas.

To powiedziawszy, możliwe jest złagodzenie frustracji związanej z takim pobocznym projektem poprzez realistyczne określenie, ile czasu zajmie zrozumienie i rozwiązanie problemów, z którymi się borykasz. Masz tylko 30 minut na noc, kilka nocy w tygodniu? Nadal możesz ukończyć projekt poboczny; po prostu nie bądź niezadowolony, jeśli twoje tempo wydaje się lodowate. Jeśli coś nie może cieszyć się twoją pełną uwagą, przygotuj się na wolniejsze i bardziej stabilne tempo, niż być może do tego przywykłeś. To prawda, niezależnie od tego, czy chodzi o kodowanie, ukończenie kursu, naukę żonglowania, czy pisanie serii artykułów o tym, dlaczego napisanie małej aplikacji internetowej zajęło tak dużo czasu!

Proste wyznaczanie celów

Nie potrzebujesz wymyślnego procesu wyznaczania celów. Ale może pomóc rozbicie rzeczy na małe/krótkie zadania. Rzeczy tak proste, jak „napisz CSS dla menu rozwijanego” są doskonale osiągalne w ograniczonym czasie. Podczas gdy „badanie i wdrażanie wzorca projektowego dla zarządzania państwem” prawdopodobnie nie jest. Rozbijaj rzeczy. Następnie, tak jak Lego, maleńkie kawałki łączą się.

Myśląc o tym procesie jako o usuwaniu większego problemu, przypomina mi się słynny cytat Billa Gatesa:

„Większość ludzi przecenia to, co może zrobić w ciągu jednego roku, i nie docenia tego, co może zrobić w ciągu dziesięciu lat”.

To od człowieka, który pomaga zwalczyć polio. Bill zna się na rzeczy. Posłuchajcie wszyscy Billa.

Wysyłka czegoś jest lepsza niż wysyłka niczego

Przed „wysyłką” tej aplikacji internetowej przejrzałem kod i byłem całkowicie zniechęcony.

Chociaż wyruszyłem w tę podróż z punktu kompletnej naiwności i braku doświadczenia, dokonałem kilku przyzwoitych wyborów, jeśli chodzi o sposób, w jaki mógłbym zaprojektować (jeśli wybaczysz tak wspaniałe określenie) kod. Zbadałem i zaimplementowałem wzorzec projektowy i cieszyłem się wszystkim, co ten wzorzec miał do zaoferowania. Niestety, gdy byłem bardziej zdesperowany, aby zakończyć projekt, nie udało mi się utrzymać dyscypliny. Kod w obecnej postaci jest prawdziwą mieszanką podejść i obfituje w nieefektywność.

W ciągu ostatnich miesięcy zdałem sobie sprawę, że te niedociągnięcia tak naprawdę nie mają znaczenia. Nie całkiem.

Jestem fanem tego cytatu z Helmuth von Moltke.

„Żaden plan działań nie wykracza z całą pewnością poza pierwszy kontakt z głównymi siłami wroga”.

Zostało to sparafrazowane jako:

„Żaden plan nie przetrwa pierwszego kontaktu z wrogiem”.

Może możemy sprowadzić to dalej i po prostu iść z „gówno zdarza się”?

Mogę się domyślić, że pogodziłem się z tym, co zostało wysłane, korzystając z następującej analogii.

Gdyby znajomy ogłosił, że spróbuje przebiec swój pierwszy maraton, liczy się tylko przekroczenie linii mety — nie krytykowałbym ich za czas na mecie.

Nie miałem zamiaru pisać najlepszej aplikacji internetowej. Zadaniem, które sobie wyznaczyłem, było po prostu zaprojektowanie i wykonanie.

Dokładniej, z perspektywy programistycznej, chciałem poznać podstawy budowy aplikacji internetowej. Z punktu widzenia projektowania chciałem spróbować samodzielnie rozwiązać niektóre (choć proste) problemy projektowe. Stworzenie tej małej aplikacji sprostało tym wyzwaniom, a nawet niektórym. JavaScript dla całej aplikacji miał zaledwie 5 KB (skompresowany w formacie gzip). Mały rozmiar pliku, do którego trudno byłoby się dostać z dowolnym frameworkiem. Może z wyjątkiem Svelte.

Jeśli stawiasz sobie tego rodzaju wyzwanie i spodziewasz się, że w pewnym momencie coś „wyślesz”, zapisz na początku, dlaczego to robisz. Utrzymuj te powody na pierwszym planie i kieruj się nimi. Ostatecznie wszystko jest jakimś kompromisem. Nie pozwól, aby wzniosłe ideały sparaliżowały Cię przed ukończeniem tego, co zamierzasz zrobić.

Streszczenie

Ogólnie rzecz biorąc, minął już rok od czasu, gdy pracowałem nad In/Out, moje odczucia dzielą się zasadniczo na trzy obszary: rzeczy, których żałowałem, rzeczy, które chciałbym poprawić/naprawić i przyszłe możliwości.

Rzeczy, których żałowałem

Jak już wspomniałem, byłem rozczarowany, że nie trzymałem się tego, co uważałem za bardziej elegancką metodę zmiany stanu aplikacji i renderowania jej do DOM. Wzorzec obserwatora, omówiony w drugiej części tej serii, który rozwiązywał tak wiele problemów w przewidywalny sposób, został ostatecznie odrzucony, ponieważ priorytetem stało się „wysyłka” projektu.

Na początku byłem zawstydzony swoim kodem, ale w kolejnych miesiącach stałem się bardziej filozoficzny. Gdybym później nie użył więcej technik pieszego, istnieje bardzo realna możliwość, że projekt nigdy by się nie zakończył. Wydawanie czegoś na świat, co wymaga poprawy, nadal wydaje się lepsze, niż w ogóle nie narodziny na świat.

Poprawa wejścia/wyjścia

Poza wyborem znaczników semantycznych nie robiłem afordancji w zakresie dostępności. Kiedy budowałem In/Out, byłem pewien standardowej dostępności strony internetowej, ale nie miałem wystarczającej wiedzy, aby poradzić sobie z aplikacją. Zrobiłem teraz znacznie więcej prac/badań w tej dziedzinie, więc chciałbym poświęcić czas na przyzwoitą pracę, aby uczynić tę aplikację bardziej dostępną.

Wdrażanie poprawionego projektu funkcji „Dodaj osobę” zostało przyspieszone. To nie jest katastrofa, tylko trochę trudniejsze niż bym chciał. Byłoby fajnie, żeby to było ładniejsze.

Nie brałem też pod uwagę większych ekranów. Interesujące byłoby rozważenie wyzwań projektowych związanych z działaniem w większych rozmiarach, poza zwykłym uczynieniem go tubą treści.

Możliwości

Korzystanie z localStorage działało dla moich uproszczonych potrzeb, ale byłoby miło mieć „właściwy” magazyn danych, więc nie trzeba było się martwić o tworzenie kopii zapasowych danych. Dodanie możliwości logowania otworzyłoby również możliwość współdzielenia organizacji gry z inną osobą. A może każdy gracz mógł po prostu zaznaczyć, czy gra sam? To zdumiewające, jak wiele dróg do zbadania można sobie wyobrazić z tak prostych i skromnych początków.

Intrygujący jest również SwiftUI dla tworzenia aplikacji na iOS. Dla kogoś, kto kiedykolwiek pracował tylko z językami internetowymi, na pierwszy rzut oka SwiftUI wygląda jak coś, do czego teraz jestem ośmielony. Prawdopodobnie spróbowałbym przebudować In/Out za pomocą SwiftUI — tylko po to, by mieć coś konkretnego do zbudowania i porównać doświadczenie programistyczne i wyniki.

A więc nadszedł czas, aby to wszystko podsumować i dać ci wersję TL;DR tego wszystkiego.

Jeśli chcesz dowiedzieć się, jak coś działa w sieci, sugeruję pominięcie abstrakcji. Porzuć frameworki, czy to CSS, czy JavaScript, aż naprawdę zrozumiesz, co dla ciebie robią.

Projektowanie jest iteracyjne, obejmij ten proces.

Rozwiązuj problemy w medium o najniższej wierności, jakim dysponujesz. Nie idź do kodu, jeśli możesz przetestować pomysł w Sketchu. Nie rysuj tego w Sketchu, jeśli możesz użyć pióra i papieru. Najpierw wypisz logikę. Następnie napisz to w kodzie.

Bądź realistą, ale nigdy nie zniechęcaj się. Wyrobienie w sobie nawyku kruszenia czegoś przez zaledwie 30 minut dziennie może przynieść rezultaty. Ten fakt jest prawdą, niezależnie od formy, jaką przybiera twoje poszukiwanie.