-
Notifications
You must be signed in to change notification settings - Fork 455
Consistent dependencies on transaction types - Closes #2779 #2844
Consistent dependencies on transaction types - Closes #2779 #2844
Conversation
@nazarhussain ready for review whenever you can |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clean out unit test from done()
when possible and use async instead of return
.
f6f7e7e
to
47695b0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@limiaspasdaniel Just one last request, if we use __scope
compared to __private
that will link up the concept of scope on higher level. The __
in start already specifying convention that its private.
353b351
to
5c24266
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would continue a bit further extending the issue to cover the root of all transaction types. https://github.com/LiskHQ/lisk/blob/5c242660e88aaef3e536770d883de22c71f4d2d3/framework/src/modules/chain/logic/transaction.js#L50
What do you think @limiaspasdaniel ? Open a new issue if you consider it appropriate.
I totally agree @diego-G , it will definitely look cleaner and it makes sense. I will open another issue so this PR doesn't get too big. |
ed01c2e
to
db8e37f
Compare
New issue will be created to remove it
bbf6a4d
to
2bb21f4
Compare
What was the problem?
Transactions logic didn't have a consistent common interface. Some of the logic presented completely different constructor definitions even passing the same dependencies.
How did I fix it?
Unifying (to some extent) how Transactions logic is instantiated and simplified their constructor definition.
How to test it?
Run unit tests
Review checklist