> How we write and think about CSS has changed significantly since the web’s beginning.
> 
> We’ve come a long way from table-based layouts, to responsive web design, and now into a new era of adaptive layouts powered by modern CSS features.
> 
> Managing and organizing CSS has always been challenging, where consensus is hard to find.

The evolution of scalable CSS

Kent C.Dodds:

>  There’s this pattern I’ve been using in my apps that has been really helpful to me and I’d like to share it with you all. I’m calling it “full stack components” and it allows me to colocate the code for my UI components with the backend code they need to function. In the same file.

Kent C. Dodds on Full Stack Components

Craig Doremus:

> Fresh is the Deno full-stack framework created by Luca Casonato of the Deno core team and now hosted in the Deno github repository.
> 
> Fresh uses Preact for the UI. Recently the Preact team has released a new library called Signals for reactive state management. Preact Signals are used for both global and local state management.

Fresh is a fun Deno framework to use and adding Preact Signals to handle state management makes it more useful.

Using Preact Signals with Fresh

Jenna Smith:

> There has been a lot of talk on the socials lately about progressive enhancement. Some good, some bad, and while the bad is often misled I get it.
> 
> Educational content on this topic usually focuses on making things work without JavaScript. That is cool but I agree with the naysayers that JavaScript is a fundamental part of the web these days, so why should we invest time in making things work without it?
> 
> Well, it isn't only about building things that "support 1% of users without JavaScript" and I'd like to try explain why. But first, let's talk about that 1%.

Progressively enhance for a more resilient web

Nick Olszanski:

> I want to be frank about my experiences with React. I’ve been using it heavily for far over 6 or 7 years and I am doing great. React is amazing!
> 
> I know that people will always find ways to shoot themselves in the foot. At the same time I understand that batteries-not-included approach will lead to that sad result. When it comes to React projects I feel that I know a few tricks to sidestep problems that people discuss online.
> 
> Let's speak about the main problems first. People get out of their skin and try to make React projects a complicated and entangled mess. In programming, there was always a semi golden rule, to not architecturally fuse your business logic to any particular framework. We logically isolate our app from whatever framework we are using at the moment.
> 
> I’ve given the same demo day (task) exercise to ~50+ React devs. Basically two inputs and a button to draw a pattern on an HTML canvas. You wouldn’t believe how many of them (roughly 47) completely and unnecessary implemented most of the business logic inside React components. The sad part is this app doesn’t need React at all. Or one could implement 99% of the business logic in pure JS and just call one function from React.
> 
> React gives an option to store business logic state in `useState` and manage it via `useEffect` and we gladly use that to our demise. Litter our code with singleton instances of a business logic because we’ve “forgot” how to do a DI without a framework.
> 
> Second there is this immutable transducer reselect memoized concurrent proxy suspense state promotion society. Performance zealots obsessing over trillion renders per second. Which they don’t deliver, by the way. They describe how their Rube Goldberg flux redux machine works. A machine to read and write data into a JSON object.
> 
> React is pretty bare bones and before critiquing it we should take a hard look in the mirror. In my view, the framework is doing it’s job just fine. Unless we learn what really goes wrong with React projects we are doomed to repeat the same mistake again and again in the next (pun intended) framework.

Overcoming Popular Issues With React Projects

[Directus](https://directus.io/) is one of the nicer headless CMSes out there, their UX, API, Insights and no-code data studio make it a powerful tool.

Fly.io hosts Directus nicely and I've set up this [repo](https://github.com/freekrai/directus-fly) to quickly get started on Fly.io, it uses SQLite for the database, and also includes [https://github.com/dimitrov-adrian/directus-extension-wpslug-interface](https://github.com/dimitrov-adrian/directus-extension-wpslug-interface) extension already setup to handle generating slugs, it's quick to change the db to postgres or other if you like.

By the way, I highly recommend taking a look at the [Directus examples repo](https://github.com/directus/examples) to get a feel for what you can do using Directus with various frameworks like Next, Remix, Nuxt, Astro, etc.

## Important 🚧

Fly requires a globally unique name for all the apps, and we've used the directory name and random hash as the app name. Of course, you can change this anytime you want BEFORE launching the app with Fly CLI. But it's not a big deal since you can reassign the internal Fly URL to any custom domain by adding a [`CNAME`][cname] record to your custom domain pointing to the Fly internal URL. We'll see that later when deploying the app to production.

## Fly Setup 🛠

1. [Install Fly](https://fly.io/docs/getting-started/installing-flyctl/)

2. Sign up and log in to Fly

```bash
flyctl auth signup
```

## Deployment 🚀

### Initial setup 👀

Before proceeding to deploy our app, we have some steps to take care of:

- Create a GitHub account [GitHub](https://repo.new)
- Create a new app on Fly

```bash
flyctl launch --name [YOUR-APP-NAME] --copy-config --no-deploy
```

<callout-info>
⚠️ **Note:** Make sure this name matches the `app` set in your `fly.toml` file. Otherwise, you will not be able to deploy.
</callout-info>

<callout-warning>
⚠️ Remember not to deploy since we have some setup steps left to complete!
</callout-warning>
  
### Environment variables and Secrets 🤫

This template comes with GitHub actions workflows to automatically deploy the app to Fly.io. First, we need to set up our GitHub actions and the Fly app with some secrets. Let's do that now.

To push the build image to the remote Fly registry from GitHub action, we need an access token from Fly. We can generate that using the Fly command line, run:

```bash
flyctl auth token
```

The command will generate an access token. You can then add this token to your GitHub actions secrets by visiting your GitHub repository's `settings` page `https://github.com/:owner/:repo/settings/secrets/actions` and then click `New repository secret`. Next, GitHub will prompt for a key and a value. The key should be `FLY_API_TOKEN`, and the value will be the token generated by the command line.

We also need to set the Fly app name as a secret, the key should be `FLY_APP_NAME`, and the value will be the app name specified in [fly.toml](./fly.toml)

Now we need to set up secrets in our Fly app.

We also need a secret to sign our session. We can do that by running the command:

```bash
flyctl secrets set KEY=$(openssl rand -hex 32)
flyctl secrets set SECRET=$(openssl rand -hex 32)
```

```bash
flyctl secrets set ADMIN_EMAIL=[YOUR@EMAIL.com]
flyctl secrets set ADMIN_PASSWORD=[YOUR-ADMIN-PASSWORD]
```

The last secret, is your `PUBLIC_URL`, you can get the initial domain from fly by typing: `flyctl info`

To get the current app URL and IP address. The app URL will be `https://YOUR-APP-NAME.fly.dev`. 

```bash
flyctl secrets set PUBLIC_URL=https://[YOUR-APP-NAME].fly.dev
```

You can change this by following Fly's DNS docs and then just update the secret anytime

### Volumes 💾

We also need to create a volume in Fly to persist our app data (SQLite DB) so that Fly can persist the data stored across deployments and container restarts. Again, we can do that using the Fly command line.

```bash
flyctl volumes create data --region [REGION] --size 1
```

<callout-info>
Note: REGION should be the region selected when launching the app. You can check the region chosen by running `flyctl regions list`.
</callout-info>
  
It's important to note that Volumes are bound to an app in a region and cannot be shared between apps in the same region or across multiple regions.

You can learn more about Fly Volumes [here](https://fly.io/docs/reference/volumes)

You should also update the region in your `fly.toml` file to whichever region you selected:

```toml
[env]
  FLY_PRIMARY_REGION = "[REGION]"
```

The other variables you can leave alone.

### Deploy 🥳

We are ready for our first deployment.

You have two ways to deploy:

- Via `npm run deploy`: deploy the current folder
- Via Github actions.

GitHub actions workflows are configured to run on push to the `main` branch. 

So let's push the local branch `main` to remote, triggering the workflows.

Once all the checks are passed, and the deployment is complete


### Logs

You can check the logs using the command `flyctl logs` from the project directory, containing the `fly.toml` file in the project's root. You can also check the logs from the console by visiting [fly.io/apps](https://fly.io/apps).

### Console

You can also log in to the remote console using the `flyctl ssh console` command.

### Connecting to your database

The sqlite database lives at `/data/database/data.db` in your deployed application. 

You can connect to the live database by running `flyctl ssh console -C database-cli`.

### Adding extensions 🔌

There are two ways to add extensions:

1. Via `package.json` like the included `directus-extension-wpslug-interface` extension or
2. Installed inside the `extensions` folder.

This works the same as any other Directus installation

2 A22 Ffbd 89 Dc 474 D Ac 4 D 2 B8 Ded 6573 C3 Ad005116ee.png

Quickly Deploy Directus On Fly.io

[The Directed Stack](https://github.com/freekrai/directed-stack) is a full-stack Remix stack that combines Directus as the backend and Remix for the app, easily customizable to build on

I use Directus for a lot of apps, from this blog, to several other projects.

The Directed Stack is based on the apps I built, you can see a [demo](https://notes.haxstax.xyz/) where you can see the about page, blog posts and sign up and add markdown notes (based on the [Indie Stack](https://github.com/remix-run/indie-stack)), all the backend work is stored in Directus.

To get started, you can fork the repo or run the following command:

```bash
npx create-remix --template freekrai/directed-stack
```

## Development

This repo contains two folders plus the root:

- `directus`: our Directus headless CMS
- `scripts`: our Directus schema
- `/`: our Remix app

## First run

On first one, clone this repo and run:

```bash
yarn
yarn setup
```

Then go into the directus folder and set up for local development by copying your `.env.example` into `.env` and filling out the fields.

Then run:

```bash
npx directus bootstrap
```

You can then import your schema into your local Directus by going into the scripts folder, save `.env.example` to `.env`, and save the required info then run:

```bash
cd scripts
node schema.mjs
```

This will create the collections locally in Directus, you can update the `.env` and run it again once your deploy _(we'll talk about that further down)_.

If you want to test creating users locally, then you'll also need to create a `users` role inside the Directus Data Studio, which needs the following permissions  _(again, we'll talk about that further down with prod)_:

- notes
   - create: all access
   - view: where `created By` equals `$CURRENT_USER`
   - edit: where `created By` equals `$CURRENT_USER`
   - remove: where `created By` equals `$CURRENT_USER`
- users:
   - view: all access, Directus handles the proper rules
   - edit: where `ID` equals `$CURRENT_USER`

On the same page, there are checkboxes for app and admin, uncheck both of these if they are checked as this role will be through the api only.

Take note of this role's ID as you'll need it when you deploy the remix app

Also edit the `public` role: 
   - directus_files
     - view: all access

Finally, let's load the remix app.

Copy `.env.example` into `.env` and fill out the info:

```yaml:.env
# run openssl rand -hex 32 to generate
SESSION_SECRET=session-secret

# DirectUs
DIRECTUS_URL=http://localhost:8055
DIRECTUS_STATIC_TOKEN=static-token
DIRECTUS_USER_ROLE=role-to-give-frontend-users
```

Now run `yarn dev` and go to `http://localhost:3000`.

## Deploying

### Railway

This app uses a [slugs](https://github.com/dimitrov-adrian/directus-extension-wpslug-interface) extension that you want pre-installed, you can use my [Directus Railway](https://github.com/freekrai/directus-railway) repo to get started on Railway, to deploy Directus to railway, click:

[![Deploy on Railway](https://railway.app/button.svg)](https://railway.app/new/template/_dszdt?referralCode=codedgeekery)

You can find more info on this repo [here](https://codedgeekery.com/blog/directus-railway).

### Fly.io

If you're prefer to install Directus on [Fly.io](http://fly.io), you can follow this [repo](https://github.com/freekrai/directus-fly) repo instead.

### Directus Cloud

Directus also gives a terrific option of hosting via their [cloud service](https://directus.cloud), but you can't use extensions on the free tier so the included schema would need to be changed so that the slug field is just a text field instead. 

Once deployed, go into the scripts folder, save `.env.example` to `.env`, and save the required info then run:

```bash
cd scripts
node schema.mjs
```

Which will create the necessary collections on your deployed Directus site.

#### Permissions

Earlier, we setup permissions for testing everything locally, we need to do the same thing to our deployed site, so create a `users` user role, which has permissions as follows:

- notes
   - create: all access
   - view: where `created By` equals `$CURRENT_USER`
   - edit: where `created By` equals `$CURRENT_USER`
   - remove: where `created By` equals `$CURRENT_USER`
- users:
   - view: all access, Directus handles the proper rules
   - edit: where `ID` equals `$CURRENT_USER`

Take note of this role's ID as you'll need it when you deploy the remix app.

Also edit the `public` role: 

   - directus_files
     - view: all access

### Vercel

The vercel button is already preloaded with the information you need to get deploying to Vercel

[![Deploy with Vercel](https://vercel.com/button)](https://vercel.com/new/clone?repository-url=https%3A%2F%2Fgithub.com%2Ffreekrai%2Fdirected-stack&env=SESSION_SECRET,DIRECTUS_URL,DIRECTUS_STATIC_TOKEN,DIRECTUS_USER_ROLE)

## What's Next?

You can build on this pretty easily to create pretty much any type of app.

<callout-info>
Stay tuned for a more detailed post about how to build this site out  step by step coming soon 🙏🏻
</callout-info>


Directed Stack

The Directed Stack: A Full-Stack App built with Remix and Directus

The [Remix Blog](https://github.com/freekrai/remix-blog) Stack is a Remix [stack](https://remix.run/stacks) I wrote for quickly building an MDX blog in Remix, it's had a few revisions recently so I thought I'd share how to get it set up and running.

To get started, you can fork the repo or run the following command:

```bash
npx create-remix --template freekrai/remix-blog
```

## Config

By default, remix-blog will try to use the file system to read files, this works great but if you are on a hosting service like cloudflare where you can't access the file system then we need to use Github, you can configure how it accesses files in your `.env` file:

- `SESSION_SECRET`: Session Secret used for sessions such as dark mode
- `USE_FILESYSTEM_OR_GITHUB`: this is either `fs` or `gh`
- `GITHUB_TOKEN`:  your Personal access token
- `GITHUB_OWNER`: your Github name
- `GITHUB_REPO`: your Github repo

The Github variables are only needed if `USE_FILESYSTEM_OR_GITHUB` is set to `gh`, it's `fs` by default.

This does allow you to do things like have one repo for the codebase and one for just content which can be handy.

---

## Development

To run your Remix app locally, first, copy `.env.example` to `.env` and configure as needed following the `Config` step above.

Next, make sure your project's local dependencies are installed:

```bash
npm install
```

Afterwards, start the Remix development server like so:

```bash
npm run dev
```

Open up [http://localhost:3000](http://localhost:3000) and you should be ready to go!

---

### Structure

It's been set up so that you have flexiblity in terms of content, for example the default setup is:

- `content`: where mdx is stored
- `content/posts`: blog posts, stored as: `SLUG/index.mdx`
- `content/pages`: pages, stored as `SLUG/index.mdx`

The structure is based on Gatsby and gives more flexibility, each page and post is a folder and contains an `index.mdx` file, this folder name becomes the slug.

This can be used to create other content types as well, posts, pages, workshops, snippets, anything you want and then just call it, you can look at the blog files for using an entire post type.

This can be expanded further, for example, you can have multiple files and folders inside one folder:

- `content/posts/hello-world/index.mdx` returns as `/hello-world`
- `content/posts/hello-world/abc.mdx` returns as `/hello-world/abc`
- `content/posts/hello-world/more-hello/index.mdx` returns as  `hello-world/more-hello`
- `content/posts/hello/still-hello/index.mdx` returns as `hello/still-hello`
- `content/posts/2022/test/index.mdx` returns as `/2022/test`

This lets you structure content however you want.

On build, the stack generates a json file in content (`blog-cache.json`) for all blog posts, which is then referenced later for the blog index, rss, sitemap, etc.

The stack also generates a separate json file in content (`page-cache.json`) for all pages, this can then be used for sitemap, etc as well.

If you are doing other content types besides posts and pages, you may want to edit `scripts/cachePosts.ts` and follow what was done for `getPosts` and `getPages` functions to create a cache file for each of those as well, the app uses these as a sort of _read-only_ database.

Mdx files contain frontmatter which is used to know about each post, this frontmatter looks like:

```jsx
---
meta:
  title: Another Post
  description: A description
date: '2021-10-02T00:00:00'
excerpt: Hello Gaseous cloud...
headers:
  Cache-Control: no-cache
---
```
---

## Deployment

Initially, this stack is set up for deploying to Vercel, but it can be deployed to other hosts quickly and I'll update the [wiki](https://github.com/freekrai/remix-blog/wiki/Deploying) with instructions for each, but to get started on Vercel:

Open `server.js` and save it as:

```jsx:server.js
import { createRequestHandler } from "@remix-run/vercel";
import * as build from "@remix-run/dev/server-build";
export default createRequestHandler({ build, mode: process.env.NODE_ENV });
```

Then update your `remix.config.js` file as follows:

```jsx:remix.config.js
/** @type {import('@remix-run/dev').AppConfig} */
module.exports = {
  serverBuildTarget: "vercel",
  server: process.env.NODE_ENV === "development" ? undefined : "./server.js",
  ignoredRouteFiles: ["**/.*"],
};
```

This will instruct your Remix app to use the Vercel runtime, after doing this, you only need to [import your Git repository](https://vercel.com/new) into Vercel, and it will be deployed.

If you'd like to avoid using a Git repository, you can also deploy the directory by running [Vercel CLI](https://vercel.com/cli):

```bash
npm i -g vercel
vercel
```

It is generally recommended to use a Git repository, because future commits will then automatically be deployed by Vercel, through its [Git Integration](https://vercel.com/docs/concepts/git).

This repo is open for pull requests and ideas to expand on it, but I wanted to make it flexible to start off.

The Remix Blog Stack

[Directus](https://directus.io/) is one of the nicer headless CMSes out there, their UX, API, Insights and Flow engine make it a powerful tool.

I set up this [repo](https://github.com/freekrai/directus-railway) to quickly get started on Railway, it uses Postgres for the database, S3 for file storage and also includes [https://github.com/dimitrov-adrian/directus-extension-wpslug-interface](https://github.com/dimitrov-adrian/directus-extension-wpslug-interface) extension already setup to handle generating slugs.

[Click here](https://github.com/freekrai/directus-railway) to open the repo and get started.

That’s it, there’s a button to push that will take you to Railway and guide you through setting up your site.

I highly recommend taking a look at the [Directus examples repo](https://github.com/directus/examples) to get a feel for what you can do using Directus with various frameworks like Next, Remix, Nuxt, Astro, etc.

### Further Config

You should also read over the [self-hosted docs](https://docs.directus.io/self-hosted/quickstart.html) which can show any further config you can add such as Redis cache, or configuring email to send via a service of your choice, these can all be configured in the railway dashboard pretty quickly. 

For example, to tell the app to send email using Sendgrid:

```jsx
EMAIL_FROM=you@youremail.com
EMAIL_TRANSPORT=smtp
EMAIL_SMTP_HOST=smtp.sendgrid.net
EMAIL_SMTP_PORT=587
EMAIL_SMTP_USER=apikey
EMAIL_SMTP_PASSWORD=YOUR-SENDGRID-API-KEY
```

Or to enable Redis cache, add a Redis service to your Railway app and add the following env vars:

```jsx
CACHE_ENABLED=true
CACHE_STORE=redis
CACHE_REDIS=redis://your-redis-connection-string
CACHE_TTL=15m
CACHE_AUTO_PURGE=true
```

If you want cache but don’t want Redis, you can also just set the app to use a memory cache with:

```jsx
CACHE_ENABLED=true
CACHE_STORE=memory
CACHE_TTL=15m
CACHE_AUTO_PURGE=true
```

Or you can leave caching off entirely like it is by default.

### Upgrading

I’ll keep the repo up to date as new releases come out which Railway will show in their dashboard and let you push to your own, it’s currently set to grab the latest during builds. 

But if you want to upgrade yourself, then you just have to set the directus version in your package.json to the latest version number, currently it’s `9.18.1`.

Quickly Deploy Directus on Railway

Josh W Comeau:

> So, I'll be honest. I had been working professionally with React *for years* without really understanding how React's re-rendering process worked. 😅
> 
> I think this is true for lots of React developers. We understand enough to get by, but if you ask a group of React developers a question like “What triggers a re-render in React?”, you'll likely get a handful of different hand-wavy answers.
> 
> There are a lot of misconceptions out there about this topic, and it can lead to a lot of uncertainty. If we don't understand React's render cycle, how can we understand how to use `React.memo`, or when we should wrap our functions in `useCallback`??

Josh’s post is a good refresher on why React re-renders.



Hi, my name is Roger Stringer.

Recent Posts

The evolution of scalable CSS

Kent C. Dodds on Full Stack Components

Using Preact Signals with Fresh

Progressively enhance for a more resilient web

Overcoming Popular Issues With React Projects

Quickly Deploy Directus On Fly.io

The Directed Stack: A Full-Stack App built with Remix and Directus

The Remix Blog Stack

Quickly Deploy Directus on Railway

Josh W Comeau : "Why React Re-Renders"

Featured Posts

Quickly Deploy Directus On Fly.io

The Directed Stack: A Full-Stack App built with Remix and Directus

Setup an nginx proxy for docker-compose