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

droplets: refactor how to assign resources #1500

Merged
merged 1 commit into from
Jan 26, 2024

Conversation

bentranter
Copy link
Member

This refactors how we move created resources to projects to make it generic-ish. As long as the resource implements the URN() method, we can use a helper that performs the assign resources call.

This is not quite ideal due to how the commands are architected. Because we double-wrap the raw godo resources (first in a wrapper struct, then in the type alias for a slice of those wrapped structs), Go's type system isn't able to recognize those slices as implementing a slice of urner interfaces. What it can do though, is recognize each individual element of those slices as implementing the urner interface, so the method I created will only accept a single urner, despite the call to assign resources accepting a slice of URNs.

I think the tradeoff is worth it, since each command that can support the projects functionality can use the same moveToProject, and what we lose in efficiency by having multiple calls to assign resources in some instances, we gain in consistency.

This refactors how we move created resources to projects to make it
generic-ish. As long as the resource implements the `URN()` method, we
can use a helper that performs the assign resources call.

This is not quite ideal due to how the commands are architected. Because
we double-wrap the raw godo resources (first in a wrapper struct, then
in the type alias for a slice of those wrapped structs), Go's type
system isn't able to recognize those slices as implementing a slice of
`urner` interfaces. What it can do though, is recognize each individual
element of those slices as implementing the `urner` interface, so the
method I created will only accept a single `urner`, despite the call to
assign resources accepting an slice of URNs.

I think the tradeoff is worth it, since each command that can support
the projects functionality can use the same `moveToProject`, and what we
lose in efficiency by having multiple calls to assign resources in some
instances, we gain in consistency.
Copy link
Member

@andrewsomething andrewsomething left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Annoying that it doesn't work as a variadic function, but still super useful.

@bentranter bentranter merged commit 5d5b24a into main Jan 26, 2024
6 checks passed
@bentranter bentranter deleted the bentranter/refactor-droplet-project-id branch January 26, 2024 19:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants