Cosealious - nowa wizja, brainstorm

Po latach pracy wizja tym, czym jest i czym ma się stać Sealious w miarę się ustabilizowała, co pomaga sprawnie go rozwijać.

Cosealious jest dosyć nowy i nie ma póki co takiego benefitu. Czas to zmienić! :muscle:

Najlepiej będzie spotkać się offline i to obgadać. Ale zanim to zrobimy, chciałbym rozpocząć z Wami jednotygodniową burzę mózgów na Forum. W trakcie jej trwania będziemy mieli okazję zebrać listę tematów do omówienia oraz zrobić wstępny research, co usprawni flow naszego spotkania IRL.


Timeline:

  • do 28.X rzucamy w niniejszym wątku pomysły, pytania i wątpliwości dotyczące teraźniejszości i przyszłości Cosealiousa
  • w tygodniu po 28 X (termin i miejsce ustalimy w PW) spotkamy się offline i ustalimy plan działania i rozwoju.

Czas na burzę mózgów!

Przez najbliższy tydzień proszę miejcie temat Cosealiousa w głowie i jak tylko wpadnie wam jakieś pytanie, wątpliwość czy sugestia - napiszcie tutaj. Kilka tematów, o których warto pomyśleć to, m.in.:

  • technologie, z jakich korzystamy
  • zakres działania - jak dużą rzeczą ma być Cosealious?
  • pomysły na API - Sealious wprowadza takie pojęcia, jak Collection i FieldType. Jakie pojęcia powinien wprowadzać Cosealious? Jaka będzie ich relacja z Sealiousem? Jak je nazwiemy?
  • jakie front-endowe rzeczy możemy zautomatyzować Cosealiousem? Jakie żmudności napotykamy w trakcie tworzenia frontu? Czy lepiej to rozwiązać autorskim, mocno zintegrowanym rozwiązaniem, czy lepiej skorzystać z czyjejś otwartej implementacji?

Nie ma głupich pytań ani głupich sugestii - każdy input się liczy. Let’s do this! :muscle:

3 Likes
  • Czy potrzebujmy reimplementować router? Dostępne alternatywy: react-router 4, reach router
  • TypeScript/Flow & propTypes?
  • react-testing-library
  • Compound components
  • React Context/Redux zamiast QueryStore
  • Ramda
  • RxJS/redux-observable?
  • config ESLint dla Reacta
  • a11y
  • i18n
  • długofalowo trzeba brać pod uwagę React 17 (time slicing, suspense)
  • spójność/konwencja - nazwy, importy, conditional rendering, loadery
  • recompose?
  • obsługa formularzy?
  • design system?
  • maksimum elastyczności komponentów (np. sytuacja, gdzie kiedyś potrzebowałem innej kolejności label/select niż ta, która była w cosealiousie)
  • render-props
  • https://github.com/maicki/why-did-you-update
  • ciekawy trik z Promise.race dla loaderów - https://www.youtube.com/watch?v=QPDA4QwkJxk
3 Likes

Nie będę może powtarzał tego co Bartek napisał, ewentualnie uściślę

  • czym w ogóle chcemy żeby był Cosealious? Frameworkiem pełną gębą czy może zbiorem komponentów, klocków i innych helperów, które dobrze gadają z Sealiousem? Może są jakieś inne możliwości?
  • wsparcie dla wersji językowych (i18n + inne rzeczy)
  • redux
  • observable ogólnie
  • elastyczność formularzy, czy będziemy dostarczać komponenty dla określonych fieldów (dany typ fieldu -> określony input, radio, textarea…), czy chcemy żeby była taka magia, że formularz sam się robi z definicji kolekcji?
  • CSRF
  • wsparcie dla walidacji
  • system notyfikacji
  • websockets
  • co z wsparciem dla Vue?
1 Like

Kontynuując dyskusję z Cosealious - nowa wizja, brainstorm:

Trzeba to będzie sprawdzić. Mam obawę, że React Router doda nam trochę boilerplate’u. Ale dawno z tego nie korzystałem, więc być może ktoś bardziej doświadczony w temacie będzie mógł się tutaj wypowiedzieć.

Aktualnie jest tak: robimy komponent, dajemy mu query_class na Urlful i voila! Możemy dodawać parametry do URL i wpływać na zachowanie tego komponentu. Nie musimy nigdzie nic deklarować, niczego z niczym innym wiązać. Ja to widzę jako zaletę, ale może to jest wada? Może przez to kod jest trudniejszy do przewidzenia? Nie wiem. Chciałbym to poddać dyskusji.

Co Wy o tym myślicie? Jakie zalety ma react-router-4 względem naszego cosealiousowego routera?

Ja przychylam się do Flow Runtime, jeżeli eksperyment z nim się powiedzie.

PropTypes są zawsze mile widziane, ale chyba nie stanowią alternatywy do statycznego typowania, nie?

