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

change: tweak API of Errors and implement IntoIter #522

Merged
merged 8 commits into from
Feb 15, 2023
Merged

change: tweak API of Errors and implement IntoIter #522

merged 8 commits into from
Feb 15, 2023

Conversation

gbj
Copy link
Collaborator

@gbj gbj commented Feb 14, 2023

I've been thinking about how to limit the API surface of Errors so we aren't committed to any particular internal implementation. I'm hoping to achieve the following with this PR:

  • avoid the abstraction leak of exposing the fact that hydration keys are used as the keys in a map here
  • avoid committing to backing this with a HashMap forever without being able to switch to another data structure
  • implement IntoIter so you can just do this
for error in errors.get() {
  // ...
}
  • get over the slightly-awkward API of errors.get().0 and friends

@benwis I'd like you to review this because a) it's your creation originally and b) without a doubt you're using this in more places than anyone else. Remember it's a lot easier for us to add additional methods in the future (not a breaking change to add a method) than to remove them or change them (breaking changes).

@gbj gbj requested a review from benwis February 14, 2023 01:45
Copy link
Contributor

@benwis benwis left a comment

Choose a reason for hiding this comment

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

Looks pretty good to me, The tricky part as always is making the internal HashMap private. We have remove, insert, and

.into_iter()
.filter_map(|(_k, v)| v.downcast_ref::<TodoAppError>().cloned())
.filter_map(|(_, v)| v.downcast_ref::<TodoAppError>().cloned())
.collect();
println!("Errors: {errors:#?}");
Copy link
Contributor

Choose a reason for hiding this comment

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

I probably did this, but we can remove this println!

#[derive(Debug, Default, Clone, PartialEq, Eq, Hash)]
pub struct ErrorKey(String);

impl<T> From<T> for ErrorKey
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this is good, but I should ask whether we make any assumptions elsewhere that this is a valid HydrationKey? I set it outside leptos with a default for 404, but is there a cleanup function somewhere that might need this to be valid?

Copy link
Contributor

Choose a reason for hiding this comment

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

Same rough idea, making this private is probably the right way to go, but there are a lot of possible things people can do to a HashMap. As long as we're okay with limiting those, this is fine.

@gbj gbj merged commit 00a796d into main Feb 15, 2023
@gbj gbj deleted the errors-api branch February 15, 2023 19:03
gbj added a commit that referenced this pull request Mar 21, 2023
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.

None yet

2 participants