Custom event args #29993

SteveSandersonMS · 2021-02-08T16:48:56Z

Implements #17552

The overall design matches what is described in the proposal at #17552, so please see that for an overview of the changes in this PR. I'll add comments on individual lines for more clarity.

Some high-level implementation notes:

While I was in the process of changing a lot of event dispatch stuff, I took the opportunity to tidy it up quite a lot. Previously the BrowserRenderer and EventDispatcher were excessively interlinked, with the event dispatch code paths repeatedly bouncing back and forth between the two. I've teased these two apart so now there's almost nothing left to do with event dispatch inside BrowserRenderer, and all the event-related code is away in a separate subdirectory that mostly just works in isolation.
The protocol for communicating events from JS to .NET is now simpler:
- Previously, the JS side code contained logic to map the raw DOM event types to one of several "categories" (e.g, copy, cut, and paste were all mapped to the clipboard category). JS would send this category name to .NET, and .NET would use to to determine which EventArgs subclass to use for deserializing the args data.
- This notion of predefined categories no longer makes sense now the event types can be entirely custom. So now, the JS side code sends the original event name to .NET (with no category), and the .NET-side code chooses how to deserialize it. For the built-in web event names, we have built-in logic mapping them to EventArgs subclasses (e.g., paste maps to ClipboardEventArgs). For custom event names, the .NET code looks at the event's registered delegate and gets its parameter type, validating that there's only one and it does inherit from EventArgs. Altogether this is simpler from the JS side, which allows for some of the decoupling I did.

SteveSandersonMS · 2021-02-10T16:00:00Z

src/Components/Components/src/RenderTree/EventArgsTypeCache.cs

