Skip to content
This repository has been archived by the owner on Feb 25, 2021. It is now read-only.

WIP Partial for fix #546 - Add more events #718

Merged
merged 3 commits into from
May 1, 2018
Merged

Conversation

rynowak
Copy link
Member

@rynowak rynowak commented May 1, 2018

Work in progress adding more built-in event types. I figure I'll keep working on this for a bit and we can merge whatever's ready before we branch

default:
throw new ArgumentException($"Unsupported value '{eventArgsType}'.", nameof(eventArgsType));
return JsonUtil.Deserialize<UIEventArgs>(eventArgsJson);
Copy link
Member Author

Choose a reason for hiding this comment

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

Changing this to allow 'unknown' to flow through makes it possible to at least pipe through any event without data.

We might want to consider something in the future that makes this abitrarily extensible by mapping 'unknown' to something with a dictionary or JSON blob. You can imagine that components might use their own bubbling events for notifications - this pattern was used in WPF as well

Copy link
Member Author

Choose a reason for hiding this comment

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

OR alternatively, we could allow you to do strongly typed things by subclassing UIEventArgs

Copy link
Member

Choose a reason for hiding this comment

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

Yes, that would be an improvement. As part of fixing the non-bubbling events, I'll enable passthrough of unknown event types, mapping them simply to UIEventHandler. We can consider ways of including custom data as a future enhancement.

Just the notifications alone cover a large proportion of scenarios.

Copy link
Member

Choose a reason for hiding this comment

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

BTW I've handled this in #722 so if that PR goes in first, you could revert this change to default.

public IKeyboard Keyboard => (Browser as IHasInputDevices)?.Keyboard;

public IMouse Mouse => (Browser as IHasInputDevices)?.Mouse;

Copy link
Member Author

Choose a reason for hiding this comment

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

Will revert this, I ended up not needing it.


public static ITestOutputHelper Output => _output.Value;

public BrowserTestBase(BrowserFixture browserFixture, ITestOutputHelper output)
{
_browser.Value = browserFixture.Browser;
_logs.Value = browserFixture.Logs;
_fixture.Value = browserFixture;
Copy link
Member Author

Choose a reason for hiding this comment

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

Will revert this, I ended up not needing it.

// Mouse over the button and then back off
var actions = new Actions(Browser)
.MoveToElement(input)
.MoveToElement(other);
Copy link
Member Author

Choose a reason for hiding this comment

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

I'm far from a webdriver expert but this seemed to be what they recommend for general interactivity scripting.

We also have the ability to run javascript to trigger events, but I wanted to avoid that until its absolutely necessary because that seems like a 'less good' way to test.

Copy link
Member

Choose a reason for hiding this comment

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

Oh, well, I should have read this earlier. Just realised I've also implemented similar E2E events coverage in #722. Sorry for duplicating your work! I even used the same filename 😞

I guess it would be good to merge what we've done together. Your test has more coverage of the mouse events, whereas mine has more coverage of the bubbling behaviors.


export interface UIEventArgs {
Type: string;
}

export interface UIFocusEventArgs extends UIEventArgs {
Copy link
Member

Choose a reason for hiding this comment

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

I don't think this interface needs to be exported, as we're only using the type parameters within this file as a way of checking that the constructor args are of a recognized format.

It wouldn't be harmful to export it either, but if we are doing so, it would be good to export all the others too for consistency.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah right, I didn't notice that. Will undo the export until we actually need these types exported

<option value="BasicTestApp.ComponentRefComponent">Component ref component</option>
<option value="BasicTestApp.AfterRenderInteropComponent">After-render interop component</option>
<!--<option value="BasicTestApp.RouterTest.Default">Router</option> Excluded because it requires additional setup to work correctly when loaded manually -->
</select>
Copy link
Member

Choose a reason for hiding this comment

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

Yes, I guess it's time to stop fighting VS over the indentation here!

Copy link
Member Author

Choose a reason for hiding this comment

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

The alternative would be to use an .editorsettings - VS should honour that.

SteveSandersonMS and others added 3 commits May 1, 2018 10:49
This change adds tag helpers and defines event types for all of the DOM
events we could find. You'll find it much easier now to subcribe to
these events.

While we did define new event types, we didn't substantially expand the
set of data that we serialize for events. We're looking for feedback on
what is most critical to have, and looking for contributions adding
those data and tests.
@rynowak rynowak force-pushed the rynowak/additional-events branch from 0398ddb to cfe44ef Compare May 1, 2018 19:01
@rynowak
Copy link
Member Author

rynowak commented May 1, 2018

@SteveSandersonMS - I added everything from my list.

I'm planning to merge when the CI is green unless you have major feedback. I felt like adding the types was important because you have 4-5 things that are required just to make the type work end to end. I didn't add the data because I don't feel good doing that without tests. This is makes it much easier for someone to do a contribution if they care about a specific event or piece of data.

@rynowak rynowak merged commit 4ae907d into dev May 1, 2018
@rynowak rynowak deleted the rynowak/additional-events branch May 1, 2018 19:22
Assert.Equal("onmousedown,onmouseup,", output.Text);
}

private string[] GetLogLines()
Copy link
Member

Choose a reason for hiding this comment

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

Looks like GetLogLines and TriggerCustomBubblingEvent aren't used, if I'm reading this correctly.

@SteveSandersonMS
Copy link
Member

@rynowak Excellent - thanks for being so quick with all this! Minor point about possibly unused test code, but don't let it stop you from cherry-picking to release/0.3.0.

@rynowak
Copy link
Member Author

rynowak commented May 1, 2018

6903327

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants