MVP aplikacji w rekordowym czasie z Bubble: Data Type - User
Logika
17 godz. 49 min · Biznes i Automatyzacje
Krzysiek PiekarzAutomation Specialist / No-code DeveloperCzego się nauczysz
- Pracy z edytorem Bubble na bardziej zaawansowanym poziomie
- Tego jak wyszukiwać, filtrować i edytować rekordy z bazy danych wbudowanej w Bubble
- Czym są privacy rules - czyli jak zabezpieczyć dostęp do naszych danych przed nieuprawnionym dostępem
- Praktycznej pracy z frontend i backend workflows
- Dodatkowo wdrożymy do naszej aplikacji system płatności Stripe oraz powiadomienia mailowe z wykorzystaniem np. SendGrid i innych
- Pokażę Ci jak łączyć się z zewnętrznymi API poprzez dostępny w Bubble plugin API Connector
- A także jak rozszerzyć funkcjonalność naszej aplikacji poprzez proste automatyzacje z serwisem Make
- Na koniec zajmiemy się również podpięciem naszej customowej domeny oraz publikacją aplikacji
Czy w Twojej głowie pojawił się pomysł na aplikację, która zrewolucjonizuje świat na miarę Facebook'a, Instagrama albo Airbnb? A może zgłosił się do Ciebie klient, który chce przetestować i wdrożyć swój projekt w jak najszybszym czasie?Jeśli tak było to na pewno zadajesz sobie teraz kolejne pytanie - od czego zacząć? Czy muszę posiadać odpowiednią wiedzę programistyczną? Na jaki język programowania się zdecydować lub z jakiego gotowego framework'u skorzystać? A może zatrudnić profesjonalnego designera i software house, który pozwoli mi zrealizować ten projekt?Niezależnie od tego czy czy zdecydujesz się działać sam/a, czy też przekażesz projekt do zewnętrznej agencji i tak staniesz przed kolejnym dylematem jakim jest nauka programowania lub konieczność przepalenia nawet setek tysięcy złoty na coś, co może okazać się niewypałem.Na szczęście szybki rozwój narzędzi no-code sprawia, że możesz wybrać jeszcze trzecie wyjście. Zaprojektować, zbudować i wypuścić w świat swoją wymarzoną aplikację tylko za pomocą własnych sił i to bez konieczności posiadania specjalistycznej wiedzy programistycznej, a nawet posiadając jedynie podstawową znajomość narzędzi do design'u.Pamiętaj również o tym, że projekt ten podzieliłem na dwie części. Ten kurs to druga część, w której zapoznamy się z bardziej zaawansowanymi opcjami, jakie zapewnia nam edytor Bubble. Zdobytą w ten sposób wiedzę teoretyczną wykorzystamy od razu w praktyce dodając do naszego statycznego designu odpowiednią logikę, dzięki czemu nasz finalny projekt będzie już w pełni działającą aplikacją.Jeśli tylko potrafisz w podstawowym zakresie pracować z edytorem Bubble, budować w nim design aplikacji i rozumiesz czym są option sets oraz workflows to posiadanie wiedzy z poprzedniego kursu nie jest koniecznie wymagane. Natomiast szczerze zachęcam Cię przynajmniej do przejrzenia materiałów z pierwszej części, gdzie skupiamy się właśnie na podstawach, ponieważ teraz będziemy efektywnie przechodzić do bardziej zaawansowanych tematów i rozbudowywać naszą aplikację.
Czego nauczysz się w ramach tego Kursu?
W tym kursie „MVP aplikacji w rekordowym czasie z Bubble (Logika)” nauczę Cię jak zamienić statyczny layout na pełnoprawną aplikację. Poruszymy takie tematy jak praca z bazą danych, privacy rules oraz bardziej zaawansowane workflows, które dodamy zarówno na froncie jak i backendzie naszej aplikacji. Dzięki zdobytej wiedzy dodamy logikę wszędzie tam, gdzie tego wymaga nasz projekt, a dodatkowo wzbogacimy go o możliwość płatności poprzez najbardziej popularny na świecie system jakim jest Stripe. To jednak nie koniec ponieważ przygotowałem dla Ciebie również szereg innych ważnych zagadnień, które omówimy i wykorzystamy w praktyce.W ramach nauki skupimy się na jak najbardziej praktycznym podejściu. Zapomnij o długich i nudnych lekcjach pełnych teorii, które zapomnisz zaraz po obejrzeniu. Będziemy budować a nie debatować! W ten sposób nauczysz się pracować z edytorem Bubble na poziomie zaawansowanym. Zrozumiesz jak zabezpieczyć swoje dane przed nieuprawnionym dostępem, w jaki sposób pobierać i dynamicznie filtrować rekordy z bazy danych. A także jak wykorzystać auto-binding by móc je aktualizować bez wykorzystania skomplikowanych workflows.Dodamy do naszej aplikacji prosty komunikator, który pozwoli na wymianę wiadomości pomiędzy użytkownikami. Zadbamy również o możliwość wysyłania powiadomień mailowych poprzez zewnętrzne serwisy by ich wygląd był zgodny z naszym brandem. Nie zabraknie również takich tematów jak SSO z Google czy też proste automatyzacje z wykorzystaniem serwisu Make.
Dla kogo jest ten kurs?
Materiał szkoleniowy został zaprojektowany tak, aby mogło z niego skorzystać jak najszersze grono odbiorców. Nieważne czy jesteś totalnym laikiem, czy też posiadasz już wiedzę z zakresu programowania lub designu, na pewno znajdziesz tu coś dla siebie. A więc kto jeszcze może skorzystać z wiedzy zawartej w tym kursie?
Zanim przystąpimy do praktycznych działań i zdefiniowaniu tego, jak ma wyglądać
rekord naszego użytkownika w bazie danych, jeszcze tylko kilka słów teorii.
Jeżeli masz doświadczenie programistyczne, to doskonale zdajesz sobie sprawę z faktu,
że wybór właściwej bazy danych dla projektu może być
niesamowicie trudnym zadaniem.
Na rynku dostępnych jest wiele różnych rozwiązań i decyzja, którą należy wybrać
zależy od potrzeb Twojej wiedzy oraz oczywiście umiejętności.
Na szczęście w przypadku Babel ten proces został dla nas maksymalnie uproszczony,
ponieważ otrzymujemy wbudowaną bazę danych, z której możemy korzystać w ramach
naszej aplikacji, bez ponoszenia dodatkowych kosztów i czasami
dość skomplikowanej konfiguracji.
Odpowiedź na to, czy jest to dobre rozwiązanie, czy też niekoniecznie
pozostawiam już Tobie, ale moim zdaniem to, że otrzymujemy
wbudowaną bazę danych, którą Babel dodatkowo wyposażył w cały
szereg przydatnych rozwiązań, z pewnością ułatwi wkroczenie tego świata osobom,
które nie miały z tym tematem do tej pory do czynienia.
Czy znajdziemy szybsze i lepsze rozwiązania bazodanowe
niż to, co oferuje Babel?
Pewnie tak, ale czy da się je zaimplementować w tak prosty
sposób, to już chyba niekoniecznie.
Pamiętaj, że za pomocą np.
API Connector, czyli pluginu dostępnego w Babel, możesz wykorzystać REST API, aby
podłączyć się do innych baz danych, ale wymaga to już nieco więcej
wiedzy i umiejętności.
My w obrębie tego kursu wykorzystamy to, co dostajemy w pakiecie i moim zdaniem
jest to całkiem dobre rozwiązanie.
Ponieważ programiści z Babel nieustannie pracują nad tym, aby ulepszyć swoją bazę
i uczynić ją jeszcze szybszą i niezawodną.
To by było na tyle teorii.
Przejdźmy teraz już do praktycznych działań.
A więc przejdźmy do naszej bazy danych, czyli tutaj do zakładki Data Types.
Zaczynamy zawsze od tego.
Jak już wiesz, pierwszej części kursu, Babel nie tylko daje nam dostęp do bazy
danych, ale dodatkowo została ona wyposażona od razu w jeden podstawowy typ
danych, czyli właśnie data type, jakim jest Data Type.
Właśnie tutaj User.
Jest to oczywiście całkowicie zrozumiałe, ponieważ trudno mi wyobrazić sobie
aplikację, która nie posiadałaby tego podstawowego komponentu, jakim są
użytkownicy z niej korzystający.
Zresztą w pierwszej części bardzo pobieżnie zahaczyliśmy o ten temat.
Mówiłem o tym, w jaki sposób możemy dodawać rekordy do naszej bazy
użytkowników, czyli wykorzystać przygotowane dla nas gotowe akcje, które
pozwolą nam w prosty sposób zarejestrować nowego użytkownika w naszej aplikacji.
Udało nam się nawet to zrobić tworząc dwa podstawowe konta, czyli konto
hosta oraz konto gościa.
Natomiast nasz Data Type User na chwilę obecną wygląda bardzo skromnie i posiada
właściwie tylko jedno pole, które rzeczywiście posiadać powinien, a
więc User tip, czyli tutaj to pole.
Za pomocą tego pola linkujemy do naszego Options.
OS User Type jesteśmy w stanie określić jaki typ konta powinien
posiadać dany użytkownik.
I jest to podręcznikowy wręcz przykład tego, do czego powinniśmy
Option sety wykorzystywać.
Role w naszym serwisie określamy z góry my, czyli twórca aplikacji
i z reguły są one stałe.
Dodatkowo bazując na User type dajemy zarejestrowanym użytkownikom dostęp do
określonych funkcjonalności przeznaczonych tylko dla nich.
I tak konto typu host pozwala na tworzenie listingu, czyli mówiąc prościej na
dodawanie ofert lokali do wynajęcia.
Zaś użytkownicy o kontach typu guest będą mogli skorzystać z takiej oferty
i zabukować z nich swój pobyt.
Oczywiście nic nie stoi na przeszkodzie, byś w przyszłości spróbował rozbudować
swój serwis i przydzielał jednemu konto różne role.
Czyli zamiast linkowania do jednego typu wstawił właśnie listę.
Ale my w ramach kursu uznajemy, że każdy użytkownik może posiadać tylko jedną rolę.
I tego się będziemy trzymać.
Oprócz pola User Type nasz user posiada też kilka pól pomocniczych.
Które dodaliśmy w pierwszym sprincie, ale służą one tylko i wyłącznie do tego,
byśmy mogli przełączyć w dashboard widok ze stanu pustego np.
zakładki Booking na finalną, którą chcemy uzyskać.
Jeżeli jesteś ciekawy jak to wygląda, to przejdźmy jeszcze do aplikacji
Zaloguj się, czyli Sign.
Wykorzystajmy np. konto gościa.
Jak widzisz mam tutaj przycisk Show Empty State.
Teraz zmieniam sobie po prostu te wartości tutaj.
Będzie to np. Booking z numbers wartości 0 na wartość 1.
I w ten sposób jestem sobie w stanie przełączać te widoki.
Jeżeli nie wiesz jak to działa to znowu odsyłam Cię do sprintu numer 1.
Ale wróćmy tutaj do naszego Data Type.
Wiemy jak wygląda nasz data type, czyli User.
I zwróć proszę uwagę, że tu zawsze stosujemy Babel liczbę pojedynczą.
Z tego prostego powodu, że na podstawie takiego pojedynczego rekordu i tego jak go
zdefiniowaliśmy, utworzona zostanie dla nas automatycznie tabela.
Aby do niej przejść klikamy w zakładkę AppData.
Jest to odpowiednik tej niebieskiej przestrzeni z AR Table.
Jak widzisz mamy tutaj już pierwszą tabelę, czyli All Users.
Dodatkowo w tym przypadku Babel wziął sobie właśnie ten data type w formie
pojedynczej i zmienię go w liczbę mnogą, czyli po prostu ją są sobie user
i z tego utworzył all users.
Stąd też ta wcześniejsza uwaga by tam stosować np.
właśnie taką nazwę pojedynczą usera.
Dodatkowo jak widzisz ten widok już nieco bardziej przypomina to, co
kojarzysz już na pewno z Realu.
Nie jest to co prawda aż tak przejrzysty i wygodny widok, dlatego też tak jak mówiłem
mi osobiście łatwiej jest rozpocząć pracę właśnie od struktury tabel, a dopiero
potem szybko odwzorować ją sobie tutaj.
Ale wróćmy do Data Type i zastanówmy się, jak zdefiniować sobie
ten data type user, czyli jakie kolumny powinien tam posiadać.
I tu pierwsza ciekawostka user jest jedynym wbudowanym data type w
Babel i jedynym, którego nie możemy usunąć.
Czyli nie musimy go dodawać.
Jest on automatycznie dodawany, ale nie możemy go również usunąć.
Każde inne dodane przez nas Data type możemy oczywiście bezproblemowo usunąć.
Zacznijmy więc może od porządków tutaj właśnie na tego Data Type User i skoro ten
user type jest jedynym polem, jedyną kolumną, która rzeczywiście
będzie nam potrzebna, a te w przyszłości będziemy mogli usunąć,
to może je sobie odpowiednio odznaczamy.
Ja zawsze stosuję takie nazewnictwo, że dodaję tutaj dep.
W ten sposób wiem, że jest to rekord, a w zasadzie kolumna oznaczona
jako kadet, czyli taka do usunięcia.
Mogę to wstawić do wszystkich kolumn.
Natomiast tutaj kolejna ciekawostka.
Nie we wszystkich bazach danych będziesz mógł w tak prosty sposób zmienić nazwę.
Kolumny, a w zasadzie nazwę będziesz mógł zmienić, ale będzie pociągało to za sobą
ten problem, że dane bardzo często w takiej kolumnie zostaną usunięte.
Musisz o tym pamiętać pracując z innymi bazami danych.
Natomiast w przypadku Babel mogę tę nazwę dowolnie zmieniać
i edytor sam zadba o to, aby po prostu poprawić te nazwy wszędzie
tam, gdzie z nich korzystamy.
A więc mogę wszędzie dodać właśnie ten przedrostek.
I teraz mamy tu już nieco większy porządek.
Teraz czas na kolejny krok, czyli na dodanie tych pól, jakich
będziemy potrzebować.
Jest to też miejsca na kolejne bardzo ważne pytanie jak podejść do
budowania naszej bazy danych?
Odpowiedź jest krótka i niestety bardzo lakoniczna.
A brzmi to zależy.
Najlepszym wzorcem jest design naszej aplikacji, z którego możemy wyczytać
jakich pól będziemy potrzebować i na tej podstawie je dodawać.
Możesz też pójść w drugą stronę i najpierw zaprojektować sobie schemat swojej bazy
danych wszystkich tabel i powiązań i potem na tej podstawie próbować tworzyć design,
by jak najlepiej to odzwierciedlić.
Metoda, którą wybierzesz zależy wyłącznie od Ciebie lub też narzuconych Ci
wymagań projektu bądź też wizji klienta.
Ja najczęściej staram się nie budować od razu pełnego schematu bazy danych,
ale rozbudowywać go zgodnie z designem i z tym, czego w danym momencie potrzebuję.
Takie podejście jest nieco prostsze, ale niesie za sobą również ten problem, że z
czasem przyjdzie Ci przebudowywać bazę danych, by dostosować ją lepiej
do nowych funkcjonalności.
I tu znów sprawdza się stara jak świat mantra im więcej projektów zbudujesz, tym
szybciej i bardziej intuicyjnie będziesz projektował kolejne bazy danych.
Zastanówmy się więc, jak to wygląda u nas i skąd mamy czerpać informacje
o tym, czego potrzebujemy.
Rozpocznijmy więc od pierwszego punktu styczności naszego przyszłego użytkownika
z naszą bazą danych, czyli miejscem, w którym rejestruje
się on w naszym serwisie.
No i oczywiście podaje tam swoje pierwsze informacje o sobie.
U nas jest to strona sign in, więc możemy sobie do niej przejść.
Kliknij tutaj Refresh.
Musimy się wylogować.
I jesteśmy teraz na stronie Sign in, aby przejść na stronę Sign up.
Czyli don't have an account.
To jest strona rejestracji.
Jak widzisz, one się tutaj niewiele różnią, ale tu są.
To jest ten pierwszy punkt styczny właśnie naszego użytkownika z serwisem.
I tu podaję swoje pierwsze informacje o sobie.
W naszym przypadku jest to tylko pole email oraz pole password
i jest to moim zdaniem rozwiązanie genialne w swojej prostocie, ponieważ od
niego zależy to, czy w ogóle ktoś zdecyduje się dołączyć
do naszej społeczności.
Jeśli w formularzu rejestracji wrzucisz całą masę pól, to możesz być absolutnie
pewien, że osoba po drugiej stronie najpierw zada sobie pytanie po co ci tyle
tych informacji, a zaraz potem stwierdzi, że może jednak nie warto Ci ich podawać.
Często też spotykam się w formularzu rejestracji z polem, w którym
musimy powtórzyć wybrane hasło.
I tu moja skromna prośba.
Jeśli już masz coś zapamiętać odnośnie tworzenia serwisów, a zwłaszcza formularzy
rejestracyjnych, nigdy tego proszę nie rób.
Jest to całkowicie zbędne i w moim odczuciu tylko wywołuje irytację.
Nowoczesne przeglądarki zapamiętują hasła, które wpisujemy, jeżeli się na to pozwoli
lub istnieje cała masa menadżerów haseł, które robią to za nie.
Dlatego też doceń fakt, że ktoś wymyślił się na to, aby wymyślić jakieś hasło i nie
każ mu go proszę jeszcze raz powtarzać.
A więc mamy tutaj tylko e-mail i hasło, więc wróćmy do bazy danych i sprawdźmy,
czy te kolumny rzeczywiście w naszym data type user istnieją.
i mail mamy tutaj.
Jak widzisz jest to pole wbudowane, podobnie zresztą jak tutaj to pole
modified, date, created date oraz Slug Slug bywa przydatny i do
niego jeszcze wrócimy.
Natomiast pod spodem istnieją jeszcze dwa pola, których co prawda tutaj nie widać
dla tego data type user, ale możesz mi uwierzyć na słowo, że one tam istnieją.
Pod spodem mamy jeszcze dwa pola, których co prawda nie widać, ale
zapewniam Cię, że tam są.
Jest to pole password, które przechowuje hasło naszego użytkownika.
I tu znów Bubble zadbało za nas o to, żeby nikt, w tym również my,
nie mieli do niego dostępu.
A więc nie musimy się martwić o to, że hasła w jakiś sposób
wyciągną z naszego serwisu.
Nawet jeżeli sprawdziłyby się logi aplikacji, gdzie np.
znajdziesz info o rejestracji konta i o danych, które tam podaje użytkownik,
to hasło zawsze będzie ukryte.
Kolejne pole to ID samego rekordu.
Ponieważ nasza baza danych w jakiś sposób musi rozróżniać poszczególne rekordy, to
każdemu z nich przypisywany jest odpowiedni identyfikator.
Tutaj co prawda go nie widać, natomiast jeżeli przeszliśmy sobie już do
AppData i klikniemy na jakikolwiek rekord tutaj, to ikonkę edycji
Tak, mam tutaj już ID i nadany właśnie taki unikalny identyfikator rekordu, o
którym blabla właśnie rozróżniania sobie w swojej bazie danych.
Jeśli stąd wyjdę i wrócę tutaj do tej bazy danych,
to jak widzisz możemy tutaj również ręcznie dodawać nowe rekordy.
Jest to przydatne zwłaszcza w fazie budowania i testowania aplikacji.
Będziemy zresztą to jeszcze nieraz robić w dalszej części kursu.
I tutaj kolejna ważna rzecz, o której jak mi się wydaje, wspominałem już w
poprzednim sprincie, czyli dodawanie rekordów do tej tabelki users.
Podstawowym sposobem jest oczywiście rejestracja użytkownika za pomocą
formularza, które zresztą właśnie widziałeś na stronie Sign Up
i odpowiedniej akcji dostępnej w zakładce Workflow.
To też już przerabialiśmy w pierwszym skrypcie, ale jak widzisz
mamy tutaj opcję New entry.
Mogę w nią kliknąć i w ten sposób dodać nowy rekord.
Natomiast największym problemem jest to, że nie widzisz tutaj
nigdzie pola password.
I bardzo dobrze, ponieważ go tutaj nie ma.
Mogę co prawda dodać tutaj jakiś mail, dodajmy jakiś testowy.
Nie musimy uzupełniać żadnych pozostałych pól oprócz np.
user type. Wybierzmy, że jest to gość.
Klikam sobie teraz Create.
OK, taki rekord został tutaj dodany do naszej bazy danych.
Czasami Babel potrzebuje chwilę, żeby sobie tutaj to odwzorować, ale spróbujmy
odświeżyć i zerknijmy, czy to tutaj wskoczy.
A jak widzisz już tam nowy rekord.
Test wskoczył.
I teraz on co prawda istnieje.
Taki użytkownik już został zarejestrowany w naszym serwisie, czyli został dodany
nowy rekord do bazy danych, ale ponieważ nie mam dostępu do jego
hasła, to nie mogę przejść przez proces logowania, a więc nie mógłbym się
zalogować jako użytkownik, czyli nie mógłbym utworzyć w ten sposób dodając
tutaj ten new entry konto dla kogoś innego.
Dlatego też z tej metody korzystamy tylko wtedy, gdy chcemy sobie dodać jakieś
rekordy testowe, z których będziemy korzystać, która będziemy np.
wyświetlać w naszej aplikacji, ale dla których nie jest tam potrzebne logowanie.
A więc wróćmy teraz znów do zakładki Data Types i zastanówmy się skąd wziąść
pozostałe te kolumny.
Musimy się zastanowić jaki jest kolejny punkt styczności naszego
użytkownika z serwisem.
Przeszliśmy przez formularz rejestracyjny, a więc mamy pola email,
mamy pola password.
Kolejnym krokiem co prawda nie wdrożyliśmy w pierwszym sprincie jaka logika,
ale przygotowaliśmy sobie do tego odpowiedni design.
Jest to strona on board ligowa, czyli klikam on boarding.
Mamy tutaj dwa kroki, jeżeli sobie to rozwinę.
Krok pierwszy, którym się oczywiście zajmiemy, natomiast na chwilę
obecną jest to nam niepotrzebne.
A więc ja sobie to ukryję.
Tak, chcę sobie to ukryć.
Przejdźmy do kroku drugiego, w którym użytkownik już podaje
więcej informacji o sobie.
Taka strona briefingu jest właśnie genialnym miejscem na to, aby zebrać
nieco więcej informacji o użytkowniku.
A więc sprawdźmy, co tutaj mamy.
W pierwszej kolejności użytkownik będzie wybierał typ konta.
Czy jest to konto typu guest, czy też konto typu host, A więc to pole mamy
już tutaj dodane do naszego Data type.
Natomiast mamy tutaj jeszcze kolejne.
Mamy obrazek tutaj nazwa Avatar name First name mamy Last name,
mamy Location i tutaj przejdźmy sobie do Appearance i w naszym przypadku jest to
pole Search box, do którego przekazywaliśmy Geographic
Places, czyli po prostu taki adres geograficzny bezpośrednio
z mapki Google'a.
Natomiast czy jest to nam potrzebne w koncie użytkownika?
Czy musimy gdzieś na mapce nanosić informację skąd pochodzi?
Moim zdaniem raczej nie.
Nam przyda się to zdecydowanie bardziej w przypadku listingu.
A więc może zróbmy tak, że zaznaczmy sobie pole na Snape, powiedzmy
usuńmy to le Katon typu Search box i zmieniajmy to tutaj.
I zmieńmy może nazwę jeszcze nie location, tylko po prostu City.
O właśnie.
Wybierajmy tylko miasto, na razie użytkownika.
Możemy potem zadbać o pobieranie jakichś bardziej szczegółowych danych,
a więc użytkownik przekaże np.
tylko o jakiejś Warsaw London cokolwiek innego.
Mamy tutaj Fort Number, oczywiście źle nazwane.
Będzie to pole input.
Mamy jakieś pole About me.
I mamy tu jeszcze oczywiście Option set odnoszący się do języków.
A więc skoro wiemy już jak wygląda nasz formularz i jakie informacje zbieramy, to
postarajmy się teraz odwzorować te pola właśnie w naszym Data Type.
A więc przechodzimy tutaj.
I zaczynamy od początku.
Będzie to awatar.
W naszym przypadku będzie to obrazek.
Mogę tutaj wybrać File albo Image File.
Pozwala mi na wgranie różnych typów plików, a obrazek jak się domyślasz
będzie to tylko obrazek np.
w formie RPG, PNP itd.
A więc klikam Create. Mamy pierwsze pole.
Kolejnym było First name.
To będzie oczywiście zwykły tekst.
Last name.
Znów tekst.
Co tam jeszcze?
Miasto i fan number.
A więc.
City.
Powiedzmy, że będzie to po prostu zwykły tekst.
Użytkownik sobie wpisze jakieś miasto.
Kolejna mamy fon.
Tutaj użytkownicy mogą wpisywać numer telefonu w różnych formatach
z nawiasami, bez nawiasów itd.
Więc określmy sobie typ tego pola również na tekst.
Pozostaje nam więc jeszcze tylko about i tutaj ten set.
A więc.
About Me to, jak się domyślasz, też będzie tekst.
I teraz jeszcze.
Odniesienie do języków.
To będzie nasz set.
Mamy ten.
I tym wypadku będzie to lista, ponieważ użytkownik może wskazać kilka języków.
A więc klikamy sobie ten checkbox i zapisujemy zmiany.
Wróćmy jeszcze na stronę parkingową.
Czy mamy coś więcej?
Wygląda na to, że nie.
Natomiast musimy w jakiś sposób oznaczyć nasz rekord
i wskazać, czy rzeczywiście ten użytkownik przeszedł już ten
boarding, czy jeszcze nie.
A więc wracamy i dodajemy kolejne pole.
o nazwie Finish on Boarding.
Typ to będzie typ Boolean, czyli jest lub None.
I tu dodatkowo mogę od razu zaznaczyć.
Jak widzisz pojawiały mi się wartości domyślne takie default.
Czyli jeżeli dodam nowy rekord to to co wpiszę tutaj uzupełnione?
Z reguły pozostawiam to puste, ale np.
tutaj będę chciał, aby właśnie finisz link dla nowego rekordu od razu wskakiwał na
nowy i dopiero kiedy użytkownik przejdzie on boarding i potem w aplikacji
zmienimy to na wartość Yes.
To by było na tyle jeżeli chodzi tutaj o stronę on buildingu.
Co się dzieje potem? Jak wygląda dalej ścieżka użytkownika?
Otóż ze strony brandingu przechodzi on do naszego dashboard.
A więc może wróćmy do aplikacji.
Zaloguj się na konto gościa, tylko oczywiście będziemy musieli sobie to
odświeżyć i zerknijmy co mamy tutaj.
W naszym dashboard mamy tag awatar, które to pole już dodaliśmy.
Mamy tutaj imię i nazwisko użytkownika.
Mamy tutaj jakieś statystyki, to na razie pomijamy.
Tym zajmiemy się później.
Tą sekcją tutaj też się je zajmiemy.
Będziemy potem dodawać booking i review itd.
I oczywiście dopinać to do konta użytkownika.
A więc nie ma tutaj jakiejś więcej informacji bezpośrednio o nim.
Przejdźmy jednak na stronę profilu.
I znów widzimy co mamy.
Tutaj znów mamy imię i nazwisko.
Mamy tutaj Professional Host.
To będzie u nas po prostu user type.
Oczywiście moglibyśmy dodać funkcjonalność, która po jakimś czasie
określa takie konto jako profesjonalny host.
Natomiast by uprościć zadanie i każdy nowy host będzie miał właśnie ten tytuł
Professional, mamy tutaj listing stóp.
Będziemy to dodawać później, podobnie jak review.
Języki już sobie ustawiliśmy.
Mamy tutaj informację, kiedy dołączył.
Jak pamiętasz mamy tam wbudowane pole Created date i będziemy
się mogli do tego odnieść.
Tu mamy informację czyli To about me to review, to znowu będziemy dodawać później.
Natomiast mamy tutaj informację o tym, że użytkownik będzie mógł usunąć takie konto
w naszym serwisie, natomiast nie będzie to działało tak, że od
razu będziemy je usuwać.
Jak widzisz mamy tutaj info, że będziemy je przenosić do archiwum
czy archiwizować na 60 dni.
Jest to bardzo dobra metoda i proszę stosuj ją w swoim serwisach.
Nigdy staraj się nie usuwać od razu jakichś bardzo ważnych rzeczy, czyli np.
rekordów użytkownika.
Użytkownicy bardzo często działają właśnie tak typowo instynktownie
i ktoś się zdenerwuje z jakiegoś powodu i stwierdzi ok, usuwam konto
i za dzień lub dwa napiszę Ci ojej, przepraszam, chciałbym je przywrócić.
Jeżeli Ty je usuniesz z bazy danych, to przywrócenie tego wszystkiego
będzie praktycznie niemożliwe.
Dlatego też będziemy potrzebowali odpowiedniej flagi
i będziemy sobie za pomocą jej określać czy konto zostało zarchiwizowane czy nie.
I po tych 60 dniach dopiero, jeżeli użytkownik nie podejmie żadnych działań,
odpowiednio wykorzystamy tą flagę i rzeczywiście usuniemy jego konto,
Wszystkie informacje o nim, wszystkie, listing itd.
A więc wróćmy do aplikacji i dodajmy jeszcze jedno pole o nazwie IS Archive.
Jak się domyślasz, to też będzie pole typu Boolean, czyli jest lub noł.
A więc skoro nasz data user został już odpowiednio skonfigurowany, mamy wszystkie
wymagane kolumny jakich będziemy potrzebować.
To ja dziękuję Ci za uwagę w tej lekcji i w kolejnej możemy rozbudować naszą
bazę danych już o testowych użytkowników.