-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Conditially require serialize #1195
Conditially require serialize #1195
Conversation
@mkawalec this is a clever solution! With these changes, a worker agent implementation would look like this: impl Agent for Worker {
type Reach = Public<Request, Response>;
type Message = Msg;
// ... What do you think about keeping the impl Agent for Worker {
type Reach = Public<Self>;
type Message = Msg;
type Input = Request;
type Output = Response;
// ... |
Also, I went ahead and addressed this ^ for you here: #1202 |
Curious what you come up with for this! I wouldn't consider it a blocker though :) |
That will be a fun merge :P |
😅 yeah, didn't think about that. How about I revert that and we get this in first? RE: trait aliasesIt looks much cleaner but I'd like to keep Yew on stable Rust. It will be a lot of ugly copy pasting trait bounds everywhere but it's internal so I think we can live with it. |
My investigation without running the code seems to suggest that local agents will respond sync (and they did that anyways, even without this change), but now the needless |
I'm getting the most bizzare of errors on 1.40.0, but not on stable, namely
looks like a compiler bug fixed in the meantime? |
Yep, here's the compiler bug rust-lang/rust#34426. Do we want to update the compiler versions we target maybe? |
@mkawalec yes, feel free! |
This is true but I need to think on #1127 some more. I think the issue there is more about getting info back from the initial bridge call so that a component doesn't need to handle the default case with option wrapping and the like |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any particular reason you chose to add a trait bounds to Input
for Debug
?
There was something requiring this constraint, I'll make sure it is actually still the case. |
Also updated the docs in yewstack/docs#89 |
Very cool how minimal the example changes were, great work! |
Thanks for a good review :) |
Implements #1212 |
There is still a single
Agent
trait, butReach
is now what constraints theInput
andOutput
types. This way we can guaranteeAgent
signatures to be the same between sync and async agents, with only constraints on the input and output types changing.One downside of this approach is that we hit this compiler bug, which requires us to write the constraints longform (
<Self::Reach as Discoverer>::Output
) instead of the standard way (Self::Reach::Output
) as there is no ambiguity, despite what the compiler reports.ToDo:
Input
andOutput
with a type alias that captures these constraints to make each repetition less boilerplatyReach
definitions closer together (and add some comments) to make it easier to understand howReach
es are definedFixes: #1212
IssueHunt Summary
Referenced issues
This pull request has been submitted to: