feat: add renderer package #2
Conversation
This adds a renderer package which can be used to parse the "frames" which would've been seen by the user. For example, if we were to render this (pseudo-ansi): ``` foo bar<CURSOR.UP(1)><ERASE.LINE> ``` We would have two frames: ```ts [ "foo\nbar", " \nbar" ] ```
webpro
left a comment
webpro
left a comment
There was a problem hiding this comment.
Looking great already! And so cool that this parser's already showing some usefulness.
Just FYI, there are few more control codes related to cursor pos/scroll and insert/erase stuff, but haven't even done the research on relevance and usefulness to add in this renderer. Some might even not be used anymore at all and best forgotten.
If the current set of supported commands is sufficient for its purpose then that's totally fine to get the ball rolling. Looking at the implementation with the string[] buffer it should be easy to extend/adapt.
In my view, the name "renderer" is a bit too generic. How about "frame-renderer"? Or something else just a tad more specific.
| const renderStreamBrand = Symbol.for('ansi-tools:render-stream'); | ||
|
|
||
| export class RenderStream extends Writable { | ||
| [renderStreamBrand] = true; |
There was a problem hiding this comment.
Just wondering: why have this prop?
There was a problem hiding this comment.
Originally it was because vitest runs tests in another realm to the one that runs snapshot serialisation. So you can't use instanceof
But I'm actually leaning more towards the serialiser not using this directly anyway. And instead, it's up to the test author to use this in their test files
I'll remove this 👍
2 participants
This adds a renderer package which can be used to parse the "frames" which would've been seen by the user.
For example, if we were to render this (pseudo-ansi):
We would have two frames:
DRAFT
until i write all the tests and settle on a public interface, and try it out in the vitest serializer which will use it