Ocena biblioteki komponentów Web UI z VirtualDom

Cześć,

Utworzyłem projekt TypeScript z biblioteką komponentów webowych opartych o Virtual DOM. Jest to wstępny etap, dlatego chciałbym Was prosić o oceny takie, które mogłyby skierować prace na właściwe tory, jeśli coś jest nie tak. Chodzi mi o sprawy związane z konfiguracją projektu; typescript, webpack, github actions, ale będzie mi miło, jeśli spojrzycie również na kod i też go ocenicie. Jest tam jeszcze kilka błędów których jestem świadomy, trochę też rzeczy niedopracowanych, ale jak wspomniałem, chodzi mi o wyprostowanie kierunku rozwoju, na który mogłoby być za późno w przyszłości.

W założeniu biblioteka będzie pozwalała tworzyć np. Layout, Formularz z różnymi kontrolkami, tabbar, tabelę itd. Kilka jest już dostępnych, a przykłady wykorzystania można zobaczyć na StackBlitz: https://stackblitz.com/@PrzemekNiedziela/collections/webcraft

Po co to wszystko? Pracuję jako programista na tym samym stanowisku od 9 lat, utrzymując i rozwijając wewnętrzną aplikację. Działam w vanilla JS + SQL Server, czasami zdarzają się jakieś inne rzeczy z C#, Java itd. Wewnątrz firmy jestem ekspertem, dobrze rozumiem jak działa internet i przeglądarka, ludzie w zespole jak mają problem do rozwiązania, to wiedzą, że ja go rozwiążę. Mam jednak kompleksy względem rynku, ponieważ nie korzystamy z nowoczesnych technologii jak TypeScript, React, a nawet git. Staram się to nadrabiać prywatnie z myślą, że może kiedyś odważę się poszukać lepszej pracy, lub nie zginąć jeśli z jakiegoś powodu stracę obecną. Robiłem sobie czasem jakieś projekty i tutoriale czy to w TS, czy React, ale teraz chciałbym zrobić coś konkretnego, co mogłoby być faktycznie przydatne dla innych, na czym mógłbym się jeszcze lepiej doszkolić i zrozumieć w jaki sposób tworzy się dzisiaj nowoczesne oprogramowanie.

Link do projektu: https://github.com/wizard8912/webcraft
Link do przykładów: https://stackblitz.com/@PrzemekNiedziela/collections/webcraft

• Wydaje się trochę mało (albo w ogóle) rozszerzalna. Wygląda jakby dało się w niej zrobić tylko to co Ty jako autor przewidzisz, i nic więcej.
• Nie udało mi się znaleźć przykładu który pokazuje np wykorzystanie wartości input z takiego pola z liczbami. Jak je odczytać, jak zareagować na zmianę, etc?

Jakbym miał podsumować tą bibliotekę, to określiłbym że to jest dosyć niskopoziomowa abstrakcja na DOM, tylko że w niektórych miejscach ta abstrakcja przecieka.

Na plus jest to że nie widzę żadnych czerwonych flag, także tutaj

Riddle napisał(a):

• Wydaje się trochę mało (albo w ogóle) rozszerzalna. Wygląda jakby dało się w niej zrobić tylko to co Ty jako autor przewidzisz, i nic więcej.
• Nie udało mi się znaleźć przykładu który pokazuje np wykorzystanie wartości input z takiego pola z liczbami. Jak je odczytać, jak zareagować na zmianę, etc?

Jakbym miał podsumować tą bibliotekę, to określiłbym że to jest dosyć niskopoziomowa abstrakcja na DOM, tylko że w niektórych miejscach ta abstrakcja przecieka.

Na plus jest to że nie widzę żadnych czerwonych flag, także tutaj

Dziękuję.

Jeśli chodzi o reagowanie na zmiany, to poszczególne komponenty (np. InputNumber) mają powiązane instancje EventEmittera, dodałem przykład jego wykorzystania tutaj: https://stackblitz.com/edit/webcraft-inputnumber?file=index.ts

Jeśli chodzi o Twoje podsumowanie to wydaje mi się, że problem przeciekania abstrakcji chyba zawsze będzie aktywny dla tego typu biblioteki - ona daje pewien zestaw narzędzi na start, dzięki którym można szybko zbudować aplikacje dla biznesu (zamiast pisać tabelę + toolbar, wykorzustujemy je), ale też ciężko jest sprostać wszystkim możliwym potrzebom, więc potencjał na korzystanie bezpośrednio z DOM chyba zawsze będzie. Oczywiście problem przeciekania będzie minimalizowany wraz z rozwojem biblioteki.

Intryguje mnie problem z rozszerzaniem, czy chodzi Ci o możliwość definiowania własnych komponentów? Dotąd nie miałem takich pomysłów, ale wydaje mi się, że to mogłoby być jakimś dodatkowym feature który można zrealizować w przyszłości. Jeśli chodzi o rozszerzanie istniejących komponentów, no to jest możliwe zgodnie z tym jak działa OOP. Ew. różne customizacje widoków są przewidziane (np. funkcje z templatkami), ale to wymaga realizacji, którą już sobie tam w przyszłości będę realizował.

Wydaje mi się, że obecnie takim "standardem" w kwestii bibliotek UI to składnia zbliżona do HTML

