|
1 | 1 | # Concept |
2 | 2 |
|
| 3 | +## Direction Since v0.14.0 |
| 4 | + |
| 5 | +Starting with v0.14.0, promkit is developed around two primary goals: |
| 6 | + |
| 7 | +1. Expand `promkit-widgets` with reusable state and view projections that |
| 8 | + applications can combine without adopting a framework-owned event policy. |
| 9 | +2. Improve `promkit-core` rendering performance and correctness so wrapping, |
| 10 | + resizing, scrolling, viewport movement, and repeated redraws remain stable |
| 11 | + without leaving stale or visually corrupted terminal content. |
| 12 | + |
| 13 | +This direction emerged from a feedback loop between the library and applications |
| 14 | +built with it, including [jnv](https://github.com/ynqa/jnv) and |
| 15 | +[sig](https://github.com/ynqa/sig). Those applications showed that a useful |
| 16 | +terminal UI eventually needs an application-specific runtime and event loop. |
| 17 | +Modes, key bindings, focus, background work, cancellation, validation, and |
| 18 | +domain state transitions cannot be generalized into prompt presets without |
| 19 | +constraining the application or adding increasingly application-specific |
| 20 | +configuration. |
| 21 | + |
| 22 | +The resulting development loop is: |
| 23 | + |
| 24 | +1. Application development exposes rendering, state, and interaction needs. |
| 25 | +2. Reusable state-to-view behavior is extracted into `promkit-widgets`. |
| 26 | +3. Rendering correctness and performance improvements are made in |
| 27 | + `promkit-core` and verified against regression scenarios and benchmarks. |
| 28 | +4. Application-specific orchestration remains in the application, while |
| 29 | + examples document useful compositions. |
| 30 | + |
| 31 | +For this reason, the `promkit` crate no longer owns preset implementations. |
| 32 | +It provides an optional `Prompt` lifecycle runtime, capabilities, and a widget |
| 33 | +facade for applications that find them useful, but it is not intended to replace |
| 34 | +an application's event loop. Removing presets is therefore not only a code |
| 35 | +reorganization; it establishes application-owned orchestration as the project |
| 36 | +direction from v0.14.0 onward. |
| 37 | + |
3 | 38 | ## Responsibility Boundaries and Data Flow |
4 | 39 |
|
5 | 40 | promkit is organized around four responsibilities with clear boundaries: |
|
0 commit comments