This is not a necessary addition, it's a nice-to-have addition.
I was thinking how we return { id, parent, purpose, ... } objects in a bunch of places, and it's getting kind of out of hand. Several different files are creating/updating these objects, and they have to follow the same shape, but we're not enforcing the same shape.
Moreover, I'm also thinking that there will be many of these objects, because each branch in branchStream has many of these. It will be better to profile memory usage if we use classes, because they show up immediately in the Chrome DevTools. Also, it helps the V8 optimizer if all of the objects share exactly the same shape (same set of Object.keys() always) because then under the hood it creates a hidden struct (in C) to back all these objects.
You could say that's premature optimization, but the primary motivation here is just organization and code readability. It's a bonus that it just happens to be better for performance and memory profiling.
Solution
Introduce a new class FeedDetails that can be constructed using various helpers: fromMyMsg, fromCreateOpts, etc. Replace all the hand-written feed details objects with this class instance.
There's a tiny breaking change with tombstoned feed details: reason => tombstoneReason. I can revert that if y'all have a different opinion.
Tests pass locally, but they don't run in CI yet because this PR isn't targeting master. This PR should be merged only after #104 is merged.
Context
This is not a necessary addition, it's a nice-to-have addition.
I was thinking how we return
{ id, parent, purpose, ... }objects in a bunch of places, and it's getting kind of out of hand. Several different files are creating/updating these objects, and they have to follow the same shape, but we're not enforcing the same shape.Moreover, I'm also thinking that there will be many of these objects, because each branch in
branchStreamhas many of these. It will be better to profile memory usage if we use classes, because they show up immediately in the Chrome DevTools. Also, it helps the V8 optimizer if all of the objects share exactly the same shape (same set ofObject.keys()always) because then under the hood it creates a hiddenstruct(in C) to back all these objects.You could say that's premature optimization, but the primary motivation here is just organization and code readability. It's a bonus that it just happens to be better for performance and memory profiling.
Solution
Introduce a new class
FeedDetailsthat can be constructed using various helpers:fromMyMsg,fromCreateOpts, etc. Replace all the hand-written feed details objects with this class instance.There's a tiny breaking change with tombstoned feed details:
reason=>tombstoneReason. I can revert that if y'all have a different opinion.Tests pass locally, but they don't run in CI yet because this PR isn't targeting
master. This PR should be merged only after #104 is merged.