мне кажется это не холивар а моя борьба со сложностью. — мало того что со стороны не понятно зачем это. Так ещё и документация вся на английском.

> быть разработчиком > негодовать по поводу английского

пишешь код, как и писал раньше, а в итоге под капотом jss, вот и все отличие

знаешь как я писал раньше ?

А там как угодно можно ?

если ты используешь css-modules, то все кейсы покрыты

может он в школе немецкий учил xd)

а какая разница? не зная английского порог входа растет экспоненциально почти во все

особенно учитывая что либы ломают бэксовместимость в npm чаще, чем переводы делать успевают даже теоретически)

может он в школе немецкий учил xd)

так и есть.

знаешь как я писал раньше ?

я это изначально и делал именно из-за того, что мне нравится писать стили в css-modules way

и еще дофига всяких утилит клевых в редакторе

ты все еще не объяснил что вы подразумеваете под этим

Загрузка только необходимого цсс

вот за все время работы ни разу словосочетания такого не встречал

Ты не читал проф статьи последние несколько лет

https://www.smashingmagazine.com/2015/08/understanding-critical-css/ кажется нагуглил. Спс за цитату.. ща бум смареть

Это была не цитата, я сам написал

Ты не читал проф статьи последние несколько лет

про цсс ен читал, это правда. мы например рубим вебпаком и грузим что надо

Критикал цсс лучше с цсс ни жс потому-что можно лези доадить

чтото не могу вкурить. критикалцсс как относится к сццинжс ?

чтото не могу вкурить. критикалцсс как относится к сццинжс ?

Jss из коробки умеет

то есть я могу указать какие имена классов мне нужны при серверном рендеринге на странице и оно сделает как я хочу ?

то есть я могу указать какие имена классов мне нужны при серверном рендеринге на странице и оно сделает как я хочу ?

Указывать не надо

Само работает именно так

оно все стили наа страницу положит ?

Да

оверхедненько.. А есть из коробки чтобы не все а только определённые ?

оверхедненько.. А есть из коробки чтобы не все а только определённые ?

Не оверхедно. Вместо загрузки огромного бандла всех стилей, из которых используются только 30-40% ты грузишь только то что нужно И быстрее страницу увидишь

то есть грузятся только стили пресутствующие на текущей странице ?

На проекте с большим количеством компонентов и стилей очень разницу видно

то есть грузятся только стили пресутствующие на текущей странице ?

Да

а. тогда норм.

только это обычные цсс модули умеют не ?

без екстракт-текст-плагина когда

только это обычные цсс модули умеют не ?

Как их в проде будешь юзать?

не думал об этом.

Как их в проде будешь юзать?

как как, девсервер деплоить

))

оверхедненько.. А есть из коробки чтобы не все а только определённые ?

Ты бы попробовал уже

Ты бы попробовал уже

я не совсем понимал зачем(да и сейчас). теперь думаю попробовать (когда дело до оптимизаций дойдёт)

Смотр ридми в PreJSS :) там целый раздел этому

С кешированием на клиенте вопрос уже решили? Или все еще рендерите JSS на каждый запрос?

С кешированием на клиенте вопрос уже решили? Или все еще рендерите JSS на каждый запрос?

Ты о чем?

Я про SSR

я уже плаваю в этих абривиатурах

Я про SSR

Ssr есть

Его не может не быть(c)

Я про то что оптимизация отдачи критического css в ssr путем постоянного рендера jss на каждый запрос просто напрочь убивается отсутствием возможности кещирования css на клиенте. И если сайт это не туду лист, а что-то большое, с тысячами компонент и юзеры постоянно заходят, уходят, рефрешат, открывают кучу вкладок, то JSS при наличии SSR это большая регрессия по перфомансу

Я про то что оптимизация отдачи критического css в ssr путем постоянного рендера jss на каждый запрос просто напрочь убивается отсутствием возможности кещирования css на клиенте. И если сайт это не туду лист, а что-то большое, с тысячами компонент и юзеры постоянно заходят, уходят, рефрешат, открывают кучу вкладок, то JSS при наличии SSR это большая регрессия по перфомансу

Вроде как был отдельный пакет с кешами для jss, или там было только для пользователя

Я про то что оптимизация отдачи критического css в ssr путем постоянного рендера jss на каждый запрос просто напрочь убивается отсутствием возможности кещирования css на клиенте. И если сайт это не туду лист, а что-то большое, с тысячами компонент и юзеры постоянно заходят, уходят, рефрешат, открывают кучу вкладок, то JSS при наличии SSR это большая регрессия по перфомансу

Жс бандл с жсс у тебя точно также кешируется как цсс бандл

Я не про бандл а про респонс сервера в случае ssr

В котором у тебя готовая разметка сгенеренная реактом и заполненый тэг style сгенеренный jss.

Генерить css каждый раз без возможности это закешировать на стороне клиента - провал. CSS-modules с успехом бьются на чанки, кажды из которых будет весить не многим более сгенеренного jss на страницы, при этом этот чанк будет нормально закеширован браузером как и все остальные ресурсы и никогда запрашивать больше не будет. Поэтому пока JSS в случае SSR не просто не имеет смысла, но просто вреден. Пока не придумают как это можно улучшить

Генерить css каждый раз без возможности это закешировать на стороне клиента - провал. CSS-modules с успехом бьются на чанки, кажды из которых будет весить не многим более сгенеренного jss на страницы, при этом этот чанк будет нормально закеширован браузером как и все остальные ресурсы и никогда запрашивать больше не будет. Поэтому пока JSS в случае SSR не просто не имеет смысла, но просто вреден. Пока не придумают как это можно улучшить

Хочешь помочь?

Нет

У тебя очень валидный кейс

Окай

; )

Генерить css каждый раз без возможности это закешировать на стороне клиента - провал. CSS-modules с успехом бьются на чанки, кажды из которых будет весить не многим более сгенеренного jss на страницы, при этом этот чанк будет нормально закеширован браузером как и все остальные ресурсы и никогда запрашивать больше не будет. Поэтому пока JSS в случае SSR не просто не имеет смысла, но просто вреден. Пока не придумают как это можно улучшить

В смысле ты хочешь закешировать criticsl css?

Нет, critical css невозможно закешировать, поэтому его ценность стремится к нулю по сравнению с нормально кешируемом статическим css

ребята помогите пожалуйста обработать 404 страницу при обращении к несуществующему post/999999 https://gist.github.com/sanyco86/17e45f4224711a1b114db70d8aec9ee0

что то не могу сообразить, как сделать

Нет, critical css невозможно закешировать, поэтому его ценность стремится к нулю по сравнению с нормально кешируемом статическим css

ну вроде SSR нам в основном нужен в следующих случаях: - индексация поисковиками (главный кейс) - отсутствие необходимости рендерить на клиенте первоначальное состояние (для скорости отображения и nojs, оба варианта целом уже более сомнительные) для первого наличие стилей не играет вообще никакой роли. для второго как раз важно иметь критикал цсс, чтобы избежать взрывов ну и кажется, что компромисс - отсутствие рендера цсс на сервере и дорендер стилей и связывание с компонентами на клиенте до их отображения. непосредственно дорендер стилей и связывание можно выносить в отдельные чанки при сборке

этого вроде как нет, но готов помочь)

Если наличие стилей для поисковика не играет роли, то достаточно иметь правильный sitemap и забить на ssr. А обычно, если хочешь более высокий ранг и чтобы была возможность просмотра кешированной версии сайта - нужен ssr со стилями

Если наличие стилей для поисковика не играет роли, то достаточно иметь правильный sitemap и забить на ssr. А обычно, если хочешь более высокий ранг и чтобы была возможность просмотра кешированной версии сайта - нужен ssr со стилями

а как правильный сайтмап поможет проиндексировать непосредственно контент?

Поисковики давно умеют исполнять клиентский js

ERROR: S client not available

Поисковики давно умеют исполнять клиентский js

ну это такое, если про гугл более-менее понятно, то про яндекс не особо

а кэш версии спокойно грузят и инициализируют скрипты

Поисковики давно умеют исполнять клиентский js

Только Гугл

Если наличие стилей для поисковика не играет роли, то достаточно иметь правильный sitemap и забить на ssr. А обычно, если хочешь более высокий ранг и чтобы была возможность просмотра кешированной версии сайта - нужен ssr со стилями

про ранк - опять же не знаю стили в качестве метрики у яндекса. у гугла да, особенно адаптивность, но только он как раз сумеет все увидеть так, как надо

Поисковики давно умеют исполнять клиентский js

Это фразу говорят уже 4 года и все равно нифига нормально никто не исполняет, только местами. Даже гугл

Это фразу говорят уже 4 года и все равно нифига нормально никто не исполняет, только местами. Даже гугл

Для гугла важно рендерить все за один раз

Да, вот из-за того что есть куча фрэймворков со своим типом рендеринга плюс каждый проект использует свой способ асинхронного фетчинга данных, движки скорее всего никогда не смогут сказать - "мы индексируем то что рендерит js" Просто потому что есть куча комбинаций как кто в какой момент отрисовывает, поисковик не может это все предусмотреть. Только если заведут спеку на событие, еоторое будет дергать ваш фрэймворк чтобы говорить поисковикам - "готово!"

Причем это было очевидно еще когда начинали, и за несколько лет гугл это событие так и не ввел

А с файбером жизнь у поисковиков которые хоть что-то могли проиндексировать еше сильнее усложнится без такого события

Ну рендерит сразу

Не проблема в общем-то тот контент который нужен для поисковика

Ребят, помогите разобраться пожалуйста, никак не выходит настроить Webpack HMR делаю по документации: https://webpack.js.org/guides/hmr-react/ нифига не понимаю почему не хочет отрабатывать... Интересует следующее: ----------------------------------------- contentBase: resolve(__dirname, 'dist') publicPath: '/' ----------------------------------------- context: resolve(__dirname, 'src') path: resolve(__dirname, 'dist') publicPath: '/' ----------------------------------------- Что означают эти вещи в конфиге и какие значения они должны содержать Вывожу console.log с resolve(__dirname, 'dist') выводит d:\dist Но в url правильные значения попадают В связи с этим в корень запутался и пробую в слепую

вот такая структура файлов: https://www.screencast.com/t/17RlbJTOyT

вот dev.conofig: https://gist.github.com/ArtemMaximum/cbdde019aaf0c94b4955fed22af4f34a вот webpack.dev.server: https://gist.github.com/ArtemMaximum/f7eaed82d68ce6663e83d09cd255afa9 global.appRoot содержит такое вот значение: d:\vagrant-projects\architecture\front-end-arch\core\client\build\

в Webpack чатике почти все заснули, может здесь кто отзавется

Тут похоже тоже

https://webpack.js.org/configuration/output/#output-publicpath

а contentBase по идее папка с файлами на диске (для дев сервера). Я не копал, но думаю он вотчит их изменения и мидлвары со статикой настраивает

А никто не знает куда react-router, катится? Чет с каждой интерацией он все упрощается и упрощается. Слишком упрощается.....

я на третьей версии остановился )

А никто не знает куда react-router, катится? Чет с каждой интерацией он все упрощается и упрощается. Слишком упрощается.....

В ад, с самого начала

Раньше хоть некоторые вещи можно было сделать. А теперь все deprecated и попытка улететь не получается

главное побыстрее переписать)

Он бы хоть API фиксировал. Говнокодер :(

Плох тем что глючный тач бэкенд

Эх, я про react-dnd, забыл чат проскроллить ...

В общем interact.js пока радует. Навесил на элемент реакт-компонента в componentDidMount и вперёд. Немножко с разделением ролей компонент (dragsource и dropzone ) все равно придётся повозиться

А и да, конкретно у interact.js нет функции "таскать клон" из коробки - на гитхабе в issues расписано как вручную переназначить операцию перетаскивания на клона.

Пробовал до этого dragula, он хоть и выглядит проще, но не получилось вообще разобраться.