Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reconsider classes, mutation #58

Open
boneskull opened this issue Oct 15, 2019 · 0 comments
Open

reconsider classes, mutation #58

boneskull opened this issue Oct 15, 2019 · 0 comments
Labels
chore Related to tests, packaging, build, releases, etc. discuss For discussion, bikeshedding, planning

Comments

@boneskull
Copy link
Contributor

boneskull commented Oct 15, 2019

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.

@boneskull boneskull added chore Related to tests, packaging, build, releases, etc. discuss For discussion, bikeshedding, planning labels Oct 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore Related to tests, packaging, build, releases, etc. discuss For discussion, bikeshedding, planning
Projects
None yet
Development

No branches or pull requests

1 participant