{"id":11405,"date":"2022-10-20T12:37:20","date_gmt":"2022-10-20T10:37:20","guid":{"rendered":"https:\/\/vived.io\/?p=11405"},"modified":"2022-10-20T12:37:22","modified_gmt":"2022-10-20T10:37:22","slug":"pobieranie-danych-w-react-juz-nigdy-nie-bedzie-takie-samo-frontend-weekly-vol-109","status":"publish","type":"post","link":"https:\/\/vived.io\/pl\/pobieranie-danych-w-react-juz-nigdy-nie-bedzie-takie-samo-frontend-weekly-vol-109\/","title":{"rendered":"Pobieranie danych w React ju\u017c nigdy nie b\u0119dzie takie samo – Frontend Weekly vol. 109"},"content":{"rendered":"\n

1. React z natywnym wsparciem dla Promise<\/h2>\n\n\n\n

Kolejne RFC (Request For Comments) zwyczajowo ju\u017c wzbudzaj\u0105 du\u017ce zainteresowanie w sieci. Nie inaczej by\u0142o i tym razem, bo nowo opublikowane RFC wprowadza do biblioteki natywne wsparcie dla Promis\u00f3w. Dla jednych zaproponowane rozwi\u0105zanie jest przekompilowane i niepotrzebne. Inni natomiast gloryfikuj\u0105 RFC do poziomu \u201costatniej brakuj\u0105cej funkcjonalno\u015bci Reacta\u201d. Jak to zwykle bywa prawda jest gdzie\u015b po\u015brodku, a my dzisiaj bli\u017cej przyjrzymy si\u0119 zaproponowanym nowo\u015bciom.<\/p>\n\n\n\n

Komponenty renderowane po stronie klienta<\/h3>\n\n\n\n

Widz\u0105c tytu\u0142 nowego RFC mo\u017cecie si\u0119 zastanawia\u0107 o co tak naprawd\u0119 chodzi. W ko\u0144cu React jest w pe\u0142ni kompatybilny z Promisami i zapewne wi\u0119kszo\u015b\u0107 z Was mia\u0142a przyjemno\u015b\u0107 napisa\u0107 kod podobny do tego:<\/p>\n\n\n\n

async function fetchNote(id) {\n  const data = await fetchNoteFromBackend(id);\n  return data.json();\n}\n\nfunction Note({id}) {\n  const [note, setNote] = useState(null);\n  \n  useEffect(() => {\n    fetchNote(id).then(it => setNote(it))\n  }, [id])\n\n  if(note === null) {\n    return <h1> Loading... <\/h1>\n  } \n\n  return (     \n    <div>\n      <h1>{note.title}<\/h1>\n      <section>{note.body}<\/section>\n    <\/div>\n    );\n}<\/code><\/pre>\n\n\n
\n
\"\"<\/figure><\/div>\n\n\n
Biblioteki takie jak React Query dostarczaj\u0105 odrobin\u0119 przyjemniejsze API, ale wci\u0105\u017c manualnie obs\u0142u\u017cy\u0107 musimy poszczeg\u00f3lne mo\u017cliwe stany Promsie<\/p>\n\n\n\n
async function fetchNote(id) {\n  const data = await fetchNoteFromBackend(id);\n  return data.json();\n}\n\nfunction Note({id}) {\n     const query = useQuery(`note-{id}`, fetchNote)\n    \n     if(query.isLoading) {\n       return (<h1> Loading... <\/h1>);\n     }\n\n    return (\n      <div>\n        <h1>{query.data..title}<\/h1>\n        <section>{query.data.body}<\/section>\n      <\/div>\n    );\n}<\/code><\/pre>\n\n\n\n
Rozwi\u0105zanie, kt\u00f3re proponuje zesp\u00f3\u0142 stoj\u0105cy za Reactem, to wprowadzenie nowego hooka o nazwie `use`. Przy jego pomocy mo\u017cliwe jest odczytanie warto\u015bci fulfilled Promise, a obs\u0142uga b\u0142\u0119d\u00f3w i \u0142adowania oddelegowana zostanie do najbli\u017cszego Suspense. Taka architektura pozwala grupowa\u0107 komponenty w konteksty, kt\u00f3re s\u0105 gotowe do wyrenderowania dopiero kiedy wszystkie komponenty za\u0142aduj\u0105 dane.<\/p>\n\n\n\n
async function fetchNote(id) {\n  const data = await fetchNoteFromBackend(id, { useCache: true});\n  return data.json();\n}\n\nfunction Note({id}) {\n  const note = use(fetchNote(id));\n  return (\n    <div>\n      <h1>{note.title}<\/h1>\n      <section>{note.body}<\/section>\n    <\/div>\n  );\n}\n\nfunction App() {\n  return (\n    {\/* Loading will be displayed until all Notes fetch necessary data *\/}\n    <Suspense fallback={<h1>Loading\u2026<\/h1>}>\n      <Note id=\u201d1\u201d \/>\n      <Note id=\u201d2\u201d \/>\n      <Note id=\u201d3\u201d \/>\n    <\/Suspense>\n  );\n}<\/code><\/pre>\n\n\n
\n
\"\"<\/figure><\/div>\n\n\n
Warto zauwa\u017cy\u0107, \u017ce je\u015bli referencja do Promise zmieni si\u0119 mi\u0119dzy renderami, to ponownie wy\u015bwietlony zostanie fallback z komponentu Suspense. Jedynym wyj\u0105tkiem od tej regu\u0142y, jest przekazanie do `use` fulfilled Promise. W takiej sytuacji React od razu wy\u015bwietli wyrenderowany komponent. To oznacza, \u017ce aby unikn\u0105\u0107 niechcianego \u201cmrugania\u201d, niezb\u0119dne jest dodanie obs\u0142ugi cache. Mo\u017cemy w tej kwestii albo polega\u0107 na zewn\u0119trznych bibliotekach, albo po prostu  skorzysta\u0107 `useMemo`. Na szcz\u0119\u015bcie zesp\u00f3\u0142 stoj\u0105cy za RFC obiecuj\u0119, \u017ce nied\u0142ugo zaprezentuje r\u00f3wnie\u017c API dedykowane temu \u0142atwiejszej obs\u0142ugi cache.<\/p>\n\n\n\n
async function fetchNote(id) {\n  const data = await fetchNoteFromBackend(id);\n  return data.json();\n}\n\nfunction Note({id}) {\n  const promise = useMemo(() => fetchNote(id), [id]);\n  const note = use(promise);\n  return (\n    <div>\n      <h1>{note.title}<\/h1>\n      <section>{note.body}<\/section>\n    <\/div>\n  );\n}<\/code><\/pre>\n\n\n\n
Je\u015bli my\u015blicie, \u017ce zrobi\u0142o si\u0119 skomplikowanie, to dopiero si\u0119 rozkr\u0119camy. `use` b\u0119dzie pierwszym i jedynym hookiem, kt\u00f3ry mo\u017ce by\u0107 u\u017cywany wewn\u0105trz instrukcji if czy p\u0119tli for. <\/p>\n\n\n\n
function Note({id, shouldIncludeAuthor}) {\n  const note = use(fetchNote(id));\n\n  let byLine = null;\n  if (shouldIncludeAuthor) {\n    const author = use(fetchNoteAuthor(note.authorId));\n    byLine = <h2>{author.displayName}<\/h2>;\n  }\n\n  return (\n    <div>\n      <h1>{note.title}<\/h1>\n      {byLine}\n      <section>{note.body}<\/section>\n    <\/div>\n  );\n}<\/code><\/pre>\n\n\n\n
W przysz\u0142o\u015bci planowane jest r\u00f3wnie\u017c dodanie interfejsu Usable, kt\u00f3ry pozwoli wpakowa\u0107 do hooka co nam si\u0119 \u017cywnie podoba. Autorzy RFC jako przyk\u0142ad podaj\u0105 kontekst. Je\u015bli ich plany wejd\u0105 w \u017cycie, to w API znajdziemy zar\u00f3wno use(Context) jak i useContext(Context). Tego pierwszego b\u0119dzie mo\u017cna u\u017cywa\u0107 wewn\u0105trz instrukcji warunkowych, ale tego drugiego ju\u017c nie. <\/p>\n\n\n\n
\/\/ \u2705 This will work fine\nfunction Author({display}) {\n  if (display) {\n    const authors = use(AuthorsContext);\n    return <h2>{authors[note.authorId]}<\/h2>;\n  } else {\n    return null\n  }\n\n\/\/ \ud83d\uded1 This will not work\nfunction Author({display}) {\n  if (display) {\n    const authors = useContext(AuthorsContext);\n    return <h2>{authors[note.authorId]}<\/h2>;\n  } else {\n    return null\n  }\n}<\/code><\/pre>\n\n\n
\n
\"\"<\/figure><\/div>\n\n\n
Komponenty renderowane po stronie serwera<\/h3>\n\n\n\n
Druga zaprezentowana w RFC nowo\u015b\u0107 dotyczy React Server Component. Z racji tego, \u017ce p\u00f3ki co s\u0105 one eksperymentaln\u0105 cz\u0119\u015bci\u0105 biblioteki zatrzymajmy si\u0119 na chwil\u0119, \u017ceby przypomnie\u0107 sobie czym w\u0142a\u015bciwie s\u0105. <\/p>\n\n\n\n
Koncepcja ta po raz pierwszy zaprezentowana zosta\u0142a pod koniec 2020 roku. Server Components umo\u017cliwiaj\u0105 wyrenderowanie cz\u0119\u015bci drzewa komponent\u00f3w po stronie klienta i cz\u0119\u015b\u0107 po stronie serwera. Komponenty wyrenderowane po stronie serwera przesy\u0142ane s\u0105 jako strumie\u0144 HTML, co pozwala odchudzi\u0107 paczk\u0119 wys\u0142an\u0105 do klienta. Taka architektura pozwala te\u017c dobra\u0107 si\u0119 do typowo serwerowych funkcji (na przyk\u0142ad do bazy danych, czy systemu plik\u00f3w) bezpo\u015brednio z poziomu kodu komponentu.<\/p>\n\n\n\n
import fs from 'react-fs';\nimport db from 'db.server';\n\nfunction FileNote({id}) {\n  const note = JSON.parse(fs.readFile(`${id}.json`));\n  return <NoteWithMarkdown note={note} \/>;\n}\n\nfunction DatabaseNote({id}) {\n  const note = db.notes.get(id);\n  return <NoteWithMarkdown note={note} \/>;\n}<\/code><\/pre>\n\n\n
\n
\"\"<\/figure><\/div>\n\n\n
Je\u015bli szukacie materia\u0142\u00f3w, kt\u00f3re pozwol\u0105 Wam lepiej zrozumie\u0107 koncepcj\u0119 Server Components, to nieustannie rekomenduj\u0119 oryginaln\u0105 prezentacj\u0119 z 2020 roku<\/a>. Wszystkich bardziej zdeterminowanych odsy\u0142am natomiast do d\u0142ugiego i obszernego RFC<\/a>.<\/p>\n\n\n\n
Sporym brakiem Server Components by\u0142a do tej pory przyjazna obs\u0142uga asynchronicznych akcji, tak typowych dla serwerowych operacji. Nowo zaprezentowane RFC adresuje ten problem umo\u017cliwiaj\u0105c korzystanie z natywnej sk\u0142adni async\/await. Jedynym zastrze\u017ceniem jest fakt, \u017ce komponenty u\u017cywaj\u0105ce async\/await nie mog\u0105 wykorzystywa\u0107 hook\u00f3w.<\/p>\n\n\n\n
async function Note({id, isEditing}) {\n  const note = await db.posts.get(id);\n  return (\n    <div>\n      <h1>{note.title}<\/h1>\n      <section>{note.body}<\/section>\n    <\/div>\n  );\n}<\/code><\/pre>\n\n\n\n
\n\n\n\n
Niezale\u017cnie od tego, czy zaproponowane zmiany przypad\u0142y Wam do gustu, czy nie pami\u0119tajmy, \u017ce nie nale\u017cy popada\u0107 w skrajne emocje. Zanim RFC zostanie wdro\u017cone najprawdopodobniej up\u0142ynie sporo czasu i raczej mo\u017cemy spodziewa\u0107 si\u0119 kilku zmian w specyfikacji. Odrzuca\u0107 nie mo\u017cemy r\u00f3wnie\u017c scenariusza, w kt\u00f3rym `use` podzieli los `useEvent` i pomimo pocz\u0105tkowego optymizmu nigdy nie ujrzy \u015bwiat\u0142a dziennego w opisanej tu dzisiaj postaci.<\/p>\n\n\n\n
\u0179r\u00f3d\u0142a<\/h3>\n\n\n\n
https:\/\/github.com\/reactjs\/rfcs\/pull\/229<\/a>
https:\/\/github.com\/acdlite\/rfcs\/blob\/first-class-promises\/text\/0000-first-class-support-for-promises.md<\/a>
https:\/\/www.youtube.com\/watch?v=ytXM05PVcFU<\/a><\/p>\n\n\n\n
2. Lerna wstaje z martwych<\/h2>\n\n\n\n
Lerna to rozwi\u0105zanie do zarz\u0105dzania monorepo, kt\u00f3re przez by\u0142o monopolist\u0105 w kategorii JavaScript. Na przestrzeni kilku ostatnich lat projekt napotka\u0142 jednak spore turbulencje. W po\u0142owie 2020 roku w repozytorium lerny pojawi\u0142o si\u0119 Issue m\u00f3wi\u0105ce, \u017ce narz\u0119dzie nie jest ju\u017c aktywnie wspierane. Patrz\u0105c na histori\u0119 commit\u00f3w ci\u0119\u017cko nie zgodzi\u0107 \u2013 wi\u0119kszo\u015b\u0107 zmian dotyczy aktualizacji zale\u017cno\u015bci oraz napraw krytycznych podatno\u015bci. W efekcie d\u0142ugich dyskusji do readme trafi\u0142 zapis informuj\u0105cy o ko\u0144cu wsparcia dla projektu. <\/p>\n\n\n
\n
\"\"<\/figure><\/div>\n\n\n
Przez ostatnie dwa lata na miejscu Lerny wyrasta\u0107 zacz\u0119\u0142y nowe alternatywy. Zar\u00f3wno yarn jak i npm przygotowa\u0142y natywne wsparcie dla monorepo w postaci workspaces. Nie zabrak\u0142o te\u017c narz\u0119dzi oferuj\u0105cych obs\u0142ug\u0119 bardziej zaawansowanych funkcjonalno\u015bci w postaci Nx i TurboRepo. Ten pierwszy zreszt\u0105 w kwietniu tego roku wyprzedzi\u0142 Lern\u0119 pod wzgl\u0119dem pobra\u0144 z npm. Chwil\u0119 po tym fakcie zdarzy\u0142o si\u0119 co\u015b zupe\u0142nie niespodziewanego – firma stoj\u0105ca za rozwojem Nx og\u0142osi\u0142a, \u017ce zamierza zaj\u0105\u0107 si\u0119 r\u00f3wnie\u017c rozwojem Lerny. <\/p>\n\n\n
\n
\"\"<\/figure><\/div>\n\n\n
Od czasu og\u0142oszenia przej\u0119cia projektu w nasze r\u0119ce trafi\u0142y ju\u017c dwie du\u017ce wersje narz\u0119dzia. Pierwsza, jeszcze w maju tego roku, podbi\u0142a kluczowe dependencje i usuwa\u0142a fa\u0142szywe ostrze\u017cenia rzucane w konsoli. Druga opublikowana w zesz\u0142ym tygodniu jest pierwsz\u0105 wersj\u0105 od ponad dw\u00f3ch lat, kt\u00f3ra wprowadza nowe funkcjonalno\u015bci. W\u015br\u00f3d nich znajdziemy<\/p>\n\n\n\n