DEV Community: Ryan Wood

Blast off! Astro 2.0 Has Arrived 🚀

Ryan Wood — Wed, 25 Jan 2023 05:33:21 +0000

Today (1/24) the Astro team announced the official release of version 2.0 of the framework. If you haven't used, or heard of Astro, it's a web framework used to build fast, content-focused websites. Astro implements islands architecture. This means that JavaScript is only shipped to the client when absolutely necessary. With this, Astro makes it easy to build performant sites, either Static or SSR, and still have interactivity where needed through islands. There are plenty of other benefits like accessibility, SEO, and more. That's another story for another time.

Enough about what Astro is though. Keep an eye out for another article about using Astro. Until then, check out the Getting Started Docs. If you're already using Astro you can check out the Migration Guide.

What's New 🆕

Astro already provides phenomenal DX that makes creating Static or SSR websites with ease. Simply build your site the Astro way, add islands with the framework/library of your choosing, add an adapter for the platform you plan to deploy to, and deploy. With Astro 2.0 there are some great improvements to further improve the DX of building with the framework.

Content Collections 🗂

Astro allows you to use Markdown and/or MDX to write your content. With the new Content Collections API you group your collections under the src/content directory. This allows you to better organize your content, make your content in the collections type-safe, and validate frontmatter. While you may have already been organizing your content in a similar way before, those last two points are a massive gain. You no longer have to go searching for the source of an error where you may have misspelled something in your frontmatter.

Hybrid Rendering 🏆

For me, and I'm sure for many others, this is a stellar (insert rimshot GIF here) addition. Now you can determine which pages are Static (prerendered) and which are SSR. This is something I really enjoy in SvelteKit and it has now been added here as well. Simply add export const prerender = true to the routes that you want to be Static and those routes will be rendered during the build rather than on the server. Let's say that you have an e-commerce site with a store and an about route. You may want to prerender your about route since it likely doesn't change, however you'll want your store to be SSR so your users can check out your cool new items as soon as you add them. With Hybrid Rendering, this is now an extremely simple task.

Improved Error Overlay 🧯

With the new and improved error overlay you get more information about errors, links to help you resolve the error, and the ability to click a button to open your code in an editor of your choosing.

And more...

There are more improvements included as well, such as:

Update to Vite 4.0
Dev Server Optimizations
& Public Roadmap

Wrap It Up 🎁

Astro was already pretty impressive, and with this latest release continues to be even more impressive. As I mentioned previously, stay tuned for my series on creating a site with Astro. In the meantime, check out the official Astro 2.0 blog post for more information and links, and go build something cool with Astro!

Private vs. Public (Part 3)

Ryan Wood — Wed, 09 Oct 2019 03:52:28 +0000

The new module system for Sass allows for certain members to be private, while others may remain publicly exposed for consumption.

This pertains mostly to library authors but this can also be wildly useful to allow developers to consume libraries, but also have the ability to adjust configurations.

Library authors can now make their helpers and members private which may cause catastrophic issues when edited, and expose public configurations for those members that should be configurable. This comes in extremely handy when working with CSS UI and utility libraries.

Public

I created a CSS utility library (fulcrum-css) that allows developers to add simple adjustments to elements, add spacing, and provides a grid built with flexbox to control layouts. The aim being to keep code dry and give the markup meaningful and identifiable class names. The grid is currently based on a 12 column system to make it easy to transition from something like Bootstrap to this smaller utility library for your project. Wouldn't it be nice if the developer could decide the number of columns that they would like to use, and pass that to the configuration of the grid though? Previously you could declare your config variables with !default and as long as you declared that variable prior to the import with the default variable your declared value would be used. You should still use !default when declaring your variables, but let's take a look at how this would work with the new @use rule.

Public members for configuration:

Here are a few config variables that are used with this grid implementation:

What happens if we want a grid that only has 6 columns:

How to solve this with @use:

You can also do this with a namespace that you provide:

Private

By using the @forward rule, library authors can decide what is able to be exposed from one module to another. If you want to allow a stylesheet to consume and imported sheets members but not allow access to them from the importing stylesheet, you simply do not forward them.

First let's take a look at how to forward members of an imported module:

Doing this would allow the members from the colors and typography modules to be accessible to any stylesheet consuming this module. It is important to note that @forward does not create a namespace, however when importing this sheet you can access the forwarded members with the consuming modules namespace:

Here the base-config module allows access to the colors modules members because they were forwarded from the base-config module. If you do not want to allow this, and would like to simply not forward the colors module:

Since we are no longer exporting the colors module, if we try to access the $yellow member through the base-config module:

We end up with this error:

Another way to create private members is to hide them in the @forward rule:

This will keep the $yellow variable private, but still expose all the other members:

This functionality helps library authors keep their utilities private, while also allowing them to expose public members so that the consuming application can adjust configurations provided by the author. This creates a much more robust platform for configurations when it comes to working with libraries, and I already have tons of ideas on how to improve mine with this!

If you would like to see more in this series, drop a comment and tell me what you would like to know. I will do my best to get back to you, and add to this if the demand is high enough. If you would like to learn more about fulcrum-css, the utility library I created, install it with NPM and kick the tires of it. If you like it, give it a star on github. If you hate it, or see something that could be added to it, feel free to open an issue regarding your feature request/comment. This library does not currently utilize the new Sass Module System but I will undoubtedly be moving it over to this shortly. I'm also working on getting a robust set of documentation for this library set up, so bear with me and if you have questions on how to use it drop me a message.

Namespaces (Part 2)

Ryan Wood — Wed, 09 Oct 2019 02:56:08 +0000

Namespaces

Avoiding name collision

@import: With this rule, using simple would almost guarantee that there was a possibility of these names being used elsewhere in the application, which would cause value re-declaration by those used further down in the cascade. This forced developers to create names that were overly complex and not always correlative to what they were tied to.
How @use solves this: This rule, as previously mentioned, creates a namespace for the members that it brings in. This means that the same name can be used since it is part of a different namespace. Say you have a light theme and a dark theme. These themes each have different blue colors that they use. With @import you would likely have to name these something like $lightThemeBlue and $darkThemeBlue. This doesn't seem so bad right? But what if you have a white-label product that has many themes that need to each have different blue colors. This could cause these names to get wildly out of control. With the new @use rule, you can just name these $blue in each theme module, and when imported it will be prefixed with a namespace that will ensure that you are getting the correct blue for that theme.

Let's take a look at how this works
First we have 3 theme files

Here is what will happen with the @import rule

Using the @import rule, members with the same name will always evaluate the the member that has been imported last.

Here is how the @use rule solves this problem

Using the @use rule, members with the same name are scoped to a specific namespace. This allows the same name to be reused in different sheets without overriding when multiple sheets are imported with the same member name. This means that you don't have to get creative with member names and reduce their correlative meaning to the property that they represent.

We can even go a step further and change the namespace to something more concise!

Using the @use 'sheet' as name; syntax, you can provide a custom namespace to the members of that sheet. This allows you to keep your file names meaningful, but reduce the size of the namespace by providing an alias for that sheet.

You can also provide the * top-level namespace to make members available without having to prefix with a namespace.

This can be useful for sheets that you maintain and do not want prefixed with a namespace.

NOTE: Only one top-level namespace can be provided, otherwise the compiler will throw an error:

Will produce this error:

Similarly, if you try to use the same provided namespace an error will occur:

Will produce this error:

With just this simple overview it is very easy to see that you could come up with wildly elaborate themes without having to come up with crazy names just to avoid collision.

In the next part (Part 3) we will take a look at how to manage private and public members and imports.

Overview (Part 1)

Ryan Wood — Wed, 09 Oct 2019 02:52:15 +0000

(This is my first article...so cut me some slack)

Recently while doing some research for a problem I had, I stumbled upon something that took me by surprise. Sass is removing support @import in favor of @use! I was amazed that I had not seen anything mentioned outside the Sass documentation, so naturally I started doing a little more digging.

What is `@use`?

Well, it is part of the new Module System that was launched by the Sass team on October 1st 2019. The goal of this new at-rule is to address some issues that have been caused by the current @import rule when importing "modules" in Sass. Let's first take a look at some of the issues caused by the @import rule and how it will be solved by @use.

Globally available imports

When including modules with @use, those member names are only available in the stylesheet that they are included in. With the @import rule, the member names are available to every other stylesheet downstream of it's inclusion.

Imports using `@import` are executed and included every time

When a stylesheet is imported multiple times that is how many times it will be included in your project. When importing with @use, these sheets are only included and executed once.

Private members

Any members which begin with - or _ are considered private and are only available to the styleshee that they are included in with @use. This was not available with @import at all. Imported utilities with @use can be kept private even when other stylesheets import the sheet using those utilities. This is handled with the new @forward rule included with the new module system.

Styles using `@extend` are contained

Styles applied with @extend are only applied to the stylesheet it imports and not stylesheets that import it.

Built in modules

With the new module system, the Sass team is also removing global functions and replacing them with built-in modules. This is similar to built-in module usage in Node, Python, etc. These built-in modules are:

sass:math
sass:color
sass:string
sass:list
sass:map
sass:selector
sass:meta

These built in modules will have similar functions to the current global functions, however some of the implementations will be a little different. The biggest change here is that in order to use these functions, the built-in module will need to be included with @use where it needs to be executed.

What does this mean for current projects with `@import`?

Currently the @use rule is available in Dart Sass v1.23.0 only. It is not yet available with LibSass (which also means no Node Sass implementation) or Ruby Sass (which has reached its EOL anyhow...RIP 💀). This means that if you would like to start testing out the @use rule, you will need to convert your project to use Dart Sass if it does not already. I mostly work in Angular, and since the v8.0.0 release Angular now uses Dart Sass, where before it was just an option. Dart Sass is also the primary implementation of Sass, which means if you want all of the shiny new features you should make the switch. Outside of that, the only hiccup that I ran into is that the extensions I use in VSCode do not currently know how to handle the @use (and subsequently the @forward) rules when written in the editor.

For larger projects this can be quite the undertaking to switch all of the import statements to utilize the new @use rule. Never fear, you can install the sass-migrator package from NPM which will help do some of the heavy lifting here.

There is also plenty of time to do this so that you can slowly switch over your imports to this new module system over time. The Sass team has made it clear that they have taken into consideration the effort that would be needed to change products over to this. The new module system is backwards-compatible between @import and @use, and nothing has been deprecated or removed just yet. According to their recent blog post here is the timeframe and/or criteria that needs to be met prior to deprecation and removal of the current system:

Deprecated: This will be done after @use has been supported in Dart Sass and LibSass for one year or two years after Dart Sass launches support for @use (which it has). This will happen no later than October 1st, 2021.
Support dropped and/or removed: This will happen one year after deprecation goes into effect. This will occur no later than October 1st 2022.

This means that there will be, at the very least, two to three more years of support for @import to be used alongside @use while you convert your applications over.

How to implement the `@use` rule

In the next few parts we will take a look at how @use solves some of the issues that exist with @import and provide some more functionality and control when working with modules.