|
| 1 | +# TinyTools Feature Ideas |
| 2 | + |
| 3 | +This document collects small, focused feature ideas that fit TinyTools' core philosophy: |
| 4 | + |
| 5 | +> Keep templates tiny, deterministic, dependency-light, and useful for data composition. |
| 6 | +
|
| 7 | +These ideas are not commitments. They are candidates to evaluate against the roadmap, implementation cost, and the project's goal of staying intentionally small. |
| 8 | + |
| 9 | +--- |
| 10 | + |
| 11 | +## Recommended First Feature |
| 12 | + |
| 13 | +### Template Diagnostics and Strict Mode |
| 14 | + |
| 15 | +The strongest next feature candidate is a diagnostics layer with optional strict rendering. |
| 16 | + |
| 17 | +Today, TinyTools is already useful for rendering deterministic text. The next quality-of-life improvement would be helping users find template mistakes before output is generated or shipped. |
| 18 | + |
| 19 | +Possible API: |
| 20 | + |
| 21 | +```csharp |
| 22 | +var diagnostics = engine.Analyze(template); |
| 23 | + |
| 24 | +foreach (var diagnostic in diagnostics) |
| 25 | +{ |
| 26 | + Console.WriteLine($"{diagnostic.Line}:{diagnostic.Column} {diagnostic.Message}"); |
| 27 | +} |
| 28 | +``` |
| 29 | + |
| 30 | +Strict rendering could build on the same analysis model: |
| 31 | + |
| 32 | +```csharp |
| 33 | +var engine = new TinyTemplateEngine(new TinyTemplateOptions |
| 34 | +{ |
| 35 | + StrictVariables = true, |
| 36 | + StrictHelpers = true |
| 37 | +}); |
| 38 | +``` |
| 39 | + |
| 40 | +Suggested diagnostics: |
| 41 | + |
| 42 | +- Missing or unresolved variables |
| 43 | +- Unknown pipe helpers |
| 44 | +- Unmatched `@if`, `@foreach`, `@else`, or closing braces |
| 45 | +- Invalid null-coalescing or ternary expressions |
| 46 | +- Line and column information for template errors |
| 47 | +- Suggestions for common mistakes, such as misspelled helper names |
| 48 | + |
| 49 | +Why it fits: |
| 50 | + |
| 51 | +- Improves trust without making templates more powerful or complex |
| 52 | +- Supports existing validation work |
| 53 | +- Helps CLI, editor tooling, and future source-generator scenarios |
| 54 | +- Keeps error handling deterministic and easy to test |
| 55 | + |
| 56 | +--- |
| 57 | + |
| 58 | +## Other Strong Candidates |
| 59 | + |
| 60 | +### Render From JSON |
| 61 | + |
| 62 | +TinyTools is often used for data composition, and JSON is a natural input format for templates. A first-class JSON render path would make examples, tests, CLIs, and automation easier. |
| 63 | + |
| 64 | +Possible API: |
| 65 | + |
| 66 | +```csharp |
| 67 | +var output = engine.RenderJson(template, json); |
| 68 | +``` |
| 69 | + |
| 70 | +Possible overloads: |
| 71 | + |
| 72 | +```csharp |
| 73 | +var output = engine.RenderJson(template, jsonString); |
| 74 | +var output = engine.RenderJson(template, jsonDocument); |
| 75 | +var output = engine.RenderJsonFile(template, "data.json"); |
| 76 | +``` |
| 77 | + |
| 78 | +Why it fits: |
| 79 | + |
| 80 | +- Aligns with generating JSON, YAML, Markdown, config files, prompts, and emails |
| 81 | +- Makes CLI rendering easier to implement later |
| 82 | +- Gives users a simple bridge from external data into `ToolContext` |
| 83 | + |
| 84 | +### Escaping Helpers |
| 85 | + |
| 86 | +TinyTools is format-agnostic, so it should help users safely project values into common text formats without becoming an HTML view engine. |
| 87 | + |
| 88 | +Possible helpers: |
| 89 | + |
| 90 | +```text |
| 91 | +${Context.Name | json} |
| 92 | +${Context.Description | yaml} |
| 93 | +${Context.Value | csv} |
| 94 | +${Context.Text | markdown} |
| 95 | +``` |
| 96 | + |
| 97 | +Why it fits: |
| 98 | + |
| 99 | +- Supports non-HTML output formats |
| 100 | +- Keeps escaping explicit in the template |
| 101 | +- Reduces accidental invalid JSON, CSV, YAML, or Markdown output |
| 102 | + |
| 103 | +### Template Includes |
| 104 | + |
| 105 | +Includes would allow reusable fragments while keeping templates simple. |
| 106 | + |
| 107 | +Possible syntax: |
| 108 | + |
| 109 | +```text |
| 110 | +@include("partials/header.tmpl") |
| 111 | +
|
| 112 | +Content here |
| 113 | +
|
| 114 | +@include("partials/footer.tmpl") |
| 115 | +``` |
| 116 | + |
| 117 | +Recommended design: |
| 118 | + |
| 119 | +```csharp |
| 120 | +public interface ITemplateLoader |
| 121 | +{ |
| 122 | + string Load(string path); |
| 123 | +} |
| 124 | +``` |
| 125 | + |
| 126 | +Why it fits: |
| 127 | + |
| 128 | +- Enables reusable headers, footers, prompts, and generated-file fragments |
| 129 | +- Keeps file-system behavior outside the engine |
| 130 | +- Allows in-memory, embedded-resource, and file-based loaders |
| 131 | + |
| 132 | +### Tiny CLI |
| 133 | + |
| 134 | +A small command-line tool would make TinyTools useful outside application code. |
| 135 | + |
| 136 | +Possible commands: |
| 137 | + |
| 138 | +```bash |
| 139 | +tinytools render --template email.tmpl --data data.json --out email.txt |
| 140 | +tinytools validate --template email.tmpl --data data.json |
| 141 | +tinytools watch --template "*.tmpl" --data data.json --out output |
| 142 | +``` |
| 143 | + |
| 144 | +Why it fits: |
| 145 | + |
| 146 | +- Makes the library easier to try |
| 147 | +- Supports automation and code-generation workflows |
| 148 | +- Provides a practical surface for diagnostics and JSON rendering |
| 149 | + |
| 150 | +--- |
| 151 | + |
| 152 | +## Lower Priority Ideas |
| 153 | + |
| 154 | +### File-Based Template Registry |
| 155 | + |
| 156 | +Allow a registry to discover `.tmpl` files from a folder and render them by name. |
| 157 | + |
| 158 | +This is useful, but it should probably come after includes and diagnostics so file templates have a clearer error model. |
| 159 | + |
| 160 | +### Editor Tooling |
| 161 | + |
| 162 | +Syntax highlighting, diagnostics, and preview tooling would be valuable. This should likely build on the diagnostics API rather than being implemented first. |
| 163 | + |
| 164 | +### Source Generator Templates |
| 165 | + |
| 166 | +Build-time template generation could be powerful, but it has a larger maintenance surface. It should probably wait until the parser, diagnostics, and strict behavior are stable. |
| 167 | + |
| 168 | +--- |
| 169 | + |
| 170 | +## Guardrails |
| 171 | + |
| 172 | +These feature ideas should preserve the current TinyTools boundaries: |
| 173 | + |
| 174 | +- No HTML-first view rendering |
| 175 | +- No runtime code execution |
| 176 | +- No JavaScript engine |
| 177 | +- No heavy dependencies |
| 178 | +- No broad template DSL expansion |
| 179 | +- No hidden global file-system behavior |
| 180 | + |
| 181 | +TinyTools should stay boring in the best way: predictable, inspectable, and easy to reason about. |
0 commit comments