Myślałem, aby dzielić komponenty na osobne pliki dla backendu i front-endu, ale pomyślałem trochę i mam pomysł, jak możemy tego uniknąć.
W trakcie prac nad kopmonentami sealpage’owymi napotkaliśmy kilka razy problem z mieszaniem kontekstów node’a i przeglądarki.
propControls
Pierwszym razem było używanie odniesień do propsControls poprzez referencję. propsControls były pisane w jsx, więc node ich nie ogarniał. Nie chcieliśmy robić transpilacji kodu po stronie backendu, dlatego zdecydowaliśmy się używać stringów z nazwą propControlsów zamiast referencji.
node’owe require’y
Za drugim razem na te problemy natrafiliśmy niezależnie z @arkadiusz.wieczorek i @micsta. Tworzyliśmy komponenty, które wymagały require’ów node’owych - np. coś do konwersji obrazków, itp. Rozwiązaniem, na które wtedy wpadłem było podzielenie komponentów na osobne pliki - jeden dla backendu, drugi dla front-endu. Wtedy front-end require’owałby tylko rzeczy potrzebne dla frontu, a backend tylko te dla backendu.
Obawiam się jednak, że taki podział na pliki spowodowałby zbyt duże zamieszanie. Dlatego proponuję, abyśmy do dodanego w trakcie prac nad T1524 obiektu s dodać funkcję backend_require, którą wywołalibyśmy wewnątrz funkcji render. Ta funkcja sprawdzałaby po prostu, czy jesteśmy w node czy nie i odpowiednio albo zwracała wynik require na zadany string albo rzucała error.
Dzięki temu, że ta funkcja będzie się nazywała inaczej niż po prostu require uda nam się zapobiec wrzucaniu tej depki do bundla na front przez Webpacka.
Ten wątek dotyczy problemów napotkanych w T1524 i T1500
