Imperatywnie kontra deklaratywnie w JavaScript/ES6

Poziom średnio-zaawansowany

Dziś mały artykuł o podejściu do pisania kodu. Czy piszesz swój kod JS deklaratywnie, czy raczej imperatywnie? Być może niektórzy nie zwracają uwagi, a jednak warto. Podobnie jak w przypadku metodologii pisania i organizacji stylów CSS.

Deklaratywnie vs imperatywnie w JavaScript/ES6

Programowanie deklaratywne jest paradygmatem programowania – podejściem do budowania struktury i elementów programów, który wyraża logikę obliczeń bez opisu jej przepływu sterowania. W przeciwieństwie do programów napisanych imperatywnie, programista opisuje warunki, jakie musi spełniać końcowe rozwiązanie (co chcemy osiągnąć), a nie szczegółową sekwencję kroków, które do niego prowadzą (jak to zrobić).

Wiele języków, które stosują podejście deklaratywne, próbuje zminimalizować lub wyeliminować efekty uboczne, opisując co program musi wykonać w swoim zakresie dziedziny, zamiast opisywać, jak osiągnąć to jako sekwencję prymitywów języka programowania. Z kolei imperatywnie – implementujemy algorytmy w wyraźnych krokach.

Nuda. Spójrzmy na to po prostu.

Kod imperatywny definiuje co oraz jak ma być zrobione, np.:

– idź do kuchni
– pokrój chleb
– wyjmij masło z lodówki
– …
– …
– połóż kanapkę na stole

Z kolei w świecie programowania deklaratywnego opisujemy czego potrzebujemy:

– chcę kanapkę

Lub innymi słowy, imperatywnie wyrażamy dokładne instrukcje jak do nas dojechać (skręć tu, jedź tam, itd). Deklaratywnie piszemy: „przyjedź do mnie pod adres XYZ”. Itd.

Gdzie haczyk? Po prostu budując nasz program deklaratywnie, opisujemy czego potrzebujemy. Program składamy (komponujemy) z poszczególnych elementów. Elementy te mogą istnieć we frameworku lub bibliotece, open-source lub w naszych własnych bibliotekach. Jeśli nie są dostępne, piszemy je. Imperatywnie? Tak, w końcu dojdziemy do takiego poziomu abstrakcji.

Wydawnictwo Strefa Kursów

Najprościej mówiąc, gdy nie ma już niższego poziomu abstrakcji, musimy napisać kod (funkcje, biblioteki, komponenty, etc), który implementuje to, czego potrzebujemy. Na wyższym poziomie abstrakcji będziemy korzystać z tego, budując program deklaratywnie, jak i modyfikując go łatwiej.

Znów bla blah. Najlepiej spójrzmy na przykłady kodu JS.

Sass (scss)

Szybka nauka Sass (SCSS)

Poziom średnio-zaawansowany

Sass (Syntactically awesome style sheets), znany również jako CSS with superpowers, jest to preprocesor, który czyni opracowywanie stylów dla naszych projektów, znacznie łatwiejszym, przyjemniejszym, szybszym. Pozwala również znacząco ulepszyć samą strukturę kodów, używać zmiennych oraz tworzyć elementy wielokrotnego użytku (mixins, placeholders), co znacząco poprawia również łatwość utrzymania i modyfikacji.

Szybka nauka Sass (SCSS)

O Sass (scss) wspominaliśmy już, oraz używaliśmy w artykułach o strukturze CSS oraz konwencjach i metodologiach dla CSS i Sass. Polecam poczytać:

część 1

część 2

Zobacz także:

https://en.wikipedia.org/wiki/Sass_(stylesheet_language)

Po co nam nauka Sass?

Cóż, pisanie kodu CSS jest proste. Pisanie kodów CSS dla większych projektów, które łatwo utrzymywać już nie jest proste. Potrzeba narzędzi oraz metodologii, które to uproszczą, przyśpieszą, oraz po prostu nakierują programistów na właściwy tor.