wygląda spoko! Na pewno musimy omówić strategię testów, bo aktualnie Cosealious nie jest prawie wcale otestowany

Co tutaj dokładnie masz na myśli?

Wyczuwam kontrowersję :smiley:

rozumiem, jaki problem rozwiązuje context - dzięki niemu nie musimy korzystać z connect_with_key_value_store. Nie jest to duża zmiana, ale wiadomo, że lepiej korzystać z wbudowanych w Reacta funkcji, niż wymyślać koło od nowa.

Nie do końca wiem, co dałoby nam korzystanie z Reduxa. Mam podobne obawy, co w przypadku react-router-4: obawiam się, że przy wykorzystaniu tego rozwiązania użytkownik Cosealiousa będzie musiał pisać więcej, a nie mniej. Rozwiązanie Cosealiousowe nie wymaga, aby użytkownik pisał jakieś akcje, consumery itp - tylko wywołuje metody store’a i reszta dzieje się sama.

Zachęcam do polemiki - jestem ciekaw, jaki problem możemy rozwiązać Reduxem

Ramda wygląda super - pytanie, czy chcemy aby była w jakiś sposób podstawą struktury Cosealiousa, czy raczej detalem implementacyjnym? Musimy pamiętać, że Ramda dodaje bodajże kilkadziesiąt kB do bundla, więc warto być ostrożnym z takimi rozwiązaniami na froncie.

Temat wielkości budla też zasługuje na osobną dyskusję - niektóre nasze buildy frontu zajmują do 1MB…

Myślę, że RxJS ma duże zastosowanie na backendzie (sealious). Czy masz jakieś pomysły dot. jego zastosowań na froncie?

+100

Myślę, że fajnie będzie jak sporządzimy nazewnictwo o podobnym stopniu sformalizowania, co w Sealiousie. Taki stan rzeczy będzie sprzyjał powstaniu wygodnych konwencji

O, to jest ciekawy temat - jak bardzo powinniśmy prowadzić użytkownika Cosealiousa za rękę? Bo Cosealious próbuje rozwiązać m.in. dwa problemy:

  1. łączenie frontu z backendem - tutaj radzimy sobie dobrze
  2. dawanie komponentów z gotowym wyglądem i layoutem - tutaj nam nie wychodziło i powoli się z tego wycofujemy.

Być może mieszanie tych odpowiedzialności w jednym narzędziu nie jest dobrym pomysłem. Czuję, że zyskamy, jeżeli zrobimy istotną separację pomiędzy wyglądem a logiką. Logikę będzie robił Cosealious: tak, aby można było ją łatwo zintegrować z jakimś UI Frameworkiem, jak np. https://evergreen.segment.com/

Proszę rozwiń trochę myśl - jaki scenariusz powoduje problem w aktualnej sytuacji? Jak te narzędzia ten problem mogą rozwiązać?

Ponownie wraca temat dualizmu Cosealiousa - UI vs logika.

Myślę, że Cosealious powinien maksymalnie ułatwić tworzenie logiki formularzy. Potem za pomocą jakiegoś innego narzędzia/zestawu komponentów można połączyć tę logikę ze spójnie wyglądającymi formularzami. Ale Cosealious sam z siebie nie powinien tego wymuszać.

Hm. Nie myślałem o tym. Być może da radę jakoś uogólnić logikę Cosealiousa tak, aby można było z niej korzystać także w Vue? Jeżeli tak, to czy warto?

Observable znakomicie działają razem z websocketami wg kolegów z Briisku. Poza tym znacznie ułatwiają implementowanie takich rzeczy jak jakiś debouncing, throttling.

Redux sam w sobie faktycznie nie daje specjalnie więcej niż te story, natomiast zaczynam doceniać ten ecosystem czyli mnóstwo paczek i nieoceniony devtools reduxowy, który bardzo ułatwia debugowanie. Faktycznie użytkownik będzie musiał pisać więcej, ale czuję że taki kod będzie łatwiejszy w utrzymaniu.

Co do tego czym ma być Cosealious wydaje mi się, że chcesz Kubo znowu iść w innym kierunku niż idzie np. React i Vue, żeby jednak w UI scalać logikę z wyglądem. Chociaż w sumie też nie tak - ich podejście jest imho pragmatyczne, a nie dogmatyczne, więc jeżeli to wygodne to się scala. Stwierdzenie, że “logikę będzie robił Cosealious” jest dla mnie trochę zbyt ogólne - co masz na myśli w sumie? :smiley:

Ja cały czas niestety nie wiem czego bym właściwie oczekiwał od niego, wiem że nie tego co jest teraz. Np. chciałbym zaimplementować formularz wyszukiwania czegoś w kolekcji. I w sumie fajne by było, że po prostu mówię po jakich polach tej kolekcji chcę wyszukiwać, czy chcę żeby request szedł na onChange czy na submit i przekazać swoją myśl dotyczącą layoutu i przekazuję akcję, która ma się wykonać po requeście.

