Skip to content
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

Closed
mcmire opened this issue Jul 3, 2024 · 0 comments · Fixed by #4550
Closed

Add guidelines for writing controllers, and add example controller #4504

mcmire opened this issue Jul 3, 2024 · 0 comments · Fixed by #4550

Comments

@mcmire
Copy link
Contributor

mcmire commented Jul 3, 2024

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

  • Documentation is present that outlines guidelines for writing controllers
  • A complete example is present that fully demonstrates all of the guidelines working together (we can base this off an existing controller, but it should be a brand new controller)
@mcmire mcmire self-assigned this Jul 3, 2024
@mcmire mcmire mentioned this issue Jul 24, 2024
3 tasks
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]>
@desi desi linked a pull request Sep 19, 2024 that will close this issue
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
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants