Minął kolejny tydzień. W zasadzie to trzy tygodnie od ostatniego wpisu w Learning Logu. Czas nadrobić zaległości! :) Dzisiaj trochę linków do ciekawych prezentacji, sprint plannig - calendar, default export vs named export i helper od emotion. Zapraszam!

default vs named exports

Często podczas pracy w Egnyte dostawałem pytania w stylu: kiedy użyć export default a kiedy po prostu export const x = ... ? Odpowiedź na to pytanie nie jest moim zdaniem jednoznaczna. Artykuł Why we have banned default exports and you should do the same trochę rozjaśnił mi obraz sytuacji.

Jednym z argumentów za porzuceniem default jest to, że przy importowaniu możemy bezpośrednio zmienić nazwę komponentu. Co może obniżyć np. czytelność kodu. Może też zwiększyć czas na zastanowienie się czy ten komponent to na pewno ten, o którym myślimy.

// Icon.js
const Icon = () => <div />;
export default Icon;

// OtherFile.js
import Button from "components/Icon";

Gdy używamy nazwanych exportów, także możemy zmienić nazwę importowanej zmiennej. Różnica jest taka, że musimy to określić wprost:

import { Icon as Button } from "components/Icon"

Takie przemianowanie zmiennych od razu powinno zapalić pomarańczową lampkę na review ;)

Przy importowaniu default możemy też popełnić literówkę, która sprawi, że refactoring przy pomocy "znajdź i zamień" nie zadziała jak byśmy tego chcieli ;)

Używając nazwanych exportów ułatawiamy sobie również życie przy tree-shaking.

Sprint planning calendar

Ostatnio trochę zaniedbałem temat Agile i Scruma na blogu. Pracuję nad doszlifowaniem materiałów ;) i potrzebuję jeszcze chwili. Do tego czasu polecam Wam artykuł Jacka Wieczorka, o tym Jak stworzyć wizualny plan dostarczenia Sprintu?.

Sposób z "kalendarzykiem" był mi znany dość pobieżnie. W artykule znalazłem odpowiedzi na nurtujące mnie pytania. Dodatkowo polecam sekcję komentarzy ;) Tylko przed tym skoczcie do kuchni po 🍿 ;)

Emotion cx

Jeśli czytacie mojego Learning Loga regularnie, to pewnie zauważyliście, że dużo czasu poświęcam w nim na temat css-in-js. Głównie skupiam się na bibliotece emotion. Ostatnio "odkryłem" bardzo prosty i ciekawy za razem helper cx.

Przed tym moim "odkryciem", przy każdym nowym projekcie powstawała funkcja/helper, który odpowiedzialny był za sklejanie klas css. Głównie chodziło o to, żeby nie zaśmiecać funckji render niepotrzebną logiką łączenia klas.

function cls(...classes) {
  return classes.filter(Boolean).join(" ");
}

const Component = () => (
  <div className={ cls(ifSometing && "a", "b") }
)

Funkcja cx idzie o krok dalej i pozwala na przekazanie np. funkcji lub obiektu:

import { cx, css } from 'emotion'

const cls1 = css`
  font-size: 20px;
  background: green;
`
const cls2 = css`
  font-size: 20px;
  background: blue;
`

const cls3 = css`
  font-size: 20px;
  background: darkorange;
`

const cls4 = css`
  font-size: 20px;
  background: darkgreen;
  color: white;
`

const foo = true
const bar = false

render(<div
  className={cx(
    { [cls1]: foo },
    { [cls2]: bar },
    () => 'modal',
    'profile',
    [[cls3, [cls4]]]
  )}
>Some content</div>)

Dodatkowo zamiast połączenia klas wygenerownych z emotion dostaniemy jedną klasę z połączonymi stylami:

.css-i43k4 {
  font-size: 20px;
  background: green;
  font-size: 20px;
  background: darkorange;
  font-size: 20px;
  background: darkgreen;
  color: white;
}
<div class="modal profile css-i43k4">Some content</div>

Po więcej szczegółów odsyłam do oficjalnej dokumentacji emotion.

Optimizing prototypes

W #6 odcinku Learning Loga wspomniałem o bardzo ciekawej prezentacji JavaScript Engines: The good parts. Niedawno Benedikt Meurer poprowadził kolejną część.

Na początku dostajemy małe przypomnienie o typach silników i o tym jak realizowany jest dostęp do pól obiektu. Następnie Benedikt opowiada o prototypach i o tym dlaczego nie powinno się zmieniać ich referencji na późniejszym etapie wykonania naszej aplikacji. Bardzo ciekawy i trudny temat - przedstawiony w bardzo przystępny sposób. Polecam.

Simply React

Na koniec prezentacja, którą powinien obejrzeć każdy kto korzysta z Reacta :)

Kent przedstawia typowe podejście do "rozszerzania" komponentu poprzez dodawanie kolejnych propsów; przechodząc płynnie do wprowadzenia abstrakcji w formie kilku wzorców. Ważna jest też końcówka prezentacji, która mówi o tym, że jeśli nie przewidujemy rozszerzania danego komponentu - to być może, wprowadzanie abstrakcji przez skomplikowanie kodu negatywnie wpłynie na jego utrzymywanie. Wszędzie należy kierować się umiarem i zdrowym rozsądkiem.


To tyle :) Zapraszam za tydzień!