PicoAjax

Końcówka roku to oczywiście czas podsumowań i powrotów do przeszłości. Z racji tego, że podsumowań nie lubię, spróbuję wrócić do przeszłości. A to umożliwi mi… biblioteka PicoAjax, którą ostatnio przez zupełny przypadek odkryłem.

Co ciekawe, nie sądzę, żeby ta biblioteka była zła, raczej całkowicie anachroniczna. Przypomina mi dawne, złote czasy Alladyna. Zanurzmy się zatem w te wspomnienia!

• Zacznijmy od samej strony. Szkoda, że jest tak niesamowicie nieczytelna, a same przykładowe kody nie są nawet zamknięte w znacznik code. Przydałby się także jakiś highlighter kodu.
• Na stronie uparcie jest używany termin Ajax jako akronim (zatem zapisywany jest dużymi literami). Problem polega na tym, że… jest nawet odniesienie do artykułu, w którym termin Ajax jest definiowany jako nie-akronim. To po prostu neologizm.
• Po przeglądnięciu dokumentacji już można wyrobić sobie zdanie o tym, jak stare praktyki są używane wewnątrz picoAjax. Mamy [onclick], mamy walidację formularzy podpiętą przy pomocy atrybutów [rel] (zamiast przy pomocy standardowych atrybutów HTML5 stworzonych w celu walidacji formularzy) czy w końcu wrzucenie ponad setki funkcji do globalnego scope. Patrząc na ten kod, naprawdę odnoszę nieodparte wrażenie, że cofnąłem się do 2005 roku.

• Jeszcze jedna rzecz zasługuje na zainteresowanie:

  <a href="javascript:picoGo('https://pl.wikipedia.org/wiki/Internet_Explorer_11')" title="Internet Explorer 11">IE11</a>

  To klasyka złego [onclick]a.

• Liczba funkcji w bibliotece robi wrażenie… ale czy obliczanie całki oznaczonej albo promil zawartości alkoholu we krwki (wg wzór E. Widmarka) (pisownia oryginalna) to są funkcje odpowiednie dla biblioteki typu jQuery?
• Nazwy poszczególnych funkcji są ręcznie zaciemniane, np. picoC to „ułatwienie” przy używaniu element.style.color. I znów: czuję się jak w 2005, gdy takie praktyki faktycznie się stosowało (bo każdy bajt kodu bolał!) – wystarczy sobie zobaczyć choćby we wspomnianym Alladynie.

• Ściągnąłem wersję 5.15 biblioteki i zajrzałem do bebechów. Pierwsza funkcja, jaką znalazłem, to loader zasobów, picLoad. I tutaj już zauważyłem kilka problemów:

  • Jeśli nie poda się adresu zasobu do wczytania, użytkownik dowie się o błędzie. Zamiast alert mimo wszystko powinniśmy rzucić błąd do konsoli.
  • Autor wyszedł z założenia, że rozszerzenie może mieć albo 2, albo 3, albo 4 znaki. Błąd. Tak naprawdę nie ma limitu znaków w rozszerzeniu. Bardziej niż samemu rozszerzeniu wierzyłbym typowi MIME.
  • Dziwi mnie także, że nie wczytam obrazka jeśli w adresie znajdzie się fraza php. Zatem loga PHP raczej nie wczytam…
• Samo formatowanie kodu jest nad wyraz oszczędne. To strasznie utrudnia czytanie kodu.
• Obsługa XHR mogłaby zostać przeniesiona do osobnej funkcji, bo na chwilę obecną jest niepotrzebnie powtarzana w kilku miejscach.
• Walidator formularzy nie pozwala zmienić komunikatów o błędach. To trochę dziwne – zwłaszcza, że walidator w ogóle nie powinien zajmować się komunikatami błędów. Walidator – jak sama nazwa wskazuje – waliduje (sprawdza poprawność). Jego zadaniem jest stwierdzenie, czy i co jest źle. A co program z tą informacją zrobi, to już nie sprawa walidatora.

• function picoGo(url) {window.location.href=url};

  Nie widzę sensu w tej funkcji – a przynajmniej nie w kontekście linków. To nic innego jak próba wynalezienia ich na nowo.

• Dużą część kodu można obecnie przenieść do CSS-a, np. obsługę rolloverów czy generowanie tabelek-zebr (z naprzemiennym kolorowaniem wierszów).
• Niektóre z funkcji można przepisać tak, aby pozbyć się w nich ifów, np. picoFullScreen mogłoby najpierw sprawdzać, jaka wersja API jest dostępna, a dopiero później się „przypisać na stałe”.

• function picoC(e,k)      {eval('e.style.color=k')}
  function picoW(e,w)      {eval('e.style.width=w')}
  function picoH(e,h)      {eval('e.style.height=h')}
  function picoB(e,b)      {eval('e.style.border=b')}
  function picoF(e,f)      {eval('e.style.fontFamily=f')}
  function picoFS(e,r)     {eval('e.style.fontSize=r')}
  function picoBC(e,k)     {eval('e.style.background=k')}
  function picoBS(e,k)     {eval('e.style.boxShadow=k')}
  function picoTS(e,k)     {eval('e.style.textShadow=k')}
  function picoTA(e,k)     {eval('e.style.textAlign=k')}
  function picoBR(e,k)     {eval('e.style.borderRadius=k')}

  Tak szczerze to bym się tego pozbył. Jest to naprawdę nieczytelne.

• function picoTxtContent(el) {return el.textContent}
  function picoTXT(id,txt) {picoId(id).innerHTML=txt}

  A tę niespójność chyba łatwo dostrzec. No i przede wszystkim: tekst to tekst! Jeśli chcę nadać wartość tekstową elementowi, to nie życzę sobie, żeby HTML był parsowany, bo np. chcę wyświetlić encje, np.   zamiast niełamliwej spacji.

Mam to dziwne uczucie, że to nie jest nowa biblioteka. Naprawdę przywodzi na myśl stare, dobre czasy sprzed jQuery. Nie umiem powiedzieć, że jest zła – raczej zagubiona w czasie.

Tyle na dzisiaj… i w 2016 roku. Szczęśliwego Nowego Roku i do przeczytania!