:sparkles: PWA :sparkles:
Twarz autora bloga

Piotr Kowalski

Organizator WarsawJS Trener YouTuber

Własna biblioteka cross-platform w JavaScript


Cykl życia programisty charakteryzuje się tym, że po skończonym projekcie przychodzi następny. W każdy projekcie piszemy kod JavaScript który wykonuje konkretną pracę.

Baner reklamujący artykuł

Bardzo często jednak zdarza się sytuacja, że kod który piszemy musimy wykorzystać ponownie. Dobry podejściem jest aby ten kod zamknąć w prostą bibliotekę, którą będziemy używali w miarę potrzeb.

Po pierwsze: Nazwa biblioteki

W każdym projekcie zalecaną praktyką jest stworzenie namespace’a o skróconej (jednowyrazowej) nazwie projektu.

Przykładem niech będzie artykuł Krzyśka Suszyńskiego na blogu technologicznym jego firmy Mediovski - artykuł: Sesja, a aktywność użytkownika.

Krzysiek napisał funkcję do przedłużania żywotności sesji:

pl.mediovski.technology.FormSessionHolder();

Pierwszą przestrzenią nazw jest tu język - pl. Według mnie jest to opcjonalny parametr, bo przecież zamysłem programisty jest napisanie funkcjonalności, a nie słownika, dlatego też język jest opcjonalny.

Kolejną przestrzenią jest mediovski - nazwa firmy. Następnym technology - nazwa produktu (tak mniemam). W ostatnim namespace’ie znajduje się klu sprawy - funkcja FormSessionHolder.

Po drugie: Wzorzec projektowy

Musimy się zastanowić w jaki sposób będziemy pisali swoją bibliotekę, tj. z jakiego wzorca skorzystamy podczas budowania prototypu naszej biblioteki.

Bardzo popularny wzorcem do tego rodzaju jest Singleton. Dla początkujących programistów jest to zalecany wzorzec.

Przykład biblioteki dla projektu Foo:


foo = {
    bar: {
        baz: function () {
            // do something
        }
    }
}

Lista najważniejszych wzorców znajduje się tutaj.

Uwaga: Komentarze

Komentowanie swojego kodu jest niepodważalnie właściwą praktyką. Mając na uwadze fakt, że często kod który piszemy nie my będziemy utrzymać, chęć komentowania spada. Ale jeśli to by będziemy głównymi odbiorcami to musimy robić zapiski w kodzie źródłowym.

Do prawie każdego języka wysokiego poziomu powstał system dokumentacji.

Przykład prosto z Wiki: komentowanie zgodne z JSDoc:


/**
 * Creates an instance of Circle.
 *
 * @constructor
 * @this {Circle}
 * @param {number} r The desired radius of the circle.
 */
function Circle(r) {
    /** @private */ this.radius = r;
    /** @private */ this.circumference = 2 * Math.PI * r;
}

Uwaga: Wywołania zwrotne (callbacks)

Dobra praktyką związaną ze zdarzeniową naturą języka JavaScript jest umieszczanie ostatniego parametru jako callback - funkcja, która uruchomi się po zakończeniu działania zdefiniowanej.

Wszystko to co opisałem pojawiło się w moich realiach programistycznych. Nie raz miałem zadanie napisania zawsze wycentrowanego kontenera - typu pklib.message.

W pewnym momencie zatrzymałem się na chwilę i zastanowiłem… po co kolejny raz piszę to samo? Dlatego kiedy napisałem to ostatni raz, zapisałem kod do swojej biblioteki wieloplatformowej i nazwałem ją (p)iotr (k)owalski (lib)rary tj: pklib.

Podsumowanie

Pisanie własnej biblioteki znacznie przyspieszy pracę przy kolejnych zadaniach. Kod raz napisany powinien być reużywalny, tj. wielokrotnie używany.