DEV Community: Daniel Einars

Introducing CloudKit - A production ready Cloudflare Sveltekit template

Daniel Einars — Tue, 31 Oct 2023 13:16:28 +0000

Why?

I was sick of always doing all the project setup for a stack I'm very happy with. I put in the work to create this template to use with my projects and wanted to share it with the community. The text below is mostly identical to the README.md on github and on the demo page.

What

This is a complete Sveltekit Template designed to help you release you SvelteKit App on Cloudflare Pages using the following services:

TypeScript, ESLint, Prettier & Husky for pre-commit hooks
Lucia Auth with a production-ready Sign Up/In/Out flow and Delete Account flow
Prisma integration (psql & redis)
- redis:
- prod: Upstash Cluster
- dev/e2e: Local redis docker container
- psql:
- prod Neon.Tech Database
- dev/e2e: Local PSQL docker container
Image hosting & processing
- prod: Cloudflare Image Service
- dev/e2e: Thumbor docker container
Playwright for E2E Tests in Github Actions and for local development
Github Actions (including Linting, Type-Verification, Unit & E2E Tests)
Publishing Action for Github pages

You can check out the live example here.

Prerequisites

Becase PR.yaml action uses docker containers, you'll have to configure the following Github Action Secrets in a CI environment in order for the Workflow to run through without errors. Example Values of these can be cound in the .env.ci file.

Running this locally

Create a .env.development file (you can just copy the .env.example file)
Start up the docker containers (docker-compose up -d)
Run pnpm prep. This will
Run the correct prisma generate command
Push the schma to the local psql db
Run the pnpm psql:seed command which will generate a admin user and 10 random users.
Start the dev server (pnpm dev)

Running this in Production

You'll need to configure some services and environment variables in the Github Actions to run this in Prod.

Services

Cloudflare Pages - There is a free tier but even the paid tier isn't very expensive.
Cloudflare Images - This one is paid only. It's 5 USD / Month / 100'000 Image served with 20 configured variations (the variations do not count to the 100'000 image limit). Delivering images is 1 USD for every 100'000 images. There's also a enterprise version. Check out the details here
Neon.Tech Database - I've been using their free tier for ages without hitting any limits so far. The only reason I went ahead and upgraded was because you can only have one project on the free tier. They don't charge you for a month if the bill is under 50 Cent. It's very affordable for what you're getting. Seriously, check them out
Upstash - They have a generous free tier. Personally, I use the "Pay As You Go" option and set a low budget limit. Check out their pricing here
Prisma Cloud - You will not be able to hack your way around this one because prisma's edge client doesn't allow connecting to a database directly. They have a generous free tier and that's the only thing I use them for. Create a project here, create the Connection String and use this. Their DataExplorer will then be linked to the production database, which can be quite handy as well.

Github Actions Environemnts

I've configured the actions using a CI and a PREVIEW environment. The Variables keys for both are the same (see .env.example).
The CI environment values should use the same values as in the .env.example file, as these are used to run the e2e tests against the docker containers.
The PREVIEW values need to be set values from the relevant services.

In addition to these you'll have to configure CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID to enable preview & production publishing. You can optain the CLOUDFLARE_API_TOKEN in the cloudflare dashboard. Create a new token which allows editing for Cloudflare Pages. Then set up a Pages Project. The Github Action should then deply accordingly. You can also assign it to a domain if you use cloudlfare to manage your domains (I highly reccomend this, it makes life so much easier).

Notes about this Project

I've collected some information I think you might find useful when working with this template.

Scripts

I've included a lot of scripts in the package.json file. The mostly depend on each other. The naming follows this pattern in general

[WHAT]:[ACTION]:[ENV].

For example, If I want to generate my prisma schema for local development I would run pnpm prisma:gen:dev.

Here are some useful scripts

pnpm psql:dump - Dumps the content of the current database into a sk-db-dump.sql file. You can mout this as a volume in the docker-compose.yaml file in the psql section with this path - ./sk-db-dump.sql:/docker-entrypoint-initdb.d/init.sql which will initialize the psql container with those contents on start up every time.
pnpm psql:restore - Restores from the latest sk-db-dump.sql file, if it exists.
pnpm test:e2e:dev - Runs the sveltekit development server and Playwright in UI mode. This way you can code and verify your tests at the same time.
pnpm clean - Deletes the ./playwright-report, ./.wrangler and ./.svelte-kit folders for a clean slate
pnpm prep - If your docker containers are running, this will generate the prisma schema, push it to the psql container and seed the database

Data Proxy

As previously mentioned, prisma doesn't a direct connection to Databases form edge functions. You need to create a Data Proxy, which does some prisma magic and then you can use Prisma in Edge Functions. This is why there are two prisma schemas.

The "normal" way of defining your data source is this

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

If you're using the Data Proxy, you have to declare it like this

datasource db {
  provider  = "postgresql"
  url       = env("DATA_PROXY")
  directUrl = env("DATABASE_URL")
}

The DATABASE_URL refers to the standard Database URL and DATA_PROXY refers to the connection string you generate when creating a Cloud Prisma Project - Its free for mostly everything.

Prisma Code Organization

I couldn't find a good way to keep all my prisma relevant code together so I came up with the following solution. There are two Repository classes. One for managing Users and one for managing Images. I've split the Prisma code up like this in order to keep the primsa imports to a bare minimum. All DB Actions I do via these classes and they are called only from the server.

Note: The ImageRepository can interchangebly be used with the local thumbor container or with Cloudflare's Image Service.

Understanding the PR.yaml Github Action

The Github PR.yaml action triggers on every opened PR and on fresh pushes to that PR and runs the following jobs:

INSTALL: Installs depdendencies from pnpm-lock.yaml and caches them
LINT: Runs prettier and the sveltekit-check command
UNIT_TEST: Runs unit tests using vitest
E2E_TEST:
- Launches the following docker containers
- ghcr.io/minimalcompact/thumbor - Image CRUD Service
- redis:6.2 - For keeping track of sessions and avoid hitting the DB for every session validation
- postgres:15 - Database
- Prepares the psql container
- Runs the prisma generate and prisma push command. This creates the basic DB and schema
- Runs the prisma seed command. This will:
  - generate 10 random users
  - pull random images from picsum
  - upload these into the thumbor container
  - insert the relevant information into the psql container
- Runs e2e tests
- Playwright CI test we have a headless configuration - playwright.config.ci.ts
- Note that these tests can be slow and might incur charges on your github account. You can always run them locally instead.

React TypeScript Basics

Daniel Einars — Tue, 07 Feb 2023 10:03:46 +0000

This article was originally published on my personal website here. There's some other react/typescript related content there as well if you want to have a look.

UPDATE

React.FC isn't really used anymore and I've removed/replaced all examples using this.

1. Overview

After a quick introduction to Typescript I'll highlight some brief examples & explanations of Typescript usage with React Children, React Hooks and HTMLElements (with and without React).
Finally, I'll sum up the differences between Interface and Type (and when to use which) as well as showing how to use untyped libraries in Typescript projects.

2. Typed Props

type Props can be declared as a type or as an interface.

What should I use? According to this article

If you write object-oriented code — use interfaces, if you write functional code — use type aliases.

The main difference is

interfaces are more “extendable” due to the support of declaration merging, and types are more “composable” due to support of union types.

Basically, you can extend existing interfaces which might become confusing in a large code base.

Example:

interface IUser {
  firstName: string
  lastName: string
}

interface IUser {
  age: number
}

const user: IUser = {
  firstName: 'Jon',
  lastName: 'Doe',
  age: 25,
}

Now to the course. This is how you declare and use a type in a Functional TS React Component

import React from 'react';

// type declaration:
type Props = {
  title: string,
  isActive: boolean
}

export const Header= ({title, isActive}:Props) => {
  return (
    <>
      <h1>{title}</h1>
      {isActive && <h3> Active</h3>}
    </>
  );
};

3. Default and/or Optional Props

Props can be marked as optional using the ?. If this is done, the component requires the prop to contain a default value.

import React from 'react';


type Props = {
  title: string,
  isActive?: boolean // optional
}

// isActive is now optional and therefor needs a default argument in case this isn't provided.
export const Header = ({title, isActive= true}:Props) => {

[...]

}

4. Types

This video covers some common types. It does not go into specifics about how you would create these when you'd actually use the <Header [...]/> component.

// User Type
type User = {
  name: string;
}
// Common types.
type Props = {
  title: string, //strings
  isActive?: boolean //booleans
  thing: number // numbers
  thing2: string[] //arrays of strings || booleans || numbers
  status: 'loading' | 'loaded' // Union Type. Accepts only one of these two strings
  thing3: object // this is an empty object. can also be declared using {}
//  thing4: User | {}  the above is typically declared like this, if at all.
  thing4: {
    name: string;
  }
  func: () => void // Define functions. Quite common
  user: User
}

5. Function Props

Way in which a function can be typed.

import React from 'react';


type Props = {
  // onClick: Function // function (lower-case "f") is not recognized. Topic of chapter 7.
  // method returns a string
  // onClick(): string // function which returns a string.

  // method which does not anything.
  // onClick(value: string): void

  // most common way to type a function.
  onClick: (text: string) => void;
}


export const Button = ({onClick}: Props) => {
  return <button onClick={() => onClick("hi there")}>Click Me</button>;
};

Accompanying App.tsx. Notice that I don't pass in the value to be logged in App.tsx but in Button.tsx

import React from 'react';
import './App.css';
import { Header } from './components/Header';
import { Button } from './components/Button';

const App = () => {

  return (
    <>
      <Header
        title="{'Hello'}"
      />
      <Button
        onClick={(text) => {
          console.log(text);
        }}
      />
    </>
  );
};

export default App;

6. React Events in TypeScript

React has its own set of Events, such as React.MouseEvent. This will accept events for all clicks (bad)

import React from "react"

type Props = {
  onClick: (e: React.MouseEvent) => void;
}

Now it is specified to only accept events from a button click (good)

import React from "react"

type Props = {
  onClick: (e: React.MouseEvent<HTMLButtonElement>) => void
}

7. Typing Children Props

The example below is receiving a string element as a child.

Because we are passing a string into the button component, this will work. However, down the line it will become difficult because you might want to pass a myriad of various
components into other components.

import React from 'react';

type Props = {
  onClick: (e: React.MouseEvent<HTMLButtonElement>) => void
  children: string;
}

// Placing the Prop declaration into the arrow handles. Use this only when children are in the mix. 
// Otherwise keep on using the previous syntax.
export const Button = ({onClick, children: Props}) => {
  return <button onClick={onClick}>{children}</button>;
};

In order to solve this, declare the react component with React.FC<Props> (see Update). Placing the Prop declaration into the arrow handles. Use this only when children are in the mix. Otherwise keep on using the previous syntax. This way it merges the Props which are expected from React.FC with the props we declared.

import React from 'react';

type Props = {
  onClick: (e: React.MouseEvent<HTMLButtonElement>) => void
}

export const Button = ({onClick, children}:Props) => {
  return <button onClick={onClick}>{children}</button>;
};

8. Typing React.useState

Because the default state is set to '', typescript will automatically recognized that the useState instance accepts texts values. TypeScript is doing it's job implicity.

import React from 'react';

export const Input = () => {
  const [name, setName] = React.useState('');
  return (
    <input value="{name}" onChange={e => setName(e.target.value)}/>
  );
};

Using the union type brackets (<>) we can define a state to be either of type string OR null. This will still throw an error because "value" can not be null.

import React, { useState } from 'react';

export const Input = () => {
  const [name, setName] = useState<string | null>("");

  return (
    <input value="{name}" onChange={e => setName(e.target.value)}/>
  );
};

Recommendation is to set the initial type to what the state expects. If that isn't enough, union types can be used.

9. Using React.useRef and typing dom elements

Type refs by declaring what type of HTML Element they will be attached to. Adding the "!" to the end of "null" declares it as a read-only value (very typical for refs)

import React, { useRef, useState } from 'react';

export const Input = () => {
  const [name, setName] = useState('');
  const ref = useRef<HTMLInputElement>(null!);

  console.log(ref?.current?.value);

  return (
    <input ref="{ref}" value="{name}" onChange={e => setName(e.target.value)}/>
  );
};

10. Using React.useReducer

Typing useReducer is no different than previous standard typing. You define types for Action & State and assign these to the initialState and the reducer function. Optionally add a payload to the action which can be typed as anything previously covered.

import React, { useReducer } from 'react';

const initialState: State = {rValue: true};

type State = {
  rValue: boolean
}

type Action = {
  type: string
  // Optionally define a payload of any type (object, boolean, etc.)
  // payload: string
}

const reducer = (state: State, action: Action) => {
  switch (action.type) {
    case 'one': {
      return {
        rValue: true
      };
    }
    case 'two': {
      return {
        rValue: false
      };
    }
    // Required in order to tell TS what state should be accepted in the default case.
    default: {
      return state;
    }
  }
};

export const ReducerButtons = () => {

  const [state, dispatch] = useReducer(reducer, initialState);
  return (
    <>
      <button onClick={() => dispatch({type: 'one'})}>Action One</button>
      <button onClick={() => dispatch({type: 'two'})}>Action Two</button>
      {state?.rValue ? <h1>visible</h1> : 'invisible'}
    </>
  );
};

In order to stop the reducers from accepting bad actions, you can type these as well using UntionTypes.

type Action = {
  type: 'one' | 'two' // using unionTypes to declare a specific set of allowed actions.
  // Optionally define a payload of any type (object, boolean, etc.)
  // payload: string
}


// Syntax for declaring multiple actions. This can also be used to type which payloads will be accepted.
type ActionExtended =
  | { type: 'one', payload: boolean }
  | { type: 'two' }
  | { type: 'three' }
  | { type: 'four' }
  | { type: 'five' };

11. React.useEffect and Custom Hooks

This custom hook es designed to execute some code depending on weather a ref is clicked or not (close modal type).

It takes a ref to the HTML Element and the handler function. Because the handler function adds DOM listeners (as opposed to React listeners)
it has to be declared as standard Mouse/Touch Events (both need to be declared because we could be on a mobile device).

Additionally, because we are mutating the reference, we need to declare the ref as a React.MutableRefObject<HTMLElement>.


import React, { useEffect } from 'react';


const useClickOutside = (
  ref: React.MutableRefObject<HTMLElement>,
  handler: (event: MouseEvent | TouchEvent) => void) => {
  useEffect(() => {
    const listener = (event: MouseEvent | TouchEvent) => {
      if (!ref.current || ref.current.contains(event.target as Node)) {
        return;
      }
      handler(event);
    };

    document.addEventListener('mousedown', listener);
    document.addEventListener('touchstart', listener );
    return () => {
      document.removeEventListener('mousedown', listener);
      document.removeEventListener('touchstart', listener);

    };
  }, [handler, ref]);
};

export { useClickOutside };

12. Generics

By example of the useClickOutside hook. Before we declared its ref type as ref: React.MutableRefObject<HTMLDivElement>. This did work, but did not allow us to use it on elements other than <div/>. Because HTMLDivElement extends HTMLElement, we can declare the ref in the hook as ref: React.MutableRefObject<HTMLElement>. When it's actually used, the ref can contain any HTMLElement and TS will not throw any errors.

13. React.useContext

TS implicitly types the declared context without having to type it. Below is an example implementation.

import { createContext } from 'react';

export const initialValues = {
  rValue: true
};

export const GlobalContext = createContext(initialValues);

We can use this example in ReducerButtons.tsx like this.

import { useContext } from "react";
import { GlobalContext } from './GlobalState';

const {rValue} = useContext(GlobalContext);

Attempts to destructor properties, which don't exist, will throw TS errors.

import { useContext } from "react";
import { GlobalContext } from './GlobalState';

const {does-not-exist} = useContext(GlobalContext);

This works just great for most cases. We can also type the context should we want to.

import { createContext } from 'react';

type InitialValues = {
  rValue: boolean
}

export const initialValues: InitialValues = {
  rValue: true
};

export const GlobalContext = createContext(initialValues);

Next we update the GlobalState component by creating a GlobalProvider. This saves us from
having to import initialValues where ever we use it and can instead just wrap the GlobalProvider component.
Additionally we refactored GlobalState.tsx to include the useReducer function from the ReducerButtons.tsx
component.

The refactored GlobalState.tsx component looks like this now

import React, { createContext, useReducer } from 'react';


export const initialValues = {
  rValue: true,
  // This creates an implied context without having to explicitly type it.
  // It allows us to assign the dispatch functions (turnOn & turnOff) in the `value` prop
  // passed in the `<GlobalContext.Provider ...` component
  turnOn: () => {},
  turnOff: () => {}
};

export const GlobalContext = createContext(initialValues);

type State = {
  rValue: boolean
}

type Action = {
  type: 'on' | 'off'
}
const reducer = (state: State, action: Action) => {
  switch (action.type) {
    case 'on': {
      return {
        rValue: true
      };
    }
    case 'off': {
      return {
        rValue: false
      };
    }
    default: {
      return state;
    }
  }
};


export const GlobalProvider = ({children}) => {
  const [state, dispatch] = useReducer(reducer, initialValues);

  return (
    <GlobalContext.Provider value="{{"
      rValue: state.rValue,
      // Functions have been added to the initialValues object. These are implicitly typed. 
      turnOn: () => dispatch({type: 'on'}),
      turnOff: () => dispatch({type: 'off'})
    }}>
      {children}
    </GlobalContext.Provider>
  );
};

The ReducerButtons.tsx component has been updated to work with GlobalState.tsx.

import React, { useContext, useRef } from 'react';
import { useClickOutside } from './useClickOutside';
import { GlobalContext } from './GlobalState';


export const ReducerButtons = () => {
  const ref = useRef<HTMLDivElement>(null!);
  const context = useContext(GlobalContext);
  const {rValue, turnOn, turnOff} = context; // Functions extracted from the GlobalContext 


  useClickOutside(ref, () => {
    console.log('Clicked Outside'); // handler passed into useClickOutside
  });
  return (
    <div ref="{ref}">
      // These functions are implicitly typed by the initialValues object in GlobalState.tsx
      <button onClick={turnOn}>Action One</button> 
      <button onClick={turnOff}>Action Two</button>
      {rValue ? <h1>visible</h1> : <h1>invisible</h1>}
    </div>
  );
};

14. Class Based Components

Classes and FC are quite similar. The following example illustrates a simple example.

type and state definitions are placed inside generic braces (< and >).

import React, { Component } from 'react';

type State = {
  shouldRender: boolean
}


type Props = {
  title: string;
}

class BigC extends Component<Props, State> {
  render() {
    return (
      <div>
        <h1>I'm in a class component</h1>
      </div>
    );
  }
}

export default BigC;

15. Interfaces Types

The gist from several articles is

When you come from OOP, use interface, if you're into functional programming, go for type

Pros for Types:

More constrained
Better for intersecting
Better in error messages
Can be used in unions

Pros for Interfaces:

Better when authoring a library
Extendable
Can be augmented

Here are some helpful tips and tricks to help you decide. In the end, what ever you choose, stick to it!

16. Using untyped libraries

Some libraries you'd like touse in your projects don't provide their own types. In this scenario you have two options:

Declare the types yourself in a *.d.ts file
Install the types (usually @types/LIBRARYMANE) from the DefinitelyTyped repository.

An example *.d.ts file can look as simple as this:

declare module 'styled-components' // This can allow you to use third-party un-typed libs.

The Only Rounding Function You Will Ever Need

Daniel Einars — Tue, 07 Feb 2023 09:57:27 +0000

This article was originally published on my personal website here. There's some other react/typescript related content there as well if you want to have a look.

We do have calls like Math.round or Math.floor, but those round to full numbers. The first rounds to a full number and the second simply rounds down. What do you do if you need to specify to how many decimal places, or specifically, to which step you want to round?. Well, look no further. I present drumroll The Last Rounding Funciton You Will Ever need

function round(value, step) {
    step || (step = 1.0);
    const inv = 1.0 / step;
    return Math.round(value * inv) / inv;
}

courtesy of Michael Deal.

I supposed you could improve it by also employing EPSILON, but I find that this suffices for the time being.

Debounce Vs Throttle

Daniel Einars — Tue, 07 Feb 2023 09:52:00 +0000

This article was originally published on my personal website here. There's some other react/typescript related content there as well if you want to have a look.

1. Overview

Every single time I'm calling a function a lot of times in quick succession I ask myself

Wait... should I debounce call or throttle this call?

So for the sake of preserving my sanity (and maybe yours), I'll briefly explain what each function does and when to use
which.

2. Debounce

This function essentially cancels running calls until it hasn't been called for a set period of time. This makes it ideal for making sure that search query is only sent to the endpoint once the user is finished typing the query.

function debounce(callback, delay = 500){
  let timeoutId;
  function debounced(...args){
    if(timeoutId){
      clearTimeout(timeoutId)
    }
    timeoutId = setTimeout(() => {
      callback(...args)
    }, delay)
  }
  return debounced
}

3. Throttle

Throttling a function call will reduce the number of times that function is called. It does that by setting a timeout
and only calling the last function once the timeout is complete. An implementation of throttle could look something like
this

function throttle(callback, delay = 500) {
  var wait = false;

  function throttled(...args) {
    if (!wait) {
      callback(...args);
      wait = true;
      setTimeout(function () {
        wait = false;
      }, delay);
    }
  }

  return throttled
}

This snippet will cancel all calls which happen within the delay. Sometimes you'll want to que the last call.


function throttle(callback, delay = 500) {
  let shouldWait = false
  let quedArguments

  function quedCallback() {
    if (quedArguments == null) {
      shouldWait = false
    } else {
      callback(...quedArguments)
      quedArguments = null
      setTimeout(quedCallback, delay)
    }
  }


  function throttled(...args) {
    if (shouldWait) {
      quedArguments = args
      return
    }

    shouldWait = true
    setTimeout(quedCallback, delay)
  }

  return throttled
}

The major difference here is that we're saving the ...args in the quedArguments variable and calling the callback with the last quedArguments contents.

Creating a Dark Theme with Tailwind in Nextjs

Daniel Einars — Tue, 07 Feb 2023 09:49:32 +0000

This article was originally published on my personal website here. There's some other react/typescript related content there as well if you want to have a look.

Creating a Dark Theme with Tailwind in Nextjs

Author: Daniel Einars

Date Published: 30.10.2022

1. Intro

With nextjs becoming the gold standard for developing react applications I thought I'd briefly explain how to create a
nice dark theme using nextjs and tailwind. We're going build the following

Theme Toggler
Theme Context Provider
Example Usage

By the end of it you'll be able to

Prerequisites:

A running nextjs application with tailwind configured.
Following dependencies:
- js-cookie@^3.0.1 & @types/js-cookie@^3.0.2to persist the theme
- tailwindcss@3.0.5 for styling the page

2. Theme Context Provider

Before we start. Tailwind implements their dark theme by css child selectors. Basically, if you're HTML element
has class="dark", them it will automatically apply all dark:some-tailwind-class styles. That's why all the
functionallity around this will involve adding/removing class="dark" when toggeling a theme.

We'll be using createContext in order to keep track of the theme and witch it when we want. In this instance.

But why are we using react's context? It causes a lot of rerenders and.. stuff!

.. to which I say:

"nu-uh! react's context is a dependency injection tool and if we don't bastardise it's intended
usage we're not causing any harm!"

For everyone who just wants to copy&paste everything just scroll to the bottom for the completed work.

2.1. Creating the Context.

This is fairly straight forward, so I won't dive into any details.


const initialState = false; // we start the first-time visitors up on the light theme

export const ThemeContext = createContext({
  isDarkTheme: initialState, // pass in the inital state
  toggleThemeHandler: () => {
  }, // define a function to toggle the theme
});

2.2. The Theme Context Provider

The Context Provider has to handle the following two cases.

New user:
1. Default to light theme
2. Set light theme cookie
3. Set class="light" on the HTML element
Returning user:
1. Read cookie
2. Call setIsDarkTheme with appropriate value
3. Set class="light" or class="dark" on the HTML element (technically we don't need the light class, but I like to keep it there)
Change the theme when the user wants to

We're going to need two functions. One to initialize the theme and handle cases 1 and 2. And a function to actually
toggle the theme.

2.2.1. Initializer

The ThemeContextProvider keeps track of which theme we currently have enabled in its own useState call. You could rely
on the cookie exclusively, but I found that to be a bit of a pain. Hence, we
have const [isDarkTheme, setIsDarkTheme] = useState(initialState); at the very top. This way we can also
call initialThemeHandler whenever the user decided to change the theme and we don't have to separate
a initialThemeHandler function from a setTheme function.

  const [isDarkTheme, setIsDarkTheme] = useState(initialState);

const initialThemeHandler = useCallback((): void => {
  // Get current cookie theme.
  const themeCookie = Cookies.get("theme");
  // js-cookie returns `undefined` if there's no cookie by that name
  setIsDarkTheme(themeCookie === "dark");
  // Here we start handling the case when we have a returning user (because we found a cookie)
  if (themeCookie) {
    // Just to be super-duper sure we're adding the right classes, remove what ever the other theme is
    document.querySelector("html")?.classList.remove(isDarkTheme ? "dark" : "light");
    // The cookie will have the value of `dark` or `light`
    // Therefore we can just set it to the value of the cookie
    document.querySelector("html")?.classList.add(themeCookie);
  } else {
    // Oooo!! A new user!
    // I set the cookie expiration to 30 days, but that's optional
    const date = new Date();
    const expires = new Date(date.setMonth(date.getMonth() + 1));
    // Set the default light cookie
    Cookies.set("theme", "light", {
      secure: true,
      expires: expires,
    });
  }
  // we're going to call this callback everytime the `isDarkTheme` property changes
}, [isDarkTheme]);

// an dalso on the initial render
useEffect(() => initialThemeHandler(), [initialThemeHandler]);

2.2.2. Theme toggle function

This is the function which the context will provide to other components via (say it with me) dependency injection.

  function toggleThemeHandler(): void {
  // get the current theme cookie. We know it exists since this will 100% of the time run after the `initialThemeHandler` function
  const themeCookie = Cookies.get("theme");
  // What ever theme we previously had, set it to the opposite.
  // Remember this is a boolean!
  setIsDarkTheme((ps) => !ps);
  // Create a new cookie expiration date
  const date = new Date();
  const expires = new Date(date.setMonth(date.getMonth() + 1));
  // Set the cookie to the opposit of what ever it's currently holding
  Cookies.set("theme", themeCookie !== "dark" ? "dark" : "light", {
    secure: true,
    expires: expires,
  });

  // add the appropriate class to the `HTML element
  toggleDarkClassToHTMLElement();
}

All this function does is remove either dark or light and then add either dark or light to the HTML element.
I chose this element because it's the top most one and I ran into some issues with nextjs and changing the body
classes.

  function toggleDarkClassToHTMLElement(): void {
  document.querySelector("html")?.classList.remove(isDarkTheme ? "dark" : "light");
  document.querySelector("html")?.classList.add(!isDarkTheme ? "dark" : "light");
}

Lastly we return the ThemeContext.Provider like this

  return (
  <ThemeContext.Provider
    value={
      {
        isDarkTheme, // remember, this is a boolean
        toggleThemeHandler // handler to toggle the theme
      }}>
    {props.children} // all other components will be child components of this one
  </ThemeContext.Provider>
);

Next we need to initialize the theme. That should handle the following scenarios

  const initialThemeHandler = useCallback((): void => {
  // Get current cookie theme.
  const themeCookie = Cookies.get("theme");
  // js-cookie returns `undefined` if there's no cookie by that name
  setIsDarkTheme(themeCookie === "dark");
  // Here we start handling the case when we have a returning user (because we found a cookie)
  if (themeCookie) {
    // Just to be super-duper sure we're adding the right classes, remove what ever the other theme is
    document.querySelector("html")?.classList.remove(isDarkTheme ? "dark" : "light");
    // The cookie will have the value of `dark` or `light`
    // Therefore we can just set it to the value of the cookie
    document.querySelector("html")?.classList.add(themeCookie);
  } else {
    // Oooo!! A new user!
    // I set the cookie expiration to 30 days, but that's optional
    const date = new Date();
    const expires = new Date(date.setMonth(date.getMonth() + 1));
    // Set the default light cookie
    Cookies.set("theme", "light", {
      secure: true,
      expires: expires,
    });
  }
  // we're going to call this callback everytime the `isDarkTheme` property changes
}, [isDarkTheme]);

// an dalso on the initial render
useEffect(() => initialThemeHandler(), [initialThemeHandler]);

3. Applying themes

Since we want all our components to be able to access the current theme and toggle it, we're going to wrap our entire
nextjs app in the provider. To do this we create a _app.tsx file and wrap all components in the provider like this

export default function Root({Component, pageProps}: AppProps) {
  return (
    <ThemeContextProvider>
      <Component {...pageProps} />
    </ThemeContextProvider>
  );
}

For now, we'll be using an old-fashioned button to toggle the theme.


interface IThemeTogglerContext{
    isDarkTheme: boolean;
    toggleThemeHandler: () => void;
}

export function ThemeToggleButton(){

  // get the `toggleThemeHandler` via *dependency injection*
  const { toggleThemeHandler }: IThemeTogglerContext = useContext(ThemeContext);

  // toggle the theme onClick
  function toggle(){
    toggleThemeHandler()
  }

  // super fancy button
  return (
  <button 
    onClick
    class={classNames(
         // styles which won't be affected by the theme
        "font-bold py-2 px-4 rounded-full",
        // light theme styles
        "bg-blue-500 hover:bg-blue-700 text-white",
        // dark theme styles
        "dark:bg-blue-100 dark:hover:bg-blue-200 dark:text-red-50", 
    )}>
    Toggle Theme
  </button>)
}

You can then place this button anywhere you want and it'll update the theme. As mentionind in the beginning, tailwind applies the dark-theme using CSS selectors, so any styles you want in a dark theme, just prefix the selector with a dark: prefix, as it's d

4. Styling the Body and adding theme switching transition

Because I want to see some sort of small transition when I change themes, I also created a _document.tsx file and added some tailwind classes, which make the theme switching a pleasent experience. Here's the completed work

import Document, { Head, Html, Main, NextScript } from "next/document";

export default class _Document extends Document {
  render() {
    return (
      <Html>
        <Head>
          <title>dle.dev</title> 
        </Head>
        <body className="bg-neutral-50 dark:bg-neutral-900 transition-colors overflow-x-hidden ">
          <Main />
          <NextScript />
        </body>
      </Html>
    );
  }
}

Yes, I know my Head / Title config isn't best practice. Check out what vercel is saying on the subject here.

5. Entire Snippit

There you go, that's all it took! In case you want to try it out, here's the complete ThemeContext component:


import type { ReactElement, ReactNode } from "react";
import { createContext, useCallback, useEffect, useState } from "react";
import Cookies from "js-cookie";

const initialState = false;

export const ThemeContext = createContext({
  isDarkTheme: initialState,
  toggleThemeHandler: () => {},
});

interface ThemePropsInterface {
  children: ReactNode;
}

export function ThemeContextProvider(props: ThemePropsInterface): ReactElement {
  const [isDarkTheme, setIsDarkTheme] = useState(initialState);

  const initialThemeHandler = useCallback((): void => {
    const themeCookie = Cookies.get("theme");
    setIsDarkTheme(themeCookie === "dark");
    if (themeCookie) {
      document.querySelector("html")?.classList.remove(isDarkTheme ? "dark" : "light");
      document.querySelector("html")?.classList.add(themeCookie);
    } else {
      const date = new Date();
      const expires = new Date(date.setMonth(date.getMonth() + 1));
      Cookies.set("theme", "light", {
        secure: true,
        expires: expires,
      });
    }
  }, [isDarkTheme]);
  useEffect(() => initialThemeHandler(), [initialThemeHandler]);

  function toggleThemeHandler(): void {
    const themeCookie = Cookies.get("theme");
    setIsDarkTheme((ps) => !ps);
    const date = new Date();
    const expires = new Date(date.setMonth(date.getMonth() + 1));
    Cookies.set("theme", themeCookie !== "dark" ? "dark" : "light", {
      secure: true,
      expires: expires,
    });
    toggleDarkClassToBody();
  }

  function toggleDarkClassToBody(): void {
    document.querySelector("html")?.classList.remove(isDarkTheme ? "dark" : "light");
    document.querySelector("html")?.classList.add(!isDarkTheme ? "dark" : "light");
  }

  return (
    <ThemeContext.Provider value={{ isDarkTheme, toggleThemeHandler }}>
      {props.children}
    </ThemeContext.Provider>
  );
}

Typescript, Webpack and legacy jquery with plugins

Daniel Einars — Mon, 30 Jan 2023 08:54:13 +0000

This article was originally published on my personal website here. There's some other react/typescript related content there as well if you want to have a look.

I recently got to experience the absolute joy of trying to migrate a legacy gulp script to webpack, including moving to Typescript, while still handling all the dependencies (jquery, jquery plugins such as own.carousel V1 and jquery-ellipsis). I'm writing this up because most of the documentation around jquery and wepback focuses on the webpack.ProvidePlugin, which barely scratches the surface in the context of legacy code.

1. Project before the migration

The project I was working on was a website using Magnolia as their CMS. It uses the Freemarker templating engine under the hood. Essentially these are super-powered HTML files, which give you access to the CMS content. You can still use all of the HTML tags you want, including the <script> tag.

As it is with any website, this one relied on some basic javascript for the majority of .. things (don't ask me what specifically, I don't like to think about it anymore than I have to). As such, it had some dependencies. These are:

jquery@3.5.1 - Released three years ago.
jquery-colorscroll - Last commit was on Dec 12, 2014 and the project has been archived
jquery.ellipsis - Last commit was on Nov 2, 2018.

All of the JS code we wrote depended in some form or another on jquery. At the time it was saving is a lot of headache in dealing with IE11. We never got around to introducing a proper tool-chain for it. The way I inherited it all worked as following.

We have this folder structure:

js
├── application.js <- Entry Point
├── modules
│   ├── scroll-animations.js
│   ├── popovers.js
│   └── ...more custom js
└── libs
├── jquery.js
├── jquery-colorscroll.js
├── jquery.ellipsis.js
└── ...more dependencies

All the modules were stored on a dedicated object, which in turn was stored on the window and every module had its own space on this. We did this by wrapping every module in IIFE. Inside this we'd assign an initialize function, which would .. well.. initialize the module. It's a little hard to read, so I'll give you an example.

Here's an example for a module.

(function () {
    $(document).ready(function () {
        function init() {
            console.info("Initialize scroller stuff")
            $('.some-class').click(
                function (event) { // Note the lack of an arrow function. We couldn't use those because IE11 does not support them and we had very little as a tool-chain
                    console.info("log this statement when I click on the element which contains the class 'some-class'")
                }
            )
        }

        window.MODULE_HOLDER.Scroller = {
            init: init
        }
    })

})()

Here's an example application.js file in its entirety (note the lack of import statements)

(function (){
    window.MODULE_HOLDER = window.MODULE_HOLDER || {}; // create the object to hold all our modules

    $(document).ready(function () {
        window.MODULE_HOLDER = window.MODULE_HOLDER || {}; // create the object to hold all our modules
        if(window.MODULE_HOLDER.Scroller && window.MODULE_HOLDER.Scroller.init !== undefined){ // check if a module has loaded itself
            window.MODULE_HOLDER.Scroller.init(); // run the init function
        }  

    })

})()

Ok, so now we have two files with IIFEs in them. application.js initializes modules, and modules register themselves to window.MODULE_HOLDER and provide the init function. How does it tie all together?

Gulp enters the stage

We had a gulp file which basically concatenated all the js files together into a giant IIFE, starting with the files in the lib directory. This would ensure that jquery would load itself into the window and be ready once application.js, or any of the modules requested it (it also did some other stuff like concatenating all css/scss files and moving them to the right directory, stripping all console statements out, minifying it and placing it where Magnolia expected it to be - don't worry, it wasn't complete anarchy, more like anarchy adjacent).

The output would be two files.

application.min.js - containing all libs (jquery, jquery plugins, etc.), and all of our js code.
theme.min.css - containing the base theme and our additions to it.

The real project had some 30-40 modules. Some were tiny. Unfortunately for me, not all of them were tiny. Some were very large, had vars all over the place, referenced other objects on the global window. Basically, I couldn't be sure that if I touched something that the functionality would remain in place.

In order to mitigate this, I decided that it would probably be a good idea to move the files over to Typescript so I'd at least have some inkling of a warning that I broke something when I changed something. I looked into doing this with gulp first, but soon gave up because... reasons.... OK! OK! .. I took a webpack course a while back and wanted to give my new skills a test drive.

Boy was I gonna be in for a ride...

2. Webpack config to replace gulp

Right, so at this point you know what the project looked like and what the output was expected to look like. Next we install all the dependencies. These were

...
  "dependencies": {
    "jquery": "3.5.1",
  },
  "devDependencies": {
    "@types/jquery": "3.5.16",
    "autoprefixer": "10.4.7",
    "css-loader": "^6.7.3",
    "mini-css-extract-plugin": "2.6.1",
    "postcss": "8.4.14",
    "postcss-loader": "7.0.1",
    "rimraf": "^4.0.7",
    "sass": "^1.22.10",
    "sass-loader": "13.0.2",
    "style-loader": "3.3.1",
    "ts-loader": "^9.4.2",
    "typescript": "^4.9.4",
    "webpack": "5.74.0",
    "webpack-cli": "4.10.0"
  },
...

I had to install jquery again, despite it existing in the libs folder because webpack just down right refused to work with the one imported from the lib folder. Everything else remained the same.

Next I created the tsconfig.json. Initially I disabled all the checks because typescript wouldn't transpile my legacy JS code, but I later found a way around that (hint, we're using the ts-loader which as a transpileOnly option). This meant that my IDE would now show me everything that Typescript thought was wrong with my JS code. There were red lines everywhere. This is good because I can see what I can fix in the future (but admittedly, I feel like I'm standing at the foot of Mount Everest of Legacy Javascript when I open a file like that).

Anyway, here's the tsconfig.json

{
  "compilerOptions": {
    "target": "esnext",
    "module": "esnext",
    "moduleResolution": "node",
    "lib": ["dom", "dom.iterable", "esnext", "scripthost"],
    "newLine": "lf",
    "sourceMap": true,
    "allowJs": true,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "noEmit": true
  }
}

The only real important thing about this config is the noEmit flag. We do not want tsc to always emit js files for everything, that should be handled by webpack.

Now we could move all our files from JS to TS. Since I'm a linux fanboy I can use the rename command for that. It looks something like this for me

rename "s/.js$/.ts"/ **/*.js

Ok, so now we've converted all our files. But there remains one other thing. Webpack has this really neat feature called tree shaking. Essentially this omits files form the output which haven't been reached via import/export calls. My goal was to keep all files as similar as possible while moving them over to typescript. Rewriting all the IIFEs would lead me down a rabbit hole I would not return from. I also didn't want to mess with any tree-shaking configs, since I

a) Didn't quite understand which config does what
b) Didn't have the time to read all the possible configuration options
c) Didn't want to accidentally remove code that I needed in some obscure part of the page

This meant that I would have to import all the modules in the application.ts file.

Recall, this is what it looked like before

(function (){
    window.MODULE_HOLDER = window.MODULE_HOLDER || {}; // create the object to hold all our modules

    $(document).ready(function () {
        window.MODULE_HOLDER = window.MODULE_HOLDER || {}; // create the object to hold all our modules
        if(window.MODULE_HOLDER.Scroller && window.MODULE_HOLDER.Scroller.init !== undefined){ // check if a module has loaded itself
            window.MODULE_HOLDER.Scroller.init(); // run the init function
        }  

    })

})()

This is what it looks like with the imports

import "./modules/scrollEffects"
import "./modules/hoverMagic"
import "./modules/fomrHideStuff"
import "./modules/aMillionOtherModules"

(function (){
    window.MODULE_HOLDER = window.MODULE_HOLDER || {}; // create the object to hold all our modules

    $(document).ready(function () {
        window.MODULE_HOLDER = window.MODULE_HOLDER || {}; // create the object to hold all our modules
        if(window.MODULE_HOLDER.Scroller && window.MODULE_HOLDER.Scroller.init !== undefined){ // check if a module has loaded itself
            window.MODULE_HOLDER.Scroller.init(); // run the init function
        }  

    })

})()

Because all of these imports are IIFEs, the imports would result in the final application.js being a concatinated version of the original, with all the init calls at the end. There was nothing to tree shake :(

Ok, but why do we need to import all of this when we previously didn't, you ask accusingly...

Well, Webpack expects a single entry point for the application. Yes, yes, I know, you can also use a glob pattern to match multiple files, but I spent half a day trying to get it to work with that I just kept on hitting a wall. If you know a better way, good for you! Also, please tell me. You can reach me on Twitter via @polaroidkidd.

Anyway, here's ~~wonderwall~~ the webpack config.

Speaking of which... It's a lot to take in. Instead of giving you tiny snippits which you the copy&paste together in your project, I'll give you the entire config here with all the comments done inline. You're welcome you lazy git.


const MiniCssExtractPlugin = require("mini-css-extract-plugin"); // This plugin is very aptly named because it extracts css and minifies it
const webpack = require("webpack"); // We need webpacks ProvidePlugin, which is on the Webpack object.
const path = require("path"); // We don't really need this, but it was there when I copied this config from somewhere else.

const outputDir = path.resolve(__dirname, "target/classes/theme/js"); // This denotes the final path where webpack will place the transpiled files. In my case this is inside the target folder, which gets created by the mvn install command. Magnolia expects all the JS files in this place (at leas that's how we've configured it)


/**
 * Webpack Config
 * @param env The env variable holds information about the current build status.
 */
module.exports = (env) => {

    // I call ther webpack cli with --env production/development. This gives me some control over when I want sourcemaps to be included or not.
    const sourceMaps = env.production ? {} : {devtool: "inline-source-map"}

    return {
        entry: "./src/main/resources/theme/js/application.ts", // Currently this fil
        ...sourceMaps,
        resolve: {
            extensions: [".tsx", ".ts", ".js"],
        },
        output: {
            filename: "application.min.js", // you don't need the "min" in there, I just like it because I'm a special boy
            path: outputDir,
        },
        module: {
            // Here's where some of the magic happens. Webpack gives us this rules array, which takes objects containing a test and a use parameter. 
            // "test" is a regex which matches files. For my typescript needs I make sure that this rule applies to all files ending in "ts"
            // "use" is either an array or an object which specifies a loader. A loader is some magic library which takes one type of file and converts it to another type
            // of file. In the case of typescript, we want to use the "ts-loader" to handle all typescript files, and we use the transpileOnly option to tell the
            // loader to ignore any typescript errors. This is especially useful if you're an idiot like me and volunteer to migrate 8 years old javascript to typescript
            // without modifying the 8 year old javascript.

            //Ok, I didn't volunteer. The JS code kept me up at night. This had to be done.


            rules: [
                {
                    // Regex
                    test: /\.ts?$/,
                    use: [
                        {
                            loader: "ts-loader",
                            options: {
                                transpileOnly: true, // magic flag to enable insanity mode
                            },
                        },
                    ],
                    exclude: /node_modules/, // super important. You don't want to start transpiling all your node_moodules.
                },
                    // Here we start handling our styles. There's a loader for css files and one for scss files
                {
                    test: /\.css$/i,
                    use: [
                        MiniCssExtractPlugin.loader,
                        {
                            loader: "css-loader",
                            options: {
                                url: false,
                            },
                        },
                        {
                            loader: "postcss-loader",
                            options: {
                                postcssOptions: {
                                  // This nifty little tool prefixes your css with more css to make sure it runs on the IE11.. 
                                  // whoops, I meant safari.
                                    plugins: () => [require("autoprefixer")],
                                },
                            },
                        },
                    ],
                },
                {
                    test: /\.(s(a|c)ss)$/,
                    use: [
                        MiniCssExtractPlugin.loader,
                        {
                            loader: "css-loader",
                            options: {
                                url: false,
                            },
                        },
                        {
                            loader: "postcss-loader",
                            options: {
                                postcssOptions: {
                                    plugins: () => [require("autoprefixer")],
                                },
                            },
                        },
                        {
                            loader: "sass-loader",
                            options: {
                                sassOptions: {
                                    outputStyle: "compressed",
                                },
                            },
                        },
                    ],
                },
            ],
        },
        plugins: [
            // Uncomment to get it to work. Find out why this works in Chapter 3.
            // new webpack.ProvidePlugin({
            //     jQuery: 'jquery',
            //     $: 'jquery',
            //     'window.jQuery': 'jquery',
            //     'window.$': 'jquery',
            // }),
            // Sometimes you'll want a separate css file. In this case you can use this directive to specify
            // the location where that should go. The path is RELATIVE TO THE OUTPUT FILE.    
            new MiniCssExtractPlugin({
                filename: "../css/theme.min.css", 
            }),
        ],
        performance: {
            // Here's some configs to start alerting you if your transpiled JS becomes bigger than
            // let me do the math here
            // carry the .. one...
            // open google...
            // "how to convert from byte to something I can understand"
            // AH! If it gets larger than 5.12 Megabyte
            maxEntrypointSize: 5120000,
            maxAssetSize: 5120000,
          // Note that this is massive. NextJS starts giving you trouble after ~200kb
        },
    };
};

That's it folks! A half-way decent way of moving 8 year old JS to typescript without changing the JS files (too much). Now the real grind can start and you can take care of all those pesky TS errors your IDE shows you! I know, you can barely wait!

But there's one more thing... jquery and the plugins...

Ok, no biggie, I have them in the libs folder, I can just import them at the top of the application.ts

Well... yes and no. This is where the fun part starts (and I mean "fun" in the sense of "not very fun at all").

If you're anything like me you google "webpack jquery" and come to the webpack documentation for the ProvidePlugin, which gives you the following plugin config

new webpack.ProvidePlugin({
  $: 'jquery',
  jQuery: 'jquery',
});

Props to the webpack guys, the documentation is usually enough to get you started, but since jquery ~~needs to burn in hell for all eternity~~ is a nifty little lib with lots of special use-cases, I feel like the documentation is a tad lacking here.

So here's the short version of how to get it fixed.

Update application.ts

import $ from  "jquery";
// init jquery to be used by all libs
// @ts-ignore
global.$ = $

// load jquery plugins
import "./libs/owl.carousel";
import "jquery-ellipsis";

// all the other imports

Add this to your webpack config plugin section (or uncomment it if you were brave enough to simply copy and paste mine like that weird beautiful creature you are)

new webpack.ProvidePlugin({
    jQuery: 'jquery',
    $: 'jquery',
    'window.jQuery': 'jquery',
    'window.$': 'jquery',
})

Now you can run it and everything should work!

Hey.. uhm.. you haven't told us yet what command to use for running it

Wow... you kids really do need everything spoon-fed... let me just look up where I copied my run config from....

You can add these two scripts to your package.json file.

...
"dev": "webpack  watch --config ./webpack.config.js --mode development --env development",
"prod": "webpack build --config ./webpack.config.js --mode production --env production",
...

The webpack watch will update your final output file everytime it noticed as chang in the entry or any imported files. It'll also create a source-map for you so your browser can pinpoint for you exactly where sh*t hit the fan.

That's it! For all you other maniacs who want to know why and how the ProvidePlugin works with jquery ~~and why the webpack documentation left me banging my head against the wall~~, continue reading at your own risk.

3. `$` is not defined

So, if you're like me ~~and copy & paste every snippit that looks like it could work for you until you get frustrated that it doesn't work~~ always read the documentation, you'll notice that the snippit provided by the webpack documentation (and a gazillion stackoverflow posts) is lacking. Mainly because all your code transpiles but you get this error

$ is not defined

Well, when we use webpack, it makes sure that jQuery isn't global anymore. jQuery notices that it is being used in modules (ie. if its needed they'll be an import statement for it) and therefore it doesn't globallify itself, but returns the jQuery function which we set to the $ and then use in that specific module/file only.

This is a good thing if you're living in 2023. But back in ~~1800~~ 2015, when ~~IE11~~ we didn't have fancy arrow functions and useful module magic which made sure that things inside one file remained in that file, we (ab)used the window object.

So how do we force this? Well, we can be blunt and simply tell it like this


import $ from "jquery";
window.$ = $;

Voilà! Now we've exposed all of our code to jquery. ~~Shame on you~~ Congratulations! I'm sure you'll fix this later)

But wait! There's more!

The ProvidePlugin, well, it's kind of getting in our way. What this plugin does is make sure that any Javascript which relies on jQuery or $, it'll rewrite that code to require it as a module. It does not make jQuery or $ globally available ^{This might be written down in the webpack config, but I never got that far}.

The issue with this is that if you have any template code (such as magnolia's Freemarker template), which rely on jQuery or $ being in the global scope, well, it won't be available to them.

Things get really tricky in legacy code. Sometimes a library will reference jQuery via window.jQuery, which is the same, but it's not. However, we can fix that too!

Adjust the ProvidePlugin as follows.

module.exports = {
    plugins: [
        new webpack.ProvidePlugin({
            jQuery: 'jquery',
            $: 'jquery',
            'window.jQuery': 'jquery',
            'window.$': 'jquery',
        })
};

You Lied! There's more errors!

Well.. uhmm.. yes. Remember when I told you that the ProvidePlugin ~~super secretly~~ really obviously rewrites your code? Well, it's also rewriting window.$ = $
Update window.$ to global.$.

But Daniel, the global keyword is from node!

Yes, and weback runs on drumroll node! But also, when it encouters something like this, it'll rewrite global to window, which is what we actually wanted in the first place!

And now, we're really done!

DEV Community: Daniel Einars

Introducing CloudKit - A production ready Cloudflare Sveltekit template

Why?

What

Prerequisites

Running this locally

Running this in Production

Services

Github Actions Environemnts

Notes about this Project

Scripts

Data Proxy

Prisma Code Organization

Understanding the PR.yaml Github Action

React TypeScript Basics

UPDATE

1. Overview

2. Typed Props

3. Default and/or Optional Props

4. Types

5. Function Props

6. React Events in TypeScript

7. Typing Children Props

8. Typing React.useState

9. Using React.useRef and typing dom elements

10. Using React.useReducer

11. React.useEffect and Custom Hooks

12. Generics

13. React.useContext

14. Class Based Components

15. Interfaces Types

16. Using untyped libraries

The Only Rounding Function You Will Ever Need

Debounce Vs Throttle

1. Overview

2. Debounce

3. Throttle

Creating a Dark Theme with Tailwind in Nextjs

Creating a Dark Theme with Tailwind in Nextjs

1. Intro

2. Theme Context Provider

2.1. Creating the Context.

2.2. The Theme Context Provider

2.2.1. Initializer

2.2.2. Theme toggle function

3. Applying themes

4. Styling the Body and adding theme switching transition

5. Entire Snippit

Typescript, Webpack and legacy jquery with plugins

1. Project before the migration

2. Webpack config to replace gulp

3. $ is not defined

3. `$` is not defined