Forem: Tom Österlund

Event Calendar with Shadcn theme 💅

Tom Österlund — Tue, 10 Dec 2024 07:57:41 +0000

Shadcn has become wildly popular, and is an easy way to set up a web-app with some well-styled components. But lately, when I've seen my users integrate the Schedule-X scheduler into an app with Shadcn, it just doesn't look right...

🎉 Enter @schedule-x/theme-shadcn

In this tutorial, I will walk you through how to integrate Schedule-X into a Shadcn project. Also, a demo app with this calendar can be viewed at: https://schedule-x-shadcn.vercel.app/

1) Install Schedule-X

First let's install the dependencies we need.

npm i @schedule-x/react @schedule-x/calendar @schedule-x/theme-shadcn

2) Import and set up some CSS

Then we need to import the CSS for the calendar...

// layout.tsx or _app.tsx depending on your router
import '@schedule-x/theme-shadcn/dist/index.css';

...and set some styles for the calendar wrapper element. The calendar does not have any default height set to it, since this will differ for every use-case.

/* globals.css */
.sx-react-calendar-wrapper {
  height: 700px;
  width: 100%;
}

3) Create calendar component

Then the most important piece; the event calendar component. In this case we're using useNextCalendarApp. If you're using React but not in a Nextjs-app, you should use the useCalendarApp-hook instead.

// EventCalendar.tsx
'use client';
import {ScheduleXCalendar, useNextCalendarApp} from "@schedule-x/react";
import {createViewDay, createViewMonthAgenda, createViewMonthGrid, createViewWeek} from "@schedule-x/calendar";

export default function EventCalendar() {
  const calendarApp = useNextCalendarApp({
    views: [
      createViewWeek(),
      createViewDay(),
      createViewMonthAgenda(),
      createViewMonthGrid(),
    ],
    theme: 'shadcn',
    calendars: {
      johndoe: {
        label: 'John Doe',
        colorName: 'johndoe',
        lightColors: {
          main: 'hsl(210 40% 93.1%)',
          container: '#000',
          onContainer: 'hsl(210 40% 93.1%)',
        },
      },
    },
    selectedDate: '2023-12-01',
    events: [
      {
        id: 1,
        title: 'Coffee with John',
        start: '2023-12-01',
        end: '2023-12-01',
        calendarId: 'johndoe'
      },
      {
        id: 2,
        title: 'Breakfast with Sam',
        description: 'Discuss the new project',
        location: 'Starbucks',
        start: '2023-11-29 05:00',
        end: '2023-11-29 06:00',
        calendarId: 'johndoe'
      },
      {
        id: 3,
        title: 'Gym',
        start: '2023-11-27 06:00',
        end: '2023-11-27 07:00',
        calendarId: 'johndoe'
      },
      {
        id: 4,
        title: 'Media fasting',
        start: '2023-12-01',
        end: '2023-12-03',
        calendarId: 'johndoe'
      },
      {
        id: 5,
        title: 'Some appointment',
        people: ['John'],
        start: '2023-12-03 03:00',
        end: '2023-12-03 04:30',
        calendarId: 'johndoe'
      },
    ]
  })

  return <>
    <ScheduleXCalendar calendarApp={calendarApp} />
  </>
}

Now we're almost there! Lastly, you need to import the EventCalendar.tsx component you just created, in your app:

<EventCalendar />

And that's it!

For more info and documentation for the Schedule-X event calendar, please visit: https://schedule-x.dev

If you like the project, you can also show some appreciation by leaving a star for the GitHub repo, over at: https://github.com/schedule-x/schedule-x

Light- and dark mode CSS, the easy way

Tom Österlund — Mon, 13 May 2024 06:22:20 +0000

One of the never-ending tech-battles on social media right now is the battle between light- and dark mode. Everyone knows this is ultimately a matter of good and evil. Light side of the force vs. dark side of the force.

Whether you prefer light mode or dark mode: as a web developer, there is a high chance you need to know how to support both modes. When building the Schedule-X calendar, I used a method for supporting both modes with very low effort. And here's how you can do it too.

Step 1: define all colors as CSS custom properties

Firstly, you need to define all the colors you want to use in CSS custom properties. You can create a color.scss file, looking something like this:

:root {
  --color-primary: #6750a4;
  --color-on-primary: #fff;
  --color-primary-container: #eaddff;
  --color-on-primary-container: #21005e;
  --color-secondary: #625b71;
  // ... and so on
}

Now, if you're using SCSS like I do, you might be tempted to write these colors as SCSS variables, like $color-primary. But don't! These SCSS variables only exist at compile-time, and won't be around to be altered at run-time where we will need them later.

Step 2: using the CSS custom property-colors everywhere in your application

If you want to successfully use this method, you need to stick consistently to this rule. Wherever you use colors in the application: use them through CSS custom properties. Even if it's "just" a simple border color, don't cheat; border colors typically need a very different nuance in dark mode than they do in light mode! So for example:

.my-rule {
  border: 1px solid var(--color-neutral);
}

Step 3: Create a single dark-mode rule

In the same file where you defined your colors for light mode, you can add a rule for the selector .is-dark, like this:

.is-dark {
  --color-primary: #d0bcff;
  --color-on-primary: #371e73;
  --color-primary-container: #4f378b;
  --color-on-primary-container: #eaddff;
  --color-secondary: #ccc2dc;
  // + other properties
}

Now what does this rule do?

Basically, it just means, that whenever you slap the class name is-dark onto an element, the dark mode colors will start being applied to everything inside of that element - as long as you consistently used the custom properties for defining color.

And that's it! Creating a dark mode for your web project does not have to be hard.

If you want to play around with the concept yourself, here's a brief demo for how it works on Codepen:

Yes, for now you can skip some basics and learn a framework

Tom Österlund — Thu, 25 Jan 2024 17:17:11 +0000

TL;DR

There is a lot of hype online around statements such as "things you need to learn before learning a framework".
While skipping the basics of a language completely is not a good idea, it is perfectly possible to learn the foundations of a programming language, parallel to learning a development framework for that language.
A better rule of thumb is: "never stop learning your programming language".

My story

I started learning JavaScript in the spring of 2020. Due to the covid lockdowns of Berlin I had a lot of spare time to learn programming. If you're learning a programming language with even remotely as broad a usage as JS, you will know that it's impossible to learn the language well in a couple of months.

Needless to say, when I started learning Vue.js through a Udemy course after 2 months of coding, I was still a proper noob.

Having spent the first 5 years of my professional career as a teacher, I know how crucial motivation is for achieving learning results. If a student is not motivated, chances are high their results and grades will tank. If a student remains motivated and is having fun while learning, chances are way higher they will also achieve some sort of academic success.

Coding is not an exception.

It therefore didn't take me much consideration to ignore all the warnings, and start learning Vue.js, even though I wouldn't know how to use any of the Array.prototype methods by heart, except maybe push. Even less so did I understand even a fragment of how JavaScript objects work.

But wait! If you don't learn all the JS-basics before learning Vue, you will always be a noob!

I call bullshit.

Going forward, I kept learning not only Vue, but also React and Node.js during that first year. I was having a blast and and was programming almost around the clock when not working. I was super excited about building full-stack applications, and using the best tools for doing so. I couldn't limit myself to learning programming basics, without dealing a blow to my high level of motivation. What might have set me apart from some people who never truly learn the intricacies of JavaScript is this: Sure, I started using frameworks right away, but I never stopped learning the foundations of JS.

A better attitude

And I think this is the correct attitude to promote: never stop learning your programming language. We shouldn't discourage people from having fun and learning stuff they are interested in. But we should encourage people to never neglect the basics of a programming language.

You can start learning Vue without understanding all the ins and outs of the this keyword. But in the long run you will be a much better developer if you have a strong understanding of this complicated little word.

You can learn how React hooks can help you manage state and build some nice little learning projects with it. But in the long run you will be better off if you also understand reactivity in JavaScript through concepts like Proxies, getters and setters.

I don't see anything stopping people from learning these concepts in parallel though.

As a matter of fact, if I had to try and teach someone how reactivity works in single page applications, I'm pretty sure I would NOT start by trying to teach someone Proxies and ES6 classes with getters and setters. Using React hooks or Vue.js ref might even be better abstractions to learn JavaScript reactivity with for a beginner. Then one could tackle more advanced "vanilla JS" topics later.

A word of caution

Okay, so learning a development framework is possible to do parallel to learning a language. Still, I would not have peace with this text without ending it with a few words of caution:

Sure, you can skip the basics and start learning a framework.

❗️For now❗️

If you cheat, and just skip learning the basics of your programming language forever, you will likely forever stay a noob.

You will try to debug the state of your Redux or Pinia store, and not understand when state mutated in an unexpected way, and even less understand why. You will assign new objects to objects passed a function parameters, and desperately scroll through Stack Overflow to try and understand why the damn object doesn't update as you'd expect. You will curse when you have memory leaks, because you didn't understand that a class method doesn't have the same reference value when referenced once in document.addEventListener and then later in document.removeEventListener.

For me, a couple of courses on Udemy helped me build up a level of understanding for JS, which I am now very grateful for having learned parallel to learning frameworks:

JavaScript - The complete Guide

Accelerated ES6 JavaScript Training

If the message here resonates with you: glad to hear from you! If this triggers you and you strongly disagree, don't hesitate to let me know 😊

How I built a cross-framework frontend library

Tom Österlund — Wed, 17 Jan 2024 15:47:14 +0000

TL;DR

Web-frontends today are built using an ever-increasing number of frameworks. Vendor lock-in is a real problem.
Writing cross-framework frontend libraries does not have to be complex. It merely requires careful planning.
Teleport / Portals are key for giving the implementer freedom to customize.

This article will discuss the general concept of building a cross-framework frontend library. It will also display some examples of how this was applied when building the event calendar Schedule-X.

The problem with framework-overflow

If you start building a frontend web-application today, one of the first technical decisions you will have to take is which framework to choose. Probably you will end up with one of the 3-4 most popular ones, but there are so many out there.

Now, I don't agree that this would be inherently bad. People come up with a lot of different solutions to similar problems all the time. People are essentially different, and will prefer different solutions. You're never going to convince me that mass producing Mercedes-Benz and Peugeot was unnecessary, just because Henry Ford had already started mass producing cars before them. Similarly: Vue, React and Angular do not make newer options redundant.

One of the challenges that do arise due to this abundance of frameworks, is a thing called vendor lock-in; you pick one framework, and chances are high you will stick to this for the duration of the project. Even if the project lasts for many years.

This too, does not necessarily need to be a problem. If the framework thrives, and its eco-system does too, this does not matter. When it does matter, is when the framework you chose, or its surrounding eco-system, starts slowing down. Your company might need a whiteboard software. But all the cool whiteboard projects out there are only compatible with all the other frameworks, not yours. What do you do?

Writing cross-framework libraries is not that hard

Some of the problems that arise due to vendor lock-in, could be resolved if more libraries chose to work without frameworks. Here is an illustration of how this can work conceptually:

OK, what is going on in this image? Let us go through this architecture piece by piece.

1. The library core

At the very bottom of the image, there are 3 blocks that I chose to call application components. If you are building a cross-framework library, these can be built with whatever tools you want! Only catch is, all the tools you use to build it, will be needed by everyone consuming it. So choose wisely, and be mindful of how many kilobytes of third party code you will need in order to ship. In Schedule-X, I chose to use Preact. You will probably be fine with most lightweight virtual DOM libraries, and just like with frameworks there are a few to pick from.

2. Pure JS/TS function or object

In order to be consumed by different types of frameworks, your library will need to be compiled to regular JavaScript. So in the end, after you have run your build scripts, the result you need is a vanilla JavaScript function or object, which under the hood mounts your application. Here is how I did this in Schedule-X:

import { createElement, render } from 'preact'
import CalendarWrapper from './components/calendar-wrapper'
import CalendarAppSingleton from '@schedule-x/shared/src/interfaces/calendar/calendar-app-singleton'

export default class CalendarApp {
  constructor(private $app: CalendarAppSingleton) {
  }

  render(el: HTMLElement): void {
    render(createElement(CalendarWrapper, { $app: this.$app }), el)
  }
}

I here have a very slimmed down class, CalendarApp, with a render method. All the render method is doing, is call the render function of Preact, mounting my calendar to the DOM. Anyone instantiating this class and calling the render method with an element passed to it, will get a calendar to consume.

3. Consuming the library

The last puzzle piece of the image above is the consumer-piece.

After I have compiled this TypeScript file above into JavaScript, anyone executing JavaScript in a modern browser can consume it: React, Angular, Vue: they can all run it. At this point, we already have a framework agnostic library, ready to be consumed by many frontend teams, regardless of their choice of tooling. One important piece is missing though.

Giving the implementer ultimate freedom

So you have built your frontend library. You spent countless hours on perfecting the looks and feel of it. Every pixel looks perfect to you. Still, if you're going to offer this library to the multitudes, chances are it won't fit into the design system others are working with.

I, for example, built the Schedule-X calendar leaning heavily towards Material Design 3. While this might work for some, it surely won't work for all. It is therefore important that I offer implementers a way of customizing what shows up in the calendar. Ultimately, it would be nice if implementers of my library could replace some components of my code with their own. This can seem like a daunting task at first. It sure did to me. Nevertheless, the solution does not have to be very complex.

In the example below, I will demonstrate how this can be done with React, but the same principles apply to any framework where UI components have reactive state that triggers DOM changes.

Here's how it works, broken down into 4 steps. Each of the steps below correlate to the same number in the image above.

There needs to be a React component, let us call it the ReactAdapter component. This component has a rendering function like all others, which places some content in the DOM. Most importantly, this component has a customComponentFn function. We can pass this function as part of the configuration to the library components. Also note that the function receives an argument: element.
In the presence of customComponentFn, our application component notices that we want to render som custom stuff. Doing so, instead of rendering its own content, it just calls customComponentFn. Here, we also pass an element, which is empty for now, but sits exactly in the place of the DOM where we want to render some custom content.
In the customComponentsMeta variable of our React component, our customComponentFn now saves some metadata about the custom component we want to render, as well as the element it should be rendered onto.
Updating the state of ReactAdapter causes our React render function to run again. This time around, we have some metadata about a custom component and the element to render it to. Using createPortal (in Vue this would be Teleport) we can now render our custom component.

Voila! We have built a cross-framework library.

Curious for more?

If these concepts sound interesting to you, but you need more precise examples of how this actually pans out in code, you can check out the actual source code that this article is based on:

React implementation: https://github.com/schedule-x/react/blob/main/src/schedule-x-calendar.tsx
Application component calling a customComponent function provided by React: https://github.com/schedule-x/schedule-x/blob/main/packages/calendar/src/components/week-grid/date-grid-event.tsx#L79

From teacher to software developer in less than 1 year

Tom Österlund — Wed, 10 Jan 2024 08:15:55 +0000

In 2020, I made a journey, starting the first week of COVID lockdowns in the beginning of March, and ending with a signature on the contract of my first developer job, in December the same year. Since then, I’ve been asked many times by people I met, how one can simply switch from pedagogical work into IT, like I did. So without further ado, here’s how it happened:

The beginning: coding the night away

In the beginning of 2020, I was working as a primary school teacher at an international school in Berlin. I had no hard feelings about the profession itself. Working in schools has the potential to be very stressful, but also to be a lot of fun.

During a conversation with a coworker, this then colleague of mine told me that he had started thinking of switching into IT. He had just taken on the role of doing IT-support for us other teachers, and was learning to program in PHP in his spare time.

At the time, I found this a peculiar concept. A coding teacher? I then asked him a question, which I have since also received myself from numerous people: “don’t you need to be really good at maths and science for that stuff?”

Fast forward a few weeks, and I was sitting in an old, noisy, Berlin subway car on my way home from work. COVID was still new. Due to the circumstances, it was clear that this had just been my last day on-site at the school in a while. Working with children in the age of 7–9, it was also clear that we would not be able to spend nearly as much time as otherwise with our students during the lockdown to come. The students were simply too young to be able to spend their whole day in front of a computer. This left me with a thought: if I end up having more spare time than usual, should I maybe try and learn some new skill? Walking out of that very same subway car some 25 minutes later, I had decided: I’m gonna try out programming.

But hey, how does one simply start programming, with no previous knowledge of computer science?

For me, it started with coming home, opening up my laptop, and typing “learn programming” into Google. The top search result in my case, was a course in HTML on freeCodeCamp.

In retrospect, I have realized how such a trivial thing as a Google search, had a huge impact on my career. I simply picked the first result. Had Google instead suggested me a course in Golang or Python, maybe my career would have taken a different turn. In my case, that night in March, I ended up embarking on a journey of learning web development, starting with a simple “hello world” HTML exercise. Many exercises and a first simple webpage later, I shut my laptop and went to bed, just as the sun was about to rise over Berlin for a new day. I knew right away: being so excited about something that I could barely allow myself to go to bed, that doesn’t happen all the time. I knew, going to bed after that first long night of coding, that I had to try and change careers.

The journey: hard work, doubts, and overcoming

The first few weeks of learning to build software, I finished that first course in HTML and CSS, and I started a course in programming with JavaScript, also on freeCodeCamp.

Though the world was experiencing a major change in the way we live and interact with others, and despite all uncertainty of how things would turn out, I was genuinely excited about the future, much thanks to this new hobby.

I built a webpage dedicated to my then fiancé, now beloved wife.

I built a quiz application for my students, which I proudly managed to deploy to Google Cloud, with the help of a friend. Here's a screenshot of the site, where my students battled the "grammar monster" in some different punctuation and spelling exercises.

I could barely find words to describe my joy, as I received the first emails with feedback from parents: the quiz website was a hit! Are there more quizzes coming?

I started staying up late almost every night, learning about control structures, data structures, CSS tricks and so on. When going for walks alone, I would more often than not hear podcasts on web development. The Syntax podcast became one of my new highlights every week. Most of the time, I enjoyed it a lot. But this story would not be complete without the other side of the story: the doubts.

Many people hold the belief, that one can only become a software developer through studying computer science at a university. I shared this belief up until 2020. Though I heard from a lot of people that this is not true, I also had my moments of doubt.

I remember a particularly frustrating week, still in the spring of 2020, where I was doing some algorithm challenges at freeCodeCamp. The website provided a task, such as: “write a function that takes an array-parameter ‘people’, that returns a list of all people older than 18, and sorts them in descending order according to their age.” You could then write a function directly in their interactive editor, and test it right away. In the beginning, I got almost every algorithm challenge wrong, which was very unsatisfying at times. Learning to work with data structures and algorithms can be hard work, regardless of whether you have a computer science background or not.

Some nights, I shut my laptop in pure frustration, thinking maybe I’m too stupid for this. Though for me I wouldn’t call it impostor syndrome, which is a very popularized term among people in IT, I did struggle. Sometimes hard. For me being a believer in God, this sometimes led me to long doubtful conversations with him, in despair over my perceived inabilities.

Though for every night of doubts and struggle, there came a morning of excitement. I just couldn’t get enough!

Getting serious: learning frameworks and starting the job search

In may of 2020, only a couple of months after that first night, I took the decision to start learning a JavaScript framework for developing websites: Vuejs. Though some people warn not to start learning frameworks too soon, and instead keep learning the foundations of programming, I was too excited to keep learning the basics.

Here, in retrospect, I would also tone down the importance of such decisions: if you’re new to coding and excited to learn a framework: do it! You can, and probably should, always come back to the basics later. Most likely over and over again.

So I started learning Vue. I took a class with the brilliant teacher Maximillian Schwarzmiller on Udemy. His class was so inspiring, that I ended up taking his class on Nodejs a couple of months later, and thus I also learned the foundations of building server-side applications. For anyone new to web development, I highly recommend the Academind course platform, from Maximillian and his colleague. For the price of a normal lunch in Germany, you get monthly access to some high quality courses.

So it happened, that my basic knowledge in JavaScript, CSS and HTML, turned into basic knowledge of Vuejs and Node. I had no idea if this would be enough to land me a job, but being curious if it would, I sat down to write my first couple of job applications at the end of July in 2020, only 4 months into my learning journey!

Out of 2 applications, I even ended up having 1 interview!

The startup in question was working on a software for higher education, and they found it interesting that a teacher was applying for a job with them. Though I had a nice chat with the founders, and though the outcome of the talk seemed positive to me, they got back to me the following week: “thanks for your interest, but we’re moving on with a person with a bit more experience”.

I was disappointed, for sure. But it also made sense, that software employee n1 apart from the founders themselves, should preferably be someone experienced.

So the month of August came around, and school started again. Hopes about a new career in front of a code editor, turned into the reality of a classroom. I was once again walking around the classroom, helping first graders write their first few sentences, and playing catch with my students in the breaks. I had once been very passionate about being a teacher. But now my passion was so clearly somewhere else.

Though many might hold this to be foolish for an adult, I took the decision to quit my job, without having found a new one. Since I had a three month notice period, and was only allowed to quit at the end of each semester, this left me a 5-month deadline to find something new.

Thus began the most intense job hunt I ever went through. I talked to recruiters. I sent my resumé around. Probably to over 20 different companies. Out of those numerous applications, only two turned into proper interviews.

The first turndown, in October, I handled quite OK. I had time.

Though after traveling all the way to Munich by train, just to be turned down at the second company, this time in December, the doubts started coming around again. Had I quit my job to soon? In 2 months I would not have a job anymore, and now I also had no lead.

The breakthrough

Desperate to start my career in software, I took to desperate measures. Having previously restricted my job search to job postings written in English, I now translated my CV into German.

Then, I went for quantity.

I went over my template for a personal letter one more time, and made it generic enough to be passed around to the masses.

Over the course of the next couple of weeks, I applied to nearly a 100 different jobs!

Though it probably isn’t the best strategy to land a job, to send around those generic letters, with no mention of the company you’re applying to, it seemed like my only hope at the time. If you’re as desperate as I was at the time, I don’t see anything wrong in this strategy. Just one word of caution here: if you go for quantity, try and make sure you don’t burn any bridges with companies that seem extra attractive to you. For example, I deliberately did not apply to the company where I now work, since I knew that they might be a great future employer. If you have some company in mind for the future, maybe they shouldn’t yet see that impersonal, generic letter of yours.

So now I had almost a hundred job applications sent out. At times, I wasn’t even sure myself if this made sense, or if I was acting crazy.

But as a matter of fact: it worked!

As an early Christmas present for me, a few days before Christmas, I finally signed for my first job as a software developer. Silly as it might sound: that felt like one of the best things that had ever happened to me. I had worked so hard. I had poured my heart into this career change, learned JavaScript and TypeScript, learned three different development frameworks, and spent many long nights in front of my computer. And now the new career could begin.

The career change in numbers

10 months from first line of code, until first job
~60 Euro spent on Udemy courses
Foundations of 3 web frameworks learned: Vue, React & Express.js
Foundations of 2 programming languages: JavaScript & TypeScript
~100 job applications sent
3 interviews without a job offer
1 job offer

A few words on what I'm doing now

Nowadays I work at the German media company ProSiebenSat.1. It's a great company, treating their employees with respect, bringing fun, local content to the German speaking countries, and where I've had the chance to grow on many levels over the past year.

In my spare time I'm developing an open source event calendar. You can check it out at: https://github.com/schedule-x/schedule-x.

3 awesome libraries I started using in 2023

Tom Österlund — Mon, 08 Jan 2024 17:14:09 +0000

TL;DR

Just want the hot tips, and no blabbering? Here's the summary:

eslint-plugin-boundaries: Eslint plugin for keeping large code bases organized and promoting module encapsulation.
ts-sinon: Easily create stubs for all types of objects in your TypeScript project.
Preact: 3kb alternative to React

Awesome software I started using in 2023

One of the things I love about starting new projects, or joining a new team, is that I get to learn new technologies. In 2023 I joined a new company, and started a new open source project. This gave me two chances of learning new stacks and new tools. Without further ado, here are 3 tools that have transformed the way I write code in the last year:

eslint-plugin-boundaries

I love organizing my frontend code as monorepos. This helps me define different packages of modules, and define how they relate to one another. It's a great pattern for scaling. One problem that all monorepos need to solve, is defining rules for how packages are allowed to depend on one another. This is where eslint-plugin-boundaries can be a huge help. With this plugin I can define packages as such in my eslint-config:

{
  "settings": {
    "boundaries/elements": [
      {
        "type": "helpers",
        "pattern": "helpers/*"
      },
      {
        "type": "components",
        "pattern": "components/*"
      },
      {
        "type": "modules",
        "pattern": "modules/*"
      }
    ]
  }
}

And then I can enforce rules for how they are allowed to depend on one another like this:

{
  "rules": {
    "boundaries/element-types": [2, {
      "default": "disallow",
      "rules": [
        {
          "from": "components",
          "allow": ["helpers"]
        },
        {
          "from": "modules",
          "allow": ["helpers"]
        }
      ]
    }]
  }
}

In the example above, all dependencies between packages is disabled by default. Then I allow components and modules to depend on the helpers package.

ts-sinon

My unit tests used to be way more bloated and unreadable than they are now. To some extent, ts-sinon helped me reduce this. Though this library is far from new, and not very famous, I love it! Given a TypeScript interface as such:

interface Product {
  price: number
  sale: boolean
  title: string
  id: string
}

I used to create mock objects in my tests such as:

const mockProduct = {
  price: 10,
  sale: false,
  title: 'Engine Wroom x100',
  id: 'asdfghjkl'
}

With ts-sinon, I instead do this:

import { stubInterface } from 'ts-sinon';

const product = stubInterface<Product>()

If I then need to set a property to a certain value, I just override that one property of the stub. For larger objects, this saves me from a great many lines of redundant test code.

Preact

Most importantly, I last year started working with Preact. Basically, the objective of this library is to offer the same APIs as React, but in 3kb of minified code! Isn't that great?

I had come across the name Preact many times over the last couple of years, but never checked it out. Now, I'm a big fan. For any project where a heavy JavaScript-framework is unnecessary, but I still want a library to perform most of the heavy lifting for me, I would now reach for Preact. No doubt.

Preact also offers it's own solution for state management called signals. Coupled with the Context API, signals can help you manage global state, similar to if you were working in a regular React application.

Lastly

If this content is helpful to you, consider checking out my profile on X, where I'm blogging about building an open source calendar: https://github.com/schedule-x/schedule-x

I built an open source web calendar inspired by the Google calendar

Tom Österlund — Mon, 08 Jan 2024 06:10:52 +0000

Shameless plug coming right up

Hi everyone. My name is Tom, and I’ve done it again.

“Ok?” You might think. “I don’t know you. What have you done?”

For some reason, I have become very fond of building web calendars. As a matter of fact, I’ve spent some time almost every day for the past two years doing so. For my third stab at building a calendar, I decided to lean heavily on the Material Design 3 specification. I did my research. Studied the Google calendar and a few other similar ones. Then I coded. The result:

https://schedule-x.dev

Happy to receive feedback of any kind, good or bad.