manage blogs
Yours blogs
Title: Generate a color palette with CSS
Post ID: a438c03c-0376-4c7a-ac18-781da56d6610 Description: In this blog, I will explain how I use the CSS color function, color() and relative values to generate a color palette. Content:
# Generate a color palette with CSS
## Wat is color function en wat kan je ermee?
[From this article](https://ishadeed.com/article/css-relative-colors/#hsl-colors) I learned how to use the color() function to modify colors.
What it does is take a color, and then you can adjust its individual values.
For the HSL color function, the syntax looks like this:
```CSS
hsl(from 'origin-color' h s l)
```
If you write out H, S, and L, the values stay the same. If you replace one with a number, only that value changes to the new number.
For example, here I change the hue, which alters my color:
```CSS
background-color: hsl(from #9333ea 20 s l);
```
If you want to create a lighter or darker version of the same color, you just need to adjust the lightness value:
```CSS
/* Darker */
background-color: hsl(from #9333ea h s calc(l - 20));
/* Lighter*/
background-color: hsl(from #9333ea h s calc(l + 20));
```
Here, I used calc() to calculate how much lighter or darker the L value should be.
1 = the original value, and we add or subtract from it to make it lighter or darker.
You might have noticed, but now we’re passing a hex color code and changing the lightness value.
How is that possible?
The hsl() color function automatically converts the color to HSL and then changes the L value.
This also works for colors in other color formats:
```CSS
/* hsl */
background-color: hsl(from hsl(201, 72%, 18%) h s calc(l + 20));
/* oklch */
background-color: hsl(from oklch(69.58% 0.16 55.54) h s calc(l + 20));
```
We can do this with hsl(), but also with [oklch()](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Values/color_value/oklch)
for example:
```CSS
background-color: oklch(from #9333ea calc(l + 20) c h);
```
*In HSL, the browser shows srgb when you hover over the color, but in OKLCH, it actually shows oklch*
<img width="504" height="105" alt="image" src="https://github.com/user-attachments/assets/d784ec2e-140b-4143-94b7-8fda0416d027" />
<img width="504" height="105" alt="image" src="https://github.com/user-attachments/assets/484fd54c-fedd-494d-abeb-198604dd536c" />
OKLCH has more values between colors, which makes lighter and darker variations look nicer because they don’t become too bright or too dark.
In this blog/tutorial, I will continue using OKLCH.
## Custom properties
Writing out the color function everywhere in a project is a lot of work and hard to maintain.
With custom properties, we can make it easier.
For example:
```CSS
:root {
--primary: oklch(32.79% 0.063 237.53);
--primary-light: oklch(from var(--primary) calc(l + 0.1) c h);
}
div {
background-color: var(--primary-light);
```
<img width="791" height="155" alt="image" src="https://github.com/user-attachments/assets/2545aaea-3cc6-47fe-95ce-492d92576d61" />
With this approach, you can use the colors much more easily, and if you change the --primary color, all color variations will update automatically.
## Don't repeat yourself
If we use this approach, a lot of repetition occurs, which becomes noticeable once you start adding more colors or color variations.
```CSS
:root {
--primary: oklch(32.79% 0.063 237.53);
--secondary: oklch(0.6073 0.1939 31.79);
--neutral: oklch(0.7 0.2358 326.14);
--primary-dark-2: oklch(from var(--primary) calc(l - 0.1) c h);
--primary-dark-1: oklch(from var(--primary) calc(l - 0.05) c h);
--primary-light-1: oklch(from var(--primary) calc(l + 0.1) c h);
--primary-light-2: oklch(from var(--primary) calc(l + 0.2) c h);
--secondary-dark-2: oklch(from var(--secondary) calc(l - 0.1) c h);
--secondary-dark-1: oklch(from var(--secondary) calc(l - 0.05) c h);
--secondary-light-1: oklch(from var(--secondary) calc(l + 0.1) c h);
--secondary-light-2: oklch(from var(--secondary) calc(l + 0.2) c h);
--neutral-dark-2: oklch(from var(--neutral) calc(l - 0.1) c h);
--neutral-dark-1: oklch(from var(--neutral) calc(l - 0.05) c h);
--neutral-light-1: oklch(from var(--neutral) calc(l + 0.1) c h);
--neutral-light-2: oklch(from var(--neutral) calc(l + 0.2) c h);
}
```
<img width="791" height="400" alt="image" src="https://github.com/user-attachments/assets/4bfac85e-1aaf-4a41-97e5-6d9052e0f22a" />
Fortunately, there’s a solution for this using only CSS:
```CSS
:root {
--primary: oklch(32.79% 0.063 237.53);
--secondary: oklch(0.6073 0.1939 31.79);
--neutral: oklch(0.7 0.2358 326.14);
}
.primary,
.secondary,
.neutral {
--dark-2: oklch(from var(--color) calc(l - 0.1) c h);
--dark-1: oklch(from var(--color) calc(l - 0.05) c h);
--light-1: oklch(from var(--color) calc(l + 0.1) c h);
--light-2: oklch(from var(--color) calc(l + 0.2) c h);
}
.primary {
--color: var(--primary);
}
.secondary {
--color: var(--secondary);
}
.neutral {
--color: var(--neutral);
}
```
```HTML
<ul class="primary">
<li><h2>Primary</h2></li>
<li><div></div></li>
<li><div></div></li>
<li><div></div></li>
<li><div></div></li>
<li><div></div></li>
</ul>
```
This looks exactly the same in the browser as before, but in the code, there are three disadvantages:
- You now have to add a class in the HTML
- And the color variations for all colors will all be `--dark-2`, `--dark-1`, `--light-1`, `--light-2` zijn, the class in the HTML determines which color is displayed.
- Because the classes for the variations all have the same names, you can only add one per container.
- So, you assign `primary` to your container, and then within that container, you can use all the variations of `primary` as well as the main colors: `--primary`, `--secondairy`, `--neutral`.
- If you give an element inside your container a new class, you can then use the color variations of another color on that element and everything inside it
```HTML
<ul class="primary">
<li><h2>Primary</h2></li>
<li><div></div></li>
<li class="secondary"><div></div></li>
</ul>
```
## Solution
The one I found was SCSS. Here, you can create a loop to generate all color variants. Each color gets its own custom property, so you don’t have to work with classes.
For example:
```SCSS
// Original colors
$colors: (
primary: oklch(32.79% 0.063 237.53),
secondary: oklch(0.6073 0.1939 31.79),
neutral: oklch(0.7 0.2358 326.14)
);
// lighter and darker variants
$variants: (
dark-2: -0.1,
dark-1: -0.05,
light-1: 0.1,
light-2: 0.2
);
// make custom properties for each color variant
:root {
// Take each color in $colors and separate the name and the color code
@each $color-name, $color-value in $colors {
// use name and color code to make a CSS custom property
--#{$color-name}: #{$color-value};
@each $variant-name, $offset in $variants {
// use name + variant name to make a new custom property
// And use color code + variant in color function
--#{$color-name}-#{$variant-name}: oklch(from var(--#{$color-name}) calc(l + #{$offset}) c h);
}
}
}
```
*I tried to replicate this loop in Vue and Svelte, but unfortunately, it’s not possible to loop over CSS in those files. A missed opportunity, if you ask me*
## Progressive Enhanced
### hsl & oklch
OKLCH has been supported in the most commonly used browsers, Chrome, Edge, Safari, and Opera since 2023. Since 2025, it’s also supported in Safari and Samsung Internet.
Because this is still very recent, we can adjust our code to use HSL by default, and use OKLCH when the browser supports it.
```CSS
:root {
--primary: #0d3951;
--secondary: #de452d;
--neutral: #e55bea;
}
.primary,
.secondary,
.neutral {
--dark-2: hsl(from var(--color) h s calc(l - 10));
--dark-1: hsl(from var(--color) h s calc(l - 5));
--light-1: hsl(from var(--color) h s calc(l + 10));
--light-2: hsl(from var(--color) h s calc(l + 20));
@supports (color: oklch(32.79% 0.063 237.53)) {
--dark-2: oklch(from var(--color) calc(l - 0.1) c h);
--dark-1: oklch(from var(--color) calc(l - 0.05) c h);
--light-1: oklch(from var(--color) calc(l + 0.1) c h);
--light-2: oklch(from var(--color) calc(l + 0.2) c h);
}
}
.primary {
--color: var(--primary);
}
.secondary {
--color: var(--secondary);
}
.neutral {
--color: var(--neutral);
}
```
What’s happening here?
- I declare the colors in hex code. Both the hsl() and oklch() color functions accept hex codes and convert them automatically to HSL or OKLCH.
- The @supports checks if OKLCH is supported. If it is, it’s used, otherwise, we fall back to HSL
### Relative colors
Relative colors for HSL and OKLCH have been supported in major browsers since 2024. Because this is still recent, we can create a fallback using color-mix.
color-mix works similarly to hsl() and oklch().
It takes a color, and you can apply a tint/filter to it. This tint is another color.
To create lighter and darker variants, I will use black and white.
color-mix can also accept a hex color and convert it to HSL or OKLCH.
```CSS
/* hsl */
--dark-2: color-mix(in hsl, var(--color) 80%, black 20%);
/* oklch */
--dark-2: color-mix(in oklch, var(--color) 80%, black 20%);
```
Since this is a fallback, I will use HSL in the color-mix:
```CSS
:root {
--primary: #0d3951;
--secondary: #de452d;
--neutral: #e55bea;
}
.primary,
.secondary,
.neutral {
--dark-2: color-mix(in hsl, var(--color) 80%, black 20%);
--dark-1: color-mix(in hsl, var(--color) 90%, black 10%);
--light-1: color-mix(in hsl, var(--color) 90%, white 10%);
--light-2: color-mix(in hsl, var(--color) 80%, white 20%);
/* comment this @support and the next one to see color-mix() */
@supports (color: hsl(201, 72%, 18%)) {
--dark-2: hsl(from var(--color) h s calc(l - 10));
--dark-1: hsl(from var(--color) h s calc(l - 5));
--light-1: hsl(from var(--color) h s calc(l + 10));
--light-2: hsl(from var(--color) h s calc(l + 20));
}
/* comment this @support to see hsl() */
@supports (color: oklch(32.79% 0.063 237.53)) {
--dark-2: oklch(from var(--color) calc(l - 0.1) c h);
--dark-1: oklch(from var(--color) calc(l - 0.05) c h);
--light-1: oklch(from var(--color) calc(l + 0.1) c h);
--light-2: oklch(from var(--color) calc(l + 0.2) c h);
}
}
.primary {
--color: var(--primary);
}
.secondary {
--color: var(--secondary);
}
.neutral {
--color: var(--neutral);
}
```
oklch():
<img width="791" height="400" alt="oklch()" src="https://github.com/user-attachments/assets/553fa509-49f5-4c2d-baac-82b8f474507c" />
<img width="500" height="100" alt="oklch-inspector" src="https://github.com/user-attachments/assets/047863f2-f2fc-49f9-9e7d-a7835fcc35c8" />
hsl():
<img width="791" height="400" alt="hsl()" src="https://github.com/user-attachments/assets/2753aed3-3988-4740-a338-f4b04cebb31b" />
<img width="500" height="100" alt="hsl-inspector" src="https://github.com/user-attachments/assets/5ad47693-5600-4f29-bea9-2d059cf6ed1c" />
color-mix():
<img width="791" height="400" alt="color-mix()" src="https://github.com/user-attachments/assets/03cff033-ccbf-42fc-ab54-65761aa7a558" />
<img width="500" height="100" alt="color-mix-inspector" src="https://github.com/user-attachments/assets/a5088fc5-44e1-4055-875e-a631e1cc3bf4" />
The only downside of color-mix is that it uses percentages to mix two colors, giving you less control over the variants.
With hsl() and oklch(), you can specify exactly which values to change.
Since both color-mix() and hsl() return HSL, I would use only color-mix() from these two, and use OKLCH as an enhancement.
## Summary
If you generate colors this way, it’s very easy to adjust your colors.
Adding new colors is also very simple—you only need this:
```CSS
:root {
--new-color: #0d3951;
}
.new-color{
--color: var(--new-color);
}
```
Four lines of code give you, (using only color-mix() and OKLCH):
4 OKLCH colors and 4 HSL colors as a fallback
If you were to write everything out manually, you’d end up with twice as many lines of code.
The downside is that you then have to work with classes in HTML and the same custom property for all colors.
But you can solve this with a loop in SCSS, which generates all these color variations with their own custom property names.
## Links
Codepen:
- [color function - CSS](https://codepen.io/vrsh/pen/MYyvWBX?editors=0100)
- [color function - SCSS](https://codepen.io/vrsh/pen/gbrxWyN?editors=0100)
- [color function - Progressive Enhanced](https://codepen.io/vrsh/pen/XJdawBM?editors=0100)
Can I Use:
- [hsl - color](https://caniuse.com/?search=hsl)
- [oklch - color](https://caniuse.com/?search=oklch)
- [hsl() - Relative colors](https://caniuse.com/mdn-css_types_color_hsl_relative_syntax)
- [oklch() - Relative colors](https://caniuse.com/mdn-css_types_color_oklch_relative_syntax)User/ author
Handle: @user2 Username: user two Account create date: 2026-03-20T13:27:31+00:00 Title: components in figma
Post ID: 3ab6679e-aa2e-406f-b103-352d451a2b2f Description: In deze blog deel ik wat ik geleerd heb over figma Content:
# components in figma
Ik vond Figma altijd lastig, omdat ik niet wist hoe ik het moest gebruiken. Vooral wanneer ik een design had dat een beetje werd aangepast, moest ik die aanpassing overal handmatig doorvoeren.
De afgelopen weken heb ik besloten om meer over Figma te leren. Ik heb ontdekt dat je met Create Component een component kunt maken en de varianten daarvan in je designs kunt gebruiken.
Alle varianten veranderen automatisch mee als je de hoofdcomponent aanpast.
Hierdoor hoef je niet meer langs alle groepen te gaan om ze te vervangen of aan te passen.
Om deze reden raad ik aan om altijd frames te gebruiken in plaats van groups. Frames ondersteunen auto layout, groups niet.
Daarnaast heeft Figma auto layout, dit werkt als display: flex in CSS, met kolom- of rij-richting.
Hiermee kun je ook paddings, margins en gaps instellen (in figma heet het niet zo, maar het doet hetzelfde), waardoor je niet meer hoeft te slepen totdat elementen de juiste afstand van elkaar hebben.
## Linkjes
Ik had een cursus op Udemy gevolgd om dit te leren, maar Figma heeft ook eigen video's die dieper op deze onderwerpen ingaan:
create component
- [components intro](https://help.figma.com/hc/en-us/articles/360038662654-Guide-to-components-in-Figma)
- [variants](https://help.figma.com/hc/en-us/articles/360056440594-Create-and-use-variants)
layouts in figma
- [auto layout - flex](https://help.figma.com/hc/en-us/articles/5731482952599-Toggle-on-auto-layout-in-designs)
- [auto layout - grid](https://help.figma.com/hc/en-us/articles/360040451373-Guide-to-auto-layout)
- deze is nog in beta
## voorbeelden
[Variants-1.webm](https://github.com/user-attachments/assets/225d90cf-6e71-4cee-bbb2-0ef8c8656447)
> Varianten maken en aanpassen via de hoofdcomponent
[Variants-2.webm](https://github.com/user-attachments/assets/10f3fe4a-0896-450e-bc32-0b44a9ebb22b)
> Een variant aanpassen zonder dat de hoofdcomponent wordt veranderd
User/ author
Handle: @user2 Username: user two Account create date: 2026-03-20T13:27:31+00:00 Title: How to setup prettier for group projects
Post ID: c7335c7b-f890-40fc-ad73-f1c06c409f36 Description: In this blog, I will explain how I set up the Prettier code formatter for my group project.
Content:
# How to setup prettier for group projects
In this blog, I will explain how I set up the Prettier code formatter for my group project.
## [Install prettier](https://prettier.io/docs/install)
- This command installs the Prettier dependency in our project. You can see it added to our package.json file. Once the updated `package.json` is pushed to GitHub, all new team members will automatically install it when they run npm install.
- If you already have a local clone of the project, you’ll need to run `git pull` to fetch the updated `package.json`, and then run `npm install` again.
```console
npm install --save-dev --save-exact prettier
```
If you already have a `prettierrc` file and a `prettierignore` file, you can skip these steps.
When setting up a Svelte project, the CLI gives you the option to add prettier to your project. If you chose this option, you probably already have these files.
```console
node --eval "fs.writeFileSync('.prettierrc','{}\n')"
```
```console
node --eval "fs.writeFileSync('.prettierignore','# Ignore artifacts:\nbuild\ncoverage\n')"
```
## Formating with prettier
To format all files in our project, run:
```console
npx prettier . --write
```
This will format all supported files in the project, except for the ones listed in `.prettierignore`
Note that this may take a while for larger projects.
You can also format only specific files, for example:
```console
npx prettier --write src/lib/components/Button.svelte
```
Prettier check
```console
npx prettier . --check
```
This checks if all files in the project are formatted. It does not format them.
You can use this to see which files have changes and then format only those files, instead of formatting everything
## [Editor integration](https://prettier.io/docs/editors)
If you have the `Prettier - Code formatter` extension in VS Code, you can configure it to format on save. Combined with auto save, you won’t have to run these commands manually, formatting will happen automatically.
This can be done locally, which means everyone would have to set it up manually.
Or, you can create a `.vscode/settings.json` file in the root of your project.
This achieves the same without requiring team members or future members to configure it manually, making it easy for everyone to use the Prettier code formatter correctly.
### [prettier code formatter for team projects](https://www.digitalocean.com/community/tutorials/how-to-format-code-with-prettier-in-visual-studio-code#configure-prettier-for-team-environments)
first make a folder named:
```console
.vscode
```
in that folder add this file:
```console
settings.json
```
in this file add the following code:
```JSON
{
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.formatOnSave": true
}
```
## after installing Prettier
After setting this up in my project, I noticed that the formatter did not run automatically. I had to format everything manually using:
```console
npx prettier . --write
```
This confirmed that Prettier was correctly installed, but it was not formatting on save.
In vscode, I had to enable `editor: format On Save` in the settings. Now, when I save a file, all the code is formatted automatically.
We already enable this feature in `.vscode/settings.json`, but because vscode user settings, locally, have higher priority, if someone turns it off in their personal VS Code settings, it will not work.
### solution
Open VS Code settings using the shortcut: `Ctrl , +`
Search for
```console
editor: format on save
```
and enable this option.
everytime you manual save, `ctrl S`, your code gets formatted
For now, I don’t see a way to automatically format on auto-save.
If I figure it out in the future, I will update this.
## [Configuration Overrides](https://prettier.io/docs/configuration#configuration-overrides)
In your `.prettierrc` file, you can add this under `overrides => options` to override the default settings:
The [`printWidth`](https://stackoverflow.com/questions/53342961/how-to-force-prettier-html-formatting-to-format-tags-in-one-line) option tells Prettier when to insert line breaks. This example sets it to 140 characters, which is wide enough to keep img and source tags on a single line.
```console
"printWidth": 140
```
To prevent prettier from adding semicolons, `;`, in JavaScript, you can add the following setting
```console
"semi": false
```
With these changes, this is what our `.prettierrc` file looks like now:
```JSON
{
"useTabs": true,
"singleQuote": true,
"trailingComma": "none",
"printWidth": 100,
"plugins": ["prettier-plugin-svelte"],
"overrides": [
{
"files": "*.svelte",
"options": {
"parser": "svelte",
"printWidth": 140,
"semi": false
}
}
]
}
```
## Summary
If you already have the project:
- Push your changes to GitHub, the prettier code formatter changes
- Your team can then pull these changes to their local clone.
- They will need to run:
- `npm install`
- to download the new dev dependencies
If this is your first time cloning the project, following the regular install instructions (probably described in the README) should install everything automatically.
Next, make sure Format on Save is enabled in VS Code:
- Open VS Code settings. `file > preferences > settings`
- Search for:
- `editor: format on save`
- Turn this option on.
Now, every time you save a file manually, `Ctrl+S`, that file will be formatted.
Note: This setup does not automatically format your code on Auto Save.
If you forget to save files manually, you can check which files have to be formatted by running:
```console
npx prettier . --check
```
Then, you can format those files either by manually saving them, `Ctrl+S`, or via the command line:
```console
npx prettier --write {path to file}
```
Or format the entire project at once:
```console
npx prettier . --write
```
This option will take the longest.
User/ author
Handle: @user2 Username: user two Account create date: 2026-03-20T13:27:31+00:00 Title: Project Board Workflow
Post ID: 198d3460-a8d5-45c3-bfda-0184028c5c5e Description: A comprehensive guide to how I set up my GitHub project boards. Content:
# Project Board Workflow
## Table of Contents
- [Setting up the project board](#setting-up-the-project-board)
- [Columns](#columns)
- [Issues – Project Board Fields](#issues--project-board-fields)
- [Customizing These Fields](#customizing-these-fields)
- [Visible Fields](#visible-fields)
- [Labels](#labels)
- [Type](#type)
- [Issue Templates](#issue-templates)
- [Branches](#Branches)
- [Pull Request Template](#pull-request-template)
- [Charts](#charts)
- [Automations](#automations)
---
## Setting up the project board
In the repository, go to Projects and click the green `+ New project` button.
Here, select `Team planning`, the first option.
<!-- <img width="800" height="500" alt="image" src="https://github.com/user-attachments/assets/77bd2a70-e21b-4ec5-bee1-2cb1d42266ce" /> -->
And then I enable `Bulk import items`, which ensures that issues created in the repository’s Issues tab are automatically added to the project board.
<!-- <img width="800" height="500" alt="image" src="https://github.com/user-attachments/assets/f4475714-76c5-4ebf-bb83-74910fdf50d2" /> -->
---
## Columns
After creating the project board, I find it useful to immediately set up all columns and adjust their descriptions.
- `Epic`: A larger feature made up of several related user stories.
- `Backlog`: User stories, tasks, and bugs that are planned but not yet selected for a sprint.
- `Todo`: Items selected for the current sprint and ready to be worked on.
- `In progress`: Work that is currently being actively developed.
- `Review`: Completed work awaiting review, testing, or approval.
- `Done`: Work that meets the Definition of Done.
---
## Issues – Project Board Fields
In each issue, you can find several fields on the right-hand side. These fields are also reflected in the project board.
<img width="300" height="350" alt="image" src="https://github.com/user-attachments/assets/c2e96360-e139-4b6f-964a-59b85a6a5606" />
- `Priority`: Used to apply the MoSCoW method (Must, Should, Could, Won’t) to indicate the importance of an issue.
- `Size`: Indicates how complex you think the work is, estimated using Planning Poker with a Fibonacci scale.
- `Estimate`: The expected time needed to complete the issue (I use hours). The total of all estimates is visible per column.
- `Iteration`: Used to assign issues to sprints. Filtering by iteration shows all work completed within a specific sprint.
- `start date` and `target date`: Used to set deadlines. Especially useful when reviewing or planning work in the roadmap.
### Customizing These Fields
In the top-right corner, click the `three dots` and then `Settings`.
<img width="800" height="100" alt="image" src="https://github.com/user-attachments/assets/2e52b87a-e42d-4174-8195-2f0a684fc576" />
- `status`: These represent the columns we created earlier on the project board.
- `sub-issues progress`: I find this field distracting, so I disable it. ***I will show how to do this later.***
- `priority`: Here I define my MoSCoW fields, based on sprints, each with a short description
- `size`: Here I create values based on the Fibonacci sequence, used for Planning Poker estimates.
- `estimate`: I only adjust the name by adding `in hours` to make the meaning clearer.
- `itteration`: Used for sprints. I prefer two-week sprints, so I leave this setting unchanged.
- `start date` and `target date`: I also leave these fields as they are.
### Visible Fields
In the project board, you can see which fields are selected for that issues. I find the default layout unclear, so I customize it via `View → Fields`:
<img width="800" height="700" alt="image" src="https://github.com/user-attachments/assets/3c13a723-f9e5-4c9a-9c94-bb62bbf06e7c" />
The fields I keep visible are:
- Priority
- Size
- Estimate
- Labels
- Parent issue
- Assignees
The order of these fields determines how they appear in the issue view. (drag and drop to youyr preference)
### Labels
How to create or modify labels:
`open an issue` → `click the settings icon next to Labels` → `Then click Edit labels at the bottom`
By default, a bug label already exists, so I do not change anything here.
I usually do not work with labels. With labels, you can add multiple values to a single issue, such as multiple MoSCoW priorities or multiple sizes.
In the fields that we adjusted earlier, only one option can be selected by default. Selecting multiple options is not possible, and when you change the value, it is updated rather than added.
### Type
In my FDND agency project from semester 3, there was a field called Type.
This field was used to indicate what kind of issue it was, for example an epic, feature, or task.
It is similar to labels, but only one option can be selected.
The Type field does not exist by default in GitHub Projects, you need to create it yourself.
In Project settings (the three dots in the top right corner of the project board → Settings),
you can create custom fields by clicking the `+` button.
<img width="515" height="393" alt="image" src="https://github.com/user-attachments/assets/8c2c4ac4-07a0-46a2-8636-a7a8f2df6d0c" />
I named the field `Type`,
set the field type to `Single select`,
and created the following options:
- `EPIC`
- `USER-STORY`
- `FEATURE`
- `TASK`
- `BUG`
- `FEEDBACK`
- `DOCUMENTATION`
I use uppercase names so they are easier to distinguish visually on the project board.
### Issue Templates
To ensure that issues are written clearly and consistently, you can create issue templates that help guide users when creating an issue.
In your repository settings, under Issues:
<img width="800" height="60" alt="image" src="https://github.com/user-attachments/assets/0e847782-e219-42dc-9744-12510bf8b3aa" />
<img width="800" height="275" alt="image" src="https://github.com/user-attachments/assets/5155a632-4475-4e80-9089-ba544b5a459a" />
GitHub provides default templates, but you can also create custom templates tailored to your project.
You can also create a `.github/ISSUE_TEMPLATE` folder in the root of your project and write all your issue templates there.
After that, you can push them to GitHub.
After creating the issue templates, GitHub automatically shows all available issue template options when you create a new issue. You can then select the appropriate template and fill in the required information.
---
## Branches
When creating a branch, I prefer to start from the issue.
In the right hand column of the issue, you can find the option to `create a branch`, which is then automatically linked to that issue.
This also ensures a consistent branch naming convention by including the `issue number` and `issue title`
<img width="460" height="141" alt="image" src="https://github.com/user-attachments/assets/4a4ef9a0-8d92-4015-81d4-a8e4ea0c3019" />
You can click `Create branch` and follow the steps in the popup to create a new branch.
By selecting `Checkout locally`, GitHub provides the terminal commands that you can copy and paste into the terminal of your project directory.
You can also use `GitHub Desktop`. Both options are convenient because the branch is created for you and you are automatically switched to that branch.
### Pull Request Template
In the `.github/` folder, you can also create pull request templates.
The file must be named `PULL_REQUEST_TEMPLATE.md`
Just like with issues, the contents of this template are automatically shown when a pull request is created.
---
## Charts
When you click `Insights` in the top-right corner of the project board, you can access the charts view.
<!-- <img width="800" height="100" alt="image" src="https://github.com/user-attachments/assets/7e1f8c9a-0492-43c9-af33-3faa495e7eff" /> -->
Some charts, such as the burn-up chart, are available by default, but you can also create custom charts.
What’s important when creating charts is that they use the fields we just created and customized, as these fields determine what data can be visualized.
I don’t have enough "data" in my project board to experiment with this. I’ll come back to it after a few sprints.
---
## Automations
With workflows, you can configure what your project board does automatically:
<img width="800" height="100" alt="image" src="https://github.com/user-attachments/assets/2e52b87a-e42d-4174-8195-2f0a684fc576" />
### Editing Default Workflows
#### Auto add to project
By default, only open issues are added to the project board: `is:issue is:open`
By adding pull requests to the filter, PRs will also be added to the project board: `is:issue,pr is:open`
#### Item added to project
Issues and pull requests are now added to the project board, but by default they are placed in a **New** column with the status `No status`.
In the workflow `Item added to project`, you can change this behavior.
If you change the `Set value` field to `Backlog`, newly created issues and PRs will automatically be placed in the Backlog instead of ending up in a `No status` column on the project board.
#### Pull request linked to issue
I was stuck on this for quite a while.
I wanted pull requests to be automatically moved to the `Review` column, but all the examples I found online used either
[GitHub Actions](https://docs.github.com/en/issues/planning-and-tracking-with-projects/automating-your-project/automating-projects-using-actions)
or additional / [duplicate workflows](https://docs.github.com/en/issues/planning-and-tracking-with-projects/automating-your-project/adding-items-automatically#duplicating-the-auto-add-workflow).
However, on the free GitHub plan there is a limited number of workflows available, so I couldn’t use those options.
I then took another look at the default workflows and noticed that I wasn’t really using `Auto close issue`.
That workflow automatically closes an issue when it is `dragged to the Done column`.
I don’t use this flow, I always close issues manually from the issue page instead of dragging them to Done.
So I thought: I’ve disabled a workflow, which means I should now be able to create a duplicate one.
Unfortunately, that’s not how it works.
After that, I noticed the `Pull request linked to issue` workflow.
When you create a PR from an issue using `Create a branch`, this workflow allows you to move the issue to a different column when the PR is created.
In this workflow, I changed the `Set value` to `Review`.
Now, the **issue** is automatically moved to the **Review** column as soon as a PR is created, without using GitHub Actions.
Note: this only moves the `issue`, not the PR itself. The `PR` will still remain in the `Backlog`.
Which is not what I originally wanted, but good enough.
Also, the issue stays in its current column until you create a PR for the branch, which is ideal because it allows the issue to remain in `In Progress` while you’re still working on the branch.
If you didn’t create the PR from the issue, you can still link it afterward by adding the PR to the issue manually:
<img width="425" height="116" src="https://github.com/user-attachments/assets/58a8f145-7668-48fc-8321-e7feb0947d8a" />
## Links
- [project setup blog by Joeylene](https://dev.to/jorenrui/a-look-into-how-i-manage-my-personal-projects-my-git-github-workflow-1e7h#project-boards)
- [github workflows](https://docs.github.com/en/issues/planning-and-tracking-with-projects/automating-your-project/adding-items-automatically)
- [PR to review column with github actions](https://docs.github.com/en/issues/planning-and-tracking-with-projects/automating-your-project/automating-projects-using-actions)
User/ author
Handle: @user2 Username: user two Account create date: 2026-03-20T13:27:31+00:00 Title: SvelteKit Remote Functions
Post ID: 8df0078c-79da-4867-be0c-88a93e902dce Description: This blog post focuses on using form-based remote functions in SvelteKit to handle server-side filtering in a component-based architecture. Content:
# SvelteKit Remote Functions
> This blog post focuses on using **form-based remote functions in SvelteKit** to handle server-side filtering in a component-based architecture. It explains _why_ this approach was chosen, _how_ data flows between the server and components, and _which pitfalls to avoid_.
> To keep the post concise, it does not include code examples. Instead, a **[GitHub repository](https://github.com/vsheo/SvelteKit-Remote-Functions)** with a fully working form-based remote function and inline comments is provided for reference.
[live link](https://sveltekit-remote-functions.netlify.app/form-filter)
***Files in the Repository***
The following files and directories are needed for this project:
- **Remote functions:** [`src/lib/remote/`](https://github.com/vsheo/SvelteKit-Remote-Functions/blob/main/src/lib/remote/filter.remote.ts)
- **Server data:** [`src/lib/server/`](https://github.com/vsheo/SvelteKit-Remote-Functions/blob/main/src/lib/server/images.js)
- **Reusable components:** [`src/lib/components/`](https://github.com/vsheo/SvelteKit-Remote-Functions/tree/main/src/lib/components)
- **Filter page - +layout.server.js:** [`src/routes/(form-filter)/form-filter/+layout.server.ts`](https://github.com/vsheo/SvelteKit-Remote-Functions/blob/main/src/routes/(form-filter)/form-filter/%2Blayout.server.js)
- **Filter page - +page.svelte:** [`src/routes/(form-filter)/form-filter/+page.svelte`](https://github.com/vsheo/SvelteKit-Remote-Functions/blob/main/src/routes/(form-filter)/form-filter/%2Bpage.svelte)
- **Remote functions configuration:** Remote functions are enabled in [`svelte.config.js`](https://github.com/vsheo/SvelteKit-Remote-Functions/blob/main/svelte.config.js)
*You can change the directory to your preference as long as it is inside lib. I chose this structure because I plan to experiment with additional remote functions here as well*
## What are Remote Functions?
[Remote functions](https://svelte.dev/docs/kit/remote-functions) are a tool for type-safe communication between client and server. They can be called anywhere in your app, but always run on the server, meaning they can safely access server-only modules containing things like environment variables and database clients.
Combined with Svelte’s experimental support for await, it allows you to load and manipulate data directly inside your components.
In practice, this means you write server logic once, and components can call that logic directly
## Which Type of Remote Function Is Used (and Why)
SvelteKit remote functions come in **four official flavours**: **query**, **form**, **command**, and **prerender**. Each one is designed for a different kind of client–server interaction.
This blog is about using the form.
### Remote Function - Form
`form` is the right choice when you want to submit data from an HTML `<form>`.
**What it’s good at**
- Handling `<form>` submissions
- Validating submitted `FormData` on the server
- Writing your own JavaScript logic to process the form request
- Returning results back to a component
In [this project](https://designingforrecognition.dev.fdnd.nl/), I initially got the filtering working **without** remote functions. The checkboxes submitted correctly (the URL got updated with the filter request), but after applying filters I only saw the updated results **after a full page reload**. I’m not entirely sure why it behaved this way in my setup.
Instead of forcing a manual refresh, I followed my teachers’ advice and explored whether **remote functions** could solve it in a cleaner way.
That turned out to be a great fit, because the project was structured around components:
- a **Filter component** (where the user selects options)
- a **results component** (where the filtered projects are displayed)
With a remote function, I can:
- call the remote function from the **Filter component** to submit the form and apply the filters **server-side**, updating the project list on the server
- use the **same** remote function in the **ProjectCardContainer** to read the updated filtered list and render it
Because both components use the same remote function, the filtering logic stays remains on the server and does not depend on +page.svelte.
This meansthat when the remote function is called:
- the filtered data is not first returned to the Filter component and does not have to go through +page.svelte to reach the results component.
- Instead, each component communicates directly with the server through the same remote function.
- The Filter component submits the filter values, while the ProjectCardContainer independently requests the filtered project list.
## What You Need to Use Remote Functions
To implement this setup, you need:
- **SvelteKit** with support for remote functions
Remote functions are experimental and must be explicitly enabled in your `svelte.config.js`.
- **data**
Data that is fetched and will later be used for filtering.
- A **remote function file**
This file must follow the naming convention
`your-function.remote.ts` or `your-function.remote.js`.
- **Valibot**
Valibot ensures that only trusted and well-structured data reaches your server and helps protect against malicious input.
- Components that:
- submit data via a form
- showcase the returned result from the remote function
### My data structure choice
I placed the data fetching logic in a shared location so it can be used by both `layout.server.js` and the `remote function`
_While writing this, I realized I could also have written a separate fetch directly inside the remote function, but this makes the fetch reusable._
- In `src/lib/server/projectData.js`, I defined a function that fetches the full projects dataset.
- When the page loads, this function is called from `layout.server.js`. From there, the complete project list is passed down to the result component as initial data.
- after the page is loaded the fetch inside the layout.server.js is not called again
- In the remote function, I call the same data-fetching function again to retrieve projects.
- This fetch is executed on every filter submit so the filtering logic always works with the most up-to-date data.
## What I did wrong
At the time I was working on this, there were very few practical examples available onlinefor my specific case.
*There were, however, many examples of login implementations*
Reading the documentation was difficult for me, and the lack of concrete examples made it hard to understand the concepts at first. I read the Svelte documentation multiple times, but I still did not fully understand how remote functions were meant to work.
These are the things I did not understand at first or did incorrectly:
- I initially tried to write remote function logic inside `page.server.js` and `layout.server.js`.
- This does not work: remote functions must be defined in a separate file named `*.remote.ts`.
- I tried to directly adapt the filtering code I already had into a remote function.
- I eventually had to take a step back and start from scratch in a clean project.
- After many attempts, I still could not get it working.
- I then copied the example from the Svelte documentation, and that version did work.
- I had previously removed [imports](https://svelte.dev/docs/kit/remote-functions#form) I thought I did not need (such as `import { form } from '$app/server';`).
- While some imports were indeed unnecessary for my case, removing others caused the example to break.
- From there, I started making small changes, removing or modifying one line at a time to understand what each part did.
- I initially tried to access data fetched in `+layout.server.js`, but later realized that this data is sent to the client, so remote functions cannot access it
- I later realized that the HTML structure of the form must be written in a specific way for form based remote functions.
- You need to let SvelteKit generate the attributes on the `<form>` and `<input>` elements.
- I initially assumed that a standard `action` attribute on the form would be sufficient, but this does not work with form based remote functions. You need something like [this](https://svelte.dev/docs/kit/remote-functions#form-Fields)
- Lastly, I skipped a lot of SvelteKit concepts I actually needed, such as **runes**. Even after my remote function worked, I still had to figure out how to display the updated results in the browser.
- For this, I needed runes (`$effect`, `$state`, and `$derived`) to ensure the results reactively update whenever the remote function is called.
## Final Notes
While the learning curve was steeper than expected, once I understood the missing pieces, the purpose of remote functions became much clearer. At first, I did not see how they were helpful or better than other approaches.
That changed after discussing it with a teacher, who pointed out that remote functions can be called directly from components, allowing those components to work independently from each other.
In my first working version, I called the remote function from the Filter component and then passed the filtered list through `+page.svelte` to the results component. Using a shared remote function instead removed that dependency and resulted in a cleaner, more component-focused architecture.
User/ author
Handle: @user2 Username: user two Account create date: 2026-03-20T13:27:31+00:00