DEV Community: Oleksandr Demian

GameMaker setup with Typescript and VS Code

Oleksandr Demian — Tue, 31 Mar 2026 12:01:44 +0000

I wrote my first line of code back in 2014, when I tried Unity 3D to create a simple game for fun. I didn't have any programming experience at the time, but I loved video games. I made a couple of them back then, nothing commercial, just some simple games I could build in 4-5 days to play with friends for a few hours before moving on.

I eventually got into programming professionally and landed a job as a Software Engineer, which meant putting game dev aside and, plot twist, focusing on work.

Twelve years have passed since then (time flies), and the other day I was reading a book about the video game industry. Once I finished it, I decided to try making a game again. I didn't want to use Unity or Godot, as they felt like "too much" for what I could realistically make. Instead, I leaned towards GameMaker, which helped limit any unrealistic scope of a "super insane 3D game" I might get tempted by later.

GameMaker was perfect for a simple 2D game (plus some of my favorite games are made in GM). I managed to put together a playable top-down shooter in just one evening. Since it is super focused on 2D development, everything is intuitive and easy to use. After spending a decade working as a full-stack dev doing hundreds of different things (writing code, optimizing SEO, CI/CD, DB migrations, analytics, scalability...), I fell in love with GameMaker. I could finally write code for fun again.

However, there were some trade-offs: GML.

GML is the programming language used in GameMaker. If I had to briefly describe it, I would say: "It's an archaic version of JavaScript". While I believe it is great for people who first start writing code, but for me there are some big no-go:

Typesafety: there are no types, you can use comments similarly to JSDoc, but I don't think it is good.
Built-in code editor: this is the biggest issue for me personally. It is eons behind VS Code and JetBrains products in terms of DX experience.

As a certified "TypeScript lover" I said to myself: I can fix ~~her~~ this.

The idea was simple: "In and out, 20 minute adventure." I would take TypeScript code, run it through a transpiler, and post-process whatever needed fixing (for example: thisdoes not exist in GML; it uses self).

Obviously, things weren't that simple. But after a weekend (and a sleepless night), I managed to pull it off. I was finally able to write TypeScript code and make it work in GameMaker.

My initial PoC used a script in watch mode to compile TS code on the fly, but an incredible coincidence happened: two days after I started working on this tool, GameMaker released a new version of their IDE. It added support for build hooks, which allowed me to get rid of the "watcher" and simply transpile the code the moment you hit the "Run" button.

The actual thing

What I came up with is a CLI tool (open source, NPM) that can be installed globally.

Setup

Install the package globaly (-g):

npm i -g @odemian/gamemaker-typescript

It has 2 commands:

setup: Prepares the GameMaker project you are currently in to use TypeScript (creates tsconfig.json, links types, and configures pre_project_step to automatically transpile).
compile: Manually compiles the project. This is useful if you've added assets like sprites or sounds, as this command will generate their respective types.

Project configuration and the TS first object

After the library has been installed, open a GameMaker project in VS Code (or whatever code editor) and run:

gmts setup

Create an object:

This will create a file at objects/obj_player/obj_player.yy. The .yy file contains the metadata for the object. Place your script in the same folder and give it any name (I call mine code.ts):

You can think of objects/obj_player as folder-based routing: each object is a folder in the objects directory, and you write your code right there.

Here is the actual code if you want to copy it:

class Player extends GMObject {
  _movement_speed: number;

  // inside of the defineObject you can declare all of your events, like onCreate, onStep, onDraw etc...
  onCreate() {
    // use "this." keyword to access object properties in a safe fully typed way
    this._movement_speed = 2;
  }

  onStep() {
    var _hspd = keyboard_check(vk_right) - keyboard_check(vk_left);
    var _vspd = keyboard_check(vk_down) - keyboard_check(vk_up);

    if (_hspd != 0 || _vspd != 0) {
        var _dir = point_direction(0, 0, _hspd, _vspd);
        this.x = this.x + lengthdir_x(this._movement_speed, _dir);
        this.y = this.y + lengthdir_y(this._movement_speed, _dir);
    }
  }
}

If you've ever used GameMaker, you might wonder: "Wait, a Player class?" Yes, OOP baby.

Most other game engines (e.g., Unity, Godot) use this approach where each object's code is encapsulated in a class. I experimented with different approaches, but I eventually settled on classes. They feel like the most natural way to write game code. In the ten years I've been working with TypeScript, I've almost never used the class keyword, it rarely feels right in modern front-end or back-end development. But for a game, it's a perfect match.

The class inherits all the standard events from GMObject:

Create -> onCreate
Step -> onStep
Draw -> onDraw
and so on, you get the idea

Run it

After creating the Player object and writing the code, we can run it (I added a sprite to my obj_player behind the scenes):

How GameMaker understands TS

If you are into GameMaker, you might wonder if it uses the newest GMRT runtime. The short answer is no. As of the time of writing, GMRT is still in beta, and it is not clear when it will be released or in what form.

What currently happens is:

When you set up a project using gmts setup, it configures a pre_project_step script to run gmts compile before building the project.
When you press "Run", it looks for all script and object resources and compiles any .ts files it finds in the resource folder.
Events like onCreate and onStep are extracted into Create_0.gml and Step_0.gml (scripts that GML understands). Other methods are then assigned to the instance in the Create event.
GameMaker builds the project by reading all of the generated .gml files.

The cool thing about this setup is that if you start your project with TS but at some point change the idea, you can simply remove .ts files, and keep .gml (they remain in readable form).

🧘‍♂️ A Minimalist’s Guide to Global State in React

Oleksandr Demian — Tue, 06 May 2025 11:10:27 +0000

When it comes to global state management in React, we’ve all been there—lost in a sea of boilerplate, magic proxies, and sprawling config files.

But what if you didn’t need any of that?

What if you could manage global state in React with:

Zero dependencies
Type safety out of the box
Efficient updates using selectors
And all under 0.5KB

Let me introduce you to @odemian/react-store: a tiny, typed, selector-based global state manager that’s built around simplicity and performance.

Why Another State Library?

React already has a ton of state solutions—Redux, Zustand, Jotai, Recoil… the list goes on.

But most apps don’t need the power or complexity that these libraries provide. Often, you just need:

Shared state between components
Selective subscriptions (don’t re-render unless the data changes)
A clean API with full TypeScript support
No weird behaviors or magic

That’s where @odemian/react-store comes in.

The Core Idea

At its heart, this library wraps the modern useSyncExternalStore API to give you predictable, stable state updates. Here’s what it gives you:

✅ Tiny

Roughly 330 bytes after minification and gzip.

🧠 Fully Typed

All store hooks, updaters, and selectors are strongly typed with TypeScript.

🎯 Selector-Based

You can subscribe to just a slice of your state—only rerendering when that part changes.

⚙️ Zero Dependencies

It’s just plain TypeScript and React—no magic, no proxies, no extra baggage.

A Real-World Example

Let’s say you want to manage user settings across your app. With @odemian/react-store, it’s as simple as:

// export hook and update function from store creator
export const [useUser, updateUser] = createStore({ name: "", surname: "" });

And in your components:

// read entire user
function User () {
  const user = useUser();
  return <span>{user.name}</span>
}

// or read part of the store
function UserName () {
  const name = useUser(u => u.name);
  // only re-renders if name changes
  return <span>{name}</span>
}

Updating state?


function updateName (name: string) {
  updateUser(u => ({ ...u, name }));
}

function UpdateName () {
  // no need to use hook, update function is available globally and does not require you to subscribe to any state
  return (
    <button onClick={() => updateName("Alice")}>Change name</button>
  );
}

Want to fetch async data on mount?

function AsyncUser () {
  const user = useUser();

  useEffect(() => {
    fetchUser().then(updateUser);
  }, []);

  return <span>{user.name}</span>
}

That’s it. No boilerplate, no destruturing in each component, no reducers, no Provider, no ceremony.

When Should You Use This?

This library shines in small to medium-sized apps or components where:

You want simple global state without setup
You need fine-grained reactivity
You’re tired of boilerplate code
You appreciate code you can fully understand in one file

If you’re building a complex app with middleware, dev tools, and advanced debugging needs—Redux or Zustand might still be a better fit. But for most projects? This will feel like a breath of fresh air.

Under the Hood

The implementation is just a few lines of code, but it covers everything you need:

A store that can get, subscribe, and update
A React hook that lets you read from the store efficiently using selectors
No re-renders unless the selected value actually changes
Full compatibility with React 18+ using useSyncExternalStore

Try It Yourself

Install it in seconds:

npm install @odemian/react-store

Then create your counter component and store:

import { createStore } from "@odemian/react-store";

const [useCounter, updateCounter] = createStore(0);

export const App = () => {
  const value = useCounter();

  return (
    <div>
      <h1>Count: {value}</h1>
      <button onClick={() => updateCounter(value - 1)}>Decrease</button>
      <button onClick={() => updateCounter(value + 1)}>Increase</button>
    </div>
  )
}

You're now ready to use global state across your app—without bloat or complexity. For more complex examples visit Github page or check this todo app example.

Wrap-Up

Global state in React doesn’t have to be heavyweight or confusing. Sometimes less is truly more.

If you’re looking for a clean, modern alternative to heavy libraries, give @odemian/react-store a try. You might be surprised by how little you actually need to manage state effectively.

⚛️ Build a Simple Todo App with React Store - a Tiny React State Manager

Oleksandr Demian — Tue, 06 May 2025 09:04:52 +0000

State management in React can sometimes feel like overkill. Whether you're reaching for Redux, Zustand, or Jotai, you might be introducing complexity when all you need is a minimal way to share state globally across components.

That’s where @odemian/react-store shines — a tiny, typed, selector-based, and dependency-free global state library powered by useSyncExternalStore.

In this article, we’ll walk through how to build a clean, performant Todo App using @odemian/react-store in just a few minutes.

🔧 Installation

npm install @odemian/react-store

🏗️ Step 1: Set up the Todo Store

Create a new file called stores/todoStore.ts:

import { createStore } from "@odemian/react-store";

export type TTodo = {
  id: number;
  name: string;
  done: boolean;
};

// Initialize the store with one task
export const [useTodos, updateTodos] = createStore<TTodo[]>([
  { id: Date.now(), name: "First task", done: false },
]);

// Add a new todo
export const addTodo = (name: string) =>
  updateTodos((todos) => [
    ...todos,
    { id: Date.now(), name, done: false },
  ]);

// Toggle todo status
export const toggleTodo = (id: number) =>
  updateTodos((todos) =>
    todos.map((t) => (t.id === id ? { ...t, done: !t.done } : t))
  );

// Remove a todo
export const removeTodo = (id: number) =>
  updateTodos((todos) => todos.filter((t) => t.id !== id));

🧑‍🎨 Step 2: Create Todo Input Component

import { useState } from "react";
import { addTodo } from "./stores/todoStore";

const CreateTodo = () => {
  const [text, setText] = useState("");

  const onAdd = () => {
    if (!text.trim()) return;
    addTodo(text);
    setText("");
  };

  return (
    <div>
      <input
        value={text}
        onChange={(e) => setText(e.currentTarget.value)}
        onKeyDown={(e) => e.key === "Enter" && onAdd()}
        placeholder="Add new task..."
      />
      <button onClick={onAdd}>Add</button>
    </div>
  );
};

export default CreateTodo;

📋 Step 3: Display and Interact with Todos

import { useTodos, toggleTodo, removeTodo } from "./stores/todoStore";

const TodoList = () => {
  const todos = useTodos(); // Full state read

  return (
    <ul>
      {todos.map((todo) => (
        <li key={todo.id}>
          <label>
            <input
              type="checkbox"
              checked={todo.done}
              onChange={() => toggleTodo(todo.id)}
            />
            {todo.name}
          </label>
          <button onClick={() => removeTodo(todo.id)}>❌</button>
        </li>
      ))}
    </ul>
  );
};

export default TodoList;

🧩 Step 4: Combine Components in App

import CreateTodo from "./CreateTodo";
import TodoList from "./TodoList";

const App = () => (
  <main>
    <h1>📝 Todo App</h1>
    <CreateTodo />
    <TodoList />
  </main>
);

export default App;

✅ Why `@odemian/react-store`?

Tiny
Fast: Uses useSyncExternalStore for optimal React updates
Typed: Works seamlessly with TypeScript
Selector-based: Components only re-render when selected state changes
No boilerplate: No Provider, context, or hook destructurings in each component

🧾 Summary

With @odemian/react-store, global state is no longer complex. You get the power of selector-based subscriptions, type safety, and zero dependencies — all in a micro-package perfect for small to medium React apps.

If you’re tired of bloated state management tools and just want something clean, predictable, and fast, give it a try! 🚀

💬 Have questions or want to see more patterns with react-store? Drop them in the comments!

🌍 The smallest and simplest global state manager for React

Oleksandr Demian — Sat, 03 May 2025 08:48:22 +0000

Important!: starting from version 0.0.8 @odemian/react-store has dropped proxy based reactivity. For the sake of simplicity it will only rely on actions to update store (instead of having a mix of actions and proxy mutations)

React has no shortage of state management libraries. From the heavyweight champion Redux to modern solutions like Zustand and Valtio, you’ve got options — sometimes too many. But what if you want something super tiny, fully type-safe, and feels like magic to use?

Meet @odemian/react-store: a global state manager that weighs less than 1KB (v0.0.5 is 400b gziped), has zero dependencies, and gives you reactive state via JavaScript proxies ✨.

⚙️ How It Works

Under the hood, it uses:

useSyncExternalStore for React 18+ compatibility
JavaScript Proxies for mutation tracking
A minimal internal pub/sub system

This gives you the mutability of Valtio, but with a more focused, compact footprint.

🚀 Getting Started

1. Install it

npm install @odemian/react-store

2. Create a Store

// stores/userStore.ts
import { createStore } from "@odemian/react-store";

export const useUser = createStore<{
  name: string;
  surname: string;
}>({
  name: "",
  surname: "",
});

3. Use It in Components

import { useUser } from "./stores/userStore";

export const UserSettings = () => {
  const user = useUser();

  return (
    <input
      value={user.name}
      onChange={(e) => (user.name = e.target.value)} // 🔮 feels like magic
    />
  );
};

Yes, you can mutate directly — and it’s reactive. No setState, no actions, no reducers.

4. Use Outside React

Need to update state outside components? Use the static .store API:

useUser.store.update({ name: "Jane" });
useUser.store.subscribe((state) => console.log("Changed", state));

🔬 Comparison with Other Tools

Feature	`@odemian/react-store`	Redux	Zustand	Valtio
Size	~1KB	~18KB	~1.2KB	~2KB
Mutation Style	Proxy (mutable)	Immutable	Functional	Proxy
Boilerplate	None	High	Low	Low
React Compatibility	✅ `useSyncExternalStore`	✅	✅	✅
Middleware Support	❌	✅	✅	⚠️ Limited
TypeScript Support	✅	✅	✅	✅

Use it when:

You want global state, but Redux is overkill
You love Valtio’s proxies but want fewer features
You value simplicity and type-safety

⚠️ Caveats

Not designed for advanced middleware or devtools
Not suitable for deeply nested logic-heavy state flows

✨ Final Thoughts

If you're building a dashboard, internal tool, or UI widget and just need a few global states, @odemian/react-store might be the most effortless way to do it.

💬 Give it a try, star the repo, and let me know what you build with it!

Typescript deserves a better dependency injection framework 💉

Oleksandr Demian — Sun, 19 Jan 2025 16:35:11 +0000

Dependency Injection (DI), also known as Inversion of Control (IoC), is a powerful design pattern that allows to write modular apps, making them easier to maintain and scaled.

The State of Dependency Injection in TypeScript

In TypeScript, there are several popular libraries for dependency injection. The major DI libraries and frameworks that use DI in TypeScript are:

All of these frameworks rely on the reflect-metadata library, which is a useful tool that enables libraries like TypeORM to work. However, when used as the backbone of DI and IoC frameworks, reflect-metadata reveals some key limitations.

How Reflect-Metadata Works and Its Limitations in DI/IoC

The reflect-metadata library helps TypeScript collect metadata about classes, such as constructor argument types and method signatures, at runtime. While this approach works for most use cases, it falls short in a few critical areas for TypeScript-based DI:

It doesn’t provide information about interfaces implemented by classes.
It doesn't retain information about class inheritance (i.e., whether a class extends another class).
It ignores type or interface definitions, which are central to TypeScript.

Let’s see these limitations in action.

A Basic Example Without Interfaces

@Component()
class ToBeInjected {}

@Component()
class MainApp {
  constructor(toBeInjected: ToBeInjected) {}
}

In this case, the DI container knows that:

ToBeInjected is a component.
MainApp requires an instance of ToBeInjected.

This is straightforward for the DI container, as the necessary metadata is available at runtime. However, things get more complicated with interfaces.

The Problem with Interfaces

interface IService {}

@Component()
class ToBeInjected implements IService {}

@Component()
class MainApp {
  constructor(toBeInjected: IService) {}
}

Here, our DI container will fail because reflect-metadata cannot track interfaces. It can only handle classes and primitive types. The container won't know that ToBeInjected implements IService, and so it can’t inject the correct dependency.

Similarly, if ToBeInjected extended another class (e.g., Service), the container would still fail because reflect-metadata doesn’t track class inheritance.

You can read more about these issues in the Angular documentation.

How Existing DI Frameworks Tackle These Problems

The concept of Injection Tokens is used to resolve such issues. An Injection Token is a unique identifier (usually a string or symbol) that tells the DI container which component to inject.

In frameworks like NestJS, this is how you would handle injecting an interface:

interface IAppService {
  getHello(): string;
}

class AppService implements IAppService {
  getHello(): string {
    return 'Hello World!';
  }
}

export const connectionProvider = {
  provide: 'SERVICE', // Injection Token
  useFactory: () => new AppService(),
};

@Injectable()
class App {
  constructor(@Inject('SERVICE') appService: IAppService) {
    console.log(appService.getHello());
  }
}

The Downsides

While Injection Tokens allow for flexibility, they come with trade-offs:

More manual work: You must explicitly provide Injection Tokens when working with non-class components (like interfaces or types).
Lack of type safety: The injection (@Inject('SERVICE') appService: IAppService) doesn't guarantee that the injected value will be of the correct type. This leads to potential issues if, for instance, you refactor a class to implement a different interface — the DI container won’t catch these errors at compile time, and you’ll only encounter them at runtime.

Can TypeScript Have a Better DI Framework?

To make DI in TypeScript better, we need to define what “better” means. A more robust DI framework should:

Offer decorator-based DI.
Support injecting components based on interfaces and extended classes.
Minimize the need for manual Injection Tokens.
Support injecting type definitions (TypeScript is all about types!).
Ensure strong type safety to prevent injection errors.

Frameworks like Angular and NestJS cover the first bullet point but fall short on the others. So, I set out to create a solution that checks all the boxes.

A New Approach to DI in TypeScript

After exploring several ideas, I realized that reflect-metadata wasn’t up to the task. Instead, I could build a system that collects metadata at build time and uses unique identifiers for types (classes, interfaces, and types) to ensure type safety and flexibility.

Here’s what I came up with:

A custom build script (based on TypeScript and ts-morph) scans and processes the code at build time.
Unique type identifiers (strings) are created for all types.
These identifiers are injected into class prototypes, enabling them to be reused at runtime for DI.

With this approach, I was able to create a DI framework that supports interfaces, types, and class inheritance, all while ensuring type safety.

You can check out the full solution in the LemonDI repository.

Examples of Better DI in Action

Injecting Components via Interfaces

In traditional DI frameworks like NestJS or Angular, you'd need to use Injection Tokens to inject interfaces. However, with LemonDI, injecting components via interfaces works seamlessly:

interface IService {
  sayHi(): void;
}

@Component()
class ComponentA implements IService {
  sayHi() {
    console.log("Hi!");
  }
}

@Component()
class App {
  constructor(toBeInjected: IService) {
    toBeInjected.sayHi(); // ComponentA is automatically injected because it implements IService
  }
}

// start the app
start({
  importFiles: [],
  modules: [App],
});

Support for `type` Injection

LemonDI also supports injecting types directly (like you would with interfaces), allowing you to inject complex structures like objects and external types easily:

type TConfig = {
  appName: string;
};

@Factory() // Factory creates components that aren't class-based
class ServiceFactory {
  @Instantiate() // Decorator for automatic instantiation
  instantiateAppConfig(): TConfig {
    return { appName: "Dependency Injection App" };
  }
}

@Component()
export class App {
  constructor(appConfig: TConfig) {
    console.log(appConfig.appName); // Output: Dependency Injection App
  }
}

// start the app
start({
  importFiles: [],
  modules: [App],
});

Ensuring Type Safety

One of the key motivations for building LemonDI was to ensure type safety. Unlike other frameworks that rely on Injection Tokens (which can lead to runtime errors), LemonDI ensures that the correct types are injected by matching based on type identifiers.

For example, if you change a service's implementation, LemonDI will catch the error at startup:

// previous interface
interface IAppService {
  getHello(): string;
}

// new interface
interface IAppNewService {
  getNewHello(): void;
}

export class AppService implements IAppNewService {
  getNewHello(): string {
    return 'Hello World!';
  }
}

@Factory()
class ComponentsFactory {
  @Instantiate({
    qualifier: "AppService"
  })
  instantiateAppService(): AppService {
    return new AppService();
  }
}

@Component()
export class App {
  constructor(@Qualifier("AppService") appService: IAppService) {
    console.log(appService.getHello());
  }
}

start({
  importFiles: [], // we don't have to import files
  modules: [App],
});

In this case, LemonDI will throw a start time error because there are no components qualified as 'AppService' that implement IAppService.

Conclusion

TypeScript’s static type system is a powerful tool, but current DI frameworks often fail to leverage it fully. By collecting metadata at build time and ensuring type safety with unique type identifiers, it's possible to create a DI framework that minimizes boilerplate, reduces errors, and fully supports TypeScript's strengths.

What I'm trying to achieve with LemonDI is to move beyond the limitations of reflect-metadata and take full advantage of TypeScript’s type system, making dependency injection in TypeScript more powerful, flexible, and type-safe.

🚧 Bear in mind that this project is in a very early stage and should not be used for production apps.

Express app with decorators based routing and dependency injection

Oleksandr Demian — Fri, 03 Jan 2025 20:04:01 +0000

When building modern Node.js and Express applications, managing routing and dependency injection can become increasingly complex. Handling controllers, services, and middleware without clean separation often leads to code that is harder to maintain. However, using the right tools and design patterns, we can significantly simplify this process.

In this article, I’ll walk you through how to build a Node.js application with decorators-based routing and dependency injection using the @lemondi library.

Why Use Decorators and Dependency Injection?

Decorators are a powerful feature in TypeScript and JavaScript that allow you to add metadata to classes, methods, and properties. With decorators, we can annotate routing methods, define their HTTP methods, and handle dependency injection without writing complex boilerplate code.

Dependency injection (DI) helps manage how services are instantiated and injected into other components. It decouples the components from each other, making your application more modular and testable. In our case, we’ll use DI for services like database connections and routing.

The @lemondi library simplifies the process by automating DI, handling decorators, and reducing the need for boilerplate code. Let’s dive into how it works!

1. Project Setup

Before we start building, let’s ensure we have the required libraries installed:

npm init -y
npm install express reflect-metadata @lemondi/core @lemondi/scanner typeorm sqlite3 class-transformer
npm install --save-dev typescript @types/node @types/express

Next, let’s set up TypeScript by creating a tsconfig.json file:

{
  "compilerOptions": {
    "lib": ["es5", "es6", "dom"],
    "target": "es5",
    "module": "commonjs",
    "moduleResolution": "node",
    "outDir": "./dist",
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true
  }
}

This configuration enables TypeScript's support for decorators and metadata reflection, which is required by the @lemondi library.

2. Decorators for Routing and Injection

`routing.ts` - Creating the Decorators

First, let’s create two decorators: one for classes (@Router) to define a router, and another for methods (@Route) to define HTTP routes.

// file: src/decorators/routing.ts
import { createClassDecorator, createMethodDecorator } from "@lemondi/scanner";

// Enum for HTTP methods
export enum HttpMethod {
  GET = "get",
  POST = "post",
  PUT = "put",
  DELETE = "delete",
  PATCH = "patch",
  OPTIONS = "options",
}

// @Router decorator for class routing
export const Router = createClassDecorator<{ path: string }>("Router");

// @Route decorator for method routing
export const Route = createMethodDecorator<{ path: string; method: HttpMethod }>("Route");

Here, we use @lemondi/scanner's createClassDecorator and createMethodDecorator to simplify the creation of decorators for routing.

3. Defining the Data Source

`datasource.ts` - The DataSource Factory

We’ll need a way to create and inject a DataSource (e.g., for connecting to a database). This is where the @lemondi library's @Factory and @Instantiate decorators come into play.

// file: src/factories/datasource.ts
import { Factory, FilesLoader, Instantiate } from "@lemondi/core";
import { DataSource } from "typeorm";

@Factory()
export class DataSourceFactory {
  @Instantiate({ qualifiers: [DataSource] })
  async createDatasource() {
    const ds = new DataSource({
      type: "sqlite",
      database: ":memory:",
      synchronize: true,
      entities: [FilesLoader.buildPath(__dirname, "..", "models", "*.entity.{js,ts}")],
    });

    await ds.initialize();
    return ds;
  }
}

The @Factory decorator marks DataSourceFactory as a provider of components, while @Instantiate marks the createDatasource method as a provider for the DataSource component. DI will automatically resolve and inject the required DataSource.

4. Defining the Entity

`user.entity.ts` - A TypeORM Entity

Here’s a simple TypeORM entity to define a User model.

// file: src/models/user.entity.ts
import { Column, Entity, PrimaryGeneratedColumn } from "typeorm";
import { plainToClass } from "class-transformer";

@Entity({ name: "users" })
export class User {
  @PrimaryGeneratedColumn("uuid")
  id?: string;

  @Column()
  firstName: string;

  @Column()
  lastName: string;

  static fromJson(json: User) {
    return plainToClass(User, json);
  }
}

This entity represents a User in the database with fields firstName and lastName. We also provide a utility function fromJson to easily convert JSON data to an instance of the User class.

5. Creating the Router

`UsersRouter.ts` - Defining Routes

With the decorators in place, we can now define our UsersRouter class to handle user-related routes.

// file: src/routers/UsersRouter.ts
import { HttpMethod, Route, Router } from "../decorators/routing";
import { UsersService } from "../services/UsersService";
import { Request } from "express";
import { User } from "../models/user.entity";

@Router({ path: "/users" })
export class UsersRouter {
  constructor(private readonly usersService: UsersService) {}

  @Route({ path: "/", method: HttpMethod.GET })
  getUsers() {
    return this.usersService.find();
  }

  @Route({ path: "/", method: HttpMethod.POST })
  createUser(req: Request) {
    const data = User.fromJson(req.body);
    return this.usersService.save(data);
  }
}

Here, the @Router decorator defines the base path /users, and the @Route decorators handle GET and POST methods for retrieving and creating users.

6. Service Layer

`UsersService.ts` - Handling Business Logic

We define the service that interacts with the database.

// file: src/services/UsersService.ts
import { Component } from "@lemondi/core";
import { DataSource, Repository } from "typeorm";
import { User } from "../models/user.entity";

@Component()
export class UsersService {
  private repository: Repository<User>;

  constructor(dataSource: DataSource) {
    this.repository = dataSource.getRepository(User);
  }

  save(user: User) {
    return this.repository.save(user);
  }

  find() {
    return this.repository.find();
  }
}

The UsersService class is decorated with @Component(), and its constructor automatically injects the DataSource instance. This allows the service to perform database operations without any manual instantiation.

7. Bootstrapping the Application

`app.ts` - Putting Everything Together

Finally, we initialize the application using the @lemondi DI system and bind routes dynamically.

// file: src/app.ts
import "reflect-metadata";
import { Component, FilesLoader, instantiate, OnInit, start } from "@lemondi/core";
import * as express from "express";
import { findClassDecorators, findMethodDecorators, scan } from "@lemondi/scanner";
import { Route, Router } from "./decorators/routing";

@Component()
class App {
  @OnInit()
  async onStart() {
    const server = express();
    server.use(express.json());

    const routers = scan(Router);

    for (const router of routers) {
      const routerInstance = await instantiate(router);
      const [routerDecorator] = findClassDecorators(router, Router);

      for (const prop of Reflect.ownKeys(router.prototype)) {
        const [props] = findMethodDecorators(router, prop, Route);
        if (props) {
          const url = routerDecorator.decoratorProps.path + props.decoratorProps.path;
          server[props.decoratorProps.method](url, async (...args) => {
            const result = await Promise.resolve(routerInstance[prop].call(routerInstance, ...args));
            args[1].json(result).end();
          });
        }
      }
    }

    server.listen(3000);
  }
}

start({
  importFiles: [
    FilesLoader.buildPath(__dirname, "factories", "**", "*.js"),
    FilesLoader.buildPath(__dirname, "routers", "**", "*.js"),
  ],
  modules: [App],
});

Here, we use the @OnInit decorator to initialize the Express server after the application is instantiated. We dynamically scan for @Router and @Route decorators and configure routes on the server.

You can now run the app using the following command:

tsc && node ./dist/app.js

Conclusion

Using decorators and the DI system provided by @lemondi, we’ve simplified our Node.js and Express application. This approach abstracts away much of the boilerplate code typically required for routing and dependency management, leading to cleaner, more maintainable code.

If you’re tired of manually configuring routing and services, this pattern is definitely worth exploring. By using decorators, we can keep the code more declarative, readable, and modular.

Creating Typescript app with decorator-based dependency injection 💉

Oleksandr Demian — Sun, 29 Dec 2024 10:43:21 +0000

As a huge fan of Node.js and TypeScript, I love how these technologies offer a fast and flexible approach to building applications. However, this flexibility can be a double-edged sword. Code can quickly become messy, which leads to a decline in maintainability and readability over time.

Having worked extensively with Spring (Java) and NestJS (TypeScript), I’ve come to realize that Dependency Injection (DI) is a powerful pattern for maintaining code quality in the long term. With this in mind, I set out to explore how I could create a TypeScript library that would serve as a foundation for Node.js projects. My goal was to create a library that enforces a component-based development approach while remaining flexible and easily extensible for various use cases. This is how I came up with 🍋 Lemon DI.

How it Works

The core idea behind Lemon DI is quite similar to NestJS (though with different naming conventions). All classes decorated with @Component automatically become injectable components, while non-class entities (e.g., types or interfaces) can be instantiated using factories (@Factory) and injected using unique tokens.

Let’s walk through an example where we integrate with an SQLite database using TypeORM.

Setting Up

Start by installing the required dependencies:

npm install @lemondi/core reflect-metadata sqlite3 tsc typeorm typescript class-transformer

Since TypeORM is an external library, we’ll create the data source using a factory:

// factory/datasource.ts
import {Factory, FilesLoader, Instantiate} from "@lemondi/core";
import {DataSource} from "typeorm";

// @Factory decorator marks this class as a provider of components through functions
@Factory()
export class DataSourceFactory {
    // @Instantiate decorator marks this function as a provider of a component
  @Instantiate({
    qualifiers: [DataSource] // This tells DI that this function creates a DataSource component
  })
  // This is an async function, which means the DI system will wait for it to resolve before using the component
  async createDatasource() {
    // create DataSource instance
    const ds = new DataSource({
      type: "sqlite", // use sqlite for simplicity, but this works perfectly with any other DB
      database: ":memory:",
      synchronize: true, // Automatically create tables on startup
      // load all models
      entities: [FilesLoader.buildPath(__dirname, "..", "models", "*.entity.{js,ts}")],
    });

    await ds.initialize(); // Initialize the DataSource before using it
    return ds;
  }
}

Now that we have our DataSource component, let’s define a model and a service to interact with it:

// models/user.entity.ts
import {Column, Entity, PrimaryGeneratedColumn} from "typeorm";
import {plainToClass} from "class-transformer";

// This is a standard TypeORM entity declaration
@Entity({ name: "users" })
export class User {
  @PrimaryGeneratedColumn("uuid")
  id?: string;

  @Column()
  firstName: string;

  @Column()
  lastName: string;

  static fromJson (json: User) {
    return plainToClass(User, json);
  }
}

// services/UsersService.ts
import {Component} from "@lemondi/core";
import {DataSource, Repository} from "typeorm";
import {User} from "../models/user.entity";

// This class is marked as component, it will automatically map itself during the dependency injection step
@Component()
export class UsersService {
  private repository: Repository<User>;

  // The component constructor is where the dependency injection happens
  // For each argument, the DI system will look for a component and provide it (the components are instantiated automatically when needed)
  constructor(
    // Here we tell DI system that we need DataSource instance (which is exported from our factory)
    // It is completely transparent for us that the DataSource component is async
    dataSource: DataSource,
  ) {
    this.repository = dataSource.getRepository(User);
  }

  save(user: User) {
    return this.repository.save(user);
  }

  find() {
    return this.repository.find();
  }
}

Now that we have our DB and Users service in place we can start our app:

import "reflect-metadata"; // this is required to emit classes metadata

import {Component, FilesLoader, OnInit, start} from "@lemondi/core";
import {UsersService} from "./services/users";
import {User} from "./models/user.entity";

@Component()
class App {
  constructor(
    private usersService: UsersService,
  ) { }

  // @OnInit decorator only works for components directly imported in `start`
  // @OnInit decorator tells the system to execute this method after the component is instantiated
  @OnInit()
  async onStart() {
    // create a new entry
    const user = User.fromJson({
      lastName: "Last",
      firstName: "First",
    });

    // save user in DB
    await this.usersService.save(user);

    // fetch user from DB
    const users = await this.usersService.find();
    console.log(users); // will print data fetched from DB
  }
}

// start method is required to start the app
start({
  importFiles: [
    // since there is no need to reference factories in the code, we need to tell our DI system to import those files to make sure they are accessible
    FilesLoader.buildPath(__dirname, "factories", "**", "*.js"),
  ],
  modules: [App], // The entry point; classes listed here will be instantiated automatically
});

TypeScript Configuration

To enable decorators and ensure everything works as expected, add the following to your tsconfig.json:

{
  "compilerOptions": {
    "lib": ["es5", "es6", "dom"],
    "target": "es5",
    "module": "commonjs",
    "moduleResolution": "node",
    "outDir": "./dist",
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true
  }
}

Finally, run the following command to compile and execute the app:

tsc && node ./dist/app.js

Final thoughts

⚠️ Important: Please note that this library is still in its early stages and should not be used in production applications yet. It’s a prototype I created for fun and exploration of decorators in TypeScript. You can find full example code here.

GPT Query: the AI tool that can write SQL queries for you

Oleksandr Demian — Sun, 12 Mar 2023 12:00:23 +0000

Introduction

GPT Query is an artificial intelligence-based tool designed to make writing SQL queries easier and faster. It allows users to generate complex database queries using natural language. Let's see some examples.

Although it's not perfect (some queries may have an error, but it is rare and only happens in very complicated cases), it is impressive the speed with which latest OpenAI model (gpt3.5) generates queries.

Examples

Consider having the following database (described using natural language):

Customers (customer_id, first_name, last_name, email, phone_number, address)
Categories (category_id, category_name, description)
Products (product_id, product_name, description, price, category_id)
Suppliers (supplier_id, supplier_name, contact_name, contact_email, phone_number, address)
Orders (order_id, customer_id, order_date, order_total, supplier_id)
OrderDetails (order_detail_id, order_id, product_id, quantity, price)

Create table

User prompt:

Create tables

GPT Query result:

CREATE TABLE Customers (
    customer_id SERIAL PRIMARY KEY,
    first_name VARCHAR(50) NOT NULL,
    last_name VARCHAR(50) NOT NULL,
    email VARCHAR(100) UNIQUE,
    phone_number VARCHAR(20),
    address VARCHAR(200)
);

CREATE TABLE Categories (
    category_id SERIAL PRIMARY KEY,
    category_name VARCHAR(50) NOT NULL,
    description TEXT
);

CREATE TABLE Products (
    product_id SERIAL PRIMARY KEY,
    product_name VARCHAR(100) NOT NULL,
    description TEXT,
    price NUMERIC(10,2) NOT NULL,
    category_id INTEGER REFERENCES Categories(category_id) ON DELETE CASCADE
);

CREATE TABLE Suppliers (
    supplier_id SERIAL PRIMARY KEY,
    supplier_name VARCHAR(100) NOT NULL,
    contact_name VARCHAR(100),
    contact_email VARCHAR(100),
    phone_number VARCHAR(20),
    address VARCHAR(200)
);

CREATE TABLE Orders (
    order_id SERIAL PRIMARY KEY,
    customer_id INTEGER REFERENCES Customers(customer_id) ON DELETE CASCADE,
    order_date DATE NOT NULL,
    order_total NUMERIC(10,2) NOT NULL,
    supplier_id INTEGER REFERENCES Suppliers(supplier_id) ON DELETE CASCADE
);

CREATE TABLE OrderDetails (
    order_detail_id SERIAL PRIMARY KEY,
    order_id INTEGER REFERENCES Orders(order_id) ON DELETE CASCADE,
    product_id INTEGER REFERENCES Products(product_id) ON DELETE CASCADE,
    quantity INTEGER NOT NULL,
    price NUMERIC(10,2) NOT NULL
);

Create dummy data

User prompt:

Create dummy data

GPT Query result:

INSERT INTO Customers (customer_id, first_name, last_name, email, phone_number, address)
VALUES 
(1, 'John', 'Doe', 'johndoe@gmail.com', '1234567890', '123 Main St'),
(2, 'Jane', 'Doe', 'janedoe@gmail.com', '0987654321', '456 Oak Ave'),
(3, 'Bob', 'Smith', 'bobsmith@gmail.com', '5555555555', '789 Elm St');

INSERT INTO Categories (category_id, category_name, description)
VALUES 
(1, 'Electronics', 'Products that use electricity'),
(2, 'Clothing', 'Apparel for men, women, and children'),
(3, 'Home Goods', 'Products for the home');

INSERT INTO Products (product_id, product_name, description, price, category_id)
VALUES 
(1, 'Smartphone', 'A mobile device with advanced computing capabilities', 999.99, 1),
(2, 'T-Shirt', 'A comfortable and casual cotton shirt', 19.99, 2),
(3, 'Sofa', 'A comfortable piece of furniture for sitting or lounging', 499.99, 3);

INSERT INTO Suppliers (supplier_id, supplier_name, contact_name, contact_email, phone_number, address)
VALUES 
(1, 'Tech Co', 'John Smith', 'john@techco.com', '5555555555', '123 Tech St'),
(2, 'Fashion Inc', 'Jane Smith', 'jane@fashioninc.com', '1234567890', '456 Fashion Ave'),
(3, 'Furniture Co', 'Bob Johnson', 'bob@furnitureco.com', '0987654321', '789 Furniture Blvd');

INSERT INTO Orders (order_id, customer_id, order_date, order_total, supplier_id)
VALUES 
(1, 1, '2021-01-01', 999.99, 1),
(2, 2, '2021-01-02', 19.99, 2),
(3, 3, '2021-01-03', 499.99, 3);

INSERT INTO OrderDetails (order_detail_id, order_id, product_id, quantity, price)
VALUES 
(1, 1, 1, 1, 999.99),
(2, 2, 2, 1, 19.99),
(3, 3, 3, 1, 499.99);

Data analysis

User prompt:

For each month, which category sells the most?

GPT Query result:

SELECT 
    EXTRACT(MONTH FROM o.order_date) AS month,
    c.category_name,
    SUM(od.quantity) AS total_quantity
FROM 
    Orders o
    JOIN OrderDetails od ON o.order_id = od.order_id
    JOIN Products p ON od.product_id = p.product_id
    JOIN Categories c ON p.category_id = c.category_id
GROUP BY 
    month, c.category_name
HAVING 
    SUM(od.quantity) = (
        SELECT 
            MAX(total_quantity)
        FROM 
            (
                SELECT 
                    EXTRACT(MONTH FROM o.order_date) AS month,
                    c.category_name,
                    SUM(od.quantity) AS total_quantity
                FROM 
                    Orders o
                    JOIN OrderDetails od ON o.order_id = od.order_id
                    JOIN Products p ON od.product_id = p.product_id
                    JOIN Categories c ON p.category_id = c.category_id
                GROUP BY 
                    month, c.category_name
            ) t
        WHERE 
            t.month = month
    )
ORDER BY 
    month;

NodeJs server with JSX routing (feat Fastify)

Oleksandr Demian — Sat, 05 Nov 2022 17:15:09 +0000

JSX is an XML-like syntax extension to javascript. It is mainly associated with front-end development since it is used in client-side libraries/frameworks such as React and Solid, but in reality its potential goes beyond template rendering. JSX is transpiled into pure JavaScript, and what you do with it is up to you.

One of the things you can do with it is to generate endpoints for a backend server.

Goal

The goal is to have a NodeJs server that will route requests using JSX components like this:

/** src/routes/Users.jsx */

const GetUser = async (req) => {
  const id = req.query.id;
  return Promise.resolve({
    id,
    message: `You requested user with id ${id}`,
  });
};

const GetAllUsers = async () => {
  return Promise.resolve({
    message: 'You requested all users',
  });
};

const PostUser = async (req) => {
  const { name, surname } = req.body;
  return Promise.resolve({
    message: `You posted user with name = "${name}" and surname = "${surname}"`,
  });
};

export const UserRouter = () => (
  <Router path="/users">
    <Endpoint method="GET">
      <GetUser />
    </Endpoint>
    <Endpoint method="POST">
      <PostUser />
    </Endpoint>
    <Endpoint method="GET" path="/all">
      <GetAllUsers />
    </Endpoint>
  </Router>
);

/** src/App.jsx */
export const App = () => {
  const port = 3000;
  const options = {
    logger: false,
  };

  const onStart = () => console.log(`App started on port ${port}`);

  return (
    <FastifyApp
      port={port}
      fastifyOptions={options}
      onStart={onStart}
    >
      <UserRouter/>
    </FastifyApp>
  );
}

Tech

esbuild: Transpile JSX and bundle server code
fastify: Fast and low overhead web framework for Node.js

Overview

To achieve the goal, the JSX code should be transpiled into plain Javascript, which can be executed by node. You can use any transpiler you want, in this tutorial I will go with esbuild, since it is simple to use and set up. We will also have to provide a custom jsx processor, which in our case will be a simple function that returns the parameters, the logic will be implemented in the components themselves.

Entities (base components)

From the above code we can already identify the following entities:

FastifyApp: a component that will instantiate the Fastify server and assign routes
Router: a component that will process its children and return a list of endpoints to the FastifyApp
Endpoint: a component containing endpoint description (method, path) and will return a handler

Setup

For this project to run you will have to install the following dependencies (you don't necessary have to use the same versions):

esbuild (v^0.15.12)
fastify (v^4.9.2)

Custom processor and start function

CustomJsxProcessor: this function will be used to replace JSX elements. It is the same as React.createElement and should be imported in all jsx files (no auto-import in this tutorial).
start: this function will start the app

/* src/CustomJsxProcessor.js */
function CustomJsxProcessor(tagName, props, ...children) {
  return {
    fn: tagName,// since we have no string tags here (all components are functions), we will rename tagName to fn
    props,
    children,
  };
}

export function start (app) {
  const proto = app();
  proto.fn({
    ...proto.props,
    children: proto.children,
  });
}

export default CustomJsxProcessor;

Base components

Note that base components (Endpoint, Router, and FastifyApp) won't return JSX as you do with client-side libraries, instead, they will return javascript objects that can be used by Fastify.

Base components will be executed at start time (once) to create routes and cannot be modified at runtime (as oposed to React where components are executed every time).

Endpoint

/* src/components/Endpoint.js */

/**
 * Process endpoint
 * For simplicity, only the first child will be used as handler
 */
const getEndpoint = ({ method, path }, children) => {
  if (children.length < 1) {
    console.warn(`No handler detected for endpoint ${method}: ${path}`);
  } else {
    if (children.length > 1) {
      console.warn(`Multiple handlers detected for endpoint ${method}: ${path}. Only the first one will be used`);
    }

    return ({
      method: method,
      url: path || '',
      handler: typeof children[0] === "function" ? children[0] : children[0].fn,
    });
  }
}

export const Endpoint = ({ method = 'GET', path, children }) => getEndpoint({ method, path }, children);

Router

/* src/components/Router.js */

import {Endpoint} from "./Endpoint";

/**
 * process Endpoint component.
 * This will take in input a JSX component and return javascript endpoint object
 * <Endpoint path="/users" method="GET">{handler}</Endpoint> -> ({
 *   path: '/users',
 *   method: 'GET',
 *   handler: (req, res) => { ... },
 * })
 */
const getEndpoint = (path, node) => {
  // path -> router path. Endpoint will use it as prefix for nesting
  // node -> a JSX element (<Endpoint ... />)

  // execute endpoint function to get endpoint info (method, url, handler)
  const endpoint = node.fn({
    ...node.props,
    children: node.children,
  });

  // prefix endpoint path with router path
  if (path) {
    endpoint.url = path + endpoint.url;
  }

  return endpoint;
};

export const Router = ({ children, path }) => {
  const endpoints = [];

  for (const child of children) {
    if (child.fn === Router) {
      // a child can be a nested router, execute it and get all of its endpoints as nested paths
      const r = child;
      endpoints.push(
        ...r.fn({
          ...r.props,
          path: r.props.path ? path + r.props.path : '',
          children: r.children,
        }),
      );
    } else if (Endpoint === child.fn) {
      // a child is endpoint, process it and add it to the endpoints list
      endpoints.push(getEndpoint(
        path,
        child,
      ));
    } else {
      console.warn(`${child.fn} is not supported under Router`);
    }
  }

  return endpoints;
}

FastifyApp

/* src/components/Router.js */

import fastify from "fastify";
import { Router } from "./Router";

/**
 * Process Router children and return list of endpoints
 */
export const getEndpoints = (nodes) => {
  const endpoints = [];

  for (const child of nodes) {
    let r;
    /**
     * A child can be Router or a component returning a Router.
     * In the latest case, we should execute the function to get the Router
     */
    if (child.fn === Router) {
      // child is a Router
      r = child;
    } else {
      // child is a Component, execute it, since it may return a Router
      r = child.fn({
        ...child.props,
        children: child.children,
      });
    }

    // if `r` is router, get endpoints
    if (r.fn === Router) {
      endpoints.push(
        ...r.fn({
          ...r.props,
          children: r.children,
        }),
      );
    }
  }

  return endpoints;
};

export const FastifyApp = ({
  children,
  onStart,
  port,
  fastifyOptions,
}) => {
  const endpoints = getEndpoints(children);
  // create fastify server
  const server = fastify(fastifyOptions);

  // assign endpoints
  for (const endpoint of endpoints) {
    console.log(`Create endpoint ${endpoint.method}: ${endpoint.url}`);
    server.route({
      method: endpoint.method,
      url: endpoint.url,
      handler: endpoint.handler,
    });
  }

  // start server
  server.listen({ port }).then(() => {
    if (onStart) {
      onStart();
    }
  });
};

App

Now that we have all the base components we can start implementing the application.

Users router

/* src/routes/Users.jsx */

/* ! REMEMBER TO IMPORT JSX FACTORY (CustomJsxProcessor) */
import CustomJsxProcessor from "../CustomJsxProcessor";
import {Router} from "../components/Router";
import {Endpoint} from "../components/Endpoint";

const GetUser = async (req) => {
  const id = req.query.id;
  return Promise.resolve({
    id,
    message: `You requested user with id ${id}`,
  });
};

const GetAllUsers = async () => {
  return Promise.resolve({
    message: 'You requested all users',
  });
};

const PostUser = async (req) => {
  const { name, surname } = req.body;
  return Promise.resolve({
    message: `You posted user with name = "${name}" and surname = "${surname}"`,
  });
};

const NestedGet = async () => Promise.resolve({
  message: `This endpoint is nested`,
});

export const UserRouter = () => (
  <Router path="/users">
    <Endpoint method="GET">
      <GetUser />
    </Endpoint>
    <Endpoint method="POST">
      <PostUser />
    </Endpoint>
    <Endpoint method="GET" path="/all">
      <GetAllUsers />
    </Endpoint>

    {/* Nested routing, will inherit /users */}
    {/* Current implementation does not allow nested component routers */}
    <Router path="/nested">
      <Endpoint method="GET">
        <NestedGet />
      </Endpoint>
      <Endpoint method="GET" path="/no-component-example">
        {async (req, res) => {
          // you can use handlers without components
          const date = Date.now();
          return Promise.resolve({
            message: `This handler does not have component`,
            timestamp: date,
          });
        }}
      </Endpoint>
    </Router>
  </Router>
);

Instantiate app with Fastify

/* src/App.jsx */

import CustomJsxProcessor from "./CustomJsxProcessor";
import {UserRouter} from "./routes/Users";
import {FastifyApp} from "./components/FastifyApp";

export const App = () => {
  const port = 3000;
  // fastify options
  const options = {
    logger: false,
  };

  const onStart = () => console.log(`App started on port ${port}`);

  return (
    <FastifyApp
      port={port}
      fastifyOptions={options}
      onStart={onStart}
    >
      <UserRouter/>
    </FastifyApp>
  );
}

Entry point to start the server

/* src/server.js */

import {App} from "./App";
import { start } from "./CustomJsxProcessor";

start(App);

Run the server

Now that all the components are in place, and App is implemented, the only remaining thing is to run it. We will need to bundle the app using esbuild and execute the bundle with node.

bundle script

/* scripts/index.js */

#!/usr/bin/env node
const esbuild = require('esbuild');

esbuild.build({
  entryPoints: ["src/server.js"],
  bundle: true,
  outfile: "build/server.js",
  jsxFactory: 'CustomJsxProcessor',
  jsx: 'transform',
  platform: 'node',
}).catch(() => process.exit(1));

script command

To run the app execute the following command:

node scripts/index.js && node ./build/server.js

package.json

Just for reference, the package.json looks like this:

{
  "name": "jsx-server-routing-with-fastify",
  "version": "0.0.0",
  "scripts": {
    "start:article": "node scripts/index.js && node ./build/server.js"
  },
  "dependencies": {
    "fastify": "^4.9.2",
    "esbuild": "^0.15.12"
  }
}

You can find the code here.

Sync height between elements in React

Oleksandr Demian — Sun, 14 Aug 2022 09:00:11 +0000

A simple problem: make sure that the different elements in the app are the same height, as if they were in a table.

Let's start with a sample react app that renders 3 cards with different items (styles are omitted, but at the end they are all flex boxes):

const ItemCard = ({
  title,
  items,
  footerItems,
}: {
  title: string;
  items: string[];
  footerItems: string[];
}) => {
  return (
    <div className="card">
      <h2>{title}</h2>
      <div className="separator" />
      <div className="items">
        {items.map((item) => (
          <p>{item}</p>
        ))}
      </div>
      <div className="separator" />
      <div className="footer">
        {footerItems.map((footerItem) => (
          <p>{footerItem}</p>
        ))}
      </div>
    </div>
  );
};

export const App = () => {
  return (
    <div>
      <ItemCard title="Card one" items={['One', 'Two']} footerItems={['One']} />
      <ItemCard
        title="Card two"
        items={['One', 'Two', 'Three', 'Four']}
        footerItems={['One', 'Two', 'Three']}
      />
      <ItemCard title="Card three" items={['One']} footerItems={['One']} />
    </div>
  );
};

When you run this app, you will get this result:

The desired result would be something like this:

In order to synchronize the height I came with the following idea: a custom hook that stores the references to all different elements that have to be matched in a {[key: string]: value: array of elements} object, and when there is a change in dependencies, the height of elements gets recalcualted in useLayoutEffect:

import { MutableRefObject, useLayoutEffect } from 'react';

type Target = MutableRefObject<HTMLElement | null>;

// Store all elements per key, so it is easy to retrieve them
const store: Record<string, Target[]> = {};

// Triggered when useLayoutEffect is executed on any of the components that use useSyncRefHeight hook
const handleResize = (key: string) => {
  // get all elements with the same key
  const elements = store[key];
  if (elements) {
    let max = 0;
    // find the element with highest clientHeight value
    elements.forEach((element) => {
      if (element.current && element.current.clientHeight > max) {
        max = element.current.clientHeight;
      }
    });
    // update height of all 'joined' elements
    elements.forEach((element) => {
      if (element.current) {
        element.current.style.minHeight = `${max}px`;
      }
    });
  }
};

// Add element to the store when component is mounted and return cleanup function
const add = (key: string, element: Target) => {
  // create store if missing
  if (!store[key]) {
    store[key] = [];
  }

  store[key].push(element);

  // cleanup function
  return () => {
    const index = store[key].indexOf(element);
    if (index > -1) {
      store[key].splice(index, 1);
    }
  };
};

// Receives multiple elements ([key, element] pairs). This way one hook can be used to handle multiple elements
export type UseSyncRefHeightProps = Array<[string, Target]>;
export const useSyncRefHeight = (refs: UseSyncRefHeightProps, deps?: any[]) => {
  useLayoutEffect(() => {
    // store cleanup functions for each entry
    const cleanups: (() => void)[] = [];
    refs.forEach(([key, element]) => {
      // add element ref to store
      cleanups.push(add(key, element));
    });
    return () => {
      // cleanup when component is destroyed
      cleanups.forEach((cleanup) => cleanup());
    };
  }, []);

  useLayoutEffect(() => {
    // when any of the dependencies changes, update all elements heights
    refs.forEach(([key]) => {
      handleResize(key);
    });
  }, deps);
};

By using this hook we can change a bit ItemCard element:

const ItemCard = ({
  title,
  items,
  footerItems,
}: {
  title: string;
  items: string[];
  footerItems: string[];
}) => {
  // create ref to the parent container, to only target its children instead of running query on the entire document
  const itemsRef = useRef(null);
  const footerRef = useRef(null);

  // align elements with class items
  // deps is an empty array, so it will only be aligned when the component is mounted.
  // You can add your dependencies, or remove it to make sure the hook runs at every render
  useSyncRefHeight(
    [
      ['items', itemsRef],
      ['footer', footerRef],
    ],
    // trigger hook when items of footerItems changes, since it may change height
    [items, footerItems],
  );
  return (
    <div className="card">
      <h2>{title}</h2>
      <div className="separator" />
      <div className="items" ref={itemsRef}>
        {items.map((item) => (
          <p>{item}</p>
        ))}
      </div>
      <div className="separator" />
      <div className="footer" ref={footerRef}>
        {footerItems.map((footerItem) => (
          <p>{footerItem}</p>
        ))}
      </div>
    </div>
  );
};

Now, items and footer elements height will be matched across all cards.

Simplify React code using Babel transpiling: useState

Oleksandr Demian — Sun, 05 Dec 2021 19:19:02 +0000

Hi devs,

I've been working with react hooks for several years now, more or less since the beginning. It is a huge improvement compared to class components you had to use before, but it still has a lot of code to write, especially compared to Svelte.

This made me think: is it possible to reduce React syntax in order to make it more concise? The short answer is yes. The solution that I decided to adopt is to write a Babel plugin (since you need Babel in any case with React) to leverage some work during the build.

The first thing I worked on is useState. My goal was to remove destructuring of the useState hook and to have a simple variable declaration to be reactive by itself. As the result I got this:

// useState import is not necessary

function Example() {
    let $value = 5;
    return (
        <button onClick={() => $value++}>{$value}</button>
    );
}

The snippet above is equivalent to this:

import { useState } from "react";

function Example() {
    const [value, setValue] = useState(5);
    return (
        <button onClick={() => setValue(value+1)}>{value}</button>
    );
}

As you can see, the gains here are:

simpler, more concise declaration of reactive property
no need for setter, assigning new value to the property will trigger reactivity
no need to import useState (not a big deal, it's done automatically in any case, but still).
better readability (imo)

After I was done with useState (with initial prototype), I started thinking about useEffect and useMemo. The problem is that they are much trickier to simplify, and it's hard to come with a cleaner syntax for them. This is what I had in mind:

function Example() {
    let $value = 5;
    const $memo = $value * 2;
    // eq: const memo = useMemo(() => $value * 2, [$value]);

    $ => {
        // effect body
        return () => {
            // effect cleanup
        }
    }
    /** the above is the same as:
     * useEffect(() => {
     *     // effect body
     *     return () => {
     *         // effect cleanup
     *     }
     * }, []);
     */

    $ => {
        console.log($memo);
    }
    /** the above is the same as:
     * useEffect(() => {
     *     console.log($memo);
     * }, [$memo]);
     */

    return (
        <button onClick={() => $value++}>{$value}</button>
    );
}

Notice there is no need for dependencies for both useMemo and useEffect alternatives. They will be injected during build.

Said that, my questions are:

Does it make sense? Or, would you use something like this, or would you stick with classic hooks?
If yes, what syntax would you like it to be?
Is there already something similar?

Dynamic readme: Tic-tac-toe

Oleksandr Demian — Sat, 10 Oct 2020 13:44:51 +0000

It was a very boring saturday...

Premise

Usually, you are used to see a readme file as something static (actually, they are thought to be static). You can add a bit of dynamic information with badges, but nothing that you can interact with.

Action

So, as I sad, the saturday morning was very boring, so I decided to challenge myself with something new, and the idea I had was to try to create interactive readme. My first thought was about a minesweeper game, but it was to much to make in a morning, so I decided for something easier: tic-tac-toe.

Development

Obviously, it requires a bit of tricks in order to work.

Initial failure

My original idea was to use a single svg image with links around different shapes. Each link will call a server with X and Y, server will update the game state, and new image will be served the next time. This idea failed instantly: github wrapps hole image inside a link to open it, so you cannot use internal links.

Second idea

At this point I started thinking on how to workaround this behaviour. Actually it was very easy: instead of having only one image, I will display a table, where each cell is a game cell with link inside of it. And it worked!

How it works

The whole project consists of 3 parts:

Readme
Server
Database

Readme

This one is very simple: 3x3 table with a footer row for some additional functionalities (restart, whose turn). Each cell contains a link that wraps around the image:

<td>
    <a href="url_to_php?x=1&y=1&action=move">
        <img src="url_to_php?x=1&y=1&action=view">
    </a>
</td>

Both image and link are pointing to the same file, but they have different action:

if action is move, it will update the game state and reload the page.
if action is view, it will fetch the image with value saved for X and Y position.

Server

This is where the business is done. It runs php (I don't know which version).

Once it receives request, it will update the database with new data or serve the image based on a value saved in DB for X and Y.

Database

Nothing special here. Database is MySQL. It has two tables:

board: saves board;
game: saves game information (next turn, was board generated, etc...);

Last words

If you want to give it a shot, you can find it here: https://github.com/OleksandrDemian/readme-tic-tac-toe

DEV Community: Oleksandr Demian

GameMaker setup with Typescript and VS Code

The actual thing

Setup

Project configuration and the TS first object

Run it

How GameMaker understands TS

🧘‍♂️ A Minimalist’s Guide to Global State in React

Why Another State Library?

The Core Idea

✅ Tiny

🧠 Fully Typed

🎯 Selector-Based

⚙️ Zero Dependencies

A Real-World Example

When Should You Use This?

Under the Hood

Try It Yourself

Wrap-Up

⚛️ Build a Simple Todo App with React Store - a Tiny React State Manager

🔧 Installation

🏗️ Step 1: Set up the Todo Store

🧑‍🎨 Step 2: Create Todo Input Component

📋 Step 3: Display and Interact with Todos

🧩 Step 4: Combine Components in App

✅ Why @odemian/react-store?

🧾 Summary

🌍 The smallest and simplest global state manager for React

⚙️ How It Works

🚀 Getting Started

1. Install it

2. Create a Store

3. Use It in Components

4. Use Outside React

🔬 Comparison with Other Tools

⚠️ Caveats

✨ Final Thoughts

Typescript deserves a better dependency injection framework 💉

The State of Dependency Injection in TypeScript

How Reflect-Metadata Works and Its Limitations in DI/IoC

A Basic Example Without Interfaces

The Problem with Interfaces

How Existing DI Frameworks Tackle These Problems

The Downsides

Can TypeScript Have a Better DI Framework?

A New Approach to DI in TypeScript

Examples of Better DI in Action

Injecting Components via Interfaces

Support for type Injection

Ensuring Type Safety

Conclusion

Express app with decorators based routing and dependency injection

Why Use Decorators and Dependency Injection?

1. Project Setup

2. Decorators for Routing and Injection

routing.ts - Creating the Decorators

3. Defining the Data Source

datasource.ts - The DataSource Factory

4. Defining the Entity

user.entity.ts - A TypeORM Entity

5. Creating the Router

UsersRouter.ts - Defining Routes

6. Service Layer

UsersService.ts - Handling Business Logic

7. Bootstrapping the Application

app.ts - Putting Everything Together

Conclusion

Creating Typescript app with decorator-based dependency injection 💉

How it Works

Setting Up

TypeScript Configuration

Final thoughts

GPT Query: the AI tool that can write SQL queries for you

Introduction

Examples

Create table

Create dummy data

Data analysis

NodeJs server with JSX routing (feat Fastify)

Goal

✅ Why `@odemian/react-store`?

Support for `type` Injection

`routing.ts` - Creating the Decorators

`datasource.ts` - The DataSource Factory

`user.entity.ts` - A TypeORM Entity

`UsersRouter.ts` - Defining Routes

`UsersService.ts` - Handling Business Logic

`app.ts` - Putting Everything Together