-
Notifications
You must be signed in to change notification settings - Fork 648
trying to fix 1009 by changing the AssignToProperties method behavior #1108
Conversation
@SteveSandersonMS can you give a quick feedback on this PR ? If you think it needs more work please tell me. The build error doesn't seems to be related to the PR content but I'll dig it if you think I'm onto something. |
Thanks for suggesting this! The approach of using the cached parameter writers to know what values to blank out is promising. We would probably want to rename the method The code in the PR as-is is pretty allocatey (for example, instantiating a new Thanks again for contributing this! |
Ok I'll have a look at this. i'm not a big expert on avoiding allocations, but I'll try to dig it. Thanks for the feedback |
@SteveSandersonMS I changed the code so there is less allocation :
And I renamed the method to "SetParameterProperty" because of the attribute name. What's the point of the generic PropertySetter here ? it's interface is not using generic parameters. |
@SteveSandersonMS ok the build is fixed after fixing the conflict with PR #1545 |
Update from source
I'll fix the CI error this week, I don't understand how my change causes error on non-Windows E2E test but it's not failing on other PR so ... |
@SteveSandersonMS or @rynowak I understand why the test fails here, but I need your opinion how I need to fix it. The problem is on \samples\ServerSideBlazor.Client\Pages\FetchData.cshtml. On line 53 we set StartDate to DateTime.Now, but if we load /fetchdata we don't send any date in the url, so my patch forces it to DateTime default value (0001/01/01 ...) and then the test fails because "StartDate.AddDays(-5)" throws an ArgumentOutOfRange" error (I think it doesn't fail on mono but does fail on core, that's why only this test is failing). I can't find any smart way to solve it :
Maybe we can add a DefaultValue to the parameter attribute but it will or in the fetchData.cshtml set StartDate as nullable and check for null value after setParameters `
if(!StartDate.HasValue) What do you think ? |
Hi all, do I need to keep this PR up-to-date with master, choose myself how to fix the CI (see previous comment), improve the code somehow, or should I close it ? |
Currently we’re focused on the code migration work. Once that’s done we can resume attending to PRs. In the meantime if you want to simplify migrating this PR you could rebase it on master. Thanks! |
Ok sure I'll do that. If there is any stuff we can do for the migration do
not hesitate to add some up-for-grabs.
Rémi
Le dim. 25 nov. 2018 11:32, Steve Sanderson <[email protected]> a
écrit :
… Currently we’re focused on the code migration work. Once that’s done we
can resume attending to PRs.
In the meantime if you want to simplify migrating this PR you could rebase
it on master. Thanks!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1108 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABS8evm77OlV2LGjaQPFwLiUkJ2HqK-7ks5uynG9gaJpZM4VIKdB>
.
|
Merge is done, the same tests are failing. FYI the file move was not correctly handled by git, I had to reproduce all the changes on the new files. It might be a problem on bigger PR. |
@RemiBou thank you very much that after a few months you are still trying to fix this bug. I really appreciate your work (and of course the work of the entire Blazor team). |
Thanks again for this, @RemiBou! It's now moved to dotnet/aspnetcore#4797, where it will be merged shortly. |
So here is my other attempt on fixing this bug, I'll let the blazor team decide which way they prefer to go