Jednym z takich narzędzi jest stary, poczciwy Less CSS, jednak od dawna go nie używam. Jego miejsce w moim przypadku zastąpił Sass, który po prostu uwielbiam.

Wydawnictwo Strefa Kursów

Klikalny numer telefonu na stronie – click to call w HTML5

Poziom średnio-zaawansowany

W tym artykule temat prosty. Zwyczajnie podsumowujemy w jednym miejscu możliwości tworzenia telephone links, lub jak kto woli klikalnych numerów telefonu. Współcześnie pewna część aplikacji mobilnych jest realizowana nie jako native, ale jako web apps, a tam często zachodzi potrzeba stworzenia linku do rozmowy telefonicznej (zadzwoń do użytkownika), lub wysłania SMS.

Klikalny numer telefonu w HTML5

Również na „zwykłych” stornach, umieszczając dane kontaktowe, w tym numery telefonów, mile widziana jest (z punktu widzenia użytkowników jak i UX) możliwość kliknięcia w numer telefonu, aby go bezpośrednio wywołać. Rozmowa telefoniczna, SMS, a może Skype? HTML5 daje nam wygodny sposób tworzenia linków do rozmowy telefonicznej, Skype, e-mail, itd.

Jak to zrobić?

Nic prostszego. Wystarczy skorzystać z atrybutu ‚href’ linku, dodając wyrażenie tel:, a następnie poprawny numer telefonu. Przykłady poniżej.

Wydawnictwo Strefa Kursów

Styl, konwencje i metodologie CSS – część 2. Sass, BEM, rscss, SMACSS, WTF?

Poziom zaawansowany

Ciąg dalszy tematyki poruszanej w części I. Dziś przyjrzymy się kolejnym metodologiom pisania CSS, takim jak BEM, rscss, SMACSS. Należy dodać, że metodologie możemy łączyć (np. OOCSS + BEM). O ile oczywiście ma to dla nas sens. Do rzeczy.

Metodologie CSS: SMACSS

Zaczniemy od SMACSS, choć od razu powiem, że nie pracowałem z tym przy realnym projekcie. Nie chodzi o to, że SMACSS jest kiepski. Ta metodologia po prostu mi nie odpowiada; z pewnością jest nie bez zalet, jednak niektóre jej detale dla mnie są irytujące. ALE może oczywiście odpowiadać innym.

SMACSS (Scalable and Modular Architecture for CSS), którego autorem jest Jonathan Snook, to style guide dla kodu CSS, które organizuje kod CSS według kategorii (Base, Layout, Module, State, Theme). Przyjrzyjmy się im bliżej.

Base

Style bazowe, ogólne. Ta grupa stylów odpowiada za wartości domyślne; domyślny wygląd elementów strony (marginesy, inputy, fonty, przykład: normalize.scss).

Layout

Style layoutu definiują wygląd i rozmieszczenie typowych dla stron i aplikacji WWW elementów, takich jak header, footer, sidebar. W SMACSS (i nie tylko) przyjęło się używać dla nich prefixu „l-„.

Module

Moduły w SMACSS to niezależne, re-używalne bloki kodu (UI), takie jak menu, search box, listy pozycji, etc. Można powiedzieć że są czymś w rodzaju bloków w BEM. Moduły zwykle znajdują się w kontenerach, wewnątrz elementów layoutu.

Założenie jest takie, że każdy moduł powinien być niezależny od pozostałych modułów. Powinien on też działać tak samo w każdym kontenerze, w jakim go umieścimy. Nie należy zatem tworzyć stylów uzależnionych od kontenera nadrzędnego.

Przykładem może być moduł menu:

...

.menu {
  background: #00a;
}

.menu h1 {
  font-size: 20px;
}

.menu .menu-item {
  border: 1px solid #000;
}
...

State

Style stanu po prostu określają wygląd stanu, w którym element może się znajdować, zależnie od sytuacji (hidden, expanded, etc). Zwijamy lub rozwijamy listę, najeżdżamy kursorem na element, i inne takie sytuacje.

Taka sytuacja

Taka sytuacja

Przykład:

<div class="menu is-expanded">
  ...
</div>

Zaleca się takie stany logiczne definiować z prefixem „is-„, np. is-active.

Theme

Themes zwykle znajdziemy w większych projektach, gdzie występują warianty (np. daily, nightly, sexy, sunny, etc), które określają różny wygląd (look and feel) dla elementów modułów i layoutów projektu.

SMACSS – przykład 1:

// Layouts
.l-default {}

// Modules 
.m-accordion {}

// States, mostly with prefix like "is-"
.is-active {}
.is-hidden {}

SMACSS – przykład 2 – mediaqueries:

.m-navigation {
  &:after {
    @media screen and (min-width: 767px) {
      content: '';
      display: inline-block;
      width: 100%;
    }
  }

  li {
    display: block;

    @media screen and (min-width: 767px) {
      float: left;
    }
  }
}

Zobacz także

Ten autor stworzył własny style guide na bazie SMACSS i OOCSS:

https://github.com/timhartmann/Scss-Styleguide

Z kolei autor SMACSS’a prowadzi stronę (https://smacss.com), gdzie możemy kupić lub przeczytać za darmo on-line, książkę poświęconą tej metodologii:

https://smacss.com/book

Styl, konwencje i struktura CSS. Sass, OOCSS, BEM, rscss, SMACSS, OMG?

Poziom zaawansowany

Co to znaczy być zajętym? Ano na przykład nie mieć absolutnie czasu nawet na nowe posty na blogu, chociaż tematów jest cała rzeka. Tak oto byłem zajęty, zawodowo oraz prywatnie. Dziś wracamy „on-line” z tematem, i to nie byle jakim… Zyskiwać czas można poprzez optymalizację codziennych czynności, ich automatyzację i organizację. I zawsze staram się to krok po kroku wdrażać. Efekty widać gołym okiem – więcej czasu, mniejsze zmęczenie i frustracja.

W aspekcie programowania można by tutaj napisać o narzędziach, np. webpack. Ale temu poświęcimy oddzielne posty. Dziś skupimy się na podejściach do pisania stylów CSS w dobry, komfortowy dla nas (i dla innych) sposób, aby to co stworzymy było łatwe w utrzymaniu i rozbudowie.

„Long term value of the software is directly proportional to the quality of code base…”
— Douglus Crockford

Czy znacie style guides i konwencje CSS? Na przykład OOCSS, BEM, rscss, SMACSS. A może OMG? Być może stosujecie wybrane podejście do tworzenia CSS, być może jedynie obiło się o uszy, ale nie porwało Was na tyle, aby to zastosować. A może widzieliście już przykłady CSS w tutorialach napisane z użyciem BEMa czy innego SMACSSa, ale nie zwracaliście uwagi na takie detale. Ten artykuł bierze pod lupę właśnie podejścia o pisania CSS, organizacji plików, nazywania klas CSS, itp. Team jest obszerny i wyjdzie poza jeden artykuł.

Notka: jako że od dawna piszę style prawie wyłącznie przy użyciu Sass (SCSS – Syntactically Awesome Style Sheets), również artykuły i przykłady kodów odnosić się będą do tego preprocesora CSS, zwanego też „CSS with superpowers” 🙂 Poświęcimy mu oddzielny artykuł, póki co można zerknąć na oficjalną stronę: http://sass-lang.com po więcej informacji.

Wydawnictwo Strefa Kursów

Pracę z Sass można zacząć (kto jeszcze tego nie zrobił) szybko i przyjemnie. Nie trzeba nawet tracić zbytnio czasu na narzędzia i konfiguracje – web framework, którego używacie prawdopodobnie wspiera Sass. Sam pracuję głównie w Ruby on Rails (RoR) oraz node.js, gdzie nie ma żadnych z tym problemów.

Co do style giude, to jeśli chodzi o JavaScript / ES6, moim ulubionym jest ten opracowany przez Airbnb:

https://github.com/airbnb/javascript

To samo dotyczy podejścia do pisania (S)CSS:

https://github.com/airbnb/css

Dla wybranych składni możemy sobie zainstalować i skonfigurować odpowiedni linting.

UWAGA: mam jedno zastrzeżenie do rekomendacji Airbnb, co do letter case dla bloków. Nie przepadam za PascalCase / camelCase, zwłaszcza we front-end development. Oczywiście np. w Ruby / RoR (które uwielbiam) używamy PascalCase dla nazw klas i snake_case dla nazw metod, gdzie wygląda to świetnie. Po prostu jakoś tak… bardzo pasuje akurat tak, a nie inaczej.

W przypadku CSS zdecydowanie preferuję kebab-case (spinal-case, hyphen delimited, https://en.wikipedia.org/wiki/Letter_case#Special_case_styles), stąd też nie piszę żadnych:

.pageHead {}
.sub_header {}
...

tylko:

.page-head {}
.sub-header {}
...

Oczywiście jest to tylko moja własna preferencja.

Tak naprawdę podejść i konwencji, zarówno dla JS i CSS, jest cała masa. My powinniśmy oczywiście używać takiej, która jest rozsądna, spójna ORAZ komfortowa dla nas. Jeśli nie mamy własnego, „lepszego” zbioru zasad, skorzystajmy z jednego z dostępnych. Mój wybór to konwencje od inżynierów Airbnb. I jak widzimy, w przypadku przewodnika dla CSS, również tam pojawia się rekomendacja używania BEM i/lub OOCSS. Tym będziemy się zajmować. Tak naprawdę… ważne jest nie tyle jakie konwencje wybieramy (… niby dlaczego A jest lepsze od B? może dla mnie, ale nie koniecznie dla Ciebie …). Ważne jest, aby trzymać się wybranych konwencji konsekwentnie. Wtedy naprawdę skorzystamy, w przeciwnym razie prędzej czy później powstanie niepotrzebny bałagan.

Zacznijmy jednak od kilku słów na temat Sass / SCSS, oraz przede wszystkim, od struktury plików dla naszych stylów.

„Writing CSS is easy. Writing maintainable CSS is hard.”

Dlaczego to wszystko ma znaczenie? OK, sam nie lubię tego „Overengineering’u”, który zdaje się być typowy dla środowiska programistów front-end. Stąd mamy miliardy narzędzi, bibliotek, approaches i „racji” co do pisania kodów JS i CSS. Niektórzy programiści niestety zdają również być, delikatnie mówiąc, dziwni, próbując narzucać jakieś podejście jako „jedyne słuszne”.

Bzdury… Niektórzy są irytująco leniwi, jako że problemem zdaje się dla nich stawianie średnika na końcu linijki. Albo problem „czy muszę uczyć się PHP lub innego języka, skoro znam JS”… nie ma to jak pasja do programowania, co? 🙂

OK, ja uczyłem się języków jeden po drugim, i nigdy nie widziałem w tym problemu (ale może jestem już dinozaurem 🙂 ?). Trochę też trwało, zanim znalazłem „swoje miejsce” w programowaniu. Dziś jest inaczej, dziś jest znacznie prościej. Wszystko mamy podane na tacy, dostęp do rozwiązań i wiedzy. Mamy na tacy wręcz za dużo, dlatego trzeba wybrać coś dla siebie.

Wiadomo że zawodowo używa się kilku języków i narzędzi, cała reszta może być for fun, czy dla pasji. Może też przydać się np. do rozwoju jakiegoś projektu open source, bądź poratować nas, gdy kiedyś okaże się, że potrzebny nam większy skill. W końcu ta branża jest dynamiczna jak chyba żadna inna.

Co więc z tymi średnikami? Helloooł, a programowałeś w czymkolwiek innym? Ja uwielbiam Język Ruby i jego konwencję. No i brak średników. Jednak co do JS i CSS, to przez wszystkie lata przywykłem do średników na końcu. Zwyczajnie. I Innych detali, jak wcięcia, itp. Wiem kiedy kod wygląda dla mnie dobrze, a kiedy nie…

Ktoś w swoich projektach jak najbardziej może używać .sass zamiast .scss lub Standard JS zamiast Airbnb JS. Grunt żeby było komfortowo i praktycznie. Oraz spójnie. Dla mnie komfortowo i praktycznie jest tak, a nie inaczej, stąd też trzymam się konwencji Airbnb dla JS, oraz preferuję składnię .scss ponad .sass. Jeśli pokażę jednak przykłady kodu według moich ulubionych konwencji, NIE powinno być żadnego problemu dla innych, aby szybko zaadaptować je do używanych przez siebie podejść. Dla prawdziwego programisty takie detale to małe piwo.

Wspominam o tym, ponieważ warto być elastycznym i adaptować się. Szczególnie w teamie. A ja pracując przez lata w różnych team’ach i projektach, po prostu musiałem „wskoczyć” w sposób programowania teamu, zamiast próbować go zmieniać – na siłę, a już na pewno nie hejtować.

Dobre, uzasadnione zmiany są zwykle mile widziane. Ale przebudowa ponad połowy kodu dla samej sztuki, albo czyjegoś wyznania… „a bo w ostatnią sobotę oglądałem video-tutorial z hiper fajnym, trendy podejściem – musimy przerobić nasz kod, będzie fajniejszy i łatwiejszy w utrzymaniu”. Hola, a czy obecny kod nie jest?

Cóż… Sam nienawidzę rozwiązań, które zdają się jedynie tworzyć problemy, ale je rozwiązać, lub takich, które rozwiązują jeden „problem”, ale w jego miejsce przynoszą 10 innych… Takich „cudów” unikamy, sięgamy po sensowne, faktycznie potrzebne rozwiązania, które przynoszą realne korzyści i dają udogodnienia.

Tak czy inaczej, warto szukać sposobności do pójścia naprzód, zamiast wymówek. Rozwijajmy się, śledźmy nowe trendy i budujmy nowoczesne oprogramowanie. Dobry, czysty i spójny kod, który nie będzie przestarzały za 5 minut. W nowoczesnych podejściach fajne jest to, że znacznie łatwiej niż kiedyś możemy aktualizować nasze rozwiązania do nowszych wersji.

Ale na tym dość już filozofii, nie chcę wchodzić w te tematy rzeki. Do dzieła!

Progress bar

Style CSS dla html5 progress bar w różnych przeglądarkach

Poziom średnio-zaawansowany

Dziś kilka słów o HTML5 progress bar, a konkretnie nadawanie mu CSS w taki sposób, aby wyglądał tak samo we wszystkich przeglądarkach. Może tego wymagać projekt, a programista może być zaskoczony, że określone style stosują się tylko w określonej przeglądarce, podczas gdy w innych przygotowany pasek postępu wygląda zupełnie inaczej.

Ten sam wygląd html5 progress bar w różnych przeglądarkach

Różne przeglądarki różnie wyświetlają pasek postępu html5, różne są także domyślne style. Jeśli chcemy, aby pasek zawsze wyglądał tak samo we wszystkich przeglądarkach, potrzebujemy małego triku CSS. Gotowe rozwiązanie poniżej.

Yeoman

Przydatne narzędzia dla programistów: Yeoman

Poziom średnio-zaawansowany

Znalazła się w końcu odrobina czasu na blogowanie, dlatego dziś chciałem napisać kilka słów o jednym z przydatnych narzędzi dla programistów – Yeoman.

Yo man! Przydatne narzędzia dla programistów – pan Yeoman

Po co robić żmudne, powtarzalne czynności skoro może to za nas robić maszyna, lub w tym przypadku – program. Yeoman pozwala nam na generowanie różnego rodzaju projektów – szczególnie tworzenie struktury katalogów i niezbędnych składników, zgodnie z najlepszymi praktykami i wzorcami.

Następuje wstępne utworzenie niezbędnych katalogów oraz plików, a także zainstalowanie potrzebnych zależności (dependencies).

Przykładowo możemy tworzyć nowy AngularJS, dla którego może zostać od razu zainstalowany Bootstrap, Saas i inne rozszerzenia, których nasz projekt będzie potrzebować.

Instalacja opiera się o npm, który z pewnością mamy w naszym środowisku, jeśli mieliśmy już do czynienia z node.js. Potrzebny jest również Bower i Grunt =>

Pasek postępu w CSS – progress bar w kilku linijkach kodu

Poziom średnio-zaawansowany

Pasek postępu (progress bar) w projekcie Web? Jasne – i to bez użycia obrazków. Dziś krótko i na temat.

Pasek postępu w CSS i HTML5

Możemy skorzystać z HTML5 i Bootstrap, lub zdefiniować własne style CSS.

Sposób 1 – HTML5

Dodajmy do strony Bootstrap i jQuery, oraz kod jak poniżej.

...
  <div class="progress" style="width: 50%">
    <div class="progress-bar" role="progressbar" aria-valuenow="40"
      aria-valuemin="0" aria-valuemax="100" style="width: 40%">
      40% (default style)
    </div>
  </div>

Gotowe. Mamy pasek postępu! Kolory i postęp definiujemy poprzez klasy CSS (np. class=”progress-bar progress-bar-danger”) oraz właściwości (np. role=”progressbar”, aria-valuenow=”100″). A ponadto ustawiamy szerokość elementu (style width).

Więcej przykładów pasków postępu poniżej.

Tutorial AngularJS – proste UI do sterowania elementami

Poziom średnio-zaawansowany

Angular w praktyce! Dziś mamy tu mały tutorial AngularJS, w którym stworzymy proste UI powiązane z dynamicznie rysowanym (odświeżanym ) obiektem graficznym.

Tutorial AngularJS – sterowanie obiektem graficznym za pomocą Angular

W kursie podstawowym skupialiśmy się głównie na informacjach, warto więc teraz zobaczyć to w realnym przykładzie. Pomoże nam ten prosty tutorial w kilku krokach.

Krok 1.

Stwórzmy dokument HTML5 i dołączmy bibliotekę AngularJS.

Krok 2.

Zdefiniujmy element, którym będziemy poruszać z poziomu UI. W naszym przykładzie stworzymy prosty element w CSS:

.my-elem {
  background: #00c;
  border-radius: 10%;
  position: absolute;
  width: 200px;
  height: 200px;
  max-width: 500px;
  max-height: 500px;

  /* speed */
  transition: 0.8s;
  -webkit-transition: 0.8s;

  /* init pos*/
  left: 100px;
  top: 200px;
}

Nauka AngularJS od podstaw – część III – podsumowanie

Poziom średnio-zaawansowany

W części III podstawowego kursu Angular kontynuujemy zagadnienia z części poprzedniej, jak i dotykamy nowych, kolejnych zagadnień dotyczących pracy z tą biblioteką.

Nauka AngularJS – kolejne zagadnienia

Zacznijmy od filtrów. To kolejna cecha AngularJS, która zdejmuje z programisty część żmudnej pracy. Zobaczmy je w akcji, podczas formatowania danych różnego rodzaju.

Filtry (AngularJS filters)

Już w poprzedniej części mogliśmy zobaczyć jak proste w użyciu (a jednocześnie pomocne) są filtry, na przykład:

...
<p>{{ message.sent | date:'MMM d, y h:mm:ss a' }}</p>
...