Repository navigation
refactor: Move Context object to new class - #929
Conversation
6565d01 to
5dedec3
Compare
| return data; | ||
| } | ||
|
|
||
| buildContext (blockHeight: number, logEntries: LogEntry[]): ContextObject { |
There was a problem hiding this comment.
I thought about integrating the functions into this class itself, or having a persistent object to update, but I wasn't sure how that would work when frozen into the VM or with any references to class variables. I decided to continue building an object when requested.
| } | ||
| } | ||
|
|
||
| // TODO: Migrate all below code to separate class |
There was a problem hiding this comment.
All of the below code will be moved to its own class and have its own unit tests. I've simply placed them here for now to reduce PR size.
| @@ -0,0 +1,292 @@ | |||
| import fetch from 'node-fetch'; | |||
There was a problem hiding this comment.
It would be good to start nesting relating components in the filesystem to provide some additional context in to the relationships in our codebase, e.g. butting context-builder under indexer as it's directly related to that? src/ is starting to grow so would be good to start encapsulating/grouping related logic.
There was a problem hiding this comment.
Ah good point. I'll do that now then for this class and move some more in the follow up DmlHandler one.
2 participants
All logic associated with the creation of the context object resides inside the Indexer class, which bloats the file and complicates unit testing. In addition, it prevents access to the context object itself so that these calls can be made through the Indexer class itself.
This PR refactors this logic into its own class, allowing access to context methods through Indexer. The object is still recreated each time it is accessed as the object bakes in some state information (block height and log entry array) which need to be updated on subsequent accesses.
I've also reorganized the folders so that we have fewer folders under src as it is getting cluttered.