Bubble: Page Parameters w praktyce
od Podstaw
6 godz. 34 min · Bubble · Full-stack i Programowanie
Krzysiek PiekarzAutomation Specialist / No-code DeveloperCzego się nauczysz
- Podstawy pracy z edytorem
- Wprowadzenie do workflows
- Praca z nowym silnikiem responsywnym
- Praktyczne wykorzystanie pluginów
- Statyczna strona główna
- Funkcjonalna strona logowania i rejestracji
Praca w stylu no-code
Zapomnij o ręcznym pisaniu kodu i żmudnym tworzeniu stron www lub aplikacji! Wykorzystując przejrzysty edytor Bubble będziemy w stanie rozpocząć naszą pracę od czystej kartki i wyklikać cały układ bezpośrednio w interfejsie. Dodatkowo pokażę Ci w jaki sposób można wdrożyć do projektu w pełni funkcjonalną logikę obsługi użytkowników nawet wtedy, gdy nie posiadasz żadnej wiedzy programistycznej. A to wszystko w niemal ekspresowym tempie i bez zbędnych konfiguracji, które bywają zmorą programistów.
Dlaczego warto korzystać z Bubble?
Edytor zapewnia spójny i intuicyjny interfejs, dzięki któremu stworzenie nawet skomplikowanej aplikacji staje się wyjątkowo proste. Dodatkowo wbudowana baza danych sprawia, że nie musimy korzystać z żadnych zewnętrznych rozwiązań a zarządzanie nią jest na tyle intuicyjne, że poradzi sobie z tym nawet niedoświadczony użytkownik. Kolejną zaletą jest dostęp do ogromnej biblioteki pluginów, dzięki którym będziemy mogli wzbogacić naszą aplikację o obsługę płatności, analitykę, SEO i wiele więcej.
Co można zbudować w Bubble?
Niemal wszystko, z wykorzystaniem Bubble bezproblemowo stworzymy klony takich serwisów jak: Twitter, Asana, Todoist, AirBnB, Trip Advisor lub Yelp. Edytor pozwala stworzyć w pełni funkcjonalną aplikację w ciągu nawet kilku dni! Dzięki temu nie będziemy musieli przepalać naszego budżetu na zewnętrzne software house, którym wdrożenie podobnych rozwiązań może zająć tygodnie pracy.
Czego dowiesz się z kursu?
W tym kursie skupimy się na podstawach pracy z edytorem, tak aby korzystanie z niego stało się dla Ciebie naturalne. Wykorzystamy w praktyce zakładkę Design, która jest odpowiedzialna za front-end naszej strony oraz zapoznamy się z działaniem workflows, które "tchną życie" w nasz projekt. Efektem naszej pracy będzie nowoczesny landing page oraz w pełni funkcjonalna strona logowania/rejestracji. Dodatkowo zadbamy również o to, by całość była w pełni responsywna i dobrze prezentowała się zarówno na ekranach desktopowych, jak i urządzeniach mobilnych.
Wykraczamy poza edytor
Jedną z zalet edytora Bubble jest to, że nie stanowi on hermetycznego środowiska, w którym jesteśmy skazani na korzystanie jedynie z rozwiązań zaprojektowanych przez jego twórców. To niesamowicie funkcjonalna platforma, którą w prosty sposób możemy połączyć również z zewnętrznymi usługami wykorzystując gotowe pluginy. Pokażę Ci w jaki sposób możemy zaimplementować do naszego projektu opcję logowania i rejestracji z wykorzystaniem Google, tak, aby użytkownik mógł utworzyć konto w naszym serwisie za pomocą jednego kliknięcia. A kolejnym bonusem będzie przesyłanie adresów e-mail z formularza zapisu na newsletter bezpośrednio do bazy w Airtable!
Dla kogo jest ten kurs?
Ten kurs powstał z myślą o osobach, które chcą poznać edytor Bubble i nowy kierunek rozwoju aplikacji no-code. Będzie również doskonałym punktem startowym dla tych wszystkich, którzy nie posiadają żadnej wiedzy programistycznej ale nadal chcą tworzyć w pełni funkcjonalne serwisy i strony internetowe. Poziom kursu został dopasowany zarówno do osób, które do tej pory nie korzystały z Bubble, jak i tych, którzy posiadają już przynajmniej podstawowe doświadczenie w tym zakresie. Dzięki zdobytej w nim wiedzy będziesz mógł postawić pierwszy krok na drodze, która pozwoli Ci przekuć Twój pomysł w działający startup.
Kontynuujemy naszą pracę nad stroną logowania i rejestracji.
Jak widzisz ja w międzyczasie utworzyłem tutaj dodatkowy folder o nazwie change-view
i do niego przeniosłem oba workflow, jakie utworzyliśmy w lekcji poprzedniej.
Zanim jednak przejdziemy do realizacji drugiej części zadania, jakie przed nami
stoi, przeanalizujmy to, co zrobiliśmy do tej pory.
Wróćmy do zakładki designe.
Jak pamiętasz, mamy tutaj naszą gotową stronę.
Dodatkowo pełen formularz, czyli formularz, który w takiej wersji, jaką
widzisz na ekranie umożliwia użytkownikowi zarejestrowanie się w naszym serwisie,
ponieważ posiada tutaj pola fullname, e-mail oraz password.
Ja właśnie tak zawsze przystępuję do pracy.
Otóż tworzę formularz w tej najbardziej rozbudowanej wersji, czyli u nas
jest to po prostu wersja z opcją rejestracji i dopiero potem za pomocą
odpowiednich custom state i zakładki conditional dostosowuje jego
wygląd do tego co mi jest akurat potrzebna.
Jak pamiętasz u nas dla całego page
authentication dodaliśmy custom state view o nazwie login i na podstawie właśnie
tej wartości login za pomocą zakładki conditional ukrywamy tutaj odpowiednie pola.
W naszym przypadku jest to oczywiście pole fullname
oraz dodatkowo dostosowujemy jeszcze treści na tych przyciskach.
Dlaczego ja tutaj tą wartość domyślną ustawiłem na login?
Otóż wychodzę z takiego prostego założenia, że użytkownik rejestruje się na naszej
stronie tylko raz, natomiast logować się będzie wielokrotnie.
Dlatego też chce, aby po przejściu na
stronę autentykacji domyślnie wyświetlał mu się właśnie formularz logowania.
Mam nadzieję, że to już jest jasne i że
teraz rozumiesz dlaczego ustawiłem tu taką wartość domyślną.
Przy okazji chciałbym również porozmawiać
o tym, do jakich elementów tak naprawdę powinniśmy dodawać custom state'y.
W naszym przypadku ten custom state view dodaliśmy tutaj do całego page'a.
Ja spotkałem się z dwoma rodzajami podejść w tym temacie.
Bardzo często widziałem sytuację, gdzie wszystkie custom state'y dodawane są
bezpośrednio do elementu page, niezależnie od tego jakiego elementu
de facto one dotyczą. I uważam, że jest to złe rozwiązanie.
Nie powinieneś z niego korzystać.
Moje podejście jest takie, aby custom state zawsze dodawać do
elementu, który rzeczywiście jest z nim powiązany.
W naszym przypadku nasz custom state jest powiązany z całą stroną,
ponieważ chcemy ją wyświetlać albo właśnie w wersji do logowania, albo do rejestracji.
Oczywiście mógłbyś się z tym kłócić,
ponieważ tak naprawdę jedyne co zmieniamy to tutaj te pola,
więc równie dobrze moglibyśmy go przypisać do tego elementu, czyli po prostu do grupy
left-inner, ponieważ tylko wewnątrz niej dzieją się tutaj jakieś zmiany.
Ja natomiast uznałem, że jednak tutaj page będzie lepszym rozwiązaniem.
Ale jeśli chciałbym dodać jakiś custom state, które dotyczy tylko i wyłącznie np.
tego przycisku, to dodałbym go właśnie bezpośrednio do niego.
Czyli wybrał przycisk ikonkę i, i tu dopiero zdefiniował jakiś
custom state, który dotyczyłby tego przycisku.
Nie dodawałem tego do całej strony,
ponieważ nie jest to w ogóle powiązane ze stroną.
Skoro mamy poprzez ten custom state
wpływać po prostu na ten przycisk, mam nadzieję, że to też jest jasne.
Oczywiście to, które rozwiązanie wybierzesz będzie zależało od Ciebie, ale
myślę, że to moje podejście, czyli custom state przypisany do konkretnego elementu,
który go dotyczy jest takie najbardziej optymalny.
A skoro tą część mamy wyjaśnioną, to jeszcze raz przeanalizujmy jak działa
tutaj nasz workflow, jaki zdefiniowaliśmy w reakcji poprzedniej.
Otóż po kliknięciu w przycisk odnosimy się
bezpośrednio do state'u przypisanego w tym przypadku to page authentication i
zmieniamy go z wartości login na wartość register w zależności od tego, który ze
zdefiniowanych przez nas warunków zostanie spełniony.
A więc skoro wiemy już teraz jak to
działa, to zastanówmy się w jaki sposób powinno to działać.
Teraz, jeżeli będziemy chcieli przekierować użytkownika ze strony indeksowej
na odpowiednią stronę z właściwym formularzem.
Na chwilę obecną po kliknięciu w przycisk
tylko kierujemy użytkownika na naszą stronę, ale w żaden sposób nie ustawiamy
custom state'u, który ma być właśnie tam wyświetlany.
Jak więc to zrobić?
Spróbujmy przejść do edytora i zastosować dokładnie to samo podejście,
jakie stosowaliśmy tutaj na stronie autentykacji.
A więc przenosimy się na stronę
indeksową.
Poczekaj aż się nam tutaj to załaduje.
Zacznijmy może od przycisku logowania.
Klikamy start edit workflow, aby się przenieść do już gotowego workflow.
Jak pamiętasz na chwilę obecną tylko
kierujemy tutaj użytkownika na stronę autentykacji.
No więc teraz skoro chcemy go tam przekierować to od razu też ustawmy
odpowiednią wartość custom state dla całej tej strony.
A więc moglibyśmy tutaj kliknąć.
Wybrać znane Ci już set state, klikamy i co chcemy zmienić?
Oczywiście state przypisany do całego elementu authentication.
A więc robimy dokładnie to samo co robiliśmy w lekcji poprzedniej.
Klikam tutaj na rozwijaną listę, zaczynam wpisywać nazwę elementu
no i okazuje się, że strona autentykacji nie zostaje tutaj znaleziona.
Dlaczego tak się dzieje?
Otóż z jednego bardzo prostego powodu jesteśmy na stronie indeksowej, a
próbujemy odnieść się do strony bądź do elementu, który na niej się nie znajduje.
W naszym przypadku jest to po prostu cała
strona autentykacji, ale równie dobrze moglibyśmy próbować odnieść się np.
do przycisku na tej stronie zewnętrznej lub jakiegoś innego elementu i okaże się,
że jest to niemożliwe poprzez workflow definiowane na danej stronie.
Możesz bezpośrednio odnosić się tylko do
tych elementów, które rzeczywiście na niej się znajdują.
W naszym przypadku strona indeksowa i strona
autentykacji to dwa tak naprawdę osobne byty, dla Bubble
nie są one połączone ze sobą, a więc nie możemy wpływać
tutaj z poziomu strony indeksowej na inną stronę.
Jak więc w takim razie ustawić to custom
state albo przekazać wartość, którą chcemy dla niego ustawić?
Skoro nie możemy tutaj zaznaczyć tego elementu bezpośrednio?
Otóż w takim przypadku będziemy musieli
wykorzystać tzw. parametry w adresie URL.
Z tymi parametrami już się spotkaliśmy,
chociaż być może nie zdawałeś sobie nawet z tego sprawy.
Usuńmy tą operację, skoro taka wersja nam tutaj nie zadziała.
Klikam delete.
Na chwilę obecną tylko zamknę tą stronę.
Spróbuję podejrzeć naszą stronę indeksową w przeglądarce.
Strona się załadowała, a my na dole widzimy już znany Ci debugger.
Dlaczego on się tutaj pojawia?
Otóż z tego powodu,
że Bubble dodał nam dodatkowy parametr w pasku adresu przeglądarki.
Jest to ten parametr tutaj po znaku zapytania.
W tym przypadku jest to debug_mode=true,
co oznacza dla Bubble tylko tyle, że powinien wyświetlać właśnie debugger.
A skoro już wiesz czym są parametry w
pasku adresu, to zastanówmy się w jaki sposób możemy dodać taki własny parametr.
Usuńmy debugger nie będzie nam tutaj potrzebny do pracy.
Wróćmy do edytora.
Przejdźmy do tej akcji, która kieruje
użytkownika na naszą stronę logowania i rejestracji.
I w tym miejscu za pomocą tej akcji, oprócz samego przekierowania
możemy dodatkowo przekazać również własne parametry.
Za pomocą tej opcji send more
parameters, klikamy ten checkbox, dodaje swój własny parametr.
W pierwszej kolejności muszę nadać mu tutaj jakąś nazwę.
Nazwa może być dowolna i wymyślona przez Ciebie.
W moim przypadku będzie to parametr o
nazwie view, a następnie przekazuję jego wartość.
Na chwilę obecną pojawia mi się tutaj takie pole click,
jak kliknę będą mógł przekazać jak doskonale wiesz jakąś wartość dynamiczną.
Ponieważ my będziemy przekazywać tylko tekst.
To aby się go pozbyć.
Klikam za tym polem.
Jak widzisz teraz tutaj kursor pojawia mi się i miga za polem click,
klikam backspace.
W ten sposób usunąłem to click i teraz mogę tutaj wpisać sobie wartość.
Ponieważ jesteśmy na przycisku logowania,
to jak się domyślasz będzie to wartość login.
Zerknijmy więc teraz jak to działa.
Przejdźmy do podglądu naszej strony.
Odświeżmy ją.
Klikam w przycisk sign in.
Jak widzisz zostaliśmy przekierowani na
stronę logowania i rejestracji, a dodatkowo tutaj w pasku adresu
przesłaliśmy nasz własny parametr o nazwie view z wartością login.
Skoro wiemy jak to zrobić dla tego przycisku, to wykonajmy odpowiednie
operacje dla pozostałych przycisków na naszej stronie.
Przejdźmy do odpowiednich folderów.
Zacznijmy od desktop menu.
Dla wartości sign in, czyli przycisku logowania mamy tutaj właściwe wartości
przekazane. To samo zróbmy teraz na przycisku Sign up.
Przechodzę do akcji go to page.
Zaznaczam ten checkbox dodaje własny parametr.
W naszym przypadku parametr będzie miał zawsze tą samą nazwę.
Będzie to nazwa view.
Klikam za tym polem click, klikam backspace i teraz wpisuję tutaj register.
W naszym przypadku do strony logowania i
rejestracji z parametrem register chcemy przekierowywać za każdym razem, kiedy
użytkownik kliknie na przycisk sign up w menu desktopowy lub mobilnym.
A więc możemy sobie skopiować tą całą akcję.
Klikam prawym przyciskiem, wybieram copy, przechodzę do menu mobilnego.
Zaznaczam tutaj sign up.
Usuwam tą akcję bez parametrów.
Wklejam tą.
I teraz również z menu mobilnego będziemy przekazywać parametr register.
To samo zresztą będziemy robić tutaj na tych wszystkich pages links.
A więc dla każdego z nich usuwam istniejącą akcję.
Wklejam tą nową zdefiniowaną razem z parametrem.
Trzeci przycisk to samo bez parametru usuwam, wklejam akcję
z przekazanym parametrem i to somo robię jeszcze tutaj dla przycisku get started now.
Usuwam tą bez parametru, wklejam.
I sprawdźmy, czy teraz wszędzie się to zgadza.
Dla każdego przycisku mamy akcję, która
będzie przekierowywać na naszą stronę, łącznie z parametrem view równym register.
Ten przycisk też wszystko działa tak jak powinno.
Wróćmy jeszcze do menu mobilnego.
Przycisk sign up jest zdefiniowany poprawnie.
Przycisk sign in nie, więc oczywiście musimy tutaj dodać odpowiedni parametr.
Będzie to view oczywiście o wartości w tym przypadku login.
I teraz już wszystkie przyciski na naszej stronie indeksowej, wróćmy na nią.
Będą kierowały
użytkownika na stronę logowania i rejestracji z odpowiednim parametrem.
Możemy to przetestować.
Przejdź np. do sekcji pricing i wybierzmy np. ten przycisk.
Klikamy.
Jak widzisz parametr został odpowiednio przekazany.
Skoro parametr o odpowiedniej wartości został
już tutaj dodany, to zastanówmy się w jaki sposób możemy pobrać tą wartość, którą
tutaj otrzymujemy i przypisać ją do naszego custom state.
W tym celu wracamy do edytora,
przechodzimy do strony autentykacji i oczywiście będziemy musieli wykorzystać
odpowiedni workflow, ponieważ będzie to zmiana widoku.
To ja przejdę do tego folderu i tutaj,
tym razem nie będziemy klikać w żaden przycisk.
Chcemy pobrać wartość tego parametru, gdy tylko nasza strona się załaduje.
W tym celu klikam tutaj i korzystam z
gotowej akcji jaką mamy tutaj dostępną w zakładce general.
Wybieram pages is loaded.
Ten trigger odpali się za każdym razem,
kiedy nasza strona będzie ładowana, a więc
definiujmy tutaj odpowiednią akcję.
Klikam w tym miejscu i dopiero tutaj jestem na stronie autentykacji.
Mogę więc zmienić custom state dla elementu, który się na niej znajduje.
A więc wybieram set state.
Odnoszę się bezpośrednio do authentication.
Do state'u o nazwię view.
I w jaki sposób teraz przekazać wartość tego parametru?
Znów w Bubble jest to niesamowicie proste.
Klikam w to pole click, zaczynam wpisywać URL
i wykorzystamy tą opcję
get data from page URL.
Teraz musimy tutaj powiedzieć jaką nazwę
nosi parametr, z którego chcemy pobierać dane.
Jest to parametr o nazwie view
typ text, ponieważ my tam przekazujemy tylko text login albo text register,
a więc pozostawiamy ten typ na tą wartość, klikam close.
I to w zasadzie wszystko.
Teraz pobierzemy wartość parametru view i
przypiszemy ją tutaj do custom state o nazwie view.
Czy to nam zadziała?
Jak widzisz na chwilę obecną mamy tutaj
domyślny formularz logowania, ponieważ włączył się ten domyślny custom state,
ale w parametrze przekazaliśmy view równa się register.
Odświeżamy więc stronę.
I wszystko wykonało się poprawnie.
Formularz rejestracji został wyświetlony.
Zgodnie z tym co mamy tutaj w tym parametrze.
Oczywiście ta sama operacja zadziała
również wtedy, kiedy przekażemy tutaj view równa się login.
Wówczas ta wartość login zostanie pobrana i też przypisana do custom state.
Natomiast zastanówmy się co by się stało,
gdybyśmy tutaj przez pomyłkę przekazali pustą wartość tego parametru.
Zapomnieli po prostu tam przy przekierowaniu wpisać do view
odpowiedniej wartości i wtedy otrzymalibyśmy parametr z pustą wartością.
Klikam, powinniśmy wyświetlić w takim przypadku
formularz logowania domyślny, ale jak widzisz nadal mamy tutaj formularz rejestracji.
Dlaczego tak się stało?
Mam nadzieję, że już się domyślasz.
Otóż zadziałał nasz workflow, czyli ten page is loaded się odpalił.
I do custom state przypisał wartość, którą pobraliśmy z parametru. A ponieważ
przekazaliśmy tam wartość pustą, to właśnie taką tutaj sobie przekazał.
A w naszym przypadku jeżeli wartość jest pusta to wyświetla się domyślny formularz,
czyli formularz rejestracji jaki jest zdefiniowany w tym miejscu.
Nam natomiast zależy na tym,
aby w takim przypadku, kiedy po prostu zapomnimy tutaj przekazać tą wartość
dla parametru lub w ogóle zapomnimy przez pomyłkę przekazać cały parametr.
Może tak się zdarzyć, po prostu przekierujemy tylko użytkownika.
Nie wpiszemy tam odpowiedniego parametru to zobacz co się stanie.
Usuwam cały ten parametr,
odświeżam stronę i znowu mam formularz rejestracji zamiast formularza logowania.
Oczywiście dzieje się tak dlatego, że znów
odpala się to workflow i znów próbuję pobrać
wartość parametru w ogóle nie znajduje
parametru, więc wpisuję tutaj oczywiście wartość pustą.
Jak więc ograniczyć działanie naszego workflow tak, aby odpalała się wyłącznie
wtedy, kiedy rzeczywiście przekażemy jakąś wartość parametru?
No mam nadzieję, że już wiesz.
Oczywiście zastosujemy tutaj odpowiedni warunek.
Przechodzę do triggera.
W sekcji only when,
mówię URL, czyli get data from page URL.
Nadaję nazwę naszego parametru, czyli odnoszę się po prostu to parametru view
przekazywanego tutaj w pasku adresu i mówię, że chcę wykonać tą operację tylko
wtedy, kiedy ten parametr nie jest pusty, a więc tylko wtedy, kiedy w ogóle go
przekażemy i dodatkowo będzie miał jeszcze jakąś wartość.
Zerknijmy jak to nam teraz zadziała.
Odśwież stronę.
W ogóle nie przekazaliśmy żadnego parametru.
A więc nasz workflow się nie odpalił i domyślnie ma zastosowanie
cutom state o wartości login.
Mam nadzieję, że teraz już rozumiesz jak to działa.
W jaki sposób możemy przekazywać parametry poprzez pasek adresu.
W jaki sposób możemy je potem odczytywać.
Oraz dodatkowo w jaki sposób sprawdzać,
czy wartość takiego parametru nie jest pusta.
I dzięki temu w pewien sposób ograniczać działanie naszych workflows.
To by było na tyle w tej lekcji.
Dziękuję Ci serdecznie za uwagę i widzimy się już za moment.