Я уже некоторое время занимаюсь веб-разработкой, впервые познакомившись с ней около десяти лет назад, когда jQuery был новичком в мире. Я свободно владею классическим способом ведения дел: цикл запрос-ответ, использование XHR для загрузки нового контента из бэкенда без перезагрузки страницы, нажатие клавиши F5 во время разработки. Много. и Т. Д.

Когда-то JavaScript был красивой краской, которую вы применяли для улучшения своей страницы. Перенесемся в наши дни, JavaScript развился. Это уже не просто «приятно иметь», это бетон, который связывает и держит все вместе. Мы больше не в Канзасе, Тото, мы в мире одностраничных приложений, повторно используемых компонентов, состояния, реквизита, однонаправленного потока данных, React, Redux, горячей перезагрузки и многих других слов, которые со временем будут расти в вас. .

Это не просто улучшенные версии старых технологий. Вы не модернизируете свой молот до молота с большей площадью поверхности и из более качественных сплавов. Вместо этого вы получаете новые инструменты. Чтобы понять и использовать их, вы также должны мыслить по-другому. Как? Вот что я пытаюсь выяснить.

Вот что я знаю на данный момент, прочитав документацию и поэкспериментировав с демонстрационным кодом:

  • Исчез цикл запрос-ответ. При начальной загрузке выполняется одностраничный поиск, и с этого момента JavaScript заботится об асинхронном сохранении состояния, синхронизированного с серверной частью. Пока ничего нового, технически вы могли бы сделать что-то подобное с помощью jQuery, но…
  • Это не та модель DOM, которую вы ищете. Прямой доступ к модели DOM и управление ею больше не нужны. Вы работаете на концептуальном уровне, пишете и собираете компоненты и описываете, как данные изменяются в зависимости от взаимодействия с пользователем, в то время как React заботится о рисовании объектов на экране в зависимости от данных. Это важно, потому что это радикальный отход от всего, что мы делали в эпоху jQuery. Больше никаких $("#input-box").val(), $(".nav>ul").toggle() и т. д. Данные, загруженные вашим приложением с сервера, явно представлены и известны в коде, а не выводятся из HTML.

Вот некоторые вещи,я знаю, что не знаю. Я знаю, что не знаю их, потому что я думал о них, и в голову не приходило очевидного ответа. С этого момента все станет более загадочным, так как я буду использовать остальную часть этого пространства в качестве своего холодильника.

  • В классическом приложении jQuery операции CRUD обычно выполняются путем вызова $.post(), $.get(), $.load() или эквивалентной функции из функции обратного вызова, привязанной к событию. Где теперь происходят операции CRUD, особенно если вы используете что-то вроде Redux? Я имею в виду «Hello World» для React/Redux, ужасное «приложение для списка дел». После того, как вы, наконец, поймете, как работают эти редюсеры, все это станет забавой и игрой, но где именно вы помещаете вызовы к серверу идиоматическим образом?
  • Когда вы впервые загружаете страницу, должны ли вы загружать исходные данные для маршрута по умолчанию в отдельном асинхронном вызове или вы можете загрузить их заранее? (…без использования полного PWA, если, например, серверная часть, с которой вам приходится работать, представляет собой устаревшую настройку Perl).
  • В классическом приложении у вас обычно есть хуки на сервере, соответствующие конкретным вызовам, которые вы хотите сделать, например. /projects/add, /projects/delete и т. д. Они либо возвращают HTML, либо перенаправляют вас на другую страницу. Когда классическое приложение переводится в React SPA, можете ли вы просто повторно использовать одни и те же хуки, изменяя только то, что они возвращают, но сохраняя нетронутой бизнес-логику?
  • Как обстоят дела с Apollo и GraphQL? Какой хороший пример убедил бы меня в том, что они бьют старые крючки?
  • В классическом приложении с аутентификацией, если срок сеанса истек или мы вышли из другой вкладки, веб-сервер обычно выдает вам экран входа в систему при перезагрузке страницы. Как это решается сейчас? Должны ли мы делать что-то вроде отслеживания токена, полученного на этапе аутентификации? Есть ли способ лучше?
  • В классическом приложении с аутентификацией разные типы пользователей получают доступ к разным страницам. Как сообщить приложению, какие маршруты разрешены и какие ссылки на панели навигации (или боковой панели) должны отображаться для данного пользователя? Насколько просто загружать только тот код, к которому имеет доступ определенная роль пользователя? (например, вы не хотели бы, чтобы все ваши крючки для опытных пользователей были доступны кому-то, кто получает доступ к экрану входа в систему, или даже пользователю более низкого уровня).

Спасибо, что остаетесь со мной до сих пор. Я намерен исследовать ответы на эти и другие вопросы (неизвестные неизвестные), и я дам вам знать, что я узнаю. Пожелайте мне Приятного мужества!