Most of report-toolkit is written in a functionalesque style, using RxJS. but there are a few classes hanging around. generally, there's no mutation of these objects after construction--everything excepting Transformer objects could be Object.freeze'd after instantiation.
classes are used because they are convenient, more or less; it's easier to generate docs, get type info, refer to them, etc. but they aren't strictly necessary, and as such, maybe it's better to avoid them altogether. or maybe it's fine...I'm not sure.
in the case of Transformer, mutation is used to chain them together (it's a linked list). but e.g., Transformer#pipeTo could instead return a new copy of the Transform instead of mutating the current object.
this is low-priority, but if we can totally avoid mutating objects as much as possible, the project will be better for it.
Most of report-toolkit is written in a functionalesque style, using RxJS. but there are a few classes hanging around. generally, there's no mutation of these objects after construction--everything excepting
Transformerobjects could beObject.freeze'd after instantiation.classes are used because they are convenient, more or less; it's easier to generate docs, get type info, refer to them, etc. but they aren't strictly necessary, and as such, maybe it's better to avoid them altogether. or maybe it's fine...I'm not sure.
in the case of
Transformer, mutation is used to chain them together (it's a linked list). but e.g.,Transformer#pipeTocould instead return a new copy of theTransforminstead of mutating the current object.this is low-priority, but if we can totally avoid mutating objects as much as possible, the project will be better for it.