В моем последнем посте я рассмотрел процесс принятия решения, через который я прошел, решая, на что перенести мой давний веб-сайт на базе Jekyll. Я пришел в «Astro и в этом посте рассказываю о своем опыте перехода на Astro и его использования.
Вы можете найти полученный код в ветке разработки, а мой сайт, естественно, chrischinchilla.com. Он еще не закончен, и скоро он получит новую волну иллюстраций, чтобы заменить мои не менее старые логотипы Chinchilla.
Что я люблю
MDX или React сочетаются с Markdown
Markdown никогда не был особенно «стандартным», и последовательные инструменты и фреймворки пытались добавить синтаксис, чтобы обеспечить широкий спектр функций.
После двух лет использования MDX (Markdown, смешанный с компонентами React) мне нравится его подход. Требуется «ванильная» уценка, и для чего-либо нестандартного вы используете компонент React. Поначалу это кажется странным, но на самом деле вы получаете два «стандарта». Конечно, у React крутая кривая обучения, но многие расширения Markdown и компоненты React также дают вам возможность доступа к данным из других источников и обширной библиотеке существующих компонентов.
Сначала меня смутило то, как Astro разделяет логику данных и их отображение в файлах контента (С тех пор это было задокументировано). По большей части вся логика происходит в том, что я считаю главной частью, а затем любое отображение этих данных происходит в том, что я считаю телом. Как только вы привыкнете к этому, это будет довольно просто, имеет смысл и, я думаю, является довольно нормальным шаблоном в приложениях в стиле реагирования.
Вам не нужно использовать какие-либо из этих функций, и вы можете просто придерживаться старой доброй уценки, что обеспечивает большую гибкость.
Все является компонентом
Продолжая тему выше, почти все в Astro может быть компонентом. То есть еще один фрагмент кода, которому вы можете передать параметры, и он выполняет функцию. Разделение интересов, так сказать. Я думаю, что это то, что Astro называет островами компонентов, поскольку это продвигает традиционную архитектуру на основе компонентов на один шаг вперед. Я не совсем понимаю это, но насколько я понимаю, Astro удаляет любой JavaScript из компонента перед его рендерингом по умолчанию. Затем вы определяете, какие компоненты вы хотите оставить динамичными, ваши острова.
Мне нравится идея компонентов, и хотя вы можете немного заблудиться в каскаде компонентов, это то, что я часто пытался реализовать на традиционных статических сайтах с включениями.
Несколько источников контента
Эта функция была для меня главным требованием. Я хотел агрегировать контент из файлов уценки, вызовов API, файлов JSON и, возможно, других источников в будущем. Astro обрабатывает все это довольно просто, одинаково обрабатывая вывод, который вы затем можете превратить в статический контент (который затем становится HTML) или просто отобразить его на странице. У меня есть проблемы с некоторыми источниками контента, которые я хочу агрегировать, но на самом деле это проблема не Astro, а исходного сервиса. Больше всего смотрю на вас и отсутствие у вас API Medium!
Мне еще предстоит выяснить, как «объединить» некоторые из этих источников, например, рассматривать контент из Medium и файлы уценки как контент блога. Я уверен, что это возможно, но я еще не копал.
Типы контента
Когда я начал переходить на Astro, у него не было конкретной концепции типа контента, которая есть у большинства других генераторов статических сайтов и CMS. Затем появилась версия 2, которая привнесла функцию коллекций и открыла путь для простой в использовании концепции типов контента. Вы можете использовать коллекции для разных типов контента (у меня сейчас есть посты, события, клиенты, игры), а также использовать такие как переводы.
Я еще не вникал в детали того, как работает Astro, но он построен на основе Typescript, который представляет собой Javascript со строгой типизацией. Это означает, что структуры данных, которые вы используете в коде, должны соответствовать определенному определению.
Большинство традиционных генераторов статических сайтов свободны, когда дело доходит до типов контента. Вы можете бросить все, что вам нравится, в уценке, и в целом сайт строится. Он может не отображаться правильно в каждом случае, но все же строится.
То, что напечатано, не будет работать, если определение данных нигде не совпадает. Это означает, что разработка и добавление контента может занять больше времени, но у вас будет больше гарантий того, что сайт будет отображаться правильно во всех случаях. Это также означает, что в редакторе или IDE вы лучше разбираетесь в интеллектуальном плане, что дает вам подсказки при создании контента.
У меня была самая большая проблема с полями даты. Поскольку я добавлял контент на свой предыдущий сайт в течение многих лет и из разных источников, значения, которые у меня были для дат, были довольно разными, от UNIX до полных временных меток ISO. Jekyll «с удовольствием» отображал бы любой формат, который я ему подбрасывал, но Astro (или TypeScript) требовали, чтобы я изменил их все на один и тот же формат, иначе он отображал бы сообщения в устаревшем порядке или не отображал бы их вообще. Это была неплохая задача, но она отнимала много времени. Возможно, я мог бы создать какую-то вспомогательную функцию для обработки различий, но в конце концов я выбрал путь преобразования.
Таким образом, для создателей контента это означает, что любой пользовательский тип контента (или коллекция), который вы определяете, получает доступ к этой системе типов, поэтому независимо от того, что вы добавляете, вы получаете эти преимущества. Или разочарования во время обучения…
После того, как вы настроите тип контента, вы можете использовать ряд любопытных файловых шаблонов, начинающихся с трех точек, для динамического создания HTML-страниц из коллекций. Три точки взяты из синтаксиса остаточного параметра JavaScript, который я никогда раньше не видел, и документы Astro никогда полностью не объясняют, что Astro делает с этим синтаксисом, и нужны ли они вам на самом деле, поскольку в нем показаны примеры с обоими. Я использую три точки, и все работает, поэтому я пока останусь на нем.
Это хорошее время для краткого рассказа о двух разных режимах, в которых Astro может отображать контент.
Один находится в статическом (SSG) режиме, и это режим, который соответствует тому, к чему привык каждый, кто приходит со статического сайта, в том смысле, что Astro создает файл HTML для каждого файла уценки. Другой режим — рендеринг на стороне сервера (SSR) для каждой страницы с сервера, когда браузер запрашивает ее.
Astro по умолчанию работает в режиме SSG, и меня это интересует.
Вернемся к синтаксису с тремя точками. Документация местами немного запутана, а поиск сообщений в блогах может добавить путаницы, поскольку они часто ссылаются на Astro до версии 2, где все работало по-другому.
Я по-прежнему не уверен в полном уровне гибкости, доступной для создания страниц из коллекций, но у меня есть следующее:
- blog/[…page].astro: «индексная» страница верхнего уровня, если кто-то посещает блог/страницу в браузере. В моем файле показан разбитый на страницы список коллекции контента.
- blog/[…slug].astro: «шаблон» страницы для каждого файла уценки, который Astro отображает как HTML. Имя файла, а затем и путь, определяются значением из используемой вступительной части, в данном случае «slug». Вы можете использовать любое другое значение, например, «автор» как […author].astro, хотя я не уверен, как Astro справляется с очисткой ввода, чтобы он работал для пути к файлу.
середнячок
Я бы не стал говорить «плохо», потому что, возможно, я неправильно понял некоторые вещи. Конечно, это не обязательно хорошо, но я хочу избежать полного негатива. Хорошо, предостережение... Итак, приступим...
Добавление макета и темы
Что еще? Ах да, давайте поговорим о макете и дизайне или «темах».
Поясню: создание тем и макетов никогда не было таким простым ни в одном из генераторов статических сайтов, которые я использовал. Они варьировались от Jekyll и Liquid, которые грязны, но все, что вы в них бросаете, обычно работает, до Hugo, где я провел много бессонных ночей, пытаясь заставить его шаблоны отображать так, как я хочу.
Astro позволяет вам использовать собственную структуру пользовательского интерфейса, включая React, Svelte и Vue. Это хорошая функция, которая имеет смысл, но стоит отметить, что все эти фреймворки пользовательского интерфейса сложны и имеют крутую кривую обучения. Традиционные языки шаблонов генераторов статических сайтов могут быть запутанными, но большинство людей могут их понять. Современные UI-фреймворки на основе JavaScript далеко не однозначны, они имеют множество зависимостей и предположений, сделанных их документацией и сообществом.
В итоге я остановился на Astrowind, так как он предлагал множество макетов, которые я искал. Но это также добавило много функций, которые мне не нужны. Должна ли функциональность быть в теме? Я не уверен, если подумать о различных материальных темах пользовательского интерфейса, которые я использовал раньше, они делают то же самое, но в каждом случае ваш сайт оказывается связанным с темой, что не совсем правильно.
Пока я переделывал свой сайт, произошло переключение Astro V2, и тема немного отстала. Обновление темы никогда не было легким, и хотя я хорошо справился с миграцией Astro и темы, я чувствую, что на моем сайте есть много устаревших фрагментов кода, от которых мне нужно постепенно избавляться.
Содержание объявлений
Создание списков любого контента — еще один хороший пример «способа JavaScript» по сравнению со способами, к которым вы, возможно, привыкли. Многие генераторы статических сайтов предоставляют в своих темах удобные методы для получения списка контента, где вы также обычно можете фильтровать и сортировать контент.
Вот Джекил:
{% for staff_member in site.staff_members %}
<h2>{{ staff_member.name }} - {{ staff_member.position }}</h2>
<p>{{ staff_member.content | markdownify }}</p>
{% endfor %}И Хьюго (хотя я признаю, что значения, которые загружаются в массив, часто загадочны для Хьюго):
{{ range .Pages }}
<li>
<a href="{{ .Permalink }}">{{ .Date.Format "2006-01-02" }} | {{ .Title }}</a>
</li>
{{ end }}С Astro вы используете функции .map для возврата массивов, отсортированных и отфильтрованных так, как вы хотите. Это не обязательно сложный синтаксис, но опять же, синтаксис карты может сбивать с толку, если вы к нему не привыкли. Синтаксис, необходимый для довольно стандартных требований, ориентированных на контент, не всегда очевиден, если вы пришли с более традиционного статического сайта. Например, вот как вы возвращаете контент, отсортированный по дате:
allPosts = allPosts.sort(
(a, b) => new Date(b.data.publishDate).valueOf() - new Date(a.data.publishDate).valueOf()
);Возвращаясь к моему замечанию выше, вы также можете обнаружить, что если ваш контент имеет несовместимые значения вступительной части и вы используете это значение для сортировки, то сортировка не работает так, как вы ожидали. Опять же, вы можете возразить, что, поскольку Astro использует типизированный язык, это скорее проблема вашего контента, и это верно. Но стоит отметить, что если вы используете более традиционный инструмент статического сайта, так как они часто справляются с сортировкой более свободно.
Сложность важнее содержания
Практически любой современный JavaScript-проект содержит огромное количество, скажем так, «предположений». Извините, поклонники JavaScript, я часто использую язык и экосистему, и это правда. В некотором смысле дела обстоят хуже в проектах, которые заявляют, что они «просты в использовании», поскольку они часто зашорены своей сложностью.
Некоторые вещи с Astro просты, но многое на самом деле не так, несмотря на то, что могут сказать документы, маркетологи или сообщество. Прежде чем я привлечу негативные комментарии, позвольте мне предупредить о нескольких вещах.
Во-первых, некоторые из самых сложных проблем, с которыми я столкнулся, стали менее сложными с версией 2 Astro, но к настоящему времени мой опыт смешался с морем долгосрочных разочарований.
Во-вторых, я сравниваю Astro с генераторами статических сайтов, такими как Jekyll, Hugo, MKDocs и Docusaurus. Хотя на сайте Astro говорится:
Astro — это универсальная веб-инфраструктура для создания быстрых веб-сайтов, ориентированных на контент.
Это более широкое заявление о цели, чем генератор статических сайтов, но все же «ориентированный на контент» заставляет меня предположить, что все построено вокруг контента, как генератор статических сайтов или CMS, и это не всегда так с Astro.
Чтобы продолжить мой пример сверху. Я потратил долгое время, пытаясь понять, как составить обзорный список контента, то есть список, например, последнего контента на сайте. Скорее всего, с заголовком, изображением, кратким описанием контента, ссылкой на контент и некоторыми метаданными.
Каждый генератор статических сайтов, который я использовал, имеет функциональные возможности для этого, у Hugo даже есть автоматический, хотя иногда и разочаровывающий, метод отображения любой папки с контентом в виде списка, если вы открываете путь в браузере.
Например, вот снова Джекилл:
<ul>
{% for post in site.posts %}
<li>
<a href="{{ post.url }}">{{ post.title }}</a>
{{ post.excerpt }}
</li>
{% endfor %}
</ul>Все генераторы статических сайтов, которые я использовал, имеют способ отображать сводку контента, как правило, с помощью комбинации первого абзаца, количества слов или слов до специального символа.
По умолчанию метод Astro показывает значение основного поля и все. Это решение, но требует дополнительной работы для создателя контента, и было бы неплохо иметь запасной план, как и любой другой инструмент, ориентированный на контент, который я когда-либо использовал. Может быть, мой вариант использования необычен, так как у меня есть тысячи старых файлов уценки, импортированных из разных источников, поэтому добавление к ним специального поля сводки было бы большой работой.
Аргумент участников сообщества, с которым я разговаривал, заключался в том, что Astro — это «фреймворк» контента. «Легко» создать пользовательскую функцию для захвата первых слов из тела или вставить новое поле при отображении содержимого. Это правда, и, возможно, я неправильно понимаю, что означает «фреймворк», но я утверждаю, что любой другой инструмент, ориентированный на контент, который я использовал, имел встроенную функцию для отображения сводки контента. Но когда я имел дело с документацией или сообществом Astro, мне казалось, что я прошу какую-то дикую новую функцию, которая была «сумасшедшим» требованием.
Я чувствую, что сообщество JavaScript часто использует слово «фреймворк», часто не определяя, что оно фактически означает.
В итоге я написал функцию, которая использовала пакет markdown-truncate, доказав, что использование пакета node для самых маленьких вещей по-прежнему верно.
Здесь я столкнулся с дополнительными сложностями, которые привели меня в долгое замешательство, которое, наконец, закончилось этим любопытным фрагментом кода:
…
const truncatedBody = truncateMarkdown(body, {
limit: 500,
ellipsis: true
})
…
<Markdown of={truncatedBody} />И угадай что? Компонент Markdown был еще одним пакетом, который мне пришлось импортировать.
Я все еще в замешательстве и очень надеюсь, что есть более простое решение, но это потому, что функция вывода списка содержимого, которую вам следует использовать в документации (могут быть и другие методы), отправляет значение тела каждого файла в виде HTML. Или в виде строки, если речь идет о TypeScript. Это означает, что когда вы доберетесь до уровня компонента контента, усечение HTML будет беспорядочным. В Ruby есть замечательный nokogiri, который я широко использовал в версии своего сайта для Jekyll для всевозможных целей очистки контента, но мой поиск foo не смог найти ничего подобного в мире JavaScript.
Это приводит меня к необходимости двух зависимостей, чтобы взять уценку, которая была преобразована в HTML, преобразовать ее обратно в уценку, чтобы я мог обрезать ее и снова преобразовать в HTML через компонент.
Возможно, есть лучший способ сделать это, я не нашел. Я повторяю, что любой другой инструмент, ориентированный на контент, который я использовал, имеет эту встроенную функцию, и поиск документов и опрос сообщества не увели меня далеко.
И мои выводы?
Я чувствую, что во многом ошибся в этом посте и своем опыте, и на самом деле я хочу, чтобы мне сказали, что я ошибаюсь. Я хочу, чтобы люди говорили мне, что я должен был сделать, чтобы я мог найти лучший способ. И это мой главный момент, я не мог понять, несмотря на много усилий и времени. Были времена, когда я почти сдавался и переключался на другой инструмент/фреймворк, но что-то в Astro заставляло меня продолжать настойчиво.
Я думаю, что это достаточно новый проект, несмотря на то, как он может показаться на первый взгляд. Документы не особенно структурированы и смешивают и сочетают простые и сложные темы с дикой энергией на одной странице. Проект стремительно развивается и регулярно добавляет новый функционал и способы ведения дел.
Но да, в Astro есть «что-то», что заставляет меня придерживаться его. Разочарование постепенно переходит в понимание. Мне наконец-то удалось добавить на свой сайт функции, которые я хочу, вместо того, чтобы бороться с инструментами и предполагаемыми знаниями. Время от времени я открываю свой старый сайт Jekyll и смотрю на него знакомыми глазами, но скучаю ли я по нему? Нет… Пока…
Дополнительные материалы на PlainEnglish.io.
Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord .
Заинтересованы в масштабировании запуска вашего программного обеспечения? Ознакомьтесь с разделом Схема.
