-
-
Notifications
You must be signed in to change notification settings - Fork 187
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
Add guidelines for writing controllers, and add example controller #4504
Labels
Comments
mikesposito
added a commit
that referenced
this issue
Sep 2, 2024
## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> So far we have not have any documentation on how to write controllers the BaseController v2 way. These guidelines aim to fill in the missing pieces. Note that while each guideline has examples, we are still missing a complete example controller file which demonstrates all of the guidelines in one go. That will come in a future PR. ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? For example: * Fixes #12345 * Related to #67890 --> Progresses #4504. ## Changelog <!-- If you're making any consumer-facing changes, list those changes here as if you were updating a changelog, using the template below as a guide. (CATEGORY is one of BREAKING, ADDED, CHANGED, DEPRECATED, REMOVED, or FIXED. For security-related issues, follow the Security Advisory process.) Please take care to name the exact pieces of the API you've added or changed (e.g. types, interfaces, functions, or methods). If there are any breaking changes, make sure to offer a solution for consumers to follow once they upgrade to the changes. Finally, if you're only making changes to development scripts or tests, you may replace the template below with "None". --> (None) ## Checklist - [ ] I've updated the test suite for new or updated code as appropriate - [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've highlighted breaking changes using the "BREAKING" category above as appropriate --------- Co-authored-by: Jongsun Suh <[email protected]> Co-authored-by: Michele Esposito <[email protected]>
3 tasks
mikesposito
added a commit
that referenced
this issue
Oct 7, 2024
## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> This commit adds controllers which are not meant to be published, but instead serve as models to exemplify best practices for writing controllers, fulfilling a long-standing need. The controllers included here are implemented within a complete package which is linted just like other packages, and they ship with working tests which are run just like other tests. This lessens the chance that they will fall out of date in the future. The two controllers included in this commit are called `GasPricesController` and `PetNamesController`, which are roughly based on, but intentionally not drawn from, `GasFeeController` and `AddressBookController`. They demonstrate the following best practices: - Setting up a common structure for controllers, including creating complete types for the messenger and for state - Using the messenger to access data from another controller - Using service objects to make HTTP requests - Mocking the messenger in tests - Creating mock service objects - Mocking time in tests Certainly, more best practices can be demonstrated, but this should be a good first start. ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? For example: * Fixes #12345 * Related to #67890 --> Progresses #4504. ## Changelog <!-- If you're making any consumer-facing changes, list those changes here as if you were updating a changelog, using the template below as a guide. (CATEGORY is one of BREAKING, ADDED, CHANGED, DEPRECATED, REMOVED, or FIXED. For security-related issues, follow the Security Advisory process.) Please take care to name the exact pieces of the API you've added or changed (e.g. types, interfaces, functions, or methods). If there are any breaking changes, make sure to offer a solution for consumers to follow once they upgrade to the changes. Finally, if you're only making changes to development scripts or tests, you may replace the template below with "None". --> (No consumer-facing changes in this commit.) ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've highlighted breaking changes using the "BREAKING" category above as appropriate --------- Co-authored-by: Michele Esposito <[email protected]> Co-authored-by: Michele Esposito <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We have a lot of misalignment among controllers in this repo: older patterns are being used along newer patterns, and controllers that attempt to use newer patterns do so in an inconsistent way. However, too frequently, contributors create new controllers that continue to use outdated patterns. This leads to much churn and makes it more difficult to bring this repo into alignment.
When it comes to controllers, we do not have any documentation around the standards we would like all contributors to follow. Crucially, we are also missing good examples for people to copy.
Acceptance Criteria
The text was updated successfully, but these errors were encountered: