DEV Community: Zell Liew 🤗

Making a nice neon button

Zell Liew 🤗 — Tue, 17 Oct 2023 00:00:00 +0000

When I was building the Magical Dev School website, I accidentally stumbled on a way to make Neon buttons look good.

There are three important elements:

A little bit of glow around the text
A larger glow around the button
A nice zoom effect

Making the text glow

The trick here is to use drop-shadow instead of text-shadow to create the glow effect.

drop-shadow works better because it creates a softer and more enveloping blur - very much like how a soft light source would fall into its surroundings.

text-shadow is too harsh.

We only want to use drop-shadow on the text, so we need to change the markup a little bit to include an extra span element.

<button>
  <span class="text">Text goes here </span>
</button>

And we can include the drop-shadow like this:

.text {
  filter: drop-shadow(0 0 1px currentcolor);
}

Making the larger glow around the button

We can make a larger glow around the button with drop-shadow and box-shadow. In this case, I prefer box-shadow over drop-shadow because I can control the spread.

This lets me cast a harsher shadow that accentuates the border.

The code for drop-shadow is simpler because you can attach it directly to the button.

button {
  filter: drop-shadow(0 0 1rem var(--purple-300));
}

The code for box-shadow is slightly harder because you'll have to use a pseudo-element to make smooth animation. That's because transitioning box-shadow creates jank.

button {
  position: relative;
  z-index: 1;
  /* ... */
}

button:after {
  content: '';
  position: absolute;
  z-index: -1;
  inset: 0;
  border-radius: inherit;
  opacity: 0.6;
  box-shadow: 0 0 1em 0.5em var(--purple-300);
}

A nice zoom effect

The third and final piece is to jell everything together with a little bit of animations.

Here, I opted to:

Change the background-color
Change the color
Make the button bigger (as if it's floating outwards)
And make the background glow a little bit stronger by changing the opacity

Codepen Link

Here's Codepen for you to play around with this neon button.

By the way, this article is originally written on my blog. Feel free to visit that if you want to have these articles delivered to your email first-hand whenever they're released! 🙂.

Splendid Astro Spacing — A Tailwind Utility for Astro

Zell Liew 🤗 — Tue, 03 Oct 2023 00:00:00 +0000

When using Tailwind with Astro, you’ll notice that Tailwind’s space utilities stop working when you use it with Astro Components or Slots .

<!-- Doesn't work when using with Astro components and slots -->
<div class='space-y-4'>
  <Component client:load />
  <Component client:load />
</div>

The reason is simple. I’ve wrote about the cause in a previous article and how to fix it.

You can read that article for more information, but the gist is:

Astro components and slots wrap it’s contents in a div that has display: contents
The * + * selector, which Tailwind uses for its space utilities, cannot target the elements within these Astro components and slots

A simple fix

Fixing this is simple. We just have to modify Tailwind’s space utilities with a plugin — so they can dive one level beyond Astro’s components and slots.

I’ve created this plugin and added it as part of Splendid UI. You can install it Splendid UI like this.

npm install splendid-ui

Then you can use the plugin in your Tailwind config file like this:

module.exports = {
  plugins: [require('splendid-ui/tailwind/plugins/astro-space.cjs')],
}

(I know the path looks long and complicated right now. It's something I'll simplify in the future as Splendid UI becomes more mature. For now, just enjoy something that works! 🙃).

That’s it!

Easy caching on the local file system with Node

Zell Liew 🤗 — Tue, 26 Sep 2023 00:00:00 +0000

Today I want to introduce you a utility that will make caching in the local file system extremely easy.

This utility is called fileCache and it’s built into Splendid UI.

npm install splendid-ui

To use the utility, import fileCache from Splendid UI.

Give it a directory and a file name.

The directory determines where to store the cached file.
The file name determines the name of the file.

import { fileCache } from 'splendid-ui/node'

const cache = await fileCache({
  dirname: '.cache',
  file: `${id}.json`,
})

When you want to save values into the cache, just use the save method. Values will automatically be converted into JSON.

const objectToSave = { some: 'value' }
await cache.save(objectToSave)

When you want to load the cache, use the load method. This method returns a promise.

cache.load()

Invalidating the cache

fileCache returns the file's modifiedAt timestamp. If you're familiar with Node, this is the mstimeMs value you get from fs.stat.

You can use this modifiedAt timestamp to check whether you want to invalidate the cache.

function getValues () {
  const cache = await fileCache(/* ... */)
  const Date = new Date()

  // Load the cache
  if (cache.modifiedAt > Date.now() + 10000) {
    return cache.load()
  }

  // Otherwise, create the cache
  const obj = { some: 'value'}
  await cache.save(obj)
  return obj
}

Invalidating the cache when other files change

It's more common for cache files to be created with the content from other files. In this case, if these source files change, you will want to invalidate the cache.

It's easy to do this with the getLastModifiedTime utility from Splendid UI.

getLastModifiedTime returns the last modified time from a list of files. You can use this to decide whether to invalidate the cache.

It takes in a glob value so you can specify all the files you want to check. This process is extremely quick so you don't have to worry about checking lots of files at once.

import { getLastModifiedTime } from 'splendid-ui/node'

// Gets the latest modified timestamp of all the files in src/content
const lastModified = await getLatestModifiedTime('src/content/**/*')

If the latest modified timestamp exceeds that of the cache, you can invalidate the cache and generate a new one.

The process looks like this:

import { fileCache, getLastModifiedTime } from 'splendid-ui/node'

function getContent () {
  const cache = await fileCache({ /* ... */ })
  const lastModified = await getLatestModifiedTime(`src/content/`)

  // Load the cache
  if (cache.modifiedAt > lastModified) {
    return cache.load()
  }

  // Otherwise, create the cache
  const obj = { some: 'value'}
  await cache.save(obj)
  return obj
}

That's it!

zlFetch now supports FormData!

Zell Liew 🤗 — Tue, 19 Sep 2023 00:00:00 +0000

"Now" is grossly inaccurate because zlFetch has supported Form Data since v5.0 (since April) and we’re already at v6.0 🙃.

Nevertheless, let me share with you what this is all about.

How `zlFetch` supports Form Data

You can now pass Form Data content into zlFetch and it will correctly send a multipart/form-data encoding to the server.

form.addEventListener('submit', async event => {
  const data = new FormData(form)

  const response = await zlFetch('some-url', {
    body: data,
  })
})

This is similar to the rest of our API where zlFetch automatically helps you set the Content-Type header:

If you pass in an object, it converts the data into JSON and sends an application/json content type.
If you pass in a string, it uses the application/x-www-form-urlencoded content type.

Problems with Form Data

I’m not a fan of using Form Data because of two reasons:

The backend needs to support it
You can’t tell what’s inside a Form Data easily

The backend needs to support it

Form Data is more complicated than json or x-www-form-urlencoded data because it can be sent in multiple parts.

In express, you can support Form Data by adding the multer package.

import multer from 'multer'
const upload = multer()
app.use(upload.array())

Most of the time, I prefer to send JSON since there's no need to use multer and mess with multipart/form-data.

It’s harder to debug Form Data

You can’t see what’s inside a Form Data easily. If you want to see the contents, you have to loop through the form data and log each entry.

const data = new FormData(form)
for (const key, value of data) {
    console.log(key, value)
}

This is way too complex for my liking. I prefer to use an Object and see everything at once.

Converting Form Data into an object

Because I like working with objects more than Form Data, I included a utility in zlFetch that lets you convert Form Data into an object.

With this, you no longer need to extract each form element individually. Just use the utility and it’ll handle the data for you.

import zlFetch, { toObject } from 'zl-fetch'

form.addEventListener('submit', async event => {
  const formData = new FormData(form)
  const data = toObject(formData)

  console.log(data)
})

You can then send this data as JSON over to the server like this:

import zlFetch, { toObject } from 'zl-fetch'

form.addEventListener('submit', async event => {
  const formData = new FormData(form)
  const data = toObject(formData)

  const response = await zlFetch('some-url', {
    body: data,
  })
})

I also added this utility into Splendid UI 🙃. So you can tell that I’m putting lots of helpful things into Splendid UI as I go along.

It’s gonna be one of the best component libraries around. I’ll share more about Splendid in another post.

Speaking about utilities, I've created another utility to it easy to send form-urlencoded data.

Utility for form-urlencoded data

zlFetch contains a toQueryString utility that can convert an object into a query string.

This makes it easy to send x-www-form-urlencoded data.

import { toQueryString } from 'zl-fetch'

zlFetch.post('some-url', {
  body: toQueryString({ message: 'Good game' }),
})

Behind the scenes, this is a simple utility since we're just passing the object through URLSearchParams 🙃. But hey, it's good to have this utility since it makes things a little bit simpler than before!

export function toQueryString(object) {
  const searchParams = new URLSearchParams(object)
  return searchParams.toString()
}

That's it for today!

Limitations of Scoped CSS

Zell Liew 🤗 — Tue, 12 Sep 2023 00:00:00 +0000

I was really excited about Scoped CSS a couple of years back when frameworks like React and Vue introduced them.

As I began trying Scoped CSS out for myself, I was disappointed and I felt it didn't live up to its hype.

But after more tries, I'm happy to announce that Scoped CSS is indeed useful. You only have to realize what its limitations are and what to do when you face these limitations.

I’m not talking about the native CSS :scope

Before you continue further, I want to make sure we’re talking about the same thing.

In this article, I’m talking about Scoped CSS that can be found in major frameworks like React, Vue, Svelte, and Astro.

I’m not talking about the native CSS :scope. You can find out more about that here.

The premise of Scoped CSS

Scoped CSS was one of the biggest features that frameworks provided us with. It promises to restrict the scope of your CSS, so your CSS would not leak into other components.

The limitations of Scoped CSS are…

You cannot style children components
You cannot style slot content

Now let’s see what I mean by these limitations.

You cannot style children components

From my experience, Scoped CSS in all frameworks behaves in the same manner. So I'm going to use Svelte here to illustrate my point.

Let's say I imported a SVG component and I'd like to style the SVG from a Menu component.

<script>
  import SVG from './SVG.svelte'
</script>

<div class="Menu">
  <SVG />
  <span>Menu</span>
</div>

The SVG component simply contains the SVG and nothing more.

<!-- SVG component -->
<svg>...</svg>

If I try to style the SVG from the Menu component, the styles will not be applied.

<!-- Menu component -->
<style>
  .Menu svg path {
    stroke: red;
  }
</style>

And I'm forced to use the global or the global selector to style this SVG.

<!-- Global attribute -->
<style global>
  .Menu svg path {
    fill: red;
  }
</style>

<!-- Global selector -->
<style>
  :global(.Menu svg path) {
    fill: red;
  }
</style>

The Global Attribute

The global attribute negates scoped CSS and allows the entire style block to act like Normal CSS.

<style global>
  .Menu svg path {
    fill: red;
  }
</style>

Using the global attribute isn't a great practice because you might as well write Normal CSS instead.

By the way, if you use Astro, the global attribute is a directive and not an attribute.

<style is:global>
  …
</style>

The Global Selector

The :global() selector allows you to expose the values wrapped inside it to the global scope.

<style>
  :global(.Menu svg path) {
    fill: red;
  }
</style>

If you want to keep .Menu in the local scope, you can use :global only on the rest of the selectors.

<style>
  .Menu :global(svg path) {
    fill: red;
  }
</style>

This is nice.

But there's a huge problem.

The global selector cannot be used in the middle of the selector chain. So this doesn't work.

<style>
  /* These don’t work */
  .Menu :global(svg) path { … }
</style>

Because the global selector cannot be used in the middle of the selector chain, nesting doesn't work as well.

<style lang="“scss”">
  /* This doesn’t work */
  .Menu :global(svg) {
    path { … }
  }
</style>

This gives Scoped CSS a big minus point in my world.

You cannot style slot content

Scoped CSS is also limited when you have to style slot content.

For this, let's say we have an <Article> component and we are going to pass the contents through a <slot>.

<article class="Article">
  <slot />
</article>

We'll use <Article> like this.

<script>
  import Article from './Article.svelte'
</script>

<article>
  <h2>This is a header</h2>
  <p>This is a paragraph</p>
</article>

If you try to style the slot content from Article with Scoped CSS, you'll realize it doesn't work.

<article class="Article">
  <slot />
</article>

<style>
  h2 {
    color: blue;
  }
  p {
    color: red;
  }
</style>

You need to use the global attribute or the global selector instead.

Styling Slot Content

You can use global selectors or the global attribute to style slot content.

In this case, let's go with global selectors.

Here's how I would style the slot content.

<article class="Article">
  <slot />
</article>

<style lang="scss">
  article {
    :global(h2) {
      color: blue;
    }
    :global(p) {
      color: red;
    }
  }
</style>

When you use global selectors to style slot content, pay attention to these points:

One: global must be written for every selector you wish to target. If you have to use a large number of global selectors, it may be worthwhile to write normal CSS instead:

Two: :global should come AFTER a selector (article in this case). If :global doesn't come after a selector, you'll be writing CSS into the global scope which is probably not what you want.

If you did what I just mentioned, your selectors should look somewhat like this:

Wrapping Up

Scoped CSS is a great future.

Scoped CSS can be frustrating to use when you don't know what its limitations are.

Once you know the limitations, you will be able to use Scoped CSS to its fullest potential.

Quality of life improvements for zlFetch

Zell Liew 🤗 — Tue, 05 Sep 2023 00:00:00 +0000

(Hey, we're having problems showing images in RSS right now, so if you want a better reading experience, consider viewing this article online here.

I silently updated zlFetch a couple of months ago with some improvements that make coding much easier — especially if you're using zlFetch in Node.

What is zlFetch?

Just in case you don't know about it, zlFetch is a wrapper over the native Fetch API. I've built zlFetch because I wanted to make it easier to use the Fetch API.

Now without further ado, let me talk about the quality of life improvements I've made recently.

Returning errors

zlFetch was built to catch and throw HTTP errors, so zlFetch is promise-friendly.

zlFetch('some-url')
  .then(/* do something when successful */)
  .catch(/* throw an error when unsuccessful */)

Although this pattern follows the promise spec, it can be very unwieldy when used in an async function. Typically, if you want to handle an error, you have to use a try/catchpattern.

try {
  const response = await zlFetch('some-url')
  // Do something with the response
} catch (error) {
  // Do something with the error
}

I didn't like this so I added a returnError property to zlFetch. This allows you to return the error message instead of throwing it.

Then you can use a standard if/else conditionals to write your Fetch requests.

const { response, error } = await zlFetch('some-url', {
  returnError: true
})

if (response) // Do something with response
if (error) // Do something with error

You can make it even easier by creating an instance of zlFetch with the options you want to use. More on this later.

Debug Mode

zlFetch now contains a debug mode.

This lets you know exactly what you're sending in your request — so you don't have to check the Network Panel to know what you sent over.

Just add the debug mode and you can log what you're sending over.

const { response, debug } = await zlFetch(
  'https://api.github.com/users/zellwk/repos',
  {
    query: { per_page: 100 },
    debug: true,
  }
)

console.log(debug)

Creating a zlFetch Instance

It's now possible to create a zlFetch instance that contains the options you wish to use.

You can attach a base URL you wish to use over a couple of APIs...

import { createZlFetch } from 'zl-fetch'

// Create the instance
const api = createZlFetch('https://your-api.com/api/v1')

// Using the instance
const response = await api.post('users', {
  body: {
    firstName: 'Zell',
    lastName: 'Liew',
    email: 'helloworld@gmail.com',
  },
})

...attach options you typically use...

import { createZlFetch } from 'zl-fetch'

// Create the instance
const api = createZlFetch({ returnError: true })

// Using the instance
const { response, error } = await api.post(/* ... */)

... or both!

import { createZlFetch } from 'zl-fetch'

// Create the instance
const api = createZlFetch('https://your-api.com/api/v1', {
  returnError: true,
})

// Using the instance
const { response, error } = await api.post('users', {
  body: {
    firstName: 'Zell',
    lastName: 'Liew',
    email: 'helloworld@gmail.com',
  },
})

This feature helps a lot when you have to send many fetch requests in the same file.

One great example is if you create a file to house all requests to a particular API.

Another great example is when you have to send many requests when you test your APIs. (I cover this in more detail in my Node Workshop).

Removing node-fetch as a dependency.

We have removed the node-fetch dependency in v6.0.0 since Node v17 contains the Fetch API.

You will still be able to use zlFetch as normal — nothing will change — if you're using Node v17 and above.

If you're using a legacy version of Node, we'll need you to import node-fetch into your project before using zlFetch.

That's it for today!

There are a few more qualify of life improvements that I've made, but I think this is big enough of an announcement today.

I'll talk about other features in another newsletter to come.

By the way, this article is originally written on my blog. Feel free to visit that if you want to have these articles delivered to your email first-hand whenever they're released! 🙂.

The Magical Dev School Student Portal is live!

Zell Liew 🤗 — Tue, 29 Aug 2023 00:00:00 +0000

(Hey, we're having problems showing images in RSS right now, so if you want a better reading experience, consider viewing this article online here.

I’ve been working on this for a long time and I’m happy to share with you that the Magical Dev School student portal is live!

What’s this portal about?

Earlier in February, I decided to put all my courses under a brand called Magical Dev School.

This portal is simply a place where you can access all my courses and workshops.

How to access the portal

It’s simple. Just go here and fill in your email and password.

If you have purchased the Courses, Workshops, or Everything package from Magical Dev School, you will be able to access the corresponding items you have purchased.

If you have purchased a course (like Learn JavaScript) before I consolidated everything into Magical Dev School, you will also be able to use the Magical Dev School student. portal. In this case, you'll have access to the full Learn JavaScript course in the portal.

You will also have access to free chapters of other courses and workshops if you haven't purchased them yet.

The Magical Dev School portal is pretty well designed

I want to take the opportunity to share with you a few quality-of-life improvements I’ve made for you on this platform.

They are:

Product Switcher to jump to any course or workshop easily
Breadcrumbs to show you where you’re at
Assess the lesson plan from every page
Estimated timestamps for each course, chapter, and lesson

Product Switcher to jump to any course or workshop easily

I added a product switcher in the menu so you can jump to any course or workshop easily.

This is a tentative design and I may change it as the portal matures.

Breadcrumbs to show you where you’re at

The second quality of life improvement is breadcrumbs that show you exactly which lesson you’re in.

I added this because it’s easy to get lost in the sea of lessons we have available in Magic’s Dev School.

Assess the lesson plan from every page

If you click the book icon on the breadcrumbs, you will be able to access the lesson plan for the entire course you’re viewing.

This will help you get a good grasp of where you’re at in the entire course.

You’ll also be able to jump to another lesson easily if you wish to backtrack or skip forward.

Estimated timestamps for each course, chapter, and lesson

Last but not least, I have added estimated timestamps to all courses, chapters, and lessons.

This should give you an idea of how much content there is in each course, chapter, and lesson, and therefore, how much time you may have to spend.

Note that these are just estimated reading/video times! You’ll likely spend way more time than the stated values since you may have to go through some lessons multiple times.

That’s it from me this week!

Hope you enjoy our new course portal!

If you have any questions, just reach out and I’ll get back to you as soon as I can.

By the way, this article is originally written on my blog. Feel free to visit that if you want to have these articles delivered to your email first-hand whenever they're released! 🙂.

Finding my roots in my business

Zell Liew 🤗 — Tue, 22 Aug 2023 00:00:00 +0000

(Hey, we're having problems showing images in RSS right now, so if you want a better reading experience, consider viewing this article online here.

I’ve pretended to be happy, okay, upbeat, and positive in my communications with you in the last couple of months.

Occasionally, I have also become cunning, manipulative, and sleazy in my communications (and I loathed that).

The discomfort towards my behaviours has been taking a hold of my emotional space. And it’s creating a huge depression.

I created this blog to document my journey and to help

Not to do business.

It’s a wonderful miracle that this blog somehow transformed into a viable business that had supported my livelihood for many years.

I’m still not quite sure how it happened. But one for I do know for sure — it seems to do best when I truly try to help.

But this miracle led to a series of tragedies

Twice now, I tried to go “all-in” on the business (and the blog).

Both times, I became obsessive, blinded by money, and I lose my way.

I would listen to gurus that tout what should be done, and I would even do some of these things that went against my conscience. (Like putting up a modal to grab emails, which obviously didn’t work with the smart crowd that I work with).

And since I have pretty good stamina, I would hammer away at the “work” with determination.

So far, when I do this for a prolonged period of time, I would find myself falling into depression.

I would end up not wanting to work, not because I don’t enjoy working, but because I have no idea what I’m doing anymore. (And sometimes because I became too ashamed of my actions)

It’s not pretty.

So eventually I had to stop.

I hope to find back my core

There is a reason why I continue to teach — even though it may not be the most profitable business in the world.
There is a reason why I chose to be a developer instead of a teacher — so teaching must not be everything I do.
And there is a reason why I choose to run my business instead of being employed as a developer and getting a cushy pay.

So far in my journey, I have always neglected at least one of these three elements for a prolonged duration.

Each time this happens, I would fall into depression too.

Recently, I was lucky to have found Jon Yongfook’s blog. One of his articles spoke about the idea of splitting time equally between marketing and coding as a tech founder.

When I read the article, I felt that I may have just found a path out of my depression with work — hopefully permanently.

So I’m planning to spend an equal amount of time doing three things:

Designing and coding
Marketing
Teaching

I have not decided on the ratio yet. But I’m likely going to experiment with a 1:1:1 ratio (or simply just two weeks each).

And I hope everything would fall back into place.

That’s it from me this week. Thanks for reading and have a nice day!

By the way, this article is originally written on my blog. Feel free to visit that if you want to have these articles delivered to your email first-hand whenever they're released! 🙂.

Here’s how to quickly test components that use container queries

Zell Liew 🤗 — Mon, 10 Jul 2023 00:00:00 +0000

Container queries are amazing. They let us build UI that allow a component looks good no matter what size the component is displayed at.

But this feature also makes it difficult to test container queries.

If you do it normally, you have to resize your browser many times, which can be irritating and a huge waste of time.

There is a better way.

There are two ways to make things easier

The first is to use a browser like Polypane that lets you debug multiple viewports at the same time. It costs only $9/m and it has the potential to reduce a lot of developmental headaches.

If you don't want to spend any money, the second way is to debug your components with a utility that lets you display the component in many different sizes.

Here's how the utility works

The basic idea is:

You create a series of containers at different widths.
Then you insert the component into each container.
And each container will let you see what the component looks like at that width.

You'll find the code below.

I’ve written this in Astro because I currently use Astro. But this can be reworked for React, Vue, Svelte, Nunjucks, Pug, and all sorts of frameworks and template engines easily.

---
let { containers, increment, startAt } = Astro.props

// Default options
containers = containers || 10 // Show 10 containers
increment = increment || 50 // Containers should increase by 50px each time by default
startAt = startAt || 300 // The smallest container is 300px wide
---

<div class='CQTestGrid'>
  {
    [...Array(containers)].map((_, i) => {
      const width = i * increment + startAt + 'px'
      return (
        <div style={`width: ${width}`}>
          <div class='size'>{width}</div>
          <slot />
        </div>
      )
    })
  }
</div>

<style>
  .CQTestGrid {
    display: flex;
    flex-flow: row wrap;
    padding: 1rem;

    > * {
      margin: 0.5rem;
    }
  }

  .size {
    font-size: 0.8rem;
    color: #666;
  }
</style>

Here's how you would use the utility in an actual test.

---
import CQTest from '../components/CQTest.astro'

const props = {
  containers: 10,
  increment: 25,
  startAt: 100,
}
---

<Base>
  <CQTest {...props}>
    {
      [...Array(props.containers)].map(_ => (
        <div class='“Container”'>Your component here</div>
      ))
    }
  </CQTest>
</Base>

By using this, I can make sure the component looks great all the time.

Take this out for a spin! 🙃

I hope this utility helps you reduce the problems you may face as you make the best UI you can!

By the way, this article is originally written on my blog. Feel free to visit that if you want to have these articles delivered to your email first-hand whenever they're released! 🙂.

When building components in Astro, you might not want to use Astro files

Zell Liew 🤗 — Thu, 15 Jun 2023 00:00:00 +0000

"If you're using Astro, you should build components with the astro extension".

That was my initial thought when I started using Astro. But after a couple of months building with Astro, my thinking has changed. I no longer build most of my components with astro files.

I mostly use Svelte files instead. This article explains why.

Three reasons

Reason 1: I use Svelte as my framework of choice

This reason is pretty obvious — I have to write Svelte files if I want to use Svelte!

I chose Svelte after evaluating the major three frameworks (React, Vue, and Svelte) and I found that Svelte has a better raw developer experience.

I can share more about why that’s the case, but I’ll have to do that in another blog post since that will be a long one.

Reason 2: the main reason

The main reason is this:

Astro can import framework files.
But framework files cannot import Astro files

Many commonly used components can be written in Svelte, so it can be imported into both Astro and Svelte files.

Here are some examples:

A Button component
An SVG component that searches the project for an SVG icon.

If build these components in Astro, we won’t be able to use them inside Svelte files — and this eventually forced me to rewrite these components in Svelte.

Reason 3: Better syntax

I say better syntax because I find it easier to read Svelte markup over React’s and Vue’s markup — especially when there are if statements or loops.

This might have been because I’ve been using nunjucks for a long time, so the if syntax is much easier for me to read.

Sometimes I choose to write components in Svelte precisely to take advantage of this syntax difference.

When to use Astro files

I only choose the Astro file extension for my component files when I need to use Astro’s API like content collections, which is not available in other frameworks.

What if a component requires both Astro APIs and JavaScript?

I encountered this a couple of times. When this happens, I typically do two things:

I build an Astro component that retrieves stuff I need with Astro’s API.
And I build a Svelte component that uses this information.

Usually, I would give both components the same name because it helps me remember that they are directly related to each other.

Wrapping up

Use the following guidelines if you’re deciding which extension when we build components in Astro:

Build the component in your framework of choice whenever possible
Only use Astro components when you need Astro’s API (or it’s heavily file-system related)

If you need both Astro’s API and JavaScript, feel free to build components with both extensions. Just remember to give them appropriate names so you know they’re related to each other!

By the way, this article is originally written on my blog. Feel free to visit that if you want to have these articles delivered to your email first-hand whenever they're released! 🙂.

Best practices for container queries

Zell Liew 🤗 — Wed, 07 Jun 2023 00:00:00 +0000

I've been playing around with container queries and so far, there is only one best practice that I would recommend.

Whenever you use container queries, make sure you wrap the element with a container element.

So your HTML should look like this:

<div class="container"> 
  <div class="component"> … <div> 
<div>

This container should not be the element that creates a grid in your layout.

So don’t do this.

<div class='grid container'> 
  <div class="component"> … <div> 
<div>

Do this instead

<div class="grid"> 
  <div class="container"> 
    <div class="component"> … </div>
  </div> 
</div>

Now, all three code examples above assume you’re using an unnamed container, which is sufficient for most use cases.

.container {
  container-type: inline-size;
}

There’s a reason why we need to do this

Most of the time, I would have preferred the second structure (where the grid is also the container) because I will be able to reduce the <div> soup in the HTML.

After all, who doesn’t love clean code?

But beyond the obvious benefit (more semantic-looking HTML structure), there’s a reason why we have to use the third HTML structure which I recommend.

<!-- There’s a reason why we need this structure -->
<div class="grid">
  <div class="container">
    <div class="component">…</div>
  </div>
</div>

If you use the second structure, you won’t be able to use container query units

These units will likely be inaccurate.

Consider this.

If you use the second HTML structure, your .grid will be the container.

Since your .grid is the container, container query units will be based on the height and width of the .grid. This is probably not what you want, because it can produce unintended (huge) sizes like the one you see below.

In this example, I set the image to 25cqi — which means 25% of the width of the container.

But because the .grid is the container, cqi draws from the width of the .grid (which is almost the same as the browser viewport in this case). So cqi produced an oversized image.

These blunders can be prevented if we used the HTML structure I recommend — because container query units will draw its width from the grid item instead.

Here’s the corrected version of what I was trying to create:

That’s it!

This is really straightforward and I hope this article helps you prevent making some of the blunders I made when testing out container queries 🙂

As to the real reason why I made this blunder… well I was simply trying to see if I could use :has to automatically make the parent element a container.

And from there, I encountered this error!

By the way, this article is originally written on my blog. Feel free to visit that if you want to have these articles delivered to your email first-hand whenever they're released! 🙂.

Overcoming styling frustrations caused by Astro islands and slots

Zell Liew 🤗 — Mon, 22 May 2023 00:00:00 +0000

After using Astro for a while, I came to realize that Astro's biggest features — islands and slots — both delight and frustrate me.

Most people already know what the delights are, so I won't bother writing about them in this article. I'll focus on what frustrates me and how I resolve those frustrations.

First, we need to talk about when Astro creates islands and slots.

When Astro creates islands and slots

Astro creates an astro-island tag, along with style and script tags when you include a component with client directives.

---
import Component from './components/Component.svelte'
---

<Component client:load />

If the component (with client directives) contains a slot, Astro will create an astro-slot tag. This astro-slot will be found within an astro-island.

---
import Component from './components/Component.svelte'
---

<Component client:load>
  <div>Some Slotted Content</div>
</Component>

Now, if you include a component without client directives, Astro will not create astro-island and astro-slot tags.

---
import Component from './components/Component.svelte'
---

<Component>
  <div>Some Slotted Content</div>
</Component>

What's frustrating about Astro islands and slots

Since Astro only creates these tags when you include client directives, styling components can become unpredictable — because some components will have client directives while others won't.

Problems arise when the DOM contains astro-island and astro-slots. That's because these tags change the document flow, so you cannot pretend that they don't exist.

To be more specific, I noticed four extremely frustrating things when astro-island and astro-slot are present in the DOM.

Direct descendant selectors no longer work
Lobotomized owls no longer work
CSS Grid positioning no longer works
Nth-child no longer works

I'm going to talk about each one in turn, and how to resolve these frustrations.

Direct descendant selectors no longer work

Direct descendant selectors no longer work when astro-island and astro-slot is in the DOM.

This makes sense because the DOM has changed, so direct descendant selectors no longer target the element you wish to target.

Imagine you want to have this HTML

<div class="Component">
  <div>Some Content</div>
</div>

But Astro creates this HTML because it has slots.

<div class="Component">
  <astro-slot>
    <div>Some Content</div>
  </astro-slot>
</div>

If you wrote a direct descendant selector, that selector wouldn't work. That's because the direct descendant selector now targets the astro-slot level children instead of the one you are aiming for.

/* No longer works */
.Component > div {
  /* Styles here */
}

Fixing it

Fixing direct descendant selectors with slots is simple — all you have to do is add astro-slot in the selector chain.

/* Works */
.Component > astro-slot > div {
  /* Styles here */
}

The above code snippets assume you're writing global CSS. If you're using CSS Scoped to the component, you'll have to write the following instead since we're dealing with slots.

/* Scoped CSS*/
.Component :global(> astro-slot > div) {
  /* Styles here */
}

Another alternative is simply to use descend selectors instead of direct descendant selectors if the HTML structure allows for it.

/* Works */
.Component div {
  /* Styles here */
}

Let's move on.

Lobotomized owls no longer work

Lobotomized owl is a way to style things with the sibling universal selectors. It was first coined by Heydon Pickering in 2014.

/* Lobotomized owl selector */
* + * {
  /* Your styles here */
}

The lobotomized owl selector can be used to style children elements easily — giving them margins, paddings, and other properties as necessary.

Here's an example that I commonly use to give some space between elements.

.Parent > * + * {
  margin-top: 1rem;
}

Unfortunately, these styles won't work on astro-island and astro-slot tags because they use the display: content property.

Fixing it

Elements with display: contents will have their styles ignored, so any styles added to these elements will be ignored.

The easy way to fix this is to add the styles to the elements contained in astro-island or astro-slot.

Here's what the CSS looks like.

.Parent > * + *,
.Parent > * + :where(astro-island, astro-slot) > *:first-child {
  margin-top: 1rem;
}

CSS Grid Positioning no longer works

This one is similar to the lobotomized owl one — because Astro islands and slots use display: contents, no styles will work on them.

These styles include grid-column, grid-row. So you will not be able to change the Conponent's positioning with grid-column.

Here's an example where we laid all items out in a two-column grid. In this example, trying to use set grid-column on the astro-island and astro-slots will not work.

---
import Component from './Component.svelte'
---

<div class='Grid'>
  <Component client:load />
  <Component client:load />
  <Component client:load />
</div>

<style>
  .Grid {
    display: grid;
    grid-template-columns: 1fr 1fr;
    gap: 1em;
  }

  /* Tries to make all grid items span the full width */
  .Grid > * {
    grid-column: 1 / -1;
  }
</style>

There are two ways to fix this problem.

Fixing it

The first way is to bypass astro-island and astro-slot with the technique mentioned above.

.grid {
  display: grid;
  grid-template-columns: 1fr 1fr;
  gap: 1em;
}

/* Tries to make all grid items span the full width */
.grid > *,
.grid > :where(astro-island, astro-slot) > *:first-child {
  grid-column: 1 / -1;
}

The second way is to put the components in another element.

<div class="Grid">
  <div><Component client:load /></div>
  <div><Component client:load /></div>
  <div><Component client:load /></div>
</div>

.Grid {
  display: grid;
  grid-template-columns: 1fr 1fr;
  gap: 1em;
}

.Grid > * {
  grid-column: 1 / -1;
}

Nth-child no longer works as expected

When Astro adds astro-island to the DOM, they also add styleand script tags to the DOM at the same time.

Since style and script tags are also considered children elements, you cannot depend on the nth-child selector to target the right element anymore.

Using the same code examples from above, let's say we have the following HTML.

<div class="Grid">
  <Component client:load></Component>
  <Component client:load></Component>
  <Component client:load></Component>
</div>

This produces a DOM that looks like this.

First element is a style tag
Second element is a script tag
Next three elements are astro-island tags

Astro will only include style and script tags for the components once in the DOM. This is why you see only one style tag and one script instead of 3 style tags and 3 script tags.

If you want to get the first component with nth-child, you need to pass in nth-child(3) instead of nth-child(1). That's because the first component is now the third element in the DOM tree.

/* Style the first component, but it's the third child */
.Grid > *:nth-child(3) > .Component {
  background-color: red;
}

Yes, I know it's confusing.

There are two ways to fix this confusing problem

Fixing it

The first way is to wrap the components with another element.

You can then use nth-child to style with a descendant selector to style the component.

<div class="Grid">
  <div><Component client:load /></div>
  <div><Component client:load /></div>
  <div><Component client:load /></div>
</div>

/* Tries to make all grid items span the full width */
.Grid > *:first-child .Component {
  background-color: red;
}

The second way is to stop using nth-child and use nth-of-type instead.

.Grid > astro-island:nth-of-type(1) > .Component {
  background-color: red;
}

A deeper layer of frustrations

Things get a little bit more confusing if you need to pass a component into a slot — especially if both components (the parent one and the one in the slot) need JavaScript functionality.

---
import Component from './components/Component.svelte'
import Nested from './components/Nested.svelte'
---

<Component client:load>
  <Nested client:load />
</Component>

Astro will create the following layout:

astro-island in the top level
astro-slot in the second level (since Component gets content through a slot)
Another astro-island after astro-slot since Nested needs to have JavaScript functionality as well.

I'm not sure whether this level of complexity is necessary though.

Most of the time, I just one layer of astro-island and a layer of astro-slot. So this should be an edge case more than anything else.

Wrapping up

I've just shared with you when and how Astro creates astro-island and astro-slot.

I've also shared with you how to overcome the styling frustrations that happen when astro-island and astro-slot elements are present in the DOM.

With this, you should now be able to use Astro effectively without encountering further styling issues.

Hope you find this useful in your coding journey.

If you wish to receive more in-depth articles about Astro, Svelte, and other web development topics, feel free to sign up for my newsletter below.

That's it for today. Thanks for reading!

By the way, this article is originally written on my blog. Feel free to visit that if you want to have these articles delivered to your email first-hand whenever they're released! 🙂.

DEV Community: Zell Liew 🤗

Making a nice neon button

Making the text glow

Making the larger glow around the button

A nice zoom effect

Codepen Link

Splendid Astro Spacing — A Tailwind Utility for Astro

A simple fix

Further Reading

Easy caching on the local file system with Node

Invalidating the cache

Invalidating the cache when other files change

Further Reading

zlFetch now supports FormData!

How zlFetch supports Form Data

Problems with Form Data

The backend needs to support it

It’s harder to debug Form Data

Converting Form Data into an object

Utility for form-urlencoded data

Further reading

Limitations of Scoped CSS

I’m not talking about the native CSS :scope

The premise of Scoped CSS

You cannot style children components

The Global Attribute

The Global Selector

You cannot style slot content

Styling Slot Content

Wrapping Up

Further Reading

Quality of life improvements for zlFetch

What is zlFetch?

Returning errors

Debug Mode

Creating a zlFetch Instance

Removing node-fetch as a dependency.

That's it for today!

The Magical Dev School Student Portal is live!

What’s this portal about?

How to access the portal

The Magical Dev School portal is pretty well designed

Product Switcher to jump to any course or workshop easily

Breadcrumbs to show you where you’re at

Assess the lesson plan from every page

Estimated timestamps for each course, chapter, and lesson

That’s it from me this week!

Finding my roots in my business

I created this blog to document my journey and to help

But this miracle led to a series of tragedies

I hope to find back my core

Here’s how to quickly test components that use container queries

There are two ways to make things easier

Here's how the utility works

Take this out for a spin! 🙃

When building components in Astro, you might not want to use Astro files

Three reasons

Reason 1: I use Svelte as my framework of choice

Reason 2: the main reason

Reason 3: Better syntax

When to use Astro files

What if a component requires both Astro APIs and JavaScript?

Wrapping up

Best practices for container queries

There’s a reason why we need to do this

If you use the second structure, you won’t be able to use container query units

Overcoming styling frustrations caused by Astro islands and slots

When Astro creates islands and slots

What's frustrating about Astro islands and slots

Direct descendant selectors no longer work

Fixing it

Lobotomized owls no longer work

Fixing it

CSS Grid Positioning no longer works

Fixing it

Nth-child no longer works as expected

Fixing it

A deeper layer of frustrations

Wrapping up

How `zlFetch` supports Form Data