Возможно вы и правы, но как реализовать динамическую подгрузку preact-а, чтобы компонент не успел до этого поломаться из-за ReferenceError это еще нужно серьезно подумать
Внутри компонента может быть свой state, свое внутреннее локальное состояние, которое никуда не денется, пока экземпляр компонента не будет уничтожен.
Если же компонент будет переодически уничтожаться и создаваться заново, и нужно чтобы данные не пропадали, или какой-то другой сложный сценарий использования компонента — тогда придется вынести состояние еще куда-то, но сделать это можно.
Тогда 100 компонентов (вес их React-овского кода) + 20кб (preact + preact-compat) + десяток килобайт на код, который соберает налету обертки из PropTypes для любого компонента
На данный момент нативно Web Components очень мало где поддерживается
C полифилами ситуация лучше
Но полифилы отжирают ~120 кб.
И опять же — в Web Components — внутри все DOM-операции и отслеживание изменений состояния компонента нужно делать ручками, что не так удобно, как в React. Уровень абстракции другой
Писать на VanilaJS, вручную отслеживать изменение состояния компонента, самостоятельно управлять перерисовкой всего и вся внутри — дело непростое. Требуется гораздно больше кода и времени на его поддержку.
Представьте, например, что есть библиотека с чартами, которая работает по принципу, описанному в статье — так почему бы ее не использовать в проекте, если она хорошая. Какая разница программисту, что там внутри, если она работает и много килобайт не отжирает.
Про некрофилию это всё враки. Вы, например, пробовали пользоваться встроенным браузером такого телефона https://market.yandex.ru/product--nokia-lumia-730-dual-sim/11030304 ?
Почему то там половина современных сайтов рассыпается и модальные окна улетают неизвестно куда. А телефон то не старый. Думаете такого хлама мало?
Web Component-ы имеют не самую лучшую поддержку в браузерах https://www.polymer-project.org/1.0/docs/browsers. Через 2-5 лет, когда вымрут всякие старые девайсы с их чудо браузерами (привет Windows Mobile и встроенный браузер несвежего Android) — вот тогда с вами уже сложно будет поспорить
Сервер на nodejs целиком писать необязательно. Достаточно написать небольшую прослойку для рендеринга на nodejs. API, работа с БД и прочими штуками может быть реализована на каком угодно языке программирования
В некоторых языках программирования, например в Haxe, использование связки enum-switch считается рекомендованным подходом http://haxe.org/manual/types-enum-using.html И про это пишут в документации
Да — я читал про это. И от этого чтива у меня слезы на глазах наворачиваются — каждое с голубиное яйцо…
Вместо того, чтобы сделать API, которое можно, не напрягаясь, использовать всегда и везде — сделали еще одно неудобное API, вокруг которого будут и дальше писать десятки и сотни разных оберток. И в каждом проекте будет своя — не такая как в других…
А ведь им ничего не мешало сделать по-нормальному
Кстати — в React 15.3.0 добавили класс верхнего уровня React.PureComponent. Чтобы нормальные пацаны от него наследовались, а не от React.Component. Там render вызывается только, когда нужно
Возможно вы и правы, но как реализовать динамическую подгрузку preact-а, чтобы компонент не успел до этого поломаться из-за
ReferenceError
это еще нужно серьезно подуматьВнутри компонента может быть свой
state
, свое внутреннее локальное состояние, которое никуда не денется, пока экземпляр компонента не будет уничтожен.Если же компонент будет переодически уничтожаться и создаваться заново, и нужно чтобы данные не пропадали, или какой-то другой сложный сценарий использования компонента — тогда придется вынести состояние еще куда-то, но сделать это можно.
Про дублирование Preact-а на каждый компонент речи не идёт. Если 100 компонентов в сборке будет — то получится 100 компонентов + один Preact
Я думаю, что создание оберток можно автоматизировать. Например генерить их налету из propTypes
DonutChart.propTypes = {
radius: React.PropTypes.number.isRequired,
holeSize: React.PropTypes.number.isRequired, //0...1
text: React.PropTypes.string.isRequired,
value: React.PropTypes.number.isRequired,
total: React.PropTypes.number.isRequired,
backgroundColor: React.PropTypes.string.isRequired,
valueColor: React.PropTypes.string.isRequired
};
Тогда 100 компонентов (вес их React-овского кода) + 20кб (preact + preact-compat) + десяток килобайт на код, который соберает налету обертки из PropTypes для любого компонента
В статье я показал, как добиться оверхеда в 20кб.
На данный момент нативно Web Components очень мало где поддерживается