+                    }
+                    else
+                    {
+                        throw new InvalidOperationException($"The event handler parameter type {declaredType.FullName} for event must inherit from {typeof(EventArgs).FullName}.");


We don't really have to have this rule, but I'd err on the side of strictness. We can always loosen such rules later, but can't tighten them.

Inheriting from EventArgs is something we've made assumptions about in other places, plus it's good to make the developer really indicate for sure that they want to deserialize arbitrary untrusted input into this type.

I think it's legit to force inheriting from EventArgs. As you mention, we need a gesture to mark these types as suitable for custom events. That said, I'm not 100% sure extending EventArgs is enough for this. Mainly because many types outside Blazor extend from it and we would want to avoid those "spurious" usages.

Maybe we can mark it with an attribute instead to be more explicit. Specially since this has security implications in SSB

The other gesture a developer does to opt into this is actually using the type as the parameter to an event handler definition (with [EventHandler(...)]). Having two indicators (subclassing EventArgs and explicitly putting it on one of these definitions) is a clear enough statement of intent IMO.

The risk is similar to a [FromBody] SomeType myParam on an MVC action method. In that case we consider it a sufficiently clear statement of intent with fewer steps and restrictions.

SteveSandersonMS · 2021-02-10T16:04:01Z

src/Components/Shared/src/WebEventData.cs

+                {
+                    // For custom events, the args type is determined from the associated delegate
+                    eventArgsType = renderer.GetEventArgsType(eventHandlerId);
+                }


The logic above is where we've changed from the old "category"-based type selection to the newer rules, i.e., for built-in known event names we have hardcoded logic, and for unknown event names we get the type from the delegate.

The reason we have to have the hardcoded logic for known event names (and can't just use the delegate in all cases) is for back-compat. People might set up an event handler delegate that receives EventArgs and expect that, at runtime, they receive whichever subclass corresponds to the actual event. We retain that edge-case feature for built-in event names, but for custom events you only receive what you declare.

Also it's quite nice that the built-in events don't have to even look at the delegate and remain closer to their historical implementation. Less chance of any obscure behavioral changes.

Is the expectation that you author a custom JsonConverter if you needed to handle complex deserialization?

Yes, same as with a JS interop call.

SteveSandersonMS · 2021-02-10T16:05:12Z

src/Components/Web.JS/src/Boot.Server.ts

@@ -8,7 +8,7 @@ import { RenderQueue } from './Platform/Circuits/RenderQueue';
 import { ConsoleLogger } from './Platform/Logging/Loggers';
 import { LogLevel, Logger } from './Platform/Logging/Logger';
 import { CircuitDescriptor } from './Platform/Circuits/CircuitManager';
-import { setEventDispatcher } from './Rendering/RendererEventDispatcher';
+import { setEventDispatcher } from './Rendering/Events/EventDispatcher';


You'll see quite a bit of renaming and file moving in this PR for the TypeScript "events" related code. This is to clean up all kinds of cruft that had accumulated in this area.

SteveSandersonMS · 2021-02-10T16:07:58Z

src/Components/Web.JS/src/GlobalExports.ts


 // Make the following APIs available in global scope for invocation from JS
 window['Blazor'] = {
  navigateTo,
+  registerCustomEventType,


API REVIEW This is new public API on the JavaScript side (Blazor.registerCustomEventType). See the implementation at https://github.com/dotnet/aspnetcore/pull/29993/files#diff-58576c4c052d6fbfb851ec2f4b3bf740a2e318f0a9aeec9bc7aaf7a8acffe2eaR12 for details of the args.

I deliberately chose a hyperspecific name for this because (1) it's a pretty uncommon and advanced thing, and (2) I want to clarify that this is for registering the event type, and not something else like "event args mapping rule" which might be something else we add as a different feature in the future.

Have you been thinking about how we would provide a typing (completion) experience as we continue to add newer JS APIs?

Good point. We have talked about shipping a .d.ts file for the public APIs, but I wonder if some smaller change to the structure of blazor.*.js would be enough to make VS able to infer the exposed APIs and offer them based on the presence of the <script src="blazor.*.js"> alone.

I'm wondering if we can put a comment reference to the d.ts in index.html somehow to have editor's pick it up. we could put a reference to the tagged version for each release on our repo.

SteveSandersonMS · 2021-02-10T16:09:01Z

src/Components/Web.JS/src/Rendering/BrowserRenderer.ts

@@ -1,15 +1,11 @@
 import { RenderBatch, ArrayBuilderSegment, RenderTreeEdit, RenderTreeFrame, EditType, FrameType, ArrayValues } from './RenderBatch/RenderBatch';


Various event-related things were decoupled from BrowserRenderer here. Mostly the spaghettification was not for any good reason and just evolved there as we added more and more event-related features over time.

SteveSandersonMS · 2021-02-10T16:10:10Z

src/Components/Web.JS/src/Rendering/EventForDotNet.ts

@@ -1,378 +0,0 @@
-export class EventForDotNet<TData extends UIEventArgs> {


This file is retired in favour of the newer EventTypes.ts

SteveSandersonMS · 2021-02-10T16:12:05Z

src/Components/Web.JS/src/Rendering/Events/EventDispatcher.ts

@@ -1,18 +1,24 @@
-import { EventDescriptor } from './BrowserRenderer';
-import { UIEventArgs } from './EventForDotNet';


I eliminated the UIEventArgs type because it didn't serve any purpose. From the JS side, event args objects are now just any (makes sense because they can be supplied by arbitrary developer-provided callbacks).

SteveSandersonMS · 2021-02-10T16:13:58Z

src/Components/Web.JS/src/Rendering/Events/EventTypes.ts

+  createEventArgs: e => parseWheelEvent(e as WheelEvent)
+});
+
+registerBuiltInEventType(['toggle'], createBlankEventArgsOptions);


All the logic for built-in event types here is just a reformulated version of what we used to have in EventForDotNet.ts before. The built-in event types are held in the same data structure we use for custom event registrations, so it's easy to treat them all equivalently when processing events, and we can guarantee uniqueness of names.

SteveSandersonMS · 2021-02-10T16:15:41Z

src/Components/Web/src/PublicAPI.Unshipped.txt

+Microsoft.AspNetCore.Components.RenderTree.WebEventDescriptor.EventName.get -> string!
+Microsoft.AspNetCore.Components.RenderTree.WebEventDescriptor.EventName.set -> void
+*REMOVED*Microsoft.AspNetCore.Components.RenderTree.WebEventDescriptor.EventArgsType.get -> string!
+*REMOVED*Microsoft.AspNetCore.Components.RenderTree.WebEventDescriptor.EventArgsType.set -> void


Although these two removals look like public API changes, they are inside the RenderTree namespace that explicitly warns people not to use it. There has always been an analyzer that tells people that any uses of these types are subject to breaking changes.

Also, the WebEventDescriptor.EventArgsType should never have been used in any application code, since it's the protocol for dispatching events from JS to .NET, and user application code is not involved in that process.

Also, the WebEventDescriptor.EventArgsType should never have been used in any application code, since it's the protocol for dispatching events from JS to .NET, and user application code is not involved in that process.

Could you file an announcement for this? We didn't explicitly warn users against using it.

Will do - #30275

SteveSandersonMS · 2021-02-10T16:16:31Z

src/Components/Web/src/Web/WebEventCallbackFactoryEventArgsExtensions.cs

@@ -19,6 +19,7 @@ public static class WebEventCallbackFactoryEventArgsExtensions
        /// <param name="receiver">The event receiver.</param>
        /// <param name="callback">The event callback.</param>
        /// <returns>The <see cref="EventCallback"/>.</returns>
+        [Obsolete("This extension method is obsolete and will be removed in a future version. Use the generic overload instead.")]


All these obsoletions are for #28414

SteveSandersonMS · 2021-02-10T16:17:20Z

src/Components/test/E2ETest/Tests/EventTest.cs

@@ -26,7 +26,6 @@ public class EventTest : ServerTestBase<ToggleExecutionModeServerFixture<Program
        protected override void InitializeAsyncCore()
        {
            Navigate(ServerPathBase, noReload: true);
-            Browser.MountTestComponent<EventBubblingComponent>();


This served no purpose

SteveSandersonMS · 2021-02-10T16:17:51Z

src/Components/test/testassets/BasicTestApp/EventBubblingComponent.razor

-    <div __internal_stopPropagation_onclick="@intermediateStopPropagation">
-        <button id="button-with-onclick" @onclick="@(() => LogEvent("target onclick"))" __internal_stopPropagation_onclick="@targetStopPropagation">
+    <div @onclick:stopPropagation="@intermediateStopPropagation">
+        <button id="button-with-onclick" @onclick="@(() => LogEvent("target onclick"))" @onclick:stopPropagation="@targetStopPropagation">


The changes in this file are not strictly required for the PR, but I'm tidying up as I go

SteveSandersonMS · 2021-02-10T16:18:14Z

src/Components/test/testassets/BasicTestApp/EventPreventDefaultComponent.razor

-<p>
-    Later, it's likely that we'll add a syntax for controlling whether any given event handler
-    triggers a synchronous <code>preventDefault</code> before the event handler runs.
-</p>


We did that. Comment is redundant.

SteveSandersonMS · 2021-02-10T16:18:57Z

src/Components/test/testassets/BasicTestApp/Index.razor

@@ -27,7 +27,7 @@
        <option value="BasicTestApp.ErrorComponent">Error throwing</option>
        <option value="BasicTestApp.EventBubblingComponent">Event bubbling</option>
        <option value="BasicTestApp.EventCallbackTest.EventCallbackCases">EventCallback</option>
-        <option value="BasicTestApp.EventCasesComponent">Event cases</option>
+        <option value="BasicTestApp.EventCustomArgsComponent">Event custom arguments</option>


I'm not renaming or replacing here, even though it looks like it in the diff.

I'm removing EventCasesComponent because it doesn't exist and hasn't done for a long time - this is an orphaned link. And separately, I'm adding EventCustomArgsComponent.

SteveSandersonMS · 2021-02-10T16:19:28Z

src/Components/test/testassets/BasicTestApp/MouseEventComponent.razor

@@ -39,56 +44,68 @@
    {
        DumpEvent(e);
        message += "onmouseover,";
-        StateHasChanged();


None of these StateHasChanged calls should have been there. They're just not needed.

src/Components/Web/src/WebEventDescriptor.cs

javiercn · 2021-02-16T15:45:34Z

src/Components/Components/src/RenderTree/EventArgsTypeCache.cs

+{
+    internal static class EventArgsTypeCache
+    {
+        private static ConcurrentDictionary<MethodInfo, Type> Cache = new ConcurrentDictionary<MethodInfo, Type>();


Do we need a concurrent dictionary here? Or are all uses within the sync context? The reason that I'm asking is because this hurts "linkability" in the wasm cases, and I believe there are a bunch of cases where we are using it and we don't need it.

It's shared across all circuits

javiercn · 2021-02-16T16:01:53Z

src/Components/Components/src/RenderTree/Renderer.cs

+        /// </summary>
+        /// <param name="eventHandlerId">The <see cref="RenderTreeFrame.AttributeEventHandlerId"/> value from the original event attribute.</param>
+        /// <returns>The parameter type expected by the event handler. Normally this is a subclass of <see cref="EventArgs"/>.</returns>
+        public Type GetEventArgsType(ulong eventHandlerId)


Is the reason for this being public that we need to call it from other assemblies?

Yes, and because it's really becoming a part of the contract a renderer makes with its host. The web host has reasons for wanting to know the .NET type to supply for an event argument, so other hosts may want to do that too.

I'm unclear why we need to do this based on the event handler id vs based on the event name since there can't be two registrations for the same name.

What is preventing us from building a map at host initialization time of (eventName -> type) and using that for the deserialization?

What is preventing us from building a map at host initialization time of (eventName -> type) and using that for the deserialization?

That information doesn't exist in any formal way. The [EventHandler] registrations are a convention for the Razor compiler, but developers aren't compelled to use it.

The information that does exist for sure is the mapping from eventHandlerId->Delegate, which the renderer already stores.

That information doesn't exist in any formal way. The [EventHandler] registrations are a convention for the Razor compiler, but developers aren't compelled to use it.

Then the comment here is not completely correct, nothing prevents me from using a random type as an event handler provided that it inherits from EventArgs.

javiercn · 2021-02-16T16:40:08Z

src/Components/Web.JS/src/Rendering/Events/EventTypes.ts

+    // some listeners for it are already present. Once the event name alias gets registered,
+    // we have to notify any existing event delegators so they can update their delegated
+    // events list.
+    eventNameAliasRegisteredCallbacks.forEach(callback => callback(eventName, options.browserEventName));


Can you give an example on when you think this is useful?

Sure. If we didn't do this, we'd be relying on the event handlers being registered on the JS side before the corresponding elements get added to the DOM. This would be really inconvenient because you'd now be forced to use the autostart=false thing on <script src="blazor.*.js"> so you could be sure to register the event handler before the first render. It would be worse still for component library authors, as they'd have to do some kind of deferred async rendering flow to guarantee their event handler registrations go through before their component(s) first appear in the UI.

I judged that these usability issues were unacceptable and needed a solution. So with the mechanism you see here, the event handler can be registered after the elements are rendered in the DOM. The only requirement is that the event handler is registered before the event actually occurs (i.e., in response to a user action), of course.

javiercn · 2021-02-16T16:51:53Z

src/Components/test/E2ETest/ServerExecutionTests/ComponentHubInvalidEventTest.cs

@@ -71,7 +71,7 @@ public async Task DispatchingAnInvalidEvent_DoesNotTriggerWarnings()
            {
                BrowserRendererId = 0,
                EventHandlerId = 1990,
-                EventArgsType = "mouse",
+                EventName = "click",


I get the reason for the property name change, but why are we changing the value here?

Because mouse was the name of the category (which included click events), and we're no longer supplying category names. We're now supplying the actual event name, which in this case is click.

javiercn · 2021-02-16T17:02:36Z

src/Components/test/testassets/BasicTestApp/EventCustomArgsComponent.razor

+     @onkeydown="@(e => { LogMessage("Received native keydown event"); })"
+     @ontestevent="@HandleTestEvent"
+     @onkeydown.testvariant="@HandleCustomKeyDown"
+     @onkeydown.yetanother="@HandleYetAnotherKeyboardEvent"


What's the invocation order for callbacks when you have multiple registered event handlers like this for the same event?

I'm assuming keydown will trigger both events.

It's basically like native DOM events, in that they occur in some particular order in practice, but you shouldn't rely on it: https://stackoverflow.com/questions/282245/dom-event-precedence. For native DOM events, it may vary across browsers.

In our implementation it would fire the native event first, and then the aliases would fire in order based on registration. But since browsers themselves don't define this officially, I hope we don't need to either.

Sounds good!

I was asking since we use lexical order for things like @splat attributes and wanted to make sure that if there was such thing in the DOM we considered respecting it.

javiercn · 2021-02-16T17:11:38Z

src/Components/test/testassets/BasicTestApp/EventCustomArgsTypes.cs

+    [EventHandler("onkeydown.testvariant", typeof(TestKeyDownEventArgs), true, true)]
+    [EventHandler("onkeydown.yetanother", typeof(YetAnotherCustomKeyboardEventArgs), true, true)]
+    [EventHandler("oncustommouseover", typeof(EventArgs), true, true)]
+    public static class EventHandlers


I'm still struggling a bit with this.

It feels more natural for EventHandler to be applied directly to the custom event class. That way everything is in one place and I think it's a nice gesture to force using a custom type if you want to define a special event.

I'm ok if we think this is out of the scope of this PR, but I truly think we should change the way this works to avoid having to use this class moving forward.

Understood.

I agree we could make this nicer. But [EventHandler] is what we've already got and need to remain back-compatible with. This PR doesn't change the .NET-side registration mechanism. If we want to create a different and nicer registration mechanism, it can be looked at separately if customer demand justifies it. This PR doesn't lock us any more closely to the existing registration style.

SteveSandersonMS · 2021-02-17T18:35:14Z

@dotnet/aspnet-blazor-eng Ping for review so we can get this into preview 2

pranavkm · 2021-02-18T18:49:00Z

src/Components/Shared/src/WebEventData.cs

+                {
+                    // For custom events, the args type is determined from the associated delegate
+                    eventArgsType = renderer.GetEventArgsType(eventHandlerId);
+                }


Is the expectation that you author a custom JsonConverter if you needed to handle complex deserialization?

pranavkm · 2021-02-18T18:53:30Z

src/Components/Web.JS/src/GlobalExports.ts


 // Make the following APIs available in global scope for invocation from JS
 window['Blazor'] = {
  navigateTo,
+  registerCustomEventType,


Have you been thinking about how we would provide a typing (completion) experience as we continue to add newer JS APIs?

pranavkm · 2021-02-18T18:59:13Z

src/Components/Web/src/PublicAPI.Unshipped.txt

+Microsoft.AspNetCore.Components.RenderTree.WebEventDescriptor.EventName.get -> string!
+Microsoft.AspNetCore.Components.RenderTree.WebEventDescriptor.EventName.set -> void
+*REMOVED*Microsoft.AspNetCore.Components.RenderTree.WebEventDescriptor.EventArgsType.get -> string!
+*REMOVED*Microsoft.AspNetCore.Components.RenderTree.WebEventDescriptor.EventArgsType.set -> void


Also, the WebEventDescriptor.EventArgsType should never have been used in any application code, since it's the protocol for dispatching events from JS to .NET, and user application code is not involved in that process.

Could you file an announcement for this? We didn't explicitly warn users against using it.

…sary types.

…use that's where other similar responsibilities are

…later

…plications during automated runs

javiercn · 2021-02-18T22:44:07Z

src/Components/test/E2ETest/Tests/EventCustomArgsTest.cs

+
+namespace Microsoft.AspNetCore.Components.E2ETest.Tests
+{
+    public class EventCustomArgsTest : ServerTestBase<ToggleExecutionModeServerFixture<Program>>


Do we have a test for validating you can't replace an existing event?

javiercn

Looks great!

I have a few more comments, but I think we can get this merged and resolve them in the future.

My biggest concern is the deserialization of "Random" custom types, but I don't think I have a good solution for it.

ghost added the area-blazor Includes: Blazor, Razor Components label Feb 8, 2021

SteveSandersonMS force-pushed the stevesa/custom-event-args-real branch from 6b739ae to 763db33 Compare February 10, 2021 11:45

SteveSandersonMS marked this pull request as ready for review February 10, 2021 15:57

SteveSandersonMS requested a review from a team as a code owner February 10, 2021 15:57

SteveSandersonMS commented Feb 10, 2021

View reviewed changes

SteveSandersonMS mentioned this pull request Feb 10, 2021

Try removing possibly-unused overloads in WebEventCallbackFactoryEventArgsExtensions #28414

Closed

SteveSandersonMS commented Feb 10, 2021

View reviewed changes

javiercn reviewed Feb 10, 2021

View reviewed changes

src/Components/Web/src/WebEventDescriptor.cs Show resolved Hide resolved

SteveSandersonMS force-pushed the stevesa/custom-event-args-real branch from 276d73f to 0686d1a Compare February 10, 2021 18:31

javiercn reviewed Feb 16, 2021

View reviewed changes

pranavkm approved these changes Feb 18, 2021

View reviewed changes

SteveSandersonMS added 21 commits February 18, 2021 19:08

Fix event mapping

eb391df

Simplify event dispatching on TypeScript side more. Eliminate unneces…

60d67eb

…sary types.

Rename file for clarity

f0a78bb

Migrate "preventDefault for submit" behavior into EventDelegator beca…

6d2694d

…use that's where other similar responsibilities are

Put event-centric files into an Events directory for more clarity

1792351

Disentangle event dispatch from BrowserRenderer

badc38f

Update comment

c832baa

Add a cache for the handler->argstype lookup

08967e8

Create a registry of event types so we'll be able to add custom ones …

66f7dba

…later

Public API for registering custom event types

c9ca4b8

Dispatch events to any registered event type aliases too

11cbd20

Back-compat for unregistered event types

6ca5e3a

Update some older E2E tests

c1523ff

Begin on E2E scenarios

3a9c621

More E2E scenarios

34c4338

Change E2E scenario to use keydown, not paste, to avoid isolation com…

c09a2f1

…plications during automated runs

Prepare E2E case for when an aliased event has no native global listener

1ebdf84

Support custom events that have no corresponding native global listener

907999d

E2E test cases

9ad4039

Another test case showing multiple aliases work

8c41111

Update blazor.server.js

5c49dac

SteveSandersonMS force-pushed the stevesa/custom-event-args-real branch from 0686d1a to 5c49dac Compare February 18, 2021 19:13

SteveSandersonMS mentioned this pull request Feb 18, 2021

File announcement about WebEventDescriptor.EventArgsType #30275

Closed

javiercn reviewed Feb 18, 2021

View reviewed changes

SteveSandersonMS merged commit d97be90 into main Feb 18, 2021

SteveSandersonMS deleted the stevesa/custom-event-args-real branch February 18, 2021 22:46

javiercn approved these changes Feb 18, 2021

View reviewed changes

This was referenced Feb 19, 2021

Support custom event args in Blazor #17552

Closed

WebEventDescriptor.EventArgsType replaced by WebEventDescriptor.EventName aspnet/Announcements#453

Open

github-actions bot locked and limited conversation to collaborators Dec 8, 2023

		@@ -1,15 +1,11 @@
		import { RenderBatch, ArrayBuilderSegment, RenderTreeEdit, RenderTreeFrame, EditType, FrameType, ArrayValues } from './RenderBatch/RenderBatch';

		@@ -1,378 +0,0 @@
		export class EventForDotNet<TData extends UIEventArgs> {

		@@ -1,18 +1,24 @@
		import { EventDescriptor } from './BrowserRenderer';
		import { UIEventArgs } from './EventForDotNet';

Custom event args #29993

Custom event args #29993

Conversation

SteveSandersonMS commented Feb 8, 2021 • edited Loading

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

SteveSandersonMS Feb 10, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SteveSandersonMS Feb 10, 2021 • edited Loading

Choose a reason for hiding this comment

SteveSandersonMS Feb 10, 2021 • edited Loading

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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

javiercn Feb 16, 2021 • edited Loading

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

SteveSandersonMS commented Feb 17, 2021

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

javiercn left a comment

Choose a reason for hiding this comment

SteveSandersonMS commented Feb 8, 2021 •

edited

Loading

SteveSandersonMS Feb 10, 2021 •

edited

Loading

SteveSandersonMS Feb 10, 2021 •

edited

Loading

SteveSandersonMS Feb 10, 2021 •

edited

Loading

javiercn Feb 16, 2021 •

edited

Loading