<CommentForm>
  <label for="...">Imię i nazwisko</label>
  <Input id="..." name="..." />

  <label for="...">Treść komentarza</label>
  <Textarea id="..." name="..." />

  <SubmitButton>Wyślij komentarz</SubmitButton>
</CommentForm>

i dopiero wewnątrz biblioteki jest to zamieniane na kod js (np https://developer.mozilla.org/en-US/docs/Web/API/Web_components)

Do takiego zapisu podchodzę niezbyt chętnie

const box = new Box({
  content: [
    {
      direction: 'row',
      content: [
        {
          header: 'Header',
          content: '1.1',
          collapsable: true,
          sizes: { minWidth: 300 },
        },
        {
          header: 'Header',
          content: '1.2',
          collapsable: true,
          sizes: { minWidth: 300 },
        },
        {
          header: 'Header',
          content: '1.3',
          collapsable: true,
          sizes: { minWidth: 300 },
        },
      ],
    },
  ]
});

bo pamiętam jak w pracy wymyślili coś podobnego tylko cały format był oparty o JSON bez statycznego typowania

I zamiast 1000 linijek HTML było 15 000 linijek JSONA niemożliwego do edycji, chyba że było się autorem pomysłu.

wizard89123 napisał(a):

Jeśli chodzi o reagowanie na zmiany, to poszczególne komponenty (np. InputNumber) mają powiązane instancje EventEmittera, dodałem przykład jego wykorzystania tutaj: https://stackblitz.com/edit/webcraft-inputnumber?file=index.ts

Ja jako użytkownik biblioteki nie chcę znać szczegółów implementacyjnych.

Nie do końca rozumiem czemu interfejs to jest input.events.on("afterChange"), zamiast np input.on("afterChange").

wizard89123 napisał(a):

Jeśli chodzi o Twoje podsumowanie to wydaje mi się, że problem przeciekania abstrakcji chyba zawsze będzie aktywny dla tego typu biblioteki - ona daje pewien zestaw narzędzi na start, dzięki którym można szybko zbudować aplikacje dla biznesu (zamiast pisać tabelę + toolbar, wykorzustujemy je), ale też ciężko jest sprostać wszystkim możliwym potrzebom, więc potencjał na korzystanie bezpośrednio z DOM chyba zawsze będzie. Oczywiście problem przeciekania będzie minimalizowany wraz z rozwojem biblioteki.

No, nie no. Nie powinno to przeciekać - Ty jako dostawca biblioteki, to powinieneś mieć jasno sprecyzowane odpowiedzialności tej biblioteki. I powinno być zrobione tak że, albo jest 0% abstrakcji na coś, np na style - i wtedy ja jako użytkownik dbam o to, i to jest wtedy moja działka; albo tak że to jest 100% abstrakcji, czyli że Ty mi tylko wystawiasz interfejs, i ja go mogę użyć.

Ale jak dostanę coś takiego, co jest takim pół na pół, czyli taką pół abstrakcją, pół nie abtrakcją, to tego mi się źle używa. Mówię np o tych atrybutach jak align i justify, które niby są interfejsem Twojej biblioteki, ale czuję że są jakieś edge'casey które można wytłumaczyć tylko tym że pod spodem jest flexbox.

wizard89123 napisał(a):

Intryguje mnie problem z rozszerzaniem, czy chodzi Ci o możliwość definiowania własnych komponentów? Dotąd nie miałem takich pomysłów, ale wydaje mi się, że to mogłoby być jakimś dodatkowym feature który można zrealizować w przyszłości. Jeśli chodzi o rozszerzanie istniejących komponentów, no to jest możliwe zgodnie z tym jak działa OOP. Ew. różne customizacje widoków są przewidziane (np. funkcje z templatkami), ale to wymaga realizacji, którą już sobie tam w przyszłości będę realizował.

Nie chodzi tylko o dodatkowe komponenty.

Powiedzmy że jest taki komponent:

const input = new InputNumber({
  label: 'Input number',
  icon: 'fa-solid fa-gauge-high', // tutaj przecieka abstrakcja, bo widać że to są ikony z font awesome.
  value: 250,
});

Widzę że do {icon:} wkłada się klasę z font-awesome, np. 'fa-solid fa-gauge-high', a Twoja biblioteka za pewne pod spodem to wsadza w <i> i doładowuje zależność. Niby spoko.

Ale co jak ja chcę użyć innej biblioteki do ikon, takiej która nie wsadza swojej ikonki w <i>?

Byłoby to rozszerzalne, gdyby Twój interfejs wyglądał jakoś tak:

import { InputNumber, attribute, label, fontAwesome } from 'webcraft-ui';

const input = new InputNumber([
  attribute({value: 250}),
  label("input number"),
  fontAwesome('fa-solid fa-gauge-high'),
]);

I ta funkcja fontAwesome() powinna odpowiadać w 100% za dodanie odpowiedniego elementu HTML, tak żeby był zgodny z fontawesome i ona powinna odpowiadać za doładowanie zależności, oczywiście nie łamiąc abstrakcji Twojej biblioteki.

Wtedy doadnie ikon np z Icomoon wiązałby się z napisaniem po prostu swojej wersji tej funkcji.

To co opisałem to w zasadzie Dependency Inversion.