C полифилами ситуация лучше
Но полифилы отжирают ~120 кб.
И опять же — в Web Components — внутри все DOM-операции и отслеживание изменений состояния компонента нужно делать ручками, что не так удобно, как в React. Уровень абстракции другой
Писать на VanilaJS, вручную отслеживать изменение состояния компонента, самостоятельно управлять перерисовкой всего и вся внутри — дело непростое. Требуется гораздно больше кода и времени на его поддержку.
Представьте, например, что есть библиотека с чартами, которая работает по принципу, описанному в статье — так почему бы ее не использовать в проекте, если она хорошая. Какая разница программисту, что там внутри, если она работает и много килобайт не отжирает.
Спору с вами нет. Web Component-ы это хорошо. Но лучше чуть погодя, чем сейчас
Про некрофилию это всё враки. Вы, например, пробовали пользоваться встроенным браузером такого телефона https://market.yandex.ru/product--nokia-lumia-730-dual-sim/11030304 ?
Почему то там половина современных сайтов рассыпается и модальные окна улетают неизвестно куда. А телефон то не старый. Думаете такого хлама мало?
Web Component-ы имеют не самую лучшую поддержку в браузерах https://www.polymer-project.org/1.0/docs/browsers. Через 2-5 лет, когда вымрут всякие старые девайсы с их чудо браузерами (привет Windows Mobile и встроенный браузер несвежего Android) — вот тогда с вами уже сложно будет поспорить
В новой версии react-redux эта проблема и другие похожие решается более элегантно через
https://github.com/reactjs/react-redux/blob/next/docs/api.md#connectadvancedselectorfactory-connectoptions
Там можно более гибко конфигурировать props для вложенного компонента.
Пример кода:
Сервер на nodejs целиком писать необязательно. Достаточно написать небольшую прослойку для рендеринга на nodejs. API, работа с БД и прочими штуками может быть реализована на каком угодно языке программирования
В 2016 уже есть фреймворки, которые могут в нормальный SPA с серверным рендерингом. Например React (http://redux.js.org/docs/recipes/ServerRendering.html) и Angular 2 (https://github.com/angular/universal).
Сама попытка делать пререндеринг сайта через PhantomJS это пережиток прошлого и ошибка природы
В некоторых языках программирования, например в Haxe, использование связки enum-switch считается рекомендованным подходом http://haxe.org/manual/types-enum-using.html И про это пишут в документации
0.15.0 (Oct 10, 2016)
Adding cancellation support (https://github.com/mzabriskie/axios/pull/452)
Про
key
забыли.Будет предупреждение:
Да — я читал про это. И от этого чтива у меня слезы на глазах наворачиваются — каждое с голубиное яйцо…
Вместо того, чтобы сделать API, которое можно, не напрягаясь, использовать всегда и везде — сделали еще одно неудобное API, вокруг которого будут и дальше писать десятки и сотни разных оберток. И в каждом проекте будет своя — не такая как в других…
А ведь им ничего не мешало сделать по-нормальному
Имею неблагоприятный опыт работы с isomorphic-fetch и в целом с Fetch API.
Стандарт кривой и ничего толком не умеет, даже работать с query парамметрами [пруф. http://stackoverflow.com/questions/35038857/setting-query-string-using-es6-fetch-get-request/35039198#35039198 ]
А когда нужно писать изоморфный код, возникают еще и проблемы с
headers["Authorization"]
иbaseUrl
.Рекомендую axios. Там всё очень круто и удобно
Кстати — в React 15.3.0 добавили класс верхнего уровня React.PureComponent. Чтобы нормальные пацаны от него наследовались, а не от React.Component. Там render вызывается только, когда нужно
Есть ли возможность сразу загружать только один язык, а остальные подтягивать по мере необходимости?