DEV Community: wszgrcy

Piying-View: write forms with a schema, field types inferred end to end

wszgrcy — Mon, 21 Sep 2026 07:43:37 +0000

What is Piying-View

Piying-View is an open-source, strongly typed TypeScript form library for the frontend.

You write one schema with Valibot (what the data looks like, what validation rules it has), and Piying-View turns it into a complete working form:

All controls rendered automatically
Two-way data binding handled for you
Validation and error display handled for you
Automatically reacts to data changes: hide / disable / couple fields

You can use it with Angular, Vue 3, Vue 2, React, Svelte, Solid. The same schema and business logic moves as-is — switching frameworks only means rewriting the registered components.

Capabilities at a glance

Capability	How
Define the structure	Valibot schema: `object` / `array` / `record` / `tuple` / `union` / `intersect` / `map` / `set`
Choose the control	`setComponent('input')`, or set global defaults with `fieldGlobalConfig`
Pass props to a component	`inputs`
Handle component events	`outputs`
Two-way binding	`models` (fully supported in Angular)
Native DOM events	`events`
HTML attributes / ARIA / `data-*`	`attributes`
Arbitrary custom metadata	`props`
Styling	`class.top` / `class.bottom` / `class.component`
Outer wrappers (label, error message, grid)	`wrappers`
Conditional hide / disable	`hideWhen` / `disableWhen`
Value coupling	`valueChange` / `outputChange`
Validation	`formConfig.validators` / `asyncValidators`, or write Valibot validation directly
Value transformation	`formConfig.transformer` (toView / toModel), `pipe` (RxJS), `v.transform`
Layout adjustment	`layout({ priority })` for ordering, `layout({ keyPath })` to move a field
Service injection	`providers` (Angular uses `inject()`, other frameworks use static-injector)
Lifecycle	`hooks`
Treat a nested object as one control	`asControl()` / `asVirtualGroup()`
JSON Schema	`jsonSchemaToValibot()` converts it automatically

Two ways to use it

They can be nested freely:

Automatic mode: <piying-view [schema]="..."> — the library renders the whole component tree for you.
Manual mode: call convertToField() yourself to get a field, then bind it with a directive wherever you want to put it.

End to end strong typing and code completion

Latest feature update

Without type hints

Actions have always worked, but they were loose about "the key you write" and "the field in your callback":

import * as v from 'valibot';
import { actions, setComponent } from '@piying/view-angular-core';

const schema = v.pipe(
  v.string(),
  setComponent('input'),
  actions.inputs.set({ placeholder: 'Enter a name', maxLength: 50 }),
  actions.inputs.patchAsync({
    content: (field) => {
      field.get(['address', 'city']); // Does this path even exist? You can't tell from the types
      field.form.control.value; // any
      field.form.root.value; // any
      return '';
    },
  }),
);

inputs is typed as Record<string, any>: keys are free-form, value types are not checked
The field in callbacks is a generic shape: get() cannot resolve an accurate type, .value is any
A typo like palceholder, or using a number where a string belongs, only shows up at runtime

With type hints

Types are not an interface bolted on afterwards — they are inferred all the way down from the schema:

Autocompleted paths: your editor completes paths from the schema structure and flags wrong ones
Typed callbacks: field is the exact field type for that path, not any
Typed values: field.form.control.value is the output type inferred from the schema; same for parent / root

`typedFieldPipe` — attach metadata to a schema by path

Adds actions (metadata) to an already defined schema and returns a new schema. It is written by path, and paths are derived from the schema structure:

import * as v from 'valibot';
import { typedFieldPipe } from '@piying/view-core';

const schema = v.object({
  name: v.string(),
  age: v.number(),
  price: v.number(),
  address: v.object({ city: v.string(), zip: v.string() }),
  tags: v.array(v.object({ label: v.string(), count: v.number() })),
});

const merged = typedFieldPipe(schema, (d) => [
  // Paths are derived from the schema; the editor flags a wrong one
  d(
    ['address', 'city'],
    [
      d.props.patchAsync({
        tag: (field) => {
          // The field in the callback == builder.get(['address', 'city'])
          field.form.control!.value; // string
          field.form.parent.value; // { city: string; zip: string }
          field.form.root.value; // { name; age; price; address; tags } — all exact

          // Query other fields and you still get exact types
          field.get(['..', 'zip'])!.form.control!.value; // string
          field.get(['#', 'age'])!.form.control!.value; // number
          field.get(['#', 'tags', 0, 'count'])!.form.control!.value; // number

          return 'ok';
        },
      }),
    ],
  ),
]);

Coupling is just as precise — whatever fields you listen to, the callback types exactly those positions:

d(
  ['address', 'city'],
  [
    d.valueChange((fn) => {
      fn({ list: [undefined, ['..', 'zip'], ['#', 'age']] }).subscribe((s) => {
        s.list; // [string, string, number] — exact per position, not any
        s.listenFields; // the matching field per position, each with .get() and .form.control
      });
    }),
  ],
);

hideWhen / disableWhen / outputChange / class.asyncTop / outputs.mergeAsync … every action with a field callback uses the same set of precise types. Official Valibot actions (v.minLength / v.check / v.transform) can be mixed in directly, and their callback parameters stay precise too.

Framework agnostic: import from @piying/view-angular-core in Angular, from @piying/view-core in Vue / React / Svelte / Solid — the syntax is identical.

`typedFieldComponentPipe` — component props are narrowed too

typedFieldPipe knows nothing about components: the keys of inputs / outputs are free-form.

typedFieldComponentPipe takes one extra argument: the "component", and locks the keys and value types of inputs / outputs / events / attributes to the properties that component actually has:

Autocompletion only lists the props / events the component really has
A wrong prop name or a wrong prop value type is flagged by the editor
The entry also automatically carries setComponent(component), so the type used for validation = the component actually rendered

import { typedComponent, typedFieldComponentPipe } from '@piying/view-angular';

const typeDefine = typedComponent({
  types: {
    // @Input() placeholder?: string; @Input() precision: number
    amount: { type: AmountInputComponent },
    // @Output() change: EventEmitter<string[]>
    tags: { type: TagPickerComponent },
  },
});

const merged = typedFieldComponentPipe(schema, typeDefine, (d) => [
  d(['price'], 'amount', [
    d.inputs.patch({ placeholder: 'Enter an amount' }),
    d.inputs.patch({ placeholder: 123 }), // editor error: wrong value type
    d.inputs.patch({ palceholder: 'x' }), // editor error: no such prop

    d.inputs.patchAsync({
      precision: (field) => (field.form.control!.value > 100 ? 0 : 2),
    }),
  ]),

  d(['tags'], 'tags', [d.outputs.merge({ change: (value: string[]) => console.log(value) }), d.outputChange((fn) => fn([{ list: undefined, output: 'change' }]))]),
]);

Usage is the same across frameworks; only "how component props map to inputs / outputs" follows each framework's own component model:

Framework	Mapping rule	Notes
Angular	`input()` / `output()` / `model()`	The only framework exposing `models`
Vue 3	Split from `$props`, emit names drop the `on` prefix	Supports `markRaw` / lazy loading
React	A function prop is an output, names kept as-is
Solid	Same shape as React, built-in keys include `classList`
Svelte 5	A function prop is an output, Snippets are not counted

In the component slot you can pass a key registered in types, or a component class directly (including lazy loading). You are not locked out when a component cannot be inferred: inputs / outputs fall back to plain key / value — keys are simply no longer validated, everything else keeps working.

typedFieldPipe is general purpose and works with any frontend framework;
typedFieldComponentPipe is framework specific, depending on which framework you use.

`convertToField` — manual conversion is equally precise

Every framework provides convertToField. After converting a schema into a field, you can still call field.get(xxx) and get equally accurate types:

const field = convertToField(
  () => schema,
  undefined,
  () => options,
);

field.get(['address', 'zip'])!.form.control!.value; // string
field.get(['tags', 0, 'count'])!.form.control!.value; // number
field.form.control!.value; // the output type of the whole schema

Manual binding — the path is remembered by the type

In manual mode, the path you bind is remembered by the type as well. In Angular that is PiyingFieldControlBindDirective:

<input [formControl]="root()" [path]="['address', 'city']" #city="formControl" />

The city template reference variable:

city.field$$(); // the field type for the path ['address', 'city']
city.fieldControl$$(); // its control, .value is string
city.summaryList$$(); // validation error summary

[path] is autocompleted too — it feeds every valid path of the root schema straight to your editor, the very same set you get from typedFieldPipe. Other frameworks have differently shaped binding directives, with the same capability.

Who is responsible for what

You write	What you get	Scope
`typedFieldPipe(schema, d => [...])`	Path autocompletion + precise `field` in callbacks + precise `field.get()` + precise `.value`	All frameworks (general)
`typedFieldComponentPipe(schema, cfg, d => [...])`	Everything above + `inputs` / `outputs` / `events` / `attributes` narrowed to the real component	One per framework
`convertToField(...)`	The converted `field`, with precise `get()` / `.value`	One per framework
`[formControl]` / `[path]` manual binding	The bound path is remembered by the type, template reference variables are strongly typed	Matching directive per framework

If you are tired of "renaming one form field means chasing changes through the template, the validation and the types" — this was built for you.

📖 Docs: https://piying-org.github.io/piying-view/ (with an online Playground — edit it and run it right there)

📦 Repo: https://github.com/piying-org/piying-view

Capacitor GeckoView: Say Goodbye to WebView Kernel Fragmentation

wszgrcy — Sun, 06 Sep 2026 01:25:25 +0000

Why This Project Exists

Capacitor is a highly popular cross-platform mobile development framework today. Its biggest strength is "one set of web code, reused across multiple platforms" — it runs frontend code through the built-in WebView on Android, allowing developers to deliver native apps using only HTML/JS/CSS.

However, there is a long-overlooked problem here: the kernel version of Android's built-in WebView is not unified.

Different vendors, different system versions, and even different models come with vastly different system WebView kernels. Older devices may have WebView stuck at Chrome versions from years ago, while newer devices run the latest versions. This means:

The new APIs you confidently use during development may directly throw errors on users' older devices.
To support legacy kernels, you have to write piles of polyfills and stick to outdated syntax.
"Same code, inconsistent behavior" becomes the norm, and testing costs remain high.

The Solution: Introducing GeckoView

To make the kernel always controllable and always up‑to‑date, I introduced GeckoView — the browser engine behind Firefox.

As an independent engine that can be packaged with your app, GeckoView's greatest advantage is that the engine version is determined by you. Whatever kernel version you bundle with the app is what runs on users' devices, completely breaking the dependency on the system WebView.

Advantages

Unified and up‑to‑date kernel version: No matter what device or system version the user has, they all run the same Firefox engine, ensuring fully consistent behavior.
No more compatibility worries during development: You can safely use the latest HTML/JS/CSS features without writing hacks for old WebViews. The development experience is almost identical to modern web development.
Same usage as vanilla Capacitor: Build commands and development workflows are exactly the same as native Capacitor, making the learning curve minimal and migration smooth.

Disadvantages

Increased package size: Bundling a complete browser engine makes the installation package larger than the default solution. However, after minimal trimming, it is now compressed to about 120MB for the arm64 architecture — much smaller than the default 200MB, with further optimization possible.

Plugin Compatibility

Since most Capacitor native plugins are written for the system WebView, some plugins are not 100% compatible with GeckoView. Common reasons include:

Plugins rely on WebView‑specific features or interfaces.
Gradle version mismatches (this project uses Gradle 9, while some plugins are written for Gradle 8 and need manual upgrades).

To address this, I have prepared a Migration Guide to help you quickly adapt existing plugins to run on GeckoView.

Resources

Content	Link
Main open‑source project	https://github.com/wszgrcy/capacitor-geckoview
Starter template (ready to use)	https://github.com/wszgrcy/capacitor-geckoview-starter
Plugin migration guide	https://github.com/wszgrcy/capacitor-geckoview-plugins/blob/main/docs/webview-to-geckoview-%E8%BF%81%E7%A7%BB%E6%8C%87%E5%8D%97.md

Feedback & Discussion

If you encounter any issues while using this project, feel free to send an email to wszgrcy@gmail.com. I will do my best to help.

I hope this project helps you break free from WebView kernel fragmentation, so you can focus your energy on building your business logic with peace of mind.

Angular Selectorless Support

wszgrcy — Sun, 19 Jul 2026 13:10:14 +0000

Preface

Recently, while implementing the Angular adapter for opentui, the special mechanism of opentui made it necessary to rewrite the renderer. This led to the discovery that virtual nodes can reduce the rendering of custom component tags. Therefore, I attempted to extract this approach for standalone use in the browser.

Usage

Install @cyia/ngx-common/service
Configuration

import { ApplicationConfig, provideBrowserGlobalErrorListeners, RendererFactory2 } from '@angular/core';
import { provideRouter } from '@angular/router';

import { routes } from './app.routes';
import { DomRendererFactory2 } from '@cyia/ngx-common/service';
export const appConfig: ApplicationConfig = {
  providers: [
    provideBrowserGlobalErrorListeners(),
    provideRouter(routes),
    // Add this configuration
    { provide: RendererFactory2, useClass: DomRendererFactory2 },
  ],
};

Limitations

Implementing styles inside components is forbidden, because styles require an outermost element with attributes to define the scope, while selectorless components have no outermost element.
Elements must be manually marked as selectorless because the implementation operates at the application layer, and element rendering is decoupled from component binding, so manual specification is required.

import { selectorlessExcludeTag } from '@cyia/ngx-common/service';
selectorlessExcludeTag('app-t1');

Directives that bind to and manipulate the DOM cannot be implemented. Normal directive binding still works, but if a directive internally performs operations that involve obtaining an ElementRef, they cannot be realized.

Source Code

cyia-ngx-common

Writing TUI in the Terminal with Angular: Introducing @cyia/opentui-angular

wszgrcy — Sun, 19 Jul 2026 10:07:26 +0000

Foreword

Terminal applications (TUI, Text User Interface) have always had a unique charm — lightweight, fast, and cross-platform. From htop to vim, from the interactive wizard of npm init to database management tools, excellent terminal interfaces can make command-line workflows more efficient.

However, developing a terminal application usually requires dealing directly with low-level rendering details: calculating character buffers, handling ANSI escape sequences, listening for terminal resize events... These tedious tasks often overshadow the business logic itself.

Recently, an Angular adapter for the OpenTUI project has emerged — @cyia/opentui-angular. It allows developers familiar with Angular to build terminal interfaces using the patterns they already know.

OpenTUI itself provides a comprehensive component system (text, box, input, scrollbox, code, diff, etc.) and a set of hooks APIs (keyboard events, focus management, paste handling, timeline animations, etc.), but its design is deeply coupled to React — it relies on react-server-dom-flight to drive the rendering loop.

The Positioning of the Angular Adapter

What @cyia/opentui-angular does is clear: retain the rendering capabilities of OpenTUI core, while replacing the React rendering engine with Angular's component system.

Specifically, this adapter accomplishes the following:

1. Custom Platform Layer

Angular's ɵinternalCreateApplication accepts a platformProviders parameter, allowing developers full control over the underlying DOM adaptation. The OpenTUI adapter implements a TDomAdapter — since terminal applications don't need a real browser DOM, this adapter provides no-op implementations or stub functions for most DOM APIs, and takes over RendererFactory2 and Sanitizer, bridging them to OpenTUI's renderer.

2. Component Mapping

OpenTUI core exports a large number of Renderable classes (such as BoxRenderable, TextRenderable, InputRenderable, etc.), which are essentially the "HTML tags" of the terminal world. The adapter registers these Renderables as Angular custom elements, and with the NO_ERRORS_SCHEMA configuration, developers can directly use tags like <box>, <text>, <input> in their templates:

@Component({
  selector: 'app-root',
  schemas: [NO_ERRORS_SCHEMA],
  template: `
    <box>
      <text [content]="message()" fg="cyan" />
    </box>
  `,
})
export class App {
  protected message = signal('Hello from Angular + OpenTUI');
}

3. Angular-ifying Hooks

OpenTUI's native hooks (like useRenderer, useKeyboard) depend on React's context mechanism. The adapter rewrites these hooks to use Angular's inject(), effect(), and computed(), enabling them to function correctly within Angular's dependency injection system:

useKeyboard((key) => {
  if (key.name === 'escape') {
    process.exit(0);
  }
});

4. Slot System Adaptation

OpenTUI's plugin system allows external components to be inserted into the render tree through a SlotRegistry mechanism. The adapter implements createAngularSlotRegistry, bridging Angular's TemplateRef, NgTemplateOutlet, and ComponentRef with OpenTUI's slot protocol, so that Angular templates can be rendered into the terminal interface as plugin content.

5. Keymap Submodule

The adapter also publishes a separate subpath export @cyia/opentui-angular/keymap, providing an Angular Signal-based key mapping solution. With utility functions like useKeymap, useBindings, and useActiveKeys, developers can define keyboard shortcut bindings declaratively, supporting advanced interaction patterns like leader keys and command completion.

6. Component Extension Capability

OpenTUI core provides an extend() API to allow custom Renderables. The adapter retains this capability — you can inherit from existing Renderables (e.g., BoxRenderable), override the rendering logic, and then register them as new tags for use:

class ConsoleButtonRenderable extends BoxRenderable {
  protected override renderSelf(buffer: OptimizedBuffer): void {
    super.renderSelf(buffer);
    // Custom button text drawing logic
  }
}

extend({ consoleButton: ConsoleButtonRenderable });

Included Examples

The project itself comes with a fairly rich set of examples covering common TUI scenarios:

Example	Description
Basic Demo	Login form, focus management, styled text (bold/italic/colors)
Counter Demo	Timed re-rendering driven by Signal state updates
Animation Demo	System monitoring animation driven by the Timeline API
Borders / Box	Border styles and layout components
Scrollbox	Scrollable content area
Code / Line Number	Code highlighting and line number display
Diff	Text diff comparison view
Hooks Demo	Comprehensive demonstration of various hooks
Keymap Demo	Complete keyboard shortcut system, supports leader keys, command completion
Extend Demo	How to extend custom Renderables
Flush Sync	Synchronous flush rendering

Tech Stack

Angular 22 — The latest Angular version, fully adopting Signals and the new control flow syntax
OpenTUI core ^0.4.x — The underlying TUI rendering engine

Usage

Quick Start

The project provides a GitHub template that can be cloned with a single command:

git clone https://github.com/wszgrcy/ngx-opentui-starter.git
cd ngx-opentui-starter
npm install && npm start

Manual Integration

If your project is already based on Angular, after installing the dependencies you only need a small amount of configuration at the application entry point:

import { bootstrapApplication, CliRendererToken } from '@cyia/opentui-angular';
import { createCliRenderer } from '@opentui/core';

const renderer = createCliRenderer();
renderer.then((cliRenderer) =>
  bootstrapApplication(App, {
    providers: [{ provide: CliRendererToken, useValue: cliRenderer }],
  }),
);

Then remember to add schemas: [NO_ERRORS_SCHEMA] in your component — this is a necessary configuration for using custom elements like <text> and <box>.

Who Is It For?

Angular Developers — If you want to build terminal applications but don't want to learn React or a completely new framework, this adapter lets you directly apply your existing Angular knowledge.
Node.js Projects Needing a TUI — Scenarios like interactive CLI tools, operations dashboards, database management interfaces, etc.
OpenTUI Users — If you are already using OpenTUI but are more accustomed to Angular's development patterns, this adapter provides a migration path.

Summary

What @cyia/opentui-angular does is not complicated — it is essentially a bridging layer that exposes the rendering capabilities of OpenTUI core as Angular components and hooks. But it solves a practical problem: allowing Angular developers to build terminal interfaces in the most natural way.

If you are looking for a solution that enables an Angular project to quickly gain TUI capabilities, or if you are simply curious about the idea of "using a virtual DOM in the terminal," this project is worth exploring.

npm: @cyia/opentui-angular
Source Code: GitHub
Quick Start Template: ngx-opentui-starter

ngx-ink: The Angular Version of Ink, A Component-Based Revolution for Terminal UI

wszgrcy — Sun, 28 Jun 2026 00:53:11 +0000

Ink is already the most mature terminal UI framework in the React ecosystem. Now, Angular developers can enjoy the same power.

Background: Ink Has Proven This Path Works

In the React ecosystem, Ink has successfully validated the feasibility of "building CLI interfaces with components." It is adopted by numerous well-known projects such as Claude Code, GitHub Copilot CLI, Cloudflare Wrangler, and Prisma, boasting a mature API design and rich ecosystem.

But there's one problem: Angular developers are left out.

Ink is built on React, relying on React's Hooks, JSX, and functional component model. For Angular teams, this means either learning an entirely new programming paradigm or giving up the ability to enjoy componentized UI in the terminal.

ngx-ink was born to solve this problem.

What is ngx-ink?

ngx-ink is the complete Angular migration of Ink. It reuses Ink's core logic—including ANSI processing, Yoga Flexbox layout calculation, and rendering pipeline—but transforms the entire programming model from React to Angular.

Core Promise: API equivalence, seamless experience transition.

If you know how to use it in Ink, you know how to use it in ngx-ink. The only difference is that the syntax changes from React-style to Angular-style.

Core Features

🎨 Declarative Componentized UI

Say goodbye to string concatenation. Use familiar Angular component syntax to build your interface in the terminal:

@Component({
  selector: 'app-root',
  template: `
    <box [style]="{ flexDirection: 'column', padding: 1 }">
      <text [color]="'cyan'" [bold]="true">🚀 My CLI Tool</text>
      <text [color]="'green'">Status: Running</text>
      <text [color]="'yellow'">Progress: {{ progress() }}%</text>
    </box>
  `
})
export class AppComponent {}

📐 Flexbox Terminal Layout

Powered by Facebook's Yoga engine, ngx-ink implements full Flexbox layout capabilities in the terminal. flexDirection, justifyContent, alignItems, margin, padding—these properties you take for granted in web development are now all available in the terminal.

<box [style]="{ flexDirection: 'row', justifyContent: 'space-between' }">
  <text>Left Item</text>
  <spacer></spacer>
  <text [color]="'green'">Right Item ✓</text>
</box>

🎬 Responsive Real-time Updates

Leveraging Angular Signals' reactivity, the terminal interface automatically refreshes as data changes, without manually calling update methods. Paired with the useAnimation hook, easily implement spinner animations, progress bar scrolling, and other effects:

animation = useAnimation(signal({ interval: 80 }));

get spinner() {
  const chars = ['⠋', '⠙', '⠹', '⠸', '⠼', '⠴', '⠦', '⠧', '⠇', '⠏'];
  return chars[this.animation().frame % chars.length];
}

⌨️ Complete Interaction Capabilities

Keyboard Input Listening — useInput hook supports arrow keys, key combinations, and full key mapping
Focus Management — useFocus enables Tab-based focus switching between components
Window Size Response — useWindowSize automatically detects terminal size changes
Standard Stream Access — useStdin / useStdout / useStderr directly manipulate I/O streams

🎭 Rich Built-in Components

Component	Purpose
`BoxComponent`	Flexbox layout container
`TextComponent`	Text display with style support (colors, bold, italic, underline, etc.)
`NewlineComponent`	Line break control
`SpacerComponent`	Flexible blank space filling
`StaticComponent`	Static content rendering (logs, completed tasks, etc.)
`TransformComponent`	Text transformation processing

🎨 Complete ANSI Color Support

Built on Chalk, supporting all ANSI color names, as well as background colors, bold, italic, underline, strikethrough, reverse video, and other rich text styles. One line of code makes your terminal output delightful:

<text [color]="'green'" [bold]="true" [underline]="true">
  ✨ Success! All tests passed.
</text>

♿ Accessibility Support

Built-in screen reader detection and ARIA attribute support ensure your CLI tool is friendly to everyone.

Why Choose ngx-ink?

1. Full Capabilities of Ink, Expressed in Angular

ngx-ink is not reinventing the wheel—it brings Ink's proven capabilities to Angular developers. Whatever features Ink has, ngx-ink has too:

✅ Flexbox terminal layout (Yoga engine)
✅ Complete ANSI colors and text styles
✅ Responsive real-time updates
✅ Keyboard input, focus management, animation-driven
✅ Static rendering, Transform text transformation
✅ Screen reader support and ARIA accessibility

Whatever Ink can do, ngx-ink can do too. The only difference is that you're writing Angular code.

2. React Hooks → Angular Hooks, Zero Mental Shift

Developers familiar with Ink already know React Hooks like useState, useEffect, and useInput. In ngx-ink, these concepts are fully preserved and adapted to Angular style:

Ink (React)	ngx-ink (Angular)
`useState`	`signal()`
`useEffect`	`effect()`
`useInput`	`useInput()`
`useWindowSize`	`useWindowSize()`
`useAnimation`	`useAnimation()`
JSX Component	`@Component` decorator
Props	`input()` / `output()`

API signatures are consistent, behaviors are consistent—you just need to convert the syntax.

3. Based on Ink 7.1.0, Production-Grade Reliability

ngx-ink reuses Ink's core logic layer—ANSI processing, Yoga layout calculation, and rendering pipeline all come from Ink 7.1.0. This means:

Proven at Scale — Ink is adopted by projects like Claude Code, GitHub Copilot CLI, and Cloudflare Wrangler
Mature Edge Case Handling — Terminal resize, special characters, ANSI escape sequences, and other edge cases have been thoroughly addressed
Continuous Evolution — Improvements in the Ink ecosystem naturally reflect in ngx-ink

ngx-ink handles the Angular adaptation layer, with core rendering capabilities originating from Ink.

4. Native Integration with the Angular Ecosystem

As an Angular library, ngx-ink seamlessly integrates into your Angular projects:

Start using the standard bootstrapApplication approach
Supports Angular routing, forms, HTTP client
Full dependency injection and Token mechanisms
TypeScript type safety with compile-time checking

Quick Start

Installation

npm install @cyia/ngx-ink

Using the Starter Template (Recommended)

The fastest way to get started is using the ngx-ink-starter template:

git clone https://github.com/wszgrcy/ngx-ink-starter.git
cd ngx-ink-starter
npm install
npm start

That's it—your terminal app is up and running, with no build configuration required.

Write a Counter by Hand

import { Component, signal, effect } from '@angular/core';
import { BoxComponent, TextComponent } from '@cyia/ngx-ink';

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [BoxComponent, TextComponent],
  template: `
    <box [style]="{ padding: 2 }">
      <text [color]="'cyan'" [bold]="true">Counter: {{ counter() }}</text>
      <text [color]="'green'">Press any key to increment</text>
    </box>
  `
})
export class AppComponent {
  counter = signal(0);

  constructor() {
    useInput(() => {
      this.counter.update(v => v + 1);
    });
  }
}

Who Needs ngx-ink?

Angular Developers — Want to build interactive CLIs in the terminal without learning React
Ink Users — Projects requiring Angular tech stack, hoping to reuse Ink's API capabilities
Cross-Framework Teams — Teams using both React and Angular, wanting CLI tools to maintain a unified component-based development experience
Terminal Tool Enthusiasts — Want to build beautiful command-line interfaces in a familiar way

Project Information

npm Package: @cyia/ngx-ink
GitHub: ngx-ink
Starter Template: ngx-ink-starter
Angular Version: Supports Angular 22+
License: MIT

Conclusion

Ink has proven the feasibility of building CLI interfaces with components. Now, ngx-ink brings this capability to Angular developers.

No need to learn new paradigms, no need to abandon familiar tools. What Ink has, ngx-ink has; what Angular excels at, ngx-ink excels at too.

ngx-ink — The Angular form of Ink.

💡 If you like this project, feel free to Star and Fork, and we welcome Issues and PRs to help improve it together!

A Next-Generation Alternative to ngx-formly: piying-view

wszgrcy — Tue, 28 Oct 2025 14:08:44 +0000

If you're using ngx-formly, or looking for a more flexible, modern, and extensible form solution, then piying-view might be the next-generation choice worth trying.

📌 Background

ngx-formly is an excellent form abstraction library.
However, as project complexity increases, I found limitations in certain areas. Therefore, inspired by the core philosophy of ngx-formly, I've made several improvements and added more features, resulting in the creation of piying-view.

🚀 Improvements

Reset

ngx-formly only supports global reset. To reset individual form controls, you need complex custom implementations.
piying-view allows any form control to be reset simply by calling its reset method, including all its child controls (if any).

Input Properties

ngx-formly only supports setting properties via custom props, and does not support Angular’s built-in input properties.
piying-view supports both props and native Angular input properties (@Input), meaning existing components can be used directly as form controls.

Form Binding

ngx-formly requires inheritance from FieldType, making it incompatible with direct use of custom form controls.
piying-view allows existing custom form controls to be used directly without modification.

Component References

ngx-formly only supports synchronous component loading.
piying-view supports both synchronous and asynchronous component loading.

Query

ngx-formly only supports querying child controls, not direct parent or root-level queries.
piying-view supports querying children, parents (..), root (#), and named controls (@xxx) via path query.

Validators

ngx-formly offers limited built-in validators, but supports custom validators.
piying-view supports all validators from valibot, includes i18n support, and also allows custom validators.

Layout

ngx-formly uses the defined position as layout.
piying-view fixes the position during definition, but allows dynamic layout adjustments using layout actions.

Input Listening

ngx-formly requires dynamic property updates to be implemented in ngOnInit.
piying-view accepts Signal, Observable, or Promise as input parameters, enabling real-time updates.

Group Disabling

ngx-formly disables all controls within a group if any control in the same group is disabled.
piying-view allows disabling only specific logical groups within a single group.

🔥 New Features

🎯 Directive Support

Supports applying Angular directives directly to components.

🧩 Selectorless Mode

Supports selectorless components — created components do not require a selector definition in the template.

🔤 Strong Typing

Definitions can be directly converted into TypeScript types, enhancing development experience and type safety.

🛠️ Custom Actions

Allows encapsulating functionality into reusable Actions.

🌐 Multi-Platform Support

Supports not only Angular, but also provides adapter layers for Vue, React, Svelte, and Solid, ideal for cross-framework projects or future migration.

🔁 Bidirectional Data Transformation

Supports pre-processing (e.g., formatting) of input data and post-processing (e.g., serialization) of output data — meeting complex business requirements. Learn more

📊 Feature Comparison

😀 - Fully supported 🤢 - Partially supported 🥵 - Not supported

Feature	piying-view	ngx-formly
Wrapper	😀	😀
Control Group	😀	😀
Controls	😀	😀
JSON Schema	😀	😀
Validators	😀	😀
Component Layout	😀	😀
Settings Class	😀	😀
Plugins	😀	😀
Form Reset	😀	🤢
Form Query	😀	🤢
Input Properties	😀	🤢
Data Transformation	😀	🤢
Async Components	😀	🥵
Group Disabling	😀	🥵
Decorators	😀	🥵
Selectorless	😀	🥵
Multi-Platform	😀	🥵
Strong Typing	😀	🥵
Pre-built Component Library	🥵	😀

🌟 Final Thoughts

Get Started Quickly
If you're interested in piying-view, feel free to visit the 👉 Official Website for more documentation and examples.
Have feedback or suggestions? We welcome your 📩 contributions.
📦 Source Code

UnOfficial Implementation of Angular's Selectorless Components

wszgrcy — Sat, 18 Oct 2025 03:17:58 +0000

As is well known, when defining components in Angular, a custom tag must be generated. In some cases, this can be inconvenient when using CSS layout.
Although the official team has begun to consider implementing selectorless components, it is still in the planning stage, and it's uncertain how long it will take to be realized.

Principle

As is well known, structural directives can dynamically insert templates.
Template content can be customized and can also use all properties and methods within the component.
Therefore, it's sufficient to turn the component into a template to achieve this.
The method is also simple, just wrap a ng-template around the component's html
Now that we have the template, we only need to consider how to use it.
This is also simple: dynamically create a component, which returns the component instance. Through the instance, we can get the template reference.
Since we have the template reference, we can use viewContainerRef to insert it.
As the inserted content is a template, the component is only created but not actually inserted into the DOM with a selector.
This achieves the selectorless component.

Implementation

The following code is only for demonstrating the principle. For more detailed information, please refer to the repository
Directive

// Create component reference, existing only in memory
this._componentRef = createComponent(this.selectlessOutlet(), {});
// Get the instantiated component, note that the component needs a templateRef to save the template reference
const instance = this._componentRef.instance as {
  templateRef: Signal<TemplateRef<any>>;
};
// Insert the template in a structural directive (similar to ngIf ngFor)
this.#viewContainerRef.createEmbeddedView(instance.templateRef());
// Bind lifecycle
this.#appRef.attachView(this._componentRef.hostView);
this._componentRef.changeDetectorRef.detectChanges();

Selectorless component part

<ng-template #templateRef> 123 </ng-template>

@Component({})
export class InsertComponent implements OnInit {
  public templateRef = viewChild.required('templateRef');
}

Usage part

<ng-container *selectlessOutlet="InsertComponent;inputs:{}"> </ng-container>

Limitations

Of course, this method has some limitations.
The implementation of ng-content will be very complex; it needs to use ng-template references to replace input variables.
Some directives may be restricted, because components implemented in this way are essentially a shell and cannot access the real element. > Because at this point, the ElementRef gets an element that is not in the DOM.

Faster Usage?

Piying View has already supported custom selectorless component definitions and can switch them conveniently. > Piying can be considered as the Pro plus version of ngx-formly, with similar concepts to ngx-formly, but with clearer logic, safer, supports strong typing, multi-framework, and more features.

Final Words

If you have other questions, feel free to contact via email wszgrcy@gmail.com.
Selectorless code repository
Piying View code repository
Demo video

I've open-sourced a form library — define metadata once, and it can be rendered anywhere.

wszgrcy — Fri, 08 Aug 2025 04:14:04 +0000

After reviewing all major form libraries on the market, I identified a critical flaw: they require repeated definitions to build a form.
For example, consider the following (pseudo-code):

interface Test {
  firstName: string;
}

const form = useForm<Test>({
  defaultValues: {
    firstName: "default",
  },
  onSubmit: async ({ value }) => {
    console.log(value);
  },
});

<form.Field
  name="firstName"
  //...
/>

As we all know, the more times you define something, the higher the chance of introducing bugs.
In the above scenario, if we want to rename firstName to name, we’d need to update it in at least three places — significantly increasing code fragility.
That’s why I created Piying — a form library that achieves all the above functionality with just one definition.

v.object({ firstName: v.optional(v.string(), "default") });

How Does Piying Achieve This?

First, thanks to valibot, the code above is simply a schema definition.
Piying implements a traversal engine that collects metadata from the schema.
This metadata is then transformed into components and form configurations, enabling full compatibility across any frontend framework.

But What About Layout Flexibility?

While the schema definition is fixed, Piying supports dynamic layout manipulation via the layout method.
You can move any field into a container schema that supports nesting — meaning you can freely rearrange the UI layout without changing the schema.

v.intersect([
  v.pipe(v.object({}), setAlias("scope1")),
  v.object({
    key1: v.pipe(
      v.object({
        test1: v.pipe(v.optional(v.string(), "value1"), layout({ keyPath: ["#", "@scope1"] })),
      }),
    ),
  }),
]);

This effectively decouples definition from visual positioning.
Regarding field order in object, refer to the MDN documentation for details on JavaScript’s object property iteration order.

How to Achieve Advanced Layouts?

Sometimes, you need more than just field rendering — think labels, validation hints, tooltips, etc.
These can be achieved using wrappers:

v.pipe(v.number(), v.title("k2-label"), setWrappers(["label"]));

If you want to customize the styling of a group of fields, you can define a custom component directly: > While wrappers can be used for field groups, direct component customization is often more convenient.

v.pipe(
  v.object({
    k1: v.pipe(v.string(), v.title("k1-label"), setWrappers(["label"])),
    k2: v.pipe(v.number(), v.title("k2-label"), v.minValue(10), setWrappers(["label", "validator"])),
  }),
  setComponent("fieldset"),
);

How to Customize Wrappers or Components?

The code examples above don’t specify a particular frontend framework — because they’re framework-agnostic.
However, wrapper and component definitions are framework-specific.
You can find setup instructions for your preferred framework in the Quick Start Guide. Currently supported: React, Vue, and Angular. If you need support for another framework, feel free to open an issue.

Is It Ready for Production?

Piying Form has been used internally for over half a year before public open-source release.
Most features have undergone rigorous testing. Code coverage exceeds 95%, making it production-ready.
We provide extensive use case demos and equivalent implementations of popular libraries to ease migration:

Project Repository

piying-view

Contact Me

If you have any feedback, suggestions, or questions, feel free to reach out: wszgrcy@gmail.com

General Form Solution --- Piying

wszgrcy — Tue, 29 Jul 2025 14:29:02 +0000

Piying provides a unified form development experience across different frameworks
It allows developers to focus more on logic and layout, freeing them from trivial tasks
Piying's configuration is more semantic, reducing cognitive load for developers, and allows for custom encapsulation
Piying is fully compatible with all valibot Actions, allowing for perfect utilization of its validation and transformation mechanisms

Documentation

A sensory understanding may help you experience the charm of Piying faster. The website has implemented a large number of examples, making it easy for you to quickly understand Piying.
https://piying-org.github.io/website/

Current Support

Angular
Vue
React

Why Use Piying?

If you meet the following conditions, Piying is suitable for you

Reduce the cost of writing and maintaining code
Type-safe implementation of forms
Separation of view and logic
Reduce dependency on underlying frameworks to make the code more generic
More convenient validation mechanism

If you meet the following conditions, you can try Piying

There are some similar logic between pages, or some code looks similar
You hope that future code can be migrated across different frameworks

What Problems Does Piying Solve?

Piying has fully covered most of the common form functions, so the following problems are solved by Piying compared to mainstream libraries.

Type Safety

Most forms on the market do not have types, and after designing the form, you often need to write a type again to constrain the input and output
By defining with valibot, you can naturally obtain the type and get the most basic type validation, ensuring that the data type is always correct in any situation

Unified Frontend and Backend Types and Validation

When both the frontend and backend are developed using JavaScript, a common problem is that the backend's type is already defined, but the backend's interface often only has interface/type, and even worse, there may be no type at all, only telling you which fields are present
valibot can provide both types and validation
With the help of Piying's parsing, the relevant validation can be perfectly reflected on the form, making the checks on the frontend and backend the same, reducing maintenance costs and improving data security

General Definition Structure

Components in different frameworks are implemented differently, so they need to be implemented separately
However, after registration, the logic part is completely independent of any content in the view, making future migration and maintenance easier

Layout Mobility

Most forms do not have type safety, and even with metadata definitions, they cannot be moved arbitrarily and can only be displayed according to the defined order
Piying successfully solves this problem, making the definition and view not coupled, allowing for arbitrary display and adjustment > This way, you can customize the form according to your design requirements rather than being limited in display

Logical OR/AND

Most forms only implement three controls: Group, Array, and Control, but lack logical OR/AND, making some logic implementations more complex
For example, anyOf and oneOf in JsonSchema can be easily handled with the corresponding FieldLogicGroup using v.intersect and v.union for dynamic switching

Model-View/View-Model Separation of Form Controls

Most form controls have equivalent input and output, meaning that the control inputs a => emits output a, and inputs a => writes a into the control
Piying allows processing in these two stages separately, enabling more complex business logic

Test Coverage

✔ Browser application bundle generation complete.
29 07 2025 22:17:37.889:INFO [karma-server]: Karma v6.4.4 server started at http://localhost:9876/
29 07 2025 22:17:37.891:INFO [launcher]: Launching browsers Chrome with concurrency unlimited
29 07 2025 22:17:37.910:INFO [launcher]: Starting browser Chrome
29 07 2025 22:17:38.530:INFO [Chrome 138.0.0.0 (Windows 10)]: Connected on socket VqecE5a27WYED9lwAAAB with id 10611162
Chrome 138.0.0.0 (Windows 10): Executed 452 of 454 (skipped 2) SUCCESS (0.944 secs / 0.854 secs)
TOTAL: 452 SUCCESS

=============================== Coverage summary ===============================
Statements   : 90.44% ( 1315/1454 )
Branches     : 82.19% ( 457/556 )
Functions    : 86.16% ( 411/477 )
Lines        : 90.69% ( 1258/1387 )
================================================================================

About Open Source

Currently, due to the large number of repositories, some code needs to be organized, so it will take about a week; please follow the website
If you have any opinions or suggestions, please feel free to contact me at wszgrcy@gmail.com

Now you can use dynamic directive in Angular

wszgrcy — Fri, 28 Feb 2025 14:22:46 +0000

wszgrcy/dynamic-component-define

npm i @cyia/dynamic-component-define

import { createDynamicComponentDefine } from "@cyia/dynamic-component-define";

export class AppComponent {
  envInjector = inject(EnvironmentInjector);
  continerRef = viewChild<ViewContainerRef, ViewContainerRef>("continerRef", {
    read: ViewContainerRef,
  });
  classInput = signal({ inputValue2: "hello" });
  ngOnInit(): void {
    let define = createDynamicComponentDefine({ type: C1Component }, [
      {
        type: ClassDirective,
        inputs: this.classInput,
      },
      {
        type: ClickDirective,
        outputs: {
          clientEvent: (event: any) => {
            console.log("click", event);
          },
        },
      },
    ]);
    let ref = createComponent(define, {
      environmentInjector: this.envInjector,
    });
    this.continerRef()!.createEmbeddedView(ref.instance.templateRef());
  }
  changeClass() {
    this.classInput.update((item) => {
      return { ...item, inputValue2: "changedClass" };
    });
  }
}

Using dependency injection in nodejs environment

wszgrcy — Tue, 30 Apr 2024 02:12:29 +0000

Introduction

Angular dependency injection standalone version
The usage method is completely consistent with Angular's dependency injection
No transformer required
0 dependencies
Remove Decorator > @Injectable()=>static injectOptions={} > @Inject() xx=>xx=inject() > @Optional()=>xx=inject(token,{optional:true})
JS/TS Support

Source

Angular 17.3.6

Usage

npm i static-injector
Create a first level dependency injector with Injector.create

import { Injector, inject } from 'static-injector';

class Main {
  child = inject(Child);
}
class Child {
  output() {
    return 'hello world';
  }
}
let injector = Injector.create({ providers: [Main, Child] });
const instance = injector.get(Main);
console.log(instance.child.output());

Different from `injection-js`

injection-js belongs to dynamic dependency injection and is a version used before Angular5. Currently no longer updated
The two are basically interchangeable (the details need to be adjusted)
Support the use of inject during construction

No Decorator

The original use of @Injectable() to pass parameters has been changed to static injectOptions={}. If there are no parameters, there is no need to set them
Originally, @Optional, @SkipSelf, @Self, please use the second pass parameter of inject instead

Test

Partially conducted unit testing to ensure that most functions are functioning properly
Because most of the code itself is extracted from Angular, stability is definitely guaranteed

Sync

Currently, the synchronization logic has been refactored and modified using @code-recycle/cli to ensure consistency with the official version of angular

Examples

https://github.com/wszgrcy/static-injector/tree/main/test/import

Contact me

If you have any technical issues, please contact me for assistance wszgrcy@gmail.com

Angular Event Modifier

wszgrcy — Sun, 21 Apr 2024 09:38:01 +0000

Source Code

version 17.3.5
commit cc57d4c4998b4e38f940afdf358af37185028072

EventManagerPlugin

For the official, it does provide an event management solution that allows for different monitoring based on any event name
However, it is only based on the event name to listen to DOM elements and handle their listening

The official does not provide a solution for processing component outputs

According to source code We know that the outputs of all components are actually subscribed directly, which means there is no chance to intercept them

Is the component output actually being monitored twice?

As mentioned above, all components are subscribed directly. However, when a component is subscribed directly, it also performs event listening, which means that EventManagerPlugin can also listen. After all, custom components are also DOM elements
But here's the problem. Even if you can handle this listening by creating an event manager, it only handles event listening, and subscriptions have nothing to do with it. In normal development, you will never call the DOM element of a component to do a dispatchEvent
Another issue is that the event manager relies on source code,addEventListener interface obtains an element and event name. How to find the corresponding component through the element?

Magic modification moment, showcasing skills begins

We found that there is an attribute called __ngContext__ on the element, and the number on this attribute is actually the LView ID
We use publicly available and non-public methods ɵgetLContext Get its LContext. Then read it to LView
On LView, there are many key attributes, and component instances are one of them Index position
Once we find the corresponding element of the component, we can hook up the original event emission and let it only go through our own listening channel. This part is relatively simple, just look at the source code

Handling event modifiers

There are two types of event modifiers, one is guard that returns true to prohibit, and the other is map, which is used for converting data
The code comes with some 'guard' type modifiers. From Vue source code
Regarding keyboard type event modifiers, fully call the official ng ɵKeyEventsPlugin

Use

source code
npm i @cyia/ngx-common

// app module
import { EVENT_MODIFIER_OPTIONS, EventModifiersPlugin } from '@cyia/ngx-common/event';

  providers: [
    {
      provide: EVENT_MANAGER_PLUGINS,
      useClass: EventModifiersPlugin,
      multi: true,
      deps: [DOCUMENT],
    },
    {
      provide: EVENT_MODIFIER_OPTIONS,
      useValue: {
        modifiers: {
          map: {
            // custom event modifier
            prefix: (value) => {
              return `prefix:${value}`;
            },
          },
        },
        componentOutput: true,
      },
    },
  ],

<div (click)="clicked('divClicked')">
  <button (click.stop.once)="clicked('btnClicked')">点击</button>
</div>
<app-a (output2.prefix.once)="output($event)" (output2)="output($event)"></app-a>

Contact me

If you have any technical issues, please contact me for assistance wszgrcy@gmail.com

DEV Community: wszgrcy

Piying-View: write forms with a schema, field types inferred end to end

What is Piying-View

Capabilities at a glance

Two ways to use it

End to end strong typing and code completion

Without type hints

With type hints

typedFieldPipe — attach metadata to a schema by path

typedFieldComponentPipe — component props are narrowed too

convertToField — manual conversion is equally precise

Manual binding — the path is remembered by the type

Who is responsible for what

Capacitor GeckoView: Say Goodbye to WebView Kernel Fragmentation

Why This Project Exists

The Solution: Introducing GeckoView

Advantages

Disadvantages

Plugin Compatibility

Resources

Feedback & Discussion

Angular Selectorless Support

Preface

Usage

Limitations

Source Code

Writing TUI in the Terminal with Angular: Introducing @cyia/opentui-angular

Foreword

The Positioning of the Angular Adapter

1. Custom Platform Layer

2. Component Mapping

3. Angular-ifying Hooks

4. Slot System Adaptation

5. Keymap Submodule

6. Component Extension Capability

Included Examples

Tech Stack

Usage

Quick Start

Manual Integration

Who Is It For?

Summary

ngx-ink: The Angular Version of Ink, A Component-Based Revolution for Terminal UI

Background: Ink Has Proven This Path Works

What is ngx-ink?

Core Features

🎨 Declarative Componentized UI

📐 Flexbox Terminal Layout

🎬 Responsive Real-time Updates

⌨️ Complete Interaction Capabilities

🎭 Rich Built-in Components

🎨 Complete ANSI Color Support

♿ Accessibility Support

Why Choose ngx-ink?

1. Full Capabilities of Ink, Expressed in Angular

2. React Hooks → Angular Hooks, Zero Mental Shift

3. Based on Ink 7.1.0, Production-Grade Reliability

4. Native Integration with the Angular Ecosystem

Quick Start

Installation

Using the Starter Template (Recommended)

Write a Counter by Hand

Who Needs ngx-ink?

Project Information

Conclusion

A Next-Generation Alternative to ngx-formly: piying-view

📌 Background

🚀 Improvements

Reset

Input Properties

Form Binding

Component References

Query

Validators

Layout

Input Listening

Group Disabling

🔥 New Features

🎯 Directive Support

🧩 Selectorless Mode

`typedFieldPipe` — attach metadata to a schema by path

`typedFieldComponentPipe` — component props are narrowed too

`convertToField` — manual conversion is equally precise

Different from `injection-js`