Поговорим об инструментах для создания клиентских веб-приложений с использованием традиционных языков программирования
Сразу оговоримся, что в этой публикации мы не будем затрагивать вопросы подходов к созданию полномасштабных приложений для Web, подразумевающих наличие крупной кодовой базы, заставляющей функционировать её серверную часть. Как-то исторически сложилось так, что клиентская часть подобных приложений, как правило, реализуется на JavaScript и производных от него языках и фреймворках, а серверная – уж на чём придётся. В конце концов, не столь уж это и важно – главное, чтобы соответствующая программная среда была поднята на сервере и реализованный в ней код спокойно выполнял свою задачу.
Вместе с тем со временем всё чаще стала возникать потребность в написании монолитных – как правило, простых и непритязательных веб-приложений, не требующих для работы серверной части. Естественно, с широким распространением HTML5 подобные приложения начали обретать весьма богатый функционал, однако. Однако же не все разработчики были готовы смириться с существующим положением вещей, когда все доступные им решения, по сути, имели своим краеугольным камнем всё тот же пресловутый JavaScript.
В конце концов, многие, что называется, “с младых ногтей” привыкли к другому подходу к проектированию и созданию приложений широкого профиля. Это, в первую очередь, различные RAD-среды, среди которых в нашей стране наибольшей популярностью (по крайней мере, в академической среде), всегда пользовалась Delphi. Натянул пару кнопок на форму, прописал нужные обработчики событий на привычном языке Pascal – красота. Чего ещё можно желать, в особенности если вы сосредоточены на реализации каких-то нужных вам алгоритмов, а интерфейс для вас не играет такой уж принципиальной роли?
При традиционном дизайне и проектировании веб-приложений всё совсем не так. Тут тебе бы неплохо помнить и все основные детали описаний различных тэгов HTML-разметки и атрибутов CSS-стили, и уметь сверстать всё это дело воедино, да ещё и “оживить” интерактивными сценариями, реализованными на JavaScript. Очевидно, что такой подход, ориентированный в первую очередь на дизайн, а не на саму разработку как таковую, вряд ли устроит нашего традиционного разработчика, воспитанного на классических алгоритмах и структурах данных, с возможным вкраплением зачатков объектно-ориентированного подхода. (Напоминаем, что речь идёт в первую очередь о разработчиках небольших приложений, где теоретически мог бы управиться и один человек.)
Так что и мы не будем подробнее их затрагивать. Каждой технологии – своё время, что называется. Сейчас нас интересуют не столько окончательно отжившие своё разработки, сколько те более современные инструменты, которые пришли им на смену.
Надо сказать, что тенденции придать веб-разработке некоторые черты RAD-технологии (Rapidapplicationdevelopment, т.е. дословно “быстрой разработки приложений” – именно так принято именовать подход к разработке приложений, реализованный, в частности, в BorlandDelphi) существуют уже достаточно давно. Здесь нельзя не упомянуть хотя бы о DHTML (или Dynamic HTML) – подходе, так же позволяющем придавать некоторую интерактивность самим приложениям и, в частности, используемым в них элементам пользовательских веб-форм, – интерактивность, похожую на то, что мы можем видеть в Delphi, VisualBasic и прочих RAD-средах проектирования традиционных приложений.
DHTML-приложения подразумевали полноценную автономную браузерную реализацию, без какой-либо поддержки со стороны сервера – именно то, что сейчас известно как Richwebapplication (ранее –RichInternetapplications, RIA) и тесно соприкасающиеся с ними SPA (Single-page applications– одностраничные веб-приложения). Однако сама по себе технология DHTML так и не оправдала возложенных на неё надежд, и была вытеснена всё теми же альтернативными подходами, требующими установки автономных плагинов, – такими, как AdobeFlash или JavaServlet (позднее – JavaFX). В то же время она в числе прочих компонентов составила прочную основу, на которой базируется такой широко известный в веб-разработке подход, как AJAX (где уже широко задействуется и серверная часть).
Правда, такие приложения уместнее сравнивать скорее с создаваемыми посредством майкрософтовской технологии ASP.NET
Вспомним заодно уж и о Xojo – кросс-платформенной объектно-ориентированной среде программирования, основанной на языке REALbasic (своеобразном аналоге VisualBasic– почти как Lazarus по отношению к BorlandDelphi; правда, на сей раз речь идёт о коммерческом продукте). Она тоже в настоящий момент позволяет создавать код не только для Windows, macOS или Linux, но и напрямую для веба – используя для этого всё те же принципы проектирования RAD. Правда, такие приложения уместнее сравнивать скорее с создаваемыми посредством майкрософтовской технологии ASP.NET – в последних, конечно же, тоже широко используются принципы проектирования RAD, но тем не менее требуют для своего развёртывания веб-сервер.
Пусть другие теперь строят прогнозы, мы же лишь попытались дать краткий сравнительный обзор технологий для построения приложений, работающих прямо в браузере пользователя (что называется, “из коробки”) – как имеющих на данный момент скорее историческое значение, так и пока ещё актуальных.
Что выбрать для разработки веб-приложений?
Доброго времени суток.
Контекст:.
Всю жизнь занимался разработкой прикладного программного обеспечения, компьютерных игр, чего-то системного, алгоритмического. Финансовые проблемы заставили моих работодателей убрать меня из моей локальной зоны комфорта (большого крутого ПО) в сторону программирования веб-приложений. По необъяснимым для себя причинам, покинуть своих любимых работодателей я не могу.
Почему спрашиваю:
Мог бы и сам все попробовать, но чтобы хорошо вникнуть в какой-то стэк технологий, нужно не меньше месяца, а технологий таких кучи. Как я могу узнать что мне подойдет лучше, если я всего не попробую… Уповаю на ваш опыт и рекомендации.
Мой опыт:
У меня хорошо с математикой, алгоритмами, проектированием. Много работал с Pascal, C, C++, C#, Delphi, JavaScript. Меньше с Python, PHP, Java, prolog. Суммарно 10 лет.
Хорошо знаком с PHP CodeIgniter, делал на нем небольшое множество серьезных проектов, но не нравится мне особо сам php и конкретно этот фреймворк.
Что ищу:
Нужен язык / язык + фреймворк для разработки сайтов, веб-приложений.
Критерии выбора (в порядке важности):
0. Ориентация на stateless.
1. Качество.
2. Перспективность. Надеюсь что выбранный стэк технологий не умрет, пока я его учу.
3. Популярность. Важно, чтобы на эту тему было много вакансий (с убер большой З. П. разумеется).
4. Развитость. Не хочется ковыряться в багах инструментов. Было бы просто отлично, если бы я мог использовать уже готовые модули, а не делать свои для каждой задачи.
5. Быстродействие.
6. Грамотное сообщество, хорошие документации. Правда я верю, что для всех фрейворков в этом плане все хорошо, но мало-ли.
7. Отсутствие проблем с хостингом.
Предпочтения:
Объектно ориентированный язык программирования со статической строгой типизацией, Си-подобного синтаксиса.
Итого:
Подскажите пожалуйста язык + возможно фреймворк для программирования сайтов / веб-приложений. Большое чисто человеческое спасибо автору каждого полезного ответа, ну и плюсик в карму разумеется.
P. S. Пожалуйста, пишите развернутые ответы.
P. P. S. Пожалуйста, ставьте плюсы и минусы ответам, это поможет мне в выборе.
Обновление 1:
Большое спасибо за ответы, но все-же хочу уточнить, что не список названий фреймворков и языков мне нужен. Хотелось бы услышать что-то типа «Рекомендую то-то и то-то, потому что так и так, подходит под такие-то критерии и прочие. ». Спасибо.
Решение:
Среди statless ориентированных, качественных фреймворков мой выбор пал на Python/Django. Меня убедили (в том числе в офлайне) в его качественности, я нашел в своем родном городе несколько активных вакансий на его тему с 2500$++ заработной платой. Решающую роль в выборе сыграли критерии качества и популярности. Java и ASP.NET — имеют лучшую производительность, вероятно даже технологически более развитые, но их stateless ориентация — под сомнением (уточню при запросе). Выбирая между самым популярным php фреймворком — Zend Framework, Python/Django, Ruby on Rails я остановился на Django поскольку он популярней чем RoR, а php / zend был исключен по критерию качества самого php (качество синтаксиса и структуры языка). Python был близок к исключению по критерию качества интерпретаторов/компиляторов/выполняторов, но меня убедили (офлайн), что это только мои личные стереотипы и давно минувших лет проблемы.
Надеюсь не ошибся в выборе.
Всем спасибо за ответы, советы, комментарии.
Оценить 1 комментарий
Как мне кажется НА сегодня веяние то одно, ну точнее два.
1 Django с питоном
2 Руби на рельсах
попробуйте, хоть одно хоть оба сразу
я попробовал Django, просто так, для самообразования, взял один из старых проектов и реализовал его на нём, изучается быстро, достаточно прост (относительно), возвращаться назад в мир ПХП, очень не просто, особенно когда просят найти ошибку или чуть чуть изменить чужой скрипт…
прошло время, остался на нём, но хорошо понимаю где его сильные стороны где не очень, но всё решаемо, да и версии новый выходят одна за другой, постоянно появляются «вкусняшки» всякие.
Сообщество конечно не как у ПХП, но и порог вхождения повыше, намного меньше вопрос по типу «как подключится к mysql » или «помогите составить запрос».
основная информация о проблемах и решения таковых находят в 90% на англоязычном stackoverflow.com/
руби не использовал, не могу за него сказать, но понимаю что идеологически они похожи, просто там другой баланс + и — какой подойдёт именно вам, это можно понять только сравнив, например написав один и тот же проект на 2х.
я вот тоже долго выбирал, пока ещё не знаю правильно я поступил или нет, время покажет, но пока не жалею, что пошёл в сторону отличную от PHP
Сильно холиварный вопрос, любители как и не любители могут закидать, кому-то не проблема ведь рыться в чужом говнокоде пхп и искать ошибки. а кому-то это отвратно.
могу уверенно сказать следующее
1 мало кода для определённого функционирования (реально афигевал по началу типо блог на 50 строк и то половина это пагинация, хотя есть встроенная)
2 если надо быстро запустить прототип или бетту, то имея навыки это будет намного быстрее чем гуру ПХП 80лв это сделает, разумеется не беру во внимание Yii с коханами (это отдельная тема для разговора)
в общем реально сильно сокращается время разработки, это главное достоинство, я считаю
3 чертовски приятный язык
4 когда-то я работал в телекоме который отныне куплен билайном, и там очень много приходилось работать с SQL запросами, сложными-большыми-огромными, за последние 1.5 года я не написал ни одного запроса, меня это радует (нет я понимаю что если встанет __нестандартная__ задача я с лёгкостью накидаю его),. но считаю, это сродни механической КПП в автомобиле городском, вроде круто и всё такое, но нафиг не нужно в повседневной жизни (гидроавтомат форевер :D). и тут так, я рад, что фреймворк делает это за меня, это чертвоски приятно
4 удобный процесс разработки, хоть под вин, хоть под linux, хоть в браузере (была пару тем на хабре)
5 язык питон более распространён в реальной жизни, в консоле linux серверов, скрипты много чего вместо bash начал делать на питоне, приложения для андройда для венды можно также писать на питоне
в общем _мой_мнение_, что в жизни он более полезнее окажется чем руби.
про минусы не буду они могут оказаться сугубо индивидуальными и зависеть от моих способностей, я не считаю себя способным, одарённым и т.п. у меня есть друг который за пол года в джанге натаскался раза в 3 больше меня, и времени он тратит также раза в 3 на всё, по его мнению в джанге свои минусы которых я не замечаю или не касался пока.
но могу с уверенностью сказать что попробовать стоит.
по быстродействию тут вопрос большой и просторный, я могу сказать, что не заметил прямо вот тормознутости, но могу сказать, что все инструменты для кэширования различных уровней есть, есть сторонние батарейки, если подойти с умом к архитектуре то будет не хуже любой ЦМС хоть джумлы хоть битрикса. хоть срипта на коленке, просто больше гибкости для дальнейшей оптимизации.
2 если хотите, конечно можно писать свои запросы, совсем не беда, ради бога.
я не говорил, что запрос будет лучше чем от аналитика, понятно, что будет не столь оптимально как узкозаточенный костыль, но местами это можно полностью простить эти мелочи.
вы наверняка владете автомобилем, и доверяете распределение момента между колёсами дифференциалу, вы не управляете временем открытия форсунки каждого цилиндра, вы не управляете фазами сдивига в работе клапанов (VVT-i да VTEC и им подобные) автомобиль всё делает за вас и вас это устраивает, тут примерно такая же ситуация, конечно вы можете вывести датчик какойнить между вами и сидушкой, чтоб от степени нажатии на него или сжатия его какая-то система автомобиля работала иначе никто не запрещает, если вам это действительно нужно
допустим еслиб вам надо было ещё дальше узнать чёнить из профиля пользователя, например какой цвет глаз преблодает и сделать ещё что-то может быть возникли проблемы с ОРМ было бы проще уже написать свой запрос. джанга не против этого нисколько
про кэширование нештатное, есть ещё и штатные
Обзор готовых и свой вариант или вот пользователь сам написал
Всё зависит от вас, от вашего опыта, это просто удобный инструмент для определённого круга задач…
3 вакансии и ЗП это вам на HH там всё будет, но как мне кажется их число будет расти. ну и запрлаты должны быть не хуже чем у опытных PHP
4 любая ОРМ тебя отодвигает от гибкости и возможностей, она тебя немного загоняет в рамки, которые заложили архитекторы ОРМ в силу разных причин.
Тут 2 варианта либо вы принимаете эти условия и радуетесь либо пытаетесь с ними бороться, если вы приняли то и архитектуру вы выстраиваете так чтоб было её легче реализовывать с этой ОРМ, не вижу в этом ничего плохого, если будет такая ОРМ которая будет давать вам просто всё, то по моему мнению, ога будет сильно громоздка, в её справке можно будет утонуть, а по настоящему хорошо в ней будут разбираться только бородатые гуру.
то есть придёт момент, когда вы упрётесь в возможности ОРМ и надо будет самому писать скул запросы не потому что так будет оптимальнее, а потому что ОРМ просто не сможет понять вашу логику.
Но все штатные(обычные повседневные) моменты она покрывает на 100%
Джанга наверное имеет тут небольшой плюс перед Рельсами, они вроде как намного больше тяжелее и по слухам, там больше возможностей.
Вот можно почитать интервью с разработчиками Django даёт представление куда оно будет двигаться и как.
сумбур по омему получился каокй-то… надо наверное погуглить немного
Делаем современное веб-приложение с нуля
Итак, вы решили сделать новый проект. И проект этот — веб-приложение. Сколько времени уйдёт на создание базового прототипа? Насколько это сложно? Что должен уже со старта уметь современный веб-сайт?
В этой статье мы попробуем набросать boilerplate простейшего веб-приложения со следующей архитектурой:
Введение
Перед разработкой, конечно, сперва нужно определиться, что мы разрабатываем! В качестве модельного приложения для этой статьи я решил сделать примитивный wiki-движок. У нас будут карточки, оформленные в Markdown; их можно будет смотреть и (когда-нибудь в будущем) предлагать правки. Всё это мы оформим в виде одностраничного приложения с server-side rendering (что совершенно необходимо для индексации наших будущих терабайт контента).
Давайте чуть подробнее пройдёмся по компонентам, которые нам для этого понадобятся:
Инфраструктура: git
Наверное, про это можно было и не говорить, но, конечно, мы будем вести разработку в git-репозитории.
Итоговый проект можно посмотреть на Github. Каждой секции статьи соответствует один коммит (я немало ребейзил, чтобы добиться этого!).
Инфраструктура: docker-compose
Начнём с настройки окружения. При том изобилии компонент, которое у нас имеется, весьма логичным решением для разработки будет использование docker-compose.
Добавим в репозиторий файл docker-compose.yml следующего содержания:
Давайте разберём вкратце, что тут происходит.
Не менее важный docker/backend/.dockerignore :
Воркер в целом аналогичен бэкенду, только вместо gunicorn у нас обычный запуск питонячьего модуля:
Наконец, фронтенд. Про него на Хабре есть целая отдельная статья, но, судя по развернутой дискуссии на StackOverflow и комментариям в духе «Ребят, уже 2018, нормального решения всё ещё нет?» там всё не так просто. Я остановился на таком варианте докерфайла.
Итак, наш каркас из контейнеров готов и можно наполнять его содержимым!
Бэкенд: каркас на Flask
Теперь наш бэкенд мы можем официально ПОДНЯТЬ!
Фронтенд: каркас на Express
В дальнейшем нам вообще не потребуется Node.js на машине разработчика (хотя мы могли и сейчас извернуться и запустить npm init через Docker, ну да ладно).
В Dockerfile мы упомянули npm run build и npm run start — нужно добавить в package.json соответствующие команды:
Команда build пока ничего не делает, но она нам ещё пригодится.
Добавим в зависимости Express и создадим в index.js простое приложение:
Теперь docker-compose up frontend поднимает наш фронтенд! Более того, на http://localhost:40002 уже должно красоваться классическое “Hello, world”.
Фронтенд: сборка с webpack и React-приложение
Пришло время изобразить в нашем приложении нечто больше, чем plain text. В этой секции мы добавим простейший React-компонент App и настроим сборку.
При программировании на React очень удобно использовать JSX — диалект JavaScript, расширенный синтаксическими конструкциями вида
Однако, JavaScript-движки не понимают его, поэтому обычно во фронтенд добавляется этап сборки. Специальные компиляторы JavaScript (ага-ага) превращают синтаксический сахар в уродливый классический JavaScript, обрабатывают импорты, минифицируют и так далее.
2014 год. apt-cache search java
Итак, простейший React-компонент выглядит очень просто.
Он просто выведет на экран наше приветствие более убедительным кеглем.
Добавим и клиентскую точку входа:
Для сборки всей этой красоты нам потребуются:
webpack — модный молодёжный сборщик для JS (хотя я уже три часа не читал статей по фронтенду, так что насчёт моды не уверен);
babel — компилятор для всевозможных примочек вроде JSX, а заодно поставщик полифиллов на все случаи IE.
Если предыдущая итерация фронтенда у вас всё ещё запущена, вам достаточно сделать
для установки новых зависимостей. Теперь настроим webpack:
Чтобы заработал babel, нужно сконфигурировать frontend/.babelrc :
Наконец, сделаем осмысленной нашу команду npm run build :
Бэкенд: данные в MongoDB
Прежде, чем двигаться дальше и вдыхать в наше приложение жизнь, надо сперва её вдохнуть в бэкенд. Кажется, мы собирались хранить размеченные в Markdown карточки — пора это сделать.
В то время, как существуют ORM для MongoDB на питоне, я считаю использование ORM практикой порочной и оставляю изучение соответствующих решений на ваше усмотрение. Вместо этого сделаем простенький класс для карточки и сопутствующий DAO:
(Если вы до сих пор не используете аннотации типов в Python, обязательно гляньте эти статьи!)
Теперь надо создать MongoCardDAO и дать Flask-приложению к нему доступ. Хотя сейчас у нас очень простая иерархия объектов (настройки → клиент pymongo → база данных pymongo → MongoCardDAO ), давайте сразу создадим централизованный царь-компонент, делающий dependency injection (он пригодится нам снова, когда мы будем делать воркер и tools).
Время добавить новый роут в Flask-приложение и наслаждаться видом!
Упс… ох, точно. Нам же нужно добавить контент! Заведём папку tools и сложим в неё скриптик, добавляющий одну тестовую карточку:
Успех! Теперь время поддержать это на фронтенде.
Фронтенд: Redux
Начнём с добавления Redux. Redux — JavaScript-библиотека для хранения состояния. Идея в том, чтобы вместо тысячи неявных состояний, изменяемых вашими компонентами при пользовательских действиях и других интересных событиях, иметь одно централизованное состояние, а любое изменение его производить через централизованный механизм действий. Так, если раньше для навигации мы сперва включали гифку загрузки, потом делали запрос через AJAX и, наконец, в success-коллбеке прописывали обновление нужных частей страницы, то в Redux-парадигме нам предлагается отправить действие “изменить контент на гифку с анимацией”, которое изменит глобальное состояние так, что одна из ваших компонент выкинет прежний контент и поставит анимацию, потом сделать запрос, а в его success-коллбеке отправить ещё одно действие, “изменить контент на подгруженный”. В общем, сейчас мы это сами увидим.
Начнём с установки новых зависимостей в наш контейнер.
Первое — собственно, Redux, второе — специальная библиотека для скрещивания React и Redux (written by mating experts), третье — очень нужная штука, необходимость который неплохо обоснована в её же README, и, наконец, четвёртое — библиотечка, необходимая для работы Redux DevTools Extension.
Начнём с бойлерплейтного Redux-кода: создания редьюсера, который ничего не делает, и инициализации состояния.
Наш клиент немного видоизменяется, морально готовясь к работе с Redux:
Фронтенд: страница карточки
Прежде, чем сделать страницы с SSR, надо сделать страницы без SSR! Давайте наконец воспользуемся нашим гениальным API для доступа к карточкам и сверстаем страницу карточки на фронтенде.
Время воспользоваться интеллектом и задизайнить структуру нашего состояния. Материалов на эту тему довольно много, так что предлагаю интеллектом не злоупотреблять и остановится на простом. Например, таком:
Заведём компонент «карточка», принимающий в качестве props содержимое cardData (оно же — фактически содержимое нашей карточки в mongo):
Теперь заведём компонент для всей страницы с карточкой. Он будет ответственен за то, чтобы достать нужные данные из API и передать их в Card. А фетчинг данных мы сделаем React-Redux way.
Для начала создадим файлик frontend/src/redux/actions.js и создадим действие, которые достаёт из API содержимое карточки, если ещё не:
Ох, у нас появилось действие, которое ЧТО-ТО ДЕЛАЕТ! Это надо поддержать в редьюсере:
(Обратите внимание на сверхмодный синтаксис для клонирования объекта с изменением отдельных полей.)
Теперь, когда вся логика унесена в Redux actions, сама компонента CardPage будет выглядеть сравнительно просто:
Добавим простенькую обработку page.type в наш корневой компонент App:
И теперь остался последний момент — надо как-то инициализировать page.type и page.cardSlug в зависимости от URL страницы.
Но в этой статье ещё много разделов, мы же не можем сделать качественное решение прямо сейчас. Давайте пока что сделаем это как-нибудь глупо. Вот прям совсем глупо. Например, регуляркой при инициализации приложения!
Так, секундочку… а где же наш контент? Ох, да мы ведь забыли распарсить Markdown!
Воркер: RQ
Парсинг Markdown и генерация HTML для карточки потенциально неограниченного размера — типичная «тяжёлая» задача, которую вместо того, чтобы решать прямо на бэкенде при сохранении изменений, обычно ставят в очередь и исполняют на отдельных машинах — воркерах.
Есть много опенсорсных реализаций очередей задач; мы возьмём Redis и простенькую библиотечку RQ (Redis Queue), которая передаёт параметры задач в формате pickle и сама организует нам спаунинг процессов для их обработки.
Время добавить редис в зависимости, настройки и вайринг!
Немного бойлерплейтного кода для воркера.
Для самого парсинга подключим библиотечку mistune и напишем простенькую функцию:
Мы объявили свой класс джобы, прокидывающий вайринг в качестве дополнительного kwargs-аргумента во все таски. (Обратите внимание, что он создаёт каждый раз НОВЫЙ вайринг, потому что некоторые клиенты нельзя создавать перед форком, который происходит внутри RQ перед началом обработки задачи.) Чтобы все наши таски не стали зависеть от вайринга — то есть от ВСЕХ наших объектов, — давайте сделаем декоратор, который будет доставать из вайринга только нужное:
Добавляем декоратор к нашей таске и радуемся жизни:
Радуемся жизни? Тьфу, я хотел сказать, запускаем воркер:
Ииии… он ничего не делает! Конечно, ведь мы не ставили ни одной таски!
Давайте перепишем нашу тулзу, которая создаёт тестовую карточку, чтобы она: а) не падала, если карточка уже создана (как в нашем случае); б) ставила таску на парсинг маркдауна.
Пересобрав контейнер с бэкендом, мы наконец можем увидеть контент нашей карточки в браузере:
Фронтенд: навигация
Прежде, чем мы перейдём к SSR, нам нужно сделать всю нашу возню с React хоть сколько-то осмысленной и сделать наше single page application действительно single page. Давайте обновим нашу тулзу, чтобы создавалось две (НЕ ОДНА, А ДВЕ! МАМА, Я ТЕПЕРЬ БИГ ДАТА ДЕВЕЛОПЕР!) карточки, ссылающиеся друг на друга, и потом займёмся навигацией между ними.
Теперь мы можем ходить по ссылкам и созерцать, как каждый раз наше чудесное приложение перезагружается. Хватит это терпеть!
Сперва навесим свой обработчик на клики по ссылкам. Поскольку HTML со ссылками у нас приходит с бэкенда, а приложение у нас на React, потребуется небольшой React-специфический фокус.
Добавляем глупенький редьюсер под это дело:
Внимательный читатель обратит внимание, что URL страницы не будет изменяться при навигации между карточками — даже на скриншоте мы видим Hello, world-карточку по адресу demo-карточки. Соответственно, навигация вперёд-назад тоже отвалилась. Давайте сразу добавим немного чёрной магии с history, чтобы починить это!
Теперь при переходах по ссылкам URL в адресной строке браузера будет реально меняться. Однако, кнопка «Назад» сломается!
А вот как — действие navigate:
Вот теперь история заработает.
Фронтенд: server-side rendering
Пришло время для нашей главной (на мой взгляд) фишечки — SEO-дружелюбия. Чтобы поисковики могли индексировать наш контент, полностью создаваемый динамически в React-компонентах, нам нужно уметь выдавать им результат рендеринга React, и ещё и научиться потом делать этот результат снова интерактивным.