A w sumie gdyby iść w stronę reduxa - jeżeli mówimy o logice, to być może można by powiedzieć - zrób mi akcje, reducery, store itd. dla odpytywania tej kolekcji, do czego mógłbym się podpiąć w komponencie? To by było o tyle fajne, że dla vue - robilibyśmy te rzeczy po prostu dla vuexa, sądzę że tu byłoby łatwo to jakoś uwspólnić.

To takie głośne myśli ode mnie

Słyszałem o time travel debugging w Reduksie, ale Mozilla pracuje nad takim ficzerem w Firefoksie bez potrzeby używania Reduxa - Firefox Is Testing "Time Travel Debugging"

Jakie jeszcze ułatwienia w debuggingu daje Redux?

React i Vue to w moim odczuciu biblioteki, a nie frameworki - ponieważ dają dużą swobodę i dowolność, dzięki czemu można używać je w bardzo wielu scenariuszach.

Ale ta swoboda ma swoją cenę - jest wiele sposobów na robienie różnych wysokopoziomowych tasków, jak np. pobieranie danych, aktualizowanie stanu aplikacji, logika formularzy i ich zgranie z url-ami, trzymanie info o tym, czy użytkownik jest zalogowany - itp, itd, udp, tcp.

Myślę, że przy pracy nad Cosealiousem możemy na podstawie np. biblioteki React zbudować framework, który robi silne założenia odnośnie tego, czym jest tworzona aplikacja i jak ma działać. Myślę, że to jest bardzo zgodne z filozofią Sealiousa - który w pewien sposób ogranicza swobodę programisty, ale daje w zamian dużo benefitów.

:thinking: To jest ciekawa myśl. Nakierowała mnie na spostrzeżenie, że w Cosealiousie próbujemy zarówno wyabstrahować przypadki użycia użytkownika cosealiousa, jak i developera cosealiousa. A moglibyśmy skupić się na punkcie widzenia użytkownika frameworka. Na podstawie kompozycji wysokopoziomowych modułów tworzylibyśmy akcje i reducery, które realizują zamierzenie developera, dając mu możliwość customizowania ich w znany mu sposób.

Pytanie: czy w reduksie można dynamicznie tworzyć reducery, akcje, itp?

Pytanie: czy w reduksie można dynamicznie tworzyć reducery, akcje, itp?

Trzeba by to sprawdzić, ale moje głębokie przekonanie jest takie, że tak :smiley:

Ogólnie twórcy Reacta nie ułatwiają nam zadania, bo właśnie wyszły hooki - można też iść w stronę, żeby Cosealious był zestawem hooków - musiałbym się pobawić jakby to wychodziło, ale krótko rozmawialiśmy z Bartkiem i chyba on też był przychylnie nastawiony do tego pomysłu. (jakby co we Vue niby też planują dodać coś podobnego).

Miałem to samo napisać - fajnie, że hooki pozwalają nam to pisać zwykłe funkcje, a nie jakieś stateful higher-order-components :smiley:

https://forum.sealcode.org/t/spotkanie-ws-nowej-wizji-cosealiousa/673/2 - termin i miejsce ustalone!

1 Like

i wszystko jasne :stuck_out_tongue:

1 Like

A nie było mniej wyraźnych pisaków? Albo gorszego aparatu? Bo tak mogę tylko trochę się wykazać znajomością Algorytmów, a gdyby np. pisać białym pisakiem i robić zdjęcia ziemniakiem, to poprzeczka byłaby na godnym mnie poziomie…

1 Like

Haha :smiley: Te notatki są bardzo na sasadzie kmwtw :wink:

Spieszę z wyjaśnieniem. Zaczęliśmy spotkanie od spisania problemów, jakie napotykamy w trakcie pracy nad front-endem. Wliczają się w nie:

  • tworzenie formularzy - walidacja, formularze wielokrokowe, tworzenie odpowiednich kontrolek dla danych pól
  • tworzenie widoków, które łączą ze sobą wiele, zmiennych źródeł informacji
  • fetchowanie danych
  • i18n
  • a11y
  • ORM
  • toasty, notyfikacje, powiadomienia o statusie (nieudane zapisanie danych, etc)
  • brak deklaratywności, jaką znamy z Sealiousa

Dokonaliśmy eksperymentu myślowego, w którym pisaliśmy hipotetyczną deklarację apki front-endowej i dyskutowaliśmy, czy bylibyśmy automatycznie taką deklarację zamieniać w działającą aplikację (ala Sealious).

Zdania były podzielone, więc zdecydowaliśmy się urządzić ergonomiczny hackaton, w którym zrobimy MVP i zobaczymy, jak się ta idea sprawuje. Wkrótce napiszę ws terminu i miejsca hackatonu :slight_smile:

1 Like