Skip to content
This repository has been archived by the owner on May 28, 2021. It is now read-only.

[contracts, client, node, apps] Move initial state validation to init() fn in appDefinition #1116

Open
ArjunBhuptani opened this issue May 10, 2020 · 2 comments
Labels
Chore Devops or refactoring task p4: Eventual Enhancements Enhancements that will eventually be needed by users but not immediately

Comments

@ArjunBhuptani
Copy link
Member

Right now, we have to create new initial state validation libraries for every new application that we write. This makes it harder to add new apps and makes the node code less easy to understand. We also have a weird pattern where a proposal can be countersigned by a responder, even if they disagree with the proposed values.

We can move these validators into an init() function within the appDefinition which is call from within the propose protocol. This way, any app that makes it through the propose protocol, must necessarily have already been validated.

@ArjunBhuptani ArjunBhuptani added p2: User Shipping Needs Important (but minimal) refactors/enhancements/fixes needed for customers Chore Devops or refactoring task labels May 10, 2020
@ArjunBhuptani ArjunBhuptani added this to To do in Sprint Task Workboard via automation May 10, 2020
@LayneHaber
Copy link
Contributor

Related issue for moving validation from listeners into validation: #1158

@ArjunBhuptani ArjunBhuptani added p3: Features/refactors Larger enhancements driven by user needs + Refactors to improve bad patterns. and removed p2: User Shipping Needs Important (but minimal) refactors/enhancements/fixes needed for customers labels May 30, 2020
@ArjunBhuptani ArjunBhuptani moved this from To do to Icebox in Sprint Task Workboard May 30, 2020
@ArjunBhuptani ArjunBhuptani removed this from Icebox in Sprint Task Workboard May 30, 2020
@ArjunBhuptani ArjunBhuptani added p4: Eventual Enhancements Enhancements that will eventually be needed by users but not immediately and removed p3: Features/refactors Larger enhancements driven by user needs + Refactors to improve bad patterns. labels Jun 15, 2020
@ArjunBhuptani
Copy link
Member Author

Deprioritizing this until we have a need to support many more apps

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Chore Devops or refactoring task p4: Eventual Enhancements Enhancements that will eventually be needed by users but not immediately
Projects
None yet
Development

No branches or pull requests

2 participants