Сергей Горностаев, нет, я это понимаю, то там сервер - тут клиент. Я про то, что на сервере предположим что обновится контент, а у пользователя будет по-прежнему старая закэшированная версия страницы отображаться. Я про этот конфликт интересов разных кэшей.
Сергей Горностаев, Сергей, я правильно понимаю, что Вы предлагаете обернуть только нужные блоки в шаблоне, а другие как бы не будут закэшированы и тогда вьюха отдаст клиенту ответ от сервера?
_, Спасибо за идею с миксином, сразу не сообразил чет ))
Если проект потребует внедрения api + фронт, то тут все понятно. Я уже обсуждал темы схожие с Вашим предложением, но танцевать надо от задачи и соразмерности потраченных сил для достижения результата.
twoone, что значит дофига и никто оценок ставить не будет? Это наш личный проект для своей целевой аудитории. С джангой вроде мне все понятно. Непонятно именно что делать с react? Я готов и его подтянуть лишь бы понять в чем его сила для меня.
В силу отсутствия опыта работы с React, я пока не представляю как генерируются статические страницы, если контент в БД будет обновляться и добавляться? Кто отвечает за ререндеринг статики и в какой это момент происходит? Это больше относится даже к продакшн
Pavel Shvedov, тогда тут получится миксовый вариант. И мне админка и логика Django в любом случае будет нужна. Здесь совместить придется.
От сюда следует:
1. Тот же gatsby (к примеру ) стоит сюда внедрять для статики ?
2. rest api потребуется на бэкенде, ведь придется вытаскивать контент из БД и отдавать фронту для подставления в шаблоны?
twoone, но комментировать работы и ставить оценки это из области блога все же я думаю. И залить фото посетитель с правами тоже способен в блоге. Разе я не прав?
Да, участников может быть до сотни и у каждого работы (фото/описание) в разных категориях плюс комменты плюс это все за 15 лет и плюс каждый год будет контент участников добавляться. Выгодно ли облако в таком случае?
twoone, я не увидел чтобы можно было обращаться к mySQL.
Но мне логика нужна на сервере. Например, загрузка работ на сервер каждым зарегистрированным пользователем и тд. Выходит, что я должен выдавать на рендеринг или готовую html страницу или json, но парсить придется. Вообщем, я в затруднении: каким путем пойти для моих нужд
Pavel Shvedov, таки сам ищу аргументы за или против. Не первый раз слышу, что надо изучать Реакт даже для простых сайтов, вроде как время выкраивается и скорость написания сайтов.
Хотел было развернуть и начать использовать, но прочтение статей тормознуло.
Есть ощущение, что я замедлюсь, а не ускорюсь. )
Блог - это образно. Я буду писать сайт с портфолио участников выставок за 15 лет с возможностью оценивать работы и комментировать. Плюс поиск и фильтр по категориям и номинациям победителей.
Все это будет поддерживаться и расти. Как-то так.
twoone, да, стоящие батарейки, но для чистой статики. Я все таки намереваюсь хранить контент в БД и здесь не без серверной стороны. Логику для выдачи представлений я все же хочу сохранить в джанге
NextJS еще существует, если СУБД нужна
Roman Kitaev, я понял уже, что галп в топку и react с webpack рулит ))). Хорошо. Нода и так была. Установлю react.
Еще один вопрос тогда, если позволите: если со статикой все более менее ясно - она остается неизменной, то как поступить с шаблонами страниц в джанге? как увязать код реакта со структурой templates файлов html? Я же туда подставляю переменные context.
Roman Kitaev, да уж ... )) сколько разных инструментов придумано - бери не хочу. Ваш уровень вижу очень продвинутый стал. Если смотреть на react, то тогда придётся изучать параллельно с бэкэндом и новый язык во фронте. Полагаю, что для небольших проектов это излишество. Хотя могу и ошибаться. Иногда лучше сразу пойти более коротким путём и набить «шишек», чтобы потом не терять время, когда приспичит уже точно ))
