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

Proposal: Possible code refactoring #36

Closed
cmdcolin opened this issue Nov 16, 2023 · 0 comments
Closed

Proposal: Possible code refactoring #36

cmdcolin opened this issue Nov 16, 2023 · 0 comments

Comments

@cmdcolin
Copy link
Contributor

I think that there may be an opportunity to conceptually simplify the code by
a) changing map types to plain old objects
b) not extending the map type
c) just parsing the object in the constructor rather than overriding Map.add to this end
d) (optional) removing the re-stringifying code, it adds extra overhead and complexity to the parsing

My ideas above come from trying to investigate a little bit on the project with the single file hub branch, I found it difficult to use the Map. I think at the very least, the SingleFileHub will be overhauled a little bit (it makes a TrackDbFile[], which is a bit odd, it should be just one TrackDbFile? or just an array of Track objects instead of using the notion of a TrackDbFile?). Additionally it seems we have pick the objects out one by one with .get, which is a little cumbersome compared to using an object.

We are not yet at a v1.0.0 semver release, so there is an opportunity there

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant