DEV Community: Navillus

The power of simplicity

Navillus — Sat, 07 Aug 2021 00:00:00 +0000

Our last post highlighted the benefits of using Astro and Forestry CMS (catch up here in case you missed it). Forestry actually shared our post with a really important point that I thought was worth digging into with a proper blog post.

The beauty of embracing open formats like Markdown and JSON on top of Git is that a CMS you designed more than 5 years ago, works perfectly with the latest modern web tooling.

Now go check @astrodotbuild to ship faster websites 🚀 https://t.co/0o6OgCfkgx
— Forestry CMS (@forestryio ) August 5, 2021

Follow @forestryio on Twitter if you don't already! Their git-based CMS tools are a huge win for any Jamstack project and should you have any questions or issues, their team is extremely responsive and helpful.

tl;dr; The web development landscape is constantly in flux. It's easy to see the latest tools, languages, and frameworks get hyped on your favorite blogs and podcasts, but at the end of the day you probably need to build quality sites that can be easily maintained for years. More often than not, the boring tools make your life easier in the long run!

A bit of history

It wasn't so long ago that sites were edited by handed - good old fashioned HTML,CSS, and (maybe) JS. A site contained more <marquee>s than pages, RIP marquee!, and the querySelector wasn't a thing.

Browsers are still fundamentally the same today. Yes they are much bigger and feature packed, but at the end of the day a browser takes markup in the form of HTML, styles in the form of CSS, and JavaScript for interactivity. We have more APIs to play with, and more caching problems to manage, but at the end of the day it's the development workflow that has really complicated.

Modern web development

Jumping ahead a few years (or 20) and now its not uncommon to start a project by deciding on the 5+ tools and platforms you will be bolting together. Do you want static site generation (SSG), server-side rendering (SSR), or client-side rendering(CSR)? Are you standing up and maintaining a backend server, or jumping on the serverless backend? Will plain CSS do the trick, or is SASS/SCSS/LESS your preferred approach? What about this CSS in JS and styled components madness?!?

Oh wait, you also need to host it somewhere. Does the project need continuous integration (CI) with automated testing, automated deployments, staging environments, etc? Better schedule another few days to decide on those tools, setup accounts, and bootstrap the basics together before you start coding!

Does it have to be so complicated?

No! Sure, all these tools and processes were created for good reason. CI can save a huge amount of time. Transpilers, build tools, and linters can help catch common mistakes and enforce team coding standards. Frontend frameworks can really be a lifesaver, especially if you need to build interfaces with complex interactivity and state management.

But all these advancements can turn into a real nightmare, too. Ever tried onboarding a new hire that is an experienced web developer but not familiar with the latest React trends like styled components or hooks? Is the time spent ramping up on these abstractions really worth the effort for a simple marketing site or statically hosted e-commerce store?

Long-term value

The tech stack you chose can be a much larger commitment than it first seems to be. I would be very surprised if react was no longer used a couple years down the road, but what about the 15 libraries you pull in to that react app?

If a project is built on an everything but the kitchen sink™ app platform like Nuxt.js, Next.js, or SvelteKit can really let you hit the ground running, but will they still be supported a few years down the road? Will developers still be excited to work with them, or will it be the butt of too many developers' jokes like WordPress?

Keep it simple, stupid

Back to the entire reason we're here, sticking with "boring" tech may not be such a bad idea. The JSON spec is around 20 years old, git is 16 years old, and markdown is 17 years old. Though the HTML/CSS/JS standards are a constant work in progress they go back as far as 1993 (ok, 1995 for JavaScript).

Even better, these are all open standards that may evolve but will never go away.

What about this site though?

This very site is built with a shiny new SSG, Astro, isn't that a bit hypocritical? I don't think so, but hear me out!

Take a look at the sourcecode for this project and you'll see that the real meat of the site is based entirely on the standards above. SCSS is used for styling, but honestly the only reason we even used that was because CSS nesting isn't supported yet.

Most of the site's pages are authored in markdown and various bits of data are stored in JSON.

Page templates and components are in .astro files that really just consists of JavaScript in the form of frontmatter, styles are either in global .css files or component-level <style> blocks, and markup is mostly HTML with a bit of JSX-like javascript inline for conditionals and for-each loops.

It would take a matter of a few hours to migrate the entire site to a different SSG, or even an entirely different platform like Next.js.

So yes, we're technically using a few new build tools to wire templates together, but at the end of the day it's easy to use Astro and forget that you aren't using the basic, web-native HTML/CSS/JS stack.

Innovation is amazing, just don't get stuck

It's a very common mistake, especially for developers newer to web development, to get stuck on the hamster wheel chasing the latest toy. Don't avoid innovation, just be strategic and selective in where you invest your time and efforts!

There's always a new tool to try or pattern to learn, but at the end of the day it's much more satisfying to ship a product rather than trying out a new tool with sample projects that never sees the light of day!

I feel like I bashed on react here - don't get me wrong, react is an excellent and extremely powerful tool. React still has a huge lead in usage compared to the other frontend frameworks and, especially if you're in the job market, it's much easier to find job listing that require react experience than listings that don't mention react at all. But if you find yourself running in circles, getting frustrated with a build pipeline that's fighting you or magic hooks that you don't understand, take a step back and learn the basic (boring) 20 year old tools. Ship fast, don't break the build!

Astro + Foresty CMS Revisited

Navillus — Tue, 03 Aug 2021 00:00:00 +0000

It's been just over a month since the original Astro + Forestry CMS demo, but things have been moving quickly in Astro land! We'll build upon the original demo, go ahead and check out the first post if you haven't done so already!

tl;dr; We received some great feedback from Forestry after the original demo was released. I had been holding off on revisiting that post until a few Astro features were released. Check out the live demo, or dive into the main diff that includes most of the updates listed below.

Specifically, Astro's Collections API was updated to handle even more use cases. Oh yeah, and their docs site was launched! It's hard to believe this project was only announced a few months ago, the community has really grown quickly and countless hours were put in to build a great looking (and localized!) documentation site.

Feedback straight from the source

Awesome post 👏
We should give a try to @astrodotbuild 🚀

Minor feedback:
1. You could set /images as your default media folder instead of the default /uploads to further reduce the diff.
2. Authors could be stored as JSON file(s) instead of Markdown if you don't need a body.
— Forestry CMS (@forestryio ) June 29, 2021

Default media folders

Forestry's CMS is extremely flexible, and honestly its crazy the feature set they're able to offer while storing all your data in your own git repo. No, this isn't a paid post. I'm a user of Forestry and big fan of the git-based CMS approach!

One of many options when configuring Forestry is the default folder for media uploads. I definitely had an eye towards minimizing the diff in the original demo, I'm just in the habit of using a /uploads directory for user uploaded content. Old dogs, new tricks, and all that.

Authors stored in JSON

This was excellent feedback, and worth digging into a little further.

I originally had author information stored in separate markdown files, /data/authors/don.md and /data/authors/sancho.md.This honestly didn't make that much sense, markdown is a great way to combine properties and content (usually built to HTML). The blog demo doesn't have any author-specific content, just a few properties like name and image.

Given that the site doesn't need to pull any HTML content for the author, it makes much more sense to store that data in a simple JSON file. Let's get rid of the author markdown files entirely, replacing it with src/data/authors.json:

{
  "don": {
    "name": "Don Quixote",
    "image": "/uploads/don.jpg"
  },
  "sancho": {
    "name": "Sancho Panza",
    "image": "/uploads/sancho.jpg"
  }
}

Forestry supports this out of the box, once you setup the sidebar to include the new JSON file it recognizes that the file is a map and it just works. I honestly expected this to fight me a little bit, and was to when I had no issue removing references to the old markdown files. I was even able to reuse the same content model.

I did need to update the content model for posts to reference the new JSON file instead of a markdown file, but a few clicks in the settings menu and it was all hooked back up.

Bonus points: Instant Previews

Forestry's instant previews run your development server in a docker container and allow you to preview CMS updates in realtime. That's one of those features that can push plenty of projects to use a hosted CMS platform, very cool to see live previews working so seamlessly in a git-based CMS.

One issue I ran into when deploying the first demo was that Astro only supported node 14+. Instant Previews allow you to customize which docker image is used for your development server, but I couldn't quite get it to work with an early version of Astro and ran out of time. As of a couple weeks though, Astro now supports node 12 out of the box!

After updating the demo project, setting up instant previews was as simple as going back to Forestry's default preview settings. I had tried a custom docker container with no luck, but the included node 12 + yarn image worked like a charm with the latest version of Astro.

The New Collections API

The original collections API in Astro was designed before the beta was publicly released, and it turns out there were a few use cases that were more common than expected.

There aren't any monumental changes here, you can dig through the merged RFC if you're curious. A few of the API names were updated to be more clear, and the API was updated to work with the newer Astro.props API.

You can check out the diff here to see exactly what I had to do to update the $posts.astro route for the new API. Personally, I'm a fan of the newer design and think the code is a bit cleaner and easier to read.

Conclusion

Astro has been moving quickly since it's public beta launched! I was glad to see how easy it was to clean up the demo a bit and take even better advantage of Forestry. If you haven't worked with a git-based CMS before I highly recommend you take an afternoon and give it a try. It may not be right for every project, but the developer experience literally having all your CMS data on your local machine just can't be beat!

Animated page transitions in Astro with Swup

Navillus — Sat, 24 Jul 2021 00:00:00 +0000

I can't be the only developer that has come across a beautifully designed website with top notch animations only to burn an afternoon trying to figure out how exactly they did it. Usually the answer is a combination of 5 different libraries and a pile of JavaScript and CSS being sent over the wire.

Animations don't have to be all or nothing though, and it really can be best to start small and slowly grow and polish the user experience. Swup is an excellent starting point, offering all the basics you need to hook up client-side routing with page transition animations. Even better, Swup's API supports plugins with over a dozen pre-made plugins for the most common use cases and a simple API to roll your own custom plugin.

tl;dr; Adding page transition animations to Astro's blog-multiple-authors example was surprisingly simple. Check out the source code here or jump right into the live demo!

Setting up the project

There's very little setup here since we're starting with an existing Astro starter. First, let's use degit to create a local copy of the blog example

npx degit snowpackjs/astro/examples/blog-multiple-authors demo-astro-swup

Prepping for swup.js

There are great docs on swup's site so I won't get too in the weeds, but it's worth having a basic idea of how the routing will work.

When a visitor clicks a link on your site, swup will hijack that request and attempt to load the next page in the background. By default swup looks for an element with the ID #swup on every page (this is configurable). When navigating to a new page, swup loads the new content in the background and swaps out all the old content inside the #swup element for the content in the new page.

During the navigation, CSS classes like is-animating and is-leaving are added giving you hooks to trigger the actual transition animations.

With that said, it'll be a little easier to add swup to every page on your site if they are all using a shared layout component in the Astro project. See this commit if you're curious exactly what I moved around to create the common layout component in this project.

Most importantly, in src/layouts/Main.astro

<main id="swup" class="wrapper">
  <slot />
</main>

This ensures that the #swup element is on every page and wraps all page-specific content that should be replaced during a page navigation.

Adding swup.js

Swup is extremely configurable, but one NPM dependency and a couple lines of code is really all it takes to get started.

npm install --save-dev swup

Initialize swup in /public/app.js...

import Swup from "swup";

const swup = new Swup();

Finally, import app.js in the shared layout...

<html>
  <body>
    ...
    <script type="module" src="/app.js"></script>
  </body>
</html>

Adding transition animations

Ok, so that won't actually animate anything yet. Check out swup's theme docs if you want to write your own CSS animations, but they do include a few basic themes on NPM. We'll stick with the basic slide theme for now, which you can see in action on the live demo.

npm install --save-dev @swup/slide-theme

import Swup from "swup";
import SwupSlideTheme from "@swup/slide-theme";

const swup = new Swup({
  plugins: [new SwupSlideTheme()],
});

Supported scoped styles

Astro supports scoped styles out of the box. This can be a huge win for performance and avoiding unnecessary CSS in the browser, but we'll need swup to update any linked stylesheets when navigating to a new page.

This is actually a problem I ran into with barba.js. I couldn't for the life of me figure out how to update the page's <head> when navigating. It seems like this may have been possible in v1 but is no longer supported in v2.

Thankfully, swup has this covered with their head plugin.

npm install --save-dev @swup/head-plugin

import Swup from "swup";
import SwupHeadPlugin from "@swup/head-plugin";
import SwupSlideTheme from "@swup/slide-theme";

const swup = new Swup({
  plugins: [new SwupHeadPlugin(), new SwupSlideTheme()],
});

Plugins to the rescue again! This plugin will replace the old <head> with the version in the new page when navigating - it even has config options should you need to persist some styles or meta tags on every page!

Accessibility support

Page transitions can really ruin the experience for anyone visiting your site with an accessibility tool like a screen reader. Many accessibility tools depend on browser events to know when the page content has changed, with swup manually changing out the DOM content a reader may never realize anything changed.

Again, there's a handy plugin to take care of this accessibility problem. It isn't a magic bullet and I strongly recommend you manually test all of your sites with a screen reader - if nothing else it's enlightening to see how different using the web can be if you are visually impaired!

npm install --save-dev @swup/a11y-plugin

import Swup from "swup";
import SwupA11yPlugin from "@swup/a11y-plugin";
import SwupHeadPlugin from "@swup/head-plugin";
import SwupSlideTheme from "@swup/slide-theme";

const swup = new Swup({
  plugins: [new SwupA11yPlugin(), new SwupHeadPlugin(), new SwupSlideTheme()],
});

Progressively enhanced, for free!

Take a look at our Progressively enhancing Svelte with JavaScript post for a more detailed explanation of why progressive enhancement is so important, but suffice it to say a site should never require JavaScript to be usable.

In the case of swup transitions, if JavaScript fails or is disabled for any reason we have a perfectly functional static site that can navigate to new pages like normal. Swup doesn't change your links or <a> tags at build time, so if app.js never loads or hits an exception you're left with exactly the same static site that Astro built in the first place!

Conclusion and next steps

There's plenty more you could do here to really get crazy with animations. Pull in gsap to create intricate animation timelines or add transition animations to SVGs. Though I haven't tried it yet, I see no reason why you couldn't have multiple instances of swup targeting different portions of your page.

Converting our site to Astro

Navillus — Tue, 20 Jul 2021 00:00:00 +0000

Not too long ago, the Navillus site was rewritten from the ground up in Astro. Since then we've had quite a bit of interest in why we jumped to Astro, how it went, and what we learned. I'll do my best to answer the common questions here, but feel free to reach out on Twitter if we missed anything!

tl;dr; Our homepage makes fewer requests (10 vs. 21), is smaller (77kB vs. 123kB), and our JavaScript footprint went down from 31kB to a whopping 2kB!

Why we moved to Astro

A huge majority of the web is static content, and our site is no different. There are exactly two components with any type of client-side interactivity, the mobile menu and our theme toggle. As you might expect, those components aren't exactly complicated and can be built with only a few lines of JavaScript.

Migrating from SvelteKit

Our site was previously written in SvelteKit and, especially for being it considered beta, we were very happy with SvelteKit. The fact is, though, that webapp frameworks like SvelteKit, Next.js, and Nuxt.js are focused on building highly interactive frontends rather than mostly static sites.

Don't get me wrong, SvelteKit earned its place at the top of my list when building large, dynamic webapps. But for most projects, I will happily build with Astro and sprinkle in Svelte components when needed.

What did it take to change?

Surprisingly, not that much! Most of the Svelte components we had were only used for layout purposes, and because Svelte sticks so closely to plain old HTML/CSS/JS it was trivial to convert most of the Svelte components to Astro components.

The main change will be related to conditional rendering syntax, like hiding/showing an element or looping over an array of data. For example,

In Svelte...

{#if open}
   ...
{/if}

<ul>
  {#each items as item}
    <li>{item}</li>
  {/each}
</ul>

becomes...

{open && (
  ...
)}

{items.map((item) => (
  <li>{item}</li>
))}

Coming from Svelte this feels a little too React-y for my taste, but it is really handy to be able to use JavaScript right in the template. I haven't actually tried this yet, but I assume you could sort() or filter() the array right in your template!

What didn't work?

Nothing! Our site is pretty straight forward with little more than static homepage content and a blog, those really are table stakes for any static site generator.

When it came time to port over the mobile menu and theme toggle, we decided to use the Svelte components as-is initially. That's the real benefit of Astro, static site generation without having to give up the component framework when needed. Note that we did recently move those components to Astro as well, helping to bring our JS size below 2kB.

What about server routes?

This site wasn't using any of SvelteKit's server endpoints, but it is important to remember that Astro is currently focused on static site generation.

Astro doesn't build any kind of server but if you happen to deploy to Netlify, their Functions product is a great fit for Astro. Subscribe to our RSS feed so you don't miss an upcoming post adding Netlify Functions to populate our site's web mentions!

What did we learn?

Working with Astro was refreshingly simple. React, Svelte, Vue, etc. have their place in modern web development but it's important to remember that they aren't always necessary. Our theme toggle does nothing more than add/remove a class from the document element, is that really enough to warrant another dependency and ~9kB in extra JS?

Astro is still in beta! The framework has been moving extremely fast, a quick glance at the changelog shows 13 releases so far in the month of July. A few APIs have had small changes and the Collections API is in the middle of a refactor, don't be surprised if you occasionally have to make a few updates to keep up with the latest Astro release.

Conclusion

It's easy to skip right past the simple solution in software projects. Full-featured frameworks can be a huge time saver when starting a dynamic web application, but if all you need is a marketing site you may just be better off with a simple statically built site powered by Astro!

Have more questions that we missed here? Reach out on Twitter!

Astro + Snipcart

Navillus — Sat, 03 Jul 2021 00:00:00 +0000

tl;dr; Check out the live demo here, or if you're feeling brave dive right into the GitHub Repo begging for a refactor!

Preface

When designing the tech stack for an e-commerce project, the web of competing priorities can start to feel like an M. C. Escher painting.

Online stores directly drive revenue through their site, making conversion rates a top priority. That often leads to the need for realtime tracking and user-specific product recommendations. Cool! We know we'll need a backend feeding the frontend realtime data.

What happens, though, when your marketing campaign goes viral and site traffic takes off like a rocket? Wait a second, so is this when we're supposed to reach for cloud-based autoscaling? Or a serverless solution?

The benefits of Jamstack

Static sites aren't a one size fits all solution, but they have some very real benefits especially at smaller scales. It seems crazy to use a static site for an online store though...right?

I'd argue that a vast majority of online shops could see huge benefits if they switched to a static setup. Their store is always available, fast, and easily indexed by Google. Most importantly, if their next Instagram post goes viral the rush of shoppers won't take down their site and throw away all those potential sales.

Enter Snipcart

We have used Snipcart on quite a few projects over the years, including Kamfly and been extremely happy with the results.

Snipcart is a drop-in shopping cart solution complete with support for subscriptions and digital goods. Their admin dashboard gives you easy access to customer and product analytics, inventory management, abandoned cart re-engagement campaigns, and even supports multiple currencies and tax solutions.

Even better, Snipcart discovers your product details right from your HTML. You include data- attributes defining things like a product's price and options and Snipcart handles the rest. And don't worry, Snipcart verifies all product details before accepting an order to make sure there wasn't any funny business.

Static e-commerce with Astro

Enough already, lets get to the solution! Fair warning, this demo is a fairly direct port from Kamfly's demo. That project was originally written in 11ty, another static site generator that provides an excellent developer experience for fans of JavaScript.

The UI design of the demo menu may look familiar to a few of you reading this. My first job out of college was as a Software Development Engineer in Test (SDET) at Microsoft. I worked on the UI team responsible for Windows Phone 7-10 and was always partial to the subway-inspired design!

Loading the menu data

I didn't want to stray too far from the original 11ty project, and that meant storing all the menu data in local JSON files.

You can see the full details in GitHub, but the basic solution here takes advantage of glob imports.

import.meta.glob("../data/menus/*.json");

The code above is a bit of import magic that allows you to use a glob pattern to load multiple files at once.

With import.meta.glob the result is an object mapping from filename to an async function that loads the file. In case you want to load all the data immediately, import.meta.globEager will be your best friend.

Adding the shopping cart button

Snipcart makes this extremely simple.

<button class="header__cartbtn snipcart-checkout">
  <img class="header__cart" src="/icons/cart.svg" alt="open cart" />
  <span class="snipcart-items-count header__cartcount">0</span>
</button>

That's all there is to it! Snipcart checks your page for a specific classes. In this case snipcart-checkout tells Snipcart this is the button that should open the shopping cart when clicked. The .snipcart-items-count span is another special class telling Snipcart to update this span with the current number of items in the cart.

Adding products to the cart

Snipcart looks for another special class to discover products on your site, snipcart-add-item.

<button
    class="menuitem__cartbtn snipcart-add-item"
    data-item-id={item.slug}
    data-item-name={item.display_title || item.title}
    data-item-price={item.price}
    data-item-url={url}
    data-item-image={item.image}
    {...modifiersMap}
>

Most of this should be pretty straight forward, we're adding data-item properties to tell Snipcart what the product is. But what about that modifiersMap thing?

Snipcart custom fields

Snipcart allows you to add custom options to products, think dropdowns for size: Medium or color: Gray. To do this their API supports custom fields.

The string formatting for custom fields can be a bit confusing at first glance, but it's hugely powerful. Not only can you tell Snipcart what options are available, you can even define extra charges for specific options.

<button
  ...
  data-item-custom1-name="Frame color"
  data-item-custom1-options="Black|Brown[+100.00]|Gold[+300.00]"
>
  ...
</button>

In this case, Snipcart would give the user a dropdown option for "Frame color". The color black is free, upgrading to brown adds $100 to the product's price and upgrading to gold adds $300.

Adding custom fields in Astro

This one was a bit tricky to figure out at first, hopefully I'll help save you some time here.

I realized pretty quickly that the {...spread} operator was going to be my friend. Because Astro allows JavaScript (and TypeScript!) inside the template's --- fence, it really is just a matter of massaging the product options into an object.

const modifierMap = {
    "data-item-custom1-name": "Sauce",
    "data-item-custom1-options": "None|BBQ|Buffalo",
    "data-item-custom2-name": "Side",
    "data-item-custom2-options": "Fries|Onion Rings[+1.50]"
}

I'll leave it to you to check the full implementation in GitHub, but once we have the map of option properties it really is as simple as {...spread}ing those properties onto the <button> in Astro.

Conclusion

A huge thanks is in order here to both the Snipcart and Astro teams here. I had the easy job of tying together two excellent projects to build a completely static restaurant ordering site!

Astro + Foresty CMS

Navillus — Mon, 28 Jun 2021 00:00:00 +0000

This is a follow-up post to our Astro + Netlify CMS demo - check that one out first if you haven't read it yet!

Our go-to content solutions:@NetlifyCMS for internal projects (when we just need it to work)@forestryio for client projects (when a clean, user friendly UI is a must)@fauna (when a file based CMS just won't cut it)

What tools are you always reaching for?
— Navillus (@navillus_dev ) June 20, 2021

Every CMS has it's benefits and best uses, but it's rare that we have to reach outside these three tools. We've already tried out Netlify CMS with Astro and, not surprisingly given how closely the Astro static site generator sticks to plain old HTML/CSS/JS, it was a breeze to get all setup. This begs the question, how does Forestry hold up to this brand new framework?

tl;dr; Check out the live demo, GitHub repo, or jump straight to the diff comparing the demo to the original Astro blog example.

The power of Forestry

Forestry CMS sits in a very special niche - a git-based CMS that is designed with non-technical users in mind. Being git-based, it allows for an extremely simple developer experience.

If you're working on a Jamstack project with a statically built front end and expect most of the content updates to be done via the CMS rather than markdown directly, I can't recommend Forestry enough.

Before you ask - No, this isn't a paid post. Navillus aren't affiliated with Forestry, we're just big fans of the product.

What changes were needed

I started this demo with Astro's blog example. Let's break down the changes that were required to setup the CMS.

Moving image assets to `/public/uploads`

This one is more personal preference than anything else. Many CMS tools drop all your image assets into the same location and let you visually pick images from a gallery.

The only time I've really found it useful to separate image assets into different directories was to transform specific images depending on their use, and we won't be bothering with image optimization for this demo.

Note that this also requires updating any image references from /images to /uploads. In our case, that meant updating /src/pages/about.astro and each blog post in /src/pages/posts.

Moving authors data to markdown

The example repo includes a /src/data/authors.json file which is a basic JSON object/map of the two demo authors. This structure doesn't make as much sense for a file-based CMS.

Instead, let's store each author in a separate markdown file in the /src/data/authors directory. Later we can point Forestry to that folder, define the property types available for each author, and allow CMS users to create new authors without touching JSON.

While you're here, make sure each author's image property is pointing to the /uploads directory instead of /images.

Loading author information

This really was the only tricky bit to work out.

import authorData from "../data/authors.json";

A few different pages and templates need to load the author data, and they all expected ot find a JSON map. Now that each author has a separate markdown file we need to fix how that data is loaded.

let allAuthors = Astro.fetchContent("../data/authors/*.md");
let authorData = allAuthors.reduce((acc, next) => {
  return {
    ...acc,
    [`src/data/authors/${next.slug}.md`]: next,
  };
}, {});

What's with the src/data/authors/${next.slug}.md code? We'll be setting up Forestry soon, but one thing to note now is how Forestry handles content relationships by default.

By the end of this post you'll be able to create authors in the CMS and link an author to each blog post. That's right, this git-based CMS handles relational data out of the box! (Sorry, no table joins, it's just a git repo!)

Forestry references other CMS objects by absolute path, based on the projects root directory. In the case of authorData above, we're mapping from each author's filepath to the author's data. There are other ways you could manage the data here, but for the demo this is easier since you won't need to update the pages templates otherwise.

Setting up the CMS

This is the easy, and fun, part! Once you have the project building locally and pushed to GitHub, head over to Forestry and follow their importing walk through.

Forestry's repo onboarding process is really impressive. Once linked to your repo, Forestry walks you through the steps of defining your data types (in our case just Author and Post).

I'll leave it to you to play around with Forestry's content model settings. Take a few minutes to poke around in the different options, especially for defining different property types and data validation.

Bonus points Forestry offers live previews that run your actual dev server and give previews of content updates before publishing. I've had luck running Astro with node v14 and out of the box Forestry only offers v12. They support custom docker images from DockerHub though, go nuts and setup your own preview server!

Conclusion

Keep an eye out for a part two of this Forestry demo! I want to revisit the best way to edit the home and about pages, or create new pages for that matter, right in the CMS.

And yes, if the tweet at the top of this post didn't give it away, we'll be posting an Astro + FaunaDB demo soon enough!

Class properties in Svelte

Navillus — Fri, 25 Jun 2021 00:00:00 +0000

I've noticed an interesting pattern when a React developer gives Svelte a try - they almost immediately add a className property to their first Svelte component.

Don't get me wrong, the power of dynamically adding classes to a component can save your butt. The term className is a dodge in the JSX world though since class is a reserved word in JavaScript. Here's a quick trick to make your Svelte components feel even more like plain old HTML with a proper class property!

tl;dr; Check out the REPL example to see a working example.

First, the problem

With Svelte, you may think it's as simple as

<script>
  export let class = "";
</script>

<div {class}>...</div>

Unfortunately you run smack into the same reserved word problem - Svelte treats the script as regular JavaSript (or TypeScript) and won't allow a variable named class.

The workaround

If you're like me you probably hit this once, banged your head against the nearest wall a couple times, then moved on to the obvious fix of renaming the prop to class.

<script>
  export let className = "";
</script>

<div class="{className}">...</div>

Writing Svelte is so close to HTML that you can almost forget there's a framework at all...until you come across something like <Button className="send-btn"/>. Those four extra characters stand out like a sour thumb, flashing a big neon sign to remind you this isn't actually HTML.

There's an easy fix

<script>
  let className = "";
  export { className as class };
</script>

<div class="{className}">...</div>

That's all there is to it! Internally the property is named className, avoiding JavaScript's reserved word issue. Externally, though, the component has an optional property named class.

<button class="send-btn" />

Doesn't that just feel right? No more JSX-like className property screaming "is this React!?!"

Conclusion

React is a very powerful framework and web development wouldn't be where it is today without it. But when it comes to workarounds like renaming class to className, or camel casing CSS properties for that matter, it can feel freeing when you can move past those quirks and get back to the basics.

Astro + Netlify CMS

Navillus — Wed, 23 Jun 2021 00:00:00 +0000

I like markdown as much as the next developer, but it's easy to forget how convenient a CMS can be. For personal projects or internal tools, though, I can't justify reaching for a full headless CMS setup. Configuration takes time and, more importantly, for Jamstack sites it can be a huge time saver to have the entire CMS alongside the source code right in git.

tl;dr; Check the live demo or dive right into the code on Github.

The power of a git-based CMS

We're huge fans of the git-based CMS idea at Navillus. When the entire site is built to be deployed as a static site it really doesn't make much sense to need to pull from a remote server to load content, and you're already working in git!

Our go-to content solutions:@NetlifyCMS for internal projects (when we just need it to work)@forestryio for client projects (when a clean, user friendly UI is a must)@fauna (when a file based CMS just won't cut it)

What tools are you always reaching for?
— Navillus (@navillus_dev ) June 20, 2021

For those that follow us on Twitter, today's blog post won't be much of a surprise. Netlify CMS is the first content management tool we reach for on side projects and internal tools. It's dead simple to setup and deploy, and is deployed alongside our site as static HTML. And before you as, yes we are loading the admin panel's JS bundle from a CDN but you can actually install that via NPM if you prefer.

Before we begin

This demo is based on the excellent eleventy-netlify-boilerplate demo. If you're interested in 11ty as well, I strongly recommend you take a look at that repo to learn best practices when setting up an 11ty project!

The basic setup

Our goal today is to highlight the Astro-specific details when integrating with Netlify CMS, so I won't be diving too far into the initial setup. Check out Netlify CMS's excellent docs for adding the CMS to your own site for a quick rundown.

For this demo, I decided to load the netlify-cms library from CDN, but as mentioned in the docs, you can install from NPM instead. In that case, Snowpack will handle bundling the JS in production builds.

When including /admin/index.html and /admin/config.yml, you can simply copy those files from the docs to your Astro project's /public folder. Astro includes everything in the /public directory as static assets, for example your /public/admin/index.html file will be available when navigating to yoursite.com/admin.

Demo blog posts

First thing's first, lets setup support for blog posts.

Configuring blog posts in the CMS

Once you have the CMS and Netlify Identity all setup, it's time to start adding content. If you take a look at our demo repo, you'll see that all of the blog posts are saved to the /src/pages/posts directory.

For Netlify CMS, The key is to make sure that your config.yml is pointing to the correct folder.

collections:
  # Our blog posts
  - name: "blog" # Used in routes, e.g., /admin/collections/blog
    label: "Post" # Used in the UI
    folder: "src/pages/posts" # The path to the folder where the documents are stored
    create: true # Allow users to create new documents in this collection
    slug: "{{slug}}" # Filename template, e.g., YYYY-MM-DD-title.md
    fields: # The fields for each document, usually in front matter
      - { label: "Title", name: "title", widget: "string" }
      - { label: "Publish Date", name: "date", widget: "datetime" }
      - { label: "Author", name: "author", widget: "string", default: "Anonymous" }
      - { label: "Summary", name: "summary", widget: "text" }
      - { label: "Tags", name: "tags", widget: "list", default: ["post"] }
      - { label: "Body", name: "body", widget: "markdown" }

In this excerpt from the demo's config.yml, note that folder is pointing to the correct directory.

Loading and rendering in Astro

Loading local data is handled with the Astro.fetchContent API.

export let collection: any;

export async function createCollection() {
    return {
        /** Load posts, sort newest -> oldest */
        async data() {
            const allPosts = Astro.fetchContent('./posts/*.md');
            return allPosts
                .sort((a, b) => new Date(b.date) - new Date(a.date));
        },

        /** Set page size */
        pageSize: 10,
    }
}

That's really all there is to it! The fetchContent API takes care of loading all matching markdown files. I left out RSS feed support here for brevity, but you can find that in the demo repo here.

<Layout title={title} description={description}>
    <h1>{title}</h1>

    {collection.data.map((post) => (
        <PostPreview post={post} />
    ))}
</Layout>

Here the $blog.astro template is taking the data loaded above and rendering a list of post previews. If you have experience with React (or JSX) this will feel very familiar. Brackets {} are used to escape plain old JS into the template, mapping over the posts loaded in data() and passing the data of to the PostPreview component.

What about individual blog posts?

Take a look at one of the sample blog posts in the demo repo. It defines the template used to render a blog post in frontmatter, just like you may have used in 11ty, Jekyll, or really any other static site generator out there.

Caveat, Astro is in beta!

Astro is still in beta and one of the big updates coming down the pipe is an update to dynamic routing. We'll skip past the routing setup for now as that may very well change in the near future, but feel free to poke around in the demo repo or ask us questions on Twitter!

I won't go into detail here on how /author/:id or /tags/:tag routes for now, but keep an eye out for a follow-up blog post once the routing APIs are finalized!

Keeping it simple with Astro

Navillus — Mon, 14 Jun 2021 00:00:00 +0000

Frontend frameworks have taken over much of the web, but the question remains - do we really need all that JavaScript in the browser?

Keeping it simple

Client-side rendering can be an extremely powerful tool, and in some cases can solve problems that are nearly impossible to solve strictly with server rendering. A vast majority of the web is pretty simple though - mostly static content with a bit of interactivity sprinkled in.

The Navillus is a perfect example. It has a mobile menu taking advantage of Svelte's excellent built-in transition, and we recently added in a dark mode toggle. That's it for interactions on our site though, the rest is entirely static.

Here's a screenshot of devtools with our homepage loaded. A grand total of ~78KB transferred, including all the HTML, CSS, JavaScript, images, and fonts. Don't get me wrong, there's more to web design and development than just minimizing bundle size, but performance matters and small wins can add up quickly.

What's the trick?

When designing our site we had performance in mind from the beginning. You may notice that we purposely don't have any images on our homepage, and the only icons used are actually taking advantage of the SVG sprites technique to load all the icons in a single file.

Just finished rebuilding https://t.co/UcT54hdIY5 with @astrodotbuild

Progressively enhanced with @sveltejs and clocking in at a whopping 12.5KB of total JS. Really digging how easy its becoming to build tiny sites these days
— Navillus (@navillus_dev ) June 11, 2021

As of last week, though, we officially swapped our site over to Astro. Why go through all that effort to trust our site with an early beta of a totally new project? Well, why not!

We didn't actually plan to go live with an Astro version of our site, expecting to kick the tires and keep an eye on the project. The build was surprisingly straightforward though, and the results don't lie.

Shipping just enough JavaScript

The main bit of JavaScript on our site is the mobile menu - we hadn't actually added the dark theme toggle yet when first starting the Astro project. We already posted about how we built our progressively enhanced menu, but the key is that we wanted to use Svelte to easily work with or without JavaScript. If the JS loads, we pull in Svelte's slide transition to nicely animate the menu in and out.

With Astro, we can build 98% of our site with little more than HTML templates and markdown while adding in a tiny amount of JavaScript to improve the experience. No client side routing, no frontend framework dynamically rendering the page, no hydration issues or content flickers.

Note: Astro isn't opinionated about what component library you prefer. They shipped with Vue, React, Svelte, and Preact out of the box and more are being added as you read this.

Speaking of hydration

One of the most interesting ideas about Astro is partial hydration. By default a component's JavaScript won't even load in the browser, it will only be used on the server. That's not always enough though, and Astro gives you a few options for how to load it on the client.

<Component:load />
<Component:idle />
<Component:visible />

Say it's a component that really needs to be available as soon as possible, just tack :load onto the component and it will be loaded on the client when the page loads.

Maybe the component is common but not needed immediately, adding :idle instead will tell Astro to wait for the browser to initially load the page and go idle before pulling down the component, boosting performance on initial load.

They have you covered for components further down the page too, :visible will take advantage of the IntersectionObserver API to only load the component if a user scrolls down to it. This might be useful for a contact form at the bottom of a marketing page where you need custom JS validation logic but don't want to risk any performance hiccups when every conversion matters.

Coming soon to an Astro near you

<Component:media ="(min-width: 40em)"></Component:media>

This is only a proposed feature still open on Github and the syntax may very likely change, but the concept here will be a huge win.

Take our mobile menu again. We're using :idle to allow our whole page to load before enhancing the menu, but on desktop that menu is never even used. With :media or similar we could make sure that the menu's JS is only loaded on mobile viewports, why even both loading it?

Wrapping up

Keep your eye on Astro, follow their Github repo (or star it if you prefer), and check out the community Discord linked on their homepage to give feedback and share your ideas for the future of Astro!

The power of Svelte actions

Navillus — Thu, 03 Jun 2021 00:00:00 +0000

Svelte does an excellent job of blurring the lines between frontend frameworks and plain old HTML/JS. Leaning on Svelte's reactivity model, property binding, and event directives will get you 99% of the way to a finished app, but every once in a while you just really need to work directly with the HTMLElement.

This can be done in a one-off way with the bind:this approach to getting a local reference to a DOM element, but there's a better way. The use: directive allows for reusable logic to be pulled out of the component itself.

Let's take a look at a really common use for this - listening for clicks/taps outside an area of the UI. I used this recently for Kamfly's modals, instead of adding a one-off click listener in the Modal component I created a clickOutside action that can be reused elsewhere. This can also help make testing a whole lot easier, testing the async nature of a full blown Modal component can be tricky, testing just the action itself is much less complicated!

tl;dr; Check out the final example in this Live REPL demo.

Svelte actions

Svelte's official tutorial has an excellent walk through of what actions are, but basically you can think of actions as lifecycle hooks for DOM elements themselves. An action works much like onMount or onDestroy, but actions are tied to DOM elements themselves rather than entire Svelte components.

Why bother with actions?

It's easier to reach for bind:this when the component you're working on needs to interact with a DOM element. I won't jump into the DRY design principles debate, instead just look at the testing challenges.

Many projects end up needing a modal at some point, and they're almost always ignored in automated testing. When the component itself is responsible for hiding/showing the modal, managing a stack of multiple open modals, etc. the logic gets tricky fast.

Testing asynchronous behavior like animations or modals hiding/showing based on user input can be a chore. What if you could move some of that logic out to a reusable function?

Anatomy of an action

action = (node: HTMLElement, parameters: any) => {
    update?: (parameters: any) => void,
    destroy?: () => void
}

That's really all there is to it! An action in Svelte takes in the DOM element and (optionally) user defined parameters. The action function can run initialization logic on the element before returning update and destroy handlers (both optional).

`use:` clickOutside

Let's look at a really common UX pattern - a modal is open on screen and you want it to hide when the user clicks/taps outside the modal (often on some kind of grayed out background).

This isn't a big deal to do in the Modal component itself - add an extra DOM element for the grayed out background and add a click handler to it. But what if you want a similar interaction for your mobile menu? That component is almost certainly different, if you copy the code over now you have duplicated JS in your site and you need complicated test coverage testing the close functionality for both components.

The clickOutside action

export default (node, _options = {}) => {
  const options = { onClickOutside: () => {}, ..._options };

  function detect({ target }) {
    if (!node.contains(target)) {
      options.onClickOutside();
    }
  }
  document.addEventListener("click", detect, { passive: true, capture: true });

  return {
    destroy() {
      document.removeEventListener("click", detect);
    },
  };
};

There's a few things going on here, let's break that down.

First, the action is taking in optional parameters (_options). The action expects options.onClickOutside to be a callback function, if one wasn't provided it's defaulted to a noop function.

The detect function does the real work of checking to see if a click event on the page was inside the original DOM element. The event listener is using passive to avoid scrolling performance issues, and capture to make sure that all clicks bubble up to the listener.

Finally, the action returns a destroy callback that will clean up the event listener when the element is being removed from the DOM.

Allow components to whitelist elements to ignore

export default (node, _options = {}) => {
  const options = { include: [], onClickOutside: () => {}, ..._options };

  function detect({ target }) {
    if (
      !node.contains(target) ||
      options.include.some((i) => target.isSameNode(i))
    ) {
      options.onClickOutside();
    }
  }

  /** Same as above */
};

A little extra functionality here allows components to pass in other DOM elements that should be considered as "inside" the action (rather than "outside").

How to test it

UI testing will be a topic for another day, but you can see how much easier this will be to test. Instead of having to write tests that can reliably wait for a Modal component to animate into view before testing the click away scenario, tests could work more closely to the REPL demo (below). DOM elements for a test wouldn't need to animate at all, they just need to accept a click event so the test can count how many times the onClickOutside handler was called!

Live REPL demo

That's all, folks! Check out the Live REPL demo for a working example.

Introducing chisel.css

Navillus — Wed, 02 Jun 2021 00:00:00 +0000

Have you ever really tried rendering some HTML without any CSS? It's a hot mess! Modern browsers are operating systems unto themselves these days - I don't envy anyone who has to sift through the complexity to add even a basic feature to a browser these days. But damn do I wish they would add spend a couple days to ship some decent looking default styles for HTML5 elements!

Enter chisel.css

Yes, it's another CSS framework. No, we don't want to see it being used for the next 10 years. If we have our way, chisel.css will make clear just how easy it could be to have modern designs with out-of-the-box HTML elements.

We've included the most common browser resets, similar to normalize.css or sanitize.css, along with modern styling based on CSS custom properties.

Why the name?

Ask any woodworker that's dabbled in hand tools and fine joinery what tool they'd keep if they could have only one, it'd be the chisel. Most people never even think about it, but when it comes down to it almost every tool used on wood is basically just a chisel anyway.

Take a close look at a saw (be careful!). See all those tiny chisels we call saw teeth? Now look at a drill bit - yep, it's pretty much a chisel blade twisted around a stick.

We realized we kept starting with the same basic CSS resets and element styles for virtually every Navillus project, after pasting it a half dozen times we figured it was time to standardize. The project quickly took aim at building one CSS framework that can be a complete reset for both browser vendor issues and horribly styled HTML elements.

Change a few variables here and there, but the goal is for chisel to help every site look good without immediately, ready for your throw in your custom CSS (or wrap a chisel around a stick if you still can't find that damn 3/8" drill bit).

How to use it

Check out the docs for full details, but it really is as simple as

npm i -s chisel.css

or from a CDN

<link href="https://unpkg.com/chisel.css" rel="stylesheet" />

Minified and compressed the entire bundle is ~3.2KB, with full support for dark mode and basic app theming.

Eating our own dog food

We recently updated navillus.dev to use chisel as a basis for styling, you can see the complete pull request on GitHub. I'm always a fan of seeing a pull request full of red, gotta love code cleanup!

Granted we're a bit biased here, most of the common CSS we copy into every Navillus sites made it's way into chisel. The power of CSS variables lets you make some pretty drastic changes though, with very little effort.

Want a different primary color? No problem, change --chisel-primary and you're all set. Prefer a different type scale? That's simple too, check the docs for our variables like --chisel-h1 or --chisel-p.

Dark theme

Dark theme support is one that gave us more headaches than expected. We wanted chisel to support both browser's native prefers-color-scheme as well as a fallback option. We landed on a custom HTML data property, data-chisel-theme. In the future we plan to ship predefined color palettes that will also take advantage of the HTML dataset property.

So what went wrong? If you take a look at v0.4.0, we added custom CSS properties for component-level styling similar to --chisel-button-bg. This worked great for making it simple to custom style buttons, say if you want a button variant like .button-hollow. Each component property defaulted to one of the main color palette styles, a la --chisel-button-bg: var(--chisel-primary).

There in lies the problem.

At least on some browsers, CSS variable scope isn't always what you'd expect.

[data-chisel-theme="dark"] {
  ---chisel-primary: #002244;
}

You'd think this would also update any CSS properties referencing this variable. Nope! If --chisel-button-bg is only defined on the :root scope it isn't necessarily going to be updated to the new color code. This seems like a bug to me, and I have it on my list to dig through the spec to see if that's actually expected behavior, but in the meantime we will avoid it.

Yes, we could use component variables if we redefined --chisel-button-bg in the dark theme selector as well. That'd lead to way to much bloat and extra CSS though, it wasn't worth the extra KB.

WIP

Chisel is still very much a work in progress. Head over to the GitHub repo to file bugs, request new features, and star the project to follow the latest updates!

Including json+ld structured data in Svelte

Navillus — Mon, 17 May 2021 00:00:00 +0000

Ever wonder how Google search results include shopping results for products, or location results for local businesses? Their search bot is constantly being improved to better find that kind of content on your site, but ultimately if you care at all about SEO on your site it's important to include structured data on the page.

Structured data allows you to give search bots scrubbing your page a helping hand by adding metadata that describes your business, product, or even your blog posts.

JSON+LD is a lightweight specification for including structured data as a simple JSON object, something we're all comfortable with in the frontend world.

tl;dr; Check out this Svelte REPL example for a working example in JS. Keep reading to get full TypeScript validation for your Schema objects!

JSON+LD by example

Let's take a look at a basic example first. I pulled this straight from the JSON-LD Playground - it's an excellent reference for quickly messing around with the different schema and data types.

{
  "@context": "http://schema.org/",
  "@type": "Person",
  "name": "Jane Doe",
  "jobTitle": "Professor",
  "telephone": "(425) 123-4567",
  "url": "http://www.janedoe.com"
}

Nothing crazy going on there (yet). When a search bot comes by to index a page with this JSON, it's guaranteed to find Professor Jane Doe's contact information. This contact information is probably included elsewhere on the page, say in a sidebar or page footer, but chances are the way the HTML is setup could prevent the search from connecting the link from a phone number to the person's name.

How do you include it on a page?

This is where JSON+LD really stands out compared to other structured data formats that require special HTML attributes.

<script type="application/ld+json">
    {
        "@context": "http://schema.org/",
        "@type": "Person",
        "name": "Jane Doe",
        "jobTitle": "Professor",
        "telephone": "(425) 123-4567",
        "url": "http://www.janedoe.com"
    }
</script>

Yep, that's really all there is to it. Wrap the JSON object in a script tag, mark it as a type of application/ld+json and you're all set. There's way more to the different kinds of schemas you may want to include - check out the JSON-LD docs for a much better walk through of all the details than I would ever fit into a single blog post.

JSON+LD in Svelte

The beauty of Svelte is how closely it follows standard web technologies. Components are written in a single file with a script tag for all the JavaScript, style tag for the component's CSS, and one or more HTML elements for the actual DOM elements.

While that makes authoring Svelte components a nearly frictionless experience for web developers, it can throw a wrench in the JSON+LD department. Tooling built for Svelte like the VS Code plugin, and even the Svelte compiler itself, can cause headaches if you try to write an application/ld+json script in your components.

This may very well get cleaned up in the future, but for now you'll likely run into warnings and errors related to having more than one script tag in a component. A Google search will lead you down a rabbit hole of different combinations of Svelte's @html expressions and string literals to get it to compile.

There's a much better way to do this though, and even better it can be combined with TypeScript to add extra type validations for your JSON schema objects.

Serialize your JSON+LD to a script

The first part of the magic trick is getting around issues related to parsing extra script tags in your Svelte component. This is where many will reach for some combination of {$html} and string literals.

I prefer to move this out of the Svelte component all together. With the logic in a plain old JavaScript file it can be unit tested and will never run into issues with tools trying to parse .svelte files.

export function serializeSchema(thing) {
  return `<script type="application/ld+json">${JSON.stringify(thing)}</script>`;
}

There's not much magic going on here, the function just takes in a JavaScript object and spits out the ld+json script tag for it.

Type checking with TypeScript

We'll lean on the schema-dts package for full Schema.org type definitions.

import type { Thing, WithContext } from "schema-dts";

export type Schema = Thing | WithContext<Thing>;

export function serializeSchema(thing: Schema) {
  return `<script type="application/ld+json">${JSON.stringify(
    thing,
    null,
    2
  )}</script>`;
}

schema-dts defines types for all of the different schema objects, see below for a more detailed example with an Organization object. This is a huge win, it's easy to accidentally structure the JSON wrong or have a typo in one of the property names. Setting it up to use TypeScript definitions we can make sure that our JSON objects are validated at build.

Defining our Schema.org objects

Here's the Organization object used by this very site.

import site from `$data/site.json`;

export const organizationSchema: WithContext<Organization> = {
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": `${site.url}#organization`,
  url: site.url,
  name: site.company.name,
  description: site.description,
  sameAs: [`https://twitter.com/${site.social.twitter}`],
  logo: `${site.url}/favicon.svg`,
};

Data specific to our site is pulled in from a local JSON file. This could be data exposed through a Git-based CMS like Forestry or pulled down from a headless CMS like Sanity. The important thing here is that our Organization object is defined in TypeScript, verified at build-time, and can be unit tested if you want to make sure the site.json data is hooked up properly.

What is WithContext doing? That's a clever setup from schema-dts, the top-level JSON+LD object should have a @context property. You can nest objects though, and they even have support for using an object graph format for multiple objects. Any nested objects, or every object in the graph, doesn't need @context. WithContext is a TypeScript wrapper for another type, in the example above I could have removed @context from the object and it would be a valid Organization type.

Importing into Svelte

Finally, let's add the JSON+LD into the DOM. Most of our projects end up with a LDTag.svelte component similar to

<script lang="ts">
  import { serializeSchema } from "$utils/json-ld";
  import type { Schema } from "$utils/json-ld";

  export let schema: Schema;
</script>

<svelte:head>
  {@html serializeSchema(schema)}
</svelte:head>

Multiple Svelte components on a page can inject their own application/ld+json script into the document's head. This works great with SvelteKit too, a layout or route component could inject page-level schemas.

Working REPL example

Take a look at our Svelte REPL example to see a full working JavaScript example.

DEV Community: Navillus

The power of simplicity

A bit of history

Modern web development

Does it have to be so complicated?

Long-term value

Keep it simple, stupid

What about this site though?

Innovation is amazing, just don't get stuck

Astro + Foresty CMS Revisited

Feedback straight from the source

Default media folders

Authors stored in JSON

Bonus points: Instant Previews

The New Collections API

Conclusion

Animated page transitions in Astro with Swup

Setting up the project

Prepping for swup.js

Adding swup.js

Adding transition animations

Supported scoped styles

Accessibility support

Progressively enhanced, for free!

Conclusion and next steps

Converting our site to Astro

Why we moved to Astro

Migrating from SvelteKit

What did it take to change?

What didn't work?

What about server routes?

What did we learn?

Conclusion

Astro + Snipcart

Preface

The benefits of Jamstack

Enter Snipcart

Static e-commerce with Astro

Loading the menu data

Adding the shopping cart button

Adding products to the cart

Snipcart custom fields

Adding custom fields in Astro

Conclusion

Astro + Foresty CMS

The power of Forestry

What changes were needed

Moving image assets to /public/uploads

Moving authors data to markdown

Loading author information

Setting up the CMS

Conclusion

Class properties in Svelte

First, the problem

The workaround

There's an easy fix

Conclusion

Astro + Netlify CMS

The power of a git-based CMS

Before we begin

The basic setup

Demo blog posts

Configuring blog posts in the CMS

Loading and rendering in Astro

What about individual blog posts?

Caveat, Astro is in beta!

Keeping it simple with Astro

Keeping it simple

What's the trick?

Shipping just enough JavaScript

Speaking of hydration

Coming soon to an Astro near you

Wrapping up

The power of Svelte actions

Svelte actions

Why bother with actions?

Anatomy of an action

use: clickOutside

The clickOutside action

Allow components to whitelist elements to ignore

Moving image assets to `/public/uploads`

`use:` clickOutside