Implemented extensible way to deal with results of commands. This is … #916

Mylan719 · 2020-12-08T21:30:28Z

Implemented an extensible way to deal with results of commands.
The point is to serve use cases when you need to return additional data from static command. One such use case is validation results. Which have up until now been unpractical to use with static commands.

As static commands are used more and more prominently due to their performance advantages. Lack features like validation is more and more painful.

The key point is to:

Let programmer define additional data to augment the command result for example via FilterAttribute.
Let the programmer change previous command result

We refrained from implementing any concrete solution like ModelState in the command result. Instead we want to let the programmer define custom solution. This is not only for validation but also telemetry and such.

…crutial use cases when you need to return additional data from static command. One such case is validation results. Which were up until now unpractical to use with static commands. As stattic commands are used more and more prominently due to their performance advantages. Lack features like validation is more and more painful.

…stomData.

tomasherceg

Looks good to me overall.
I've updated the code so customData and result / commandResult would work for classic postback too.

Please add UI test for the SimpleExceptionFilter test
Please rename "StaticCommandResult" folder in tests to just "CommandResult" so it better expresses what the sample is for

cafour · 2020-12-18T11:39:28Z

src/DotVVM.Framework/ViewModel/Serialization/DefaultViewModelSerializer.cs

            }
            catch (Exception ex)
            {
-                throw new Exception($"Could not serialize viewModel of type { context.ViewModel.GetType().Name }. Serialization failed at property { writer.Path }. {GeneralViewModelRecommendations}", ex);
+                throw new Exception($"Could not serialize static command {description} of type '{ data.GetType().FullName}'. Serialization failed at property { writer.Path }. {GeneralViewModelRecommendations}", ex);


It's imho missing an article. "Could not serialize a static command {description} object of type ..." sounds a bit better to me.

- Changed interface for CustomData

exyi

Also, how do I access customData on the first (GET) request?

exyi · 2020-12-30T11:52:12Z

src/DotVVM.Framework/Hosting/IDotvvmRequestContext.cs

@@ -111,5 +111,7 @@ public interface IDotvvmRequestContext
        string? ResultIdFragment { get; set; }

        IServiceProvider Services { get; }
+        object? CommandResult { get; set; }


Why do we need this property. Wouldn't it be simpler to just pass the commandResult as an argument to the filter. This way, it's yet another stateful property in IDotvvmrequestContext which may cause confusion when it contains what and when it can be overwritten.

For example, I could write a command:

public void MyCommand() { Context.CommandResult = new SomeObject(); }

This will return null, which seems wrong.

Agree that this property does not have to be there. But do you have some idea how to provide an interface to modify the result of command or static command in OnCommandExecutedAsync and etc.?

Just add an (ref) parameter to the OnCommandExecutedAsync method. Since most people use the base class, we can add a second overload and prevent a breaking change.

exyi · 2020-12-30T11:54:22Z

src/DotVVM.Framework/Hosting/IDotvvmRequestContext.cs

@@ -111,5 +111,7 @@ public interface IDotvvmRequestContext
        string? ResultIdFragment { get; set; }

        IServiceProvider Services { get; }
+        object? CommandResult { get; set; }
+        Dictionary<string, object>? CustomData { get; }


Do we need this to be a dictionary? I think the data should not be readable server-side.

We could just have a method AddCustomData(string key, object data). The data will be accessible only client-side. The benefit is that order of execution will not matter.

When you will need to modify some object in CustomData, the AddCustomData method does not provide you the interface to do so.
You can add some additional CustomData in static command resolution and you can also want to modify it in the OnPresenterExecutedAsync method. This is actually based on one of my use-cases.

For example, you have custom validation and you have multiple places where you just adding errors. At the end of execution, you want to filter the collection for duplicities. If there is just the add method, you cannot filter it.

Also, CustomData was inspired by ModelState (MVC). There is used the same approach as here.

I am fine with CustomData as a Dictionary (or IDictionary) - HttpContext.Items and other similar containers are also dictionaries. Being able to see what's in the collection can be useful.

But I agree with removing CommandResult from context. Also, I think that allowing the users to change it (in action filters) is a bad idea at all - if the users want to send something else than the result, they can use CustomData and deal with them in the postback handler.

However, unlike ModelState and Items, this is not intended for component-componet communication.

@quigamdev I'd suggest you to rather create a request scoped service that will register your error, then do deduplication and put it into custom data. Then you'll be able to detect cases when you add an error after the deduplication.

When you will need to modify some object in CustomData, the AddCustomData method does not provide you the interface to do so.

That's the purpose - then the order of execution can not matter. In DotVVM we generally have a big problem that things only work at certain time and this will be another source of such issues.

src/DotVVM.Framework/Resources/Scripts/global-declarations.ts

exyi · 2020-12-30T11:56:05Z

src/DotVVM.Framework/Resources/Scripts/postback/postback.ts

@@ -68,7 +68,7 @@ export async function postBack(
                serverResponseObject,
                wasInterrupted,
                commandResult: null,
-                response: (err.reason as any).response,
+                response: (err.reason as any)?.response,


The reason should not be null, why is the ?. needed?

When an exception is thrown the reason si null. That's why null propagation is needed.

Exception on the server? That would be type: "serverError". Exception on the client should also contain the reason when it's of type DotvvmPostbackError. DotvvmPostbackError's type definition does not allow null, so could either update it or (preferably IMHO) fix the bug that's causing null in there?

The null in reason was caused by an exception in dotvvm.events.<>.subscirbe((e)=>{ "some error here" }). In this case, you need to expect that it can be null. It is non-dotvvm code that will result in this exception and dotvvm has to work with it.
The type definition works only for typescript. But not everyone has to be using it.

In that case, I'd better add a null check to the constructor. If you terribly need to be null-tollerant, I'd suggest changing the type signature so we can at least be consistent. Even with your additional null checks, the handler is going to crash in isInterruptingErrorReason

@quigamdev I think we should add try/catch blocks around errors in event handlers and wrap the error with reason: event. But I think we can do it in a separate PR.

src/DotVVM.Framework/Resources/Scripts/postback/postbackCore.ts

exyi · 2020-12-30T11:59:07Z

src/DotVVM.Framework/ViewModel/Serialization/DefaultViewModelSerializer.cs

            }
            catch (Exception ex)
            {
-                throw new Exception($"Could not serialize viewModel of type { context.ViewModel.GetType().Name }. Serialization failed at property { writer.Path }. {GeneralViewModelRecommendations}", ex);
+                throw new Exception($"Could not serialize static command {description} of type '{ data.GetType().FullName}'. Serialization failed at property { writer.Path }. {GeneralViewModelRecommendations}", ex);


Nitpick: It will say "static command", even commands. We could just say "Could not serialize result"/"Could not serialize custom data".

exyi · 2020-12-30T12:02:35Z

...VVM.Samples.Common/ViewModels/FeatureSamples/CommandResult/SimpleExceptionFilterViewModel.cs

+            {
+                context.CommandResult = new PageErrorModel {
+                    Message = clientError.Message
+                };


This changes the CommandResult type, which will only cause problems and should be probably forbidden.

I agree. This is not good practice.

Co-authored-by: Stanislav Lukeš <exyi@outlook.cz>

…operies are now read-only.

…e building.

exyi

Ok, this looks fine.

Just, could the AddCustomResponseProperty throw an exception after the data is serialized? (In a similar fashion like AddResource does it)

…xt has been serialized. Test for that.

… be setting this.

Mylan719 requested review from tomasherceg, exyi and quigamdev December 8, 2020 21:30

Milan Mikuš and others added 4 commits December 9, 2020 02:43

Sample testing the exception filter that changes CommandResult and Cu…

9b164ee

…stomData.

Moved command result assignment to ViewModelSerializer

35744dd

CustomData are returned on postbacks too

f13d1e4

Command added to the test samples

b921c1c

tomasherceg requested changes Dec 9, 2020

View reviewed changes

cafour reviewed Dec 18, 2020

View reviewed changes

- Added UI test

977696a

- Changed interface for CustomData

quigamdev requested review from tomasherceg and cafour December 29, 2020 17:00

quigamdev approved these changes Dec 29, 2020

View reviewed changes

quigamdev added this to the Version 3.0 milestone Dec 29, 2020

exyi requested changes Dec 30, 2020

View reviewed changes

quigamdev and others added 8 commits December 30, 2020 17:38

Update src/DotVVM.Framework/Resources/Scripts/postback/postbackCore.ts

2de91de

Co-authored-by: Stanislav Lukeš <exyi@outlook.cz>

Update src/DotVVM.Framework/Resources/Scripts/global-declarations.ts

a0f37a5

Co-authored-by: Stanislav Lukeš <exyi@outlook.cz>

CommandResult removed from DotvvmContext.

6ba6afa

Fixing uncompillable tests

05ca21a

Custom data renamed to custom response properties. Custom response pr…

101a60e

…operies are now read-only.

Renaming and refactoring the custom presponse properties sample.

5784e12

Changed custom response property test to work with renamed UI handle.

48de474

More tests for viewmodel response building and static command respons…

fdcb359

…e building.

exyi approved these changes Jan 13, 2021

View reviewed changes

Mylan719 added 5 commits January 14, 2021 16:42

Now the error message should be gramaticaly and factually correct.

11194c3

Merge

3ab69eb

Now Custom properties complain when property is added after the conte…

02fdf6a

…xt has been serialized. Test for that.

Merge branch 'main' into ferature/command-response-customisation

d8eb1dc

Correcting faulty implementation of TestDotvvmRequestContext.

6435964

Mylan719 and others added 3 commits January 21, 2021 15:14

Removed setters for custom response properties manager. Nobody should…

42b98ea

… be setting this.

Merge branch 'main' into ferature/command-response-customisation

b8a7bad

Fixed CommandResultTests.SimpleExceptionFilterTest

ae0d2bd

quigamdev merged commit d2ec207 into main Jan 21, 2021

quigamdev deleted the ferature/command-response-customisation branch January 31, 2021 18:40

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implemented extensible way to deal with results of commands. This is … #916

Implemented extensible way to deal with results of commands. This is … #916

Mylan719 commented Dec 8, 2020

tomasherceg left a comment

cafour Dec 18, 2020

exyi left a comment

exyi Dec 30, 2020

quigamdev Dec 30, 2020

exyi Dec 30, 2020

exyi Dec 30, 2020

quigamdev Dec 30, 2020

tomasherceg Dec 30, 2020

exyi Dec 30, 2020

exyi Dec 30, 2020

quigamdev Dec 30, 2020

exyi Dec 30, 2020

quigamdev Dec 31, 2020

exyi Dec 31, 2020

tomasherceg Jan 14, 2021

exyi Dec 30, 2020

exyi Dec 30, 2020

quigamdev Dec 30, 2020

exyi left a comment

Implemented extensible way to deal with results of commands. This is … #916

Implemented extensible way to deal with results of commands. This is … #916

Conversation

Mylan719 commented Dec 8, 2020

tomasherceg left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

exyi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

exyi left a comment

Choose a reason for hiding this comment