Skip to content

Conversation

@sgithens
Copy link

@amb26 @the-t-in-rtf I'm going to look at adding a few unit tests, but if you wanted to take an initial look at this and give me any feedback, that'd be helpful

@gpii-bot
Copy link

CI job failed: https://ci.gpii.net/job/gpii-binder-tests/2/

@the-t-in-rtf
Copy link
Collaborator

Great idea, and very useful, as we do this kind of grunt work all the time in downstream grades. Although I could look at stuff in isolation, it'd be helpful to see tests so that I can see examples of what you're passing and what the intended effect is. I'm happy with these being synthetic testem-friendly tests, simulating keyboard input crudely rather than using gpii-webdriver.

Also, linting! Dude! (I was wondering how the heck you managed to break the tests without adding tests for your work. That's how.)

@sgithens
Copy link
Author

Hi @the-t-in-rtf . I added a few unit tests for this, and everything should lint now. :)

@gpii-bot
Copy link

CI job failed: https://ci.gpii.net/job/gpii-binder-tests/4/

@the-t-in-rtf
Copy link
Collaborator

Hi, @sgithens, I'm trying to make sense of the associated ticket, you kind of describe in the title the change you're making, but I couldn't get more info as most of the links to example there are broken. I think I get it, but for posterity we need a clear summary.

Also, the new functionality needs to be described somewhere, perhaps in a new section towards the end of the README.

@gpii-bot
Copy link

CI job failed: https://ci.gpii.net/job/gpii-binder-tests/5/

@sgithens
Copy link
Author

@the-t-in-rtf Updated the README and ticket. I believe this should be ready for another review now.

@gpii-bot
Copy link

CI job failed: https://ci.gpii.net/job/gpii-binder-tests/6/

* Function to process the markup binding decorators and create the events described
* by them. The markup needs to be rendered and settled before this can be called.
*
* @param {Object} that - The component itself.
Copy link
Collaborator

Choose a reason for hiding this comment

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

I am the guiltiest party here, I do this all the time, but in later work, @amb26 and I have been adding the grade to these for purposes of clarity.

Copy link
Author

Choose a reason for hiding this comment

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

Make these more specific using the component grade for the type.

@the-t-in-rtf
Copy link
Collaborator

I left a few comments, but am happy with this. @amb26, can you look through this as well? I know you and @sgithens have already discussed this, it'd be good to confirm this roughly matches what you had in mind.

paragraphClick: ".paragraph-click",
multipleEventInputButton: "#input-multiple-events-button"
},
markupEventBindings: {
Copy link
Member

Choose a reason for hiding this comment

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

Also supply a test which shows that these handlers can be overridden cleanly

Copy link
Author

Choose a reason for hiding this comment

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

Added a test where 1) Some are left as is, 2) some are overridden, and 3) some new one is introduced.

markupEventBindings: {
inputButton: {
method: "click",
args: ["{that}.handleInputClick"]
Copy link
Member

Choose a reason for hiding this comment

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

Supply further tests to validate the primitive kinds of "compact" IoC syntax we support which allows for args

Copy link
Author

Choose a reason for hiding this comment

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

Thanks for this tip, I didn't know this was possibly actually, and will simplify my usage in the capture tool, PPT, and elsewhere

@gpii-bot
Copy link

gpii-bot commented Apr 2, 2020

CI job failed: https://ci.gpii.net/job/gpii-binder-tests/11/

- Adding ability to pass an array of handlers to eventMarkupBindings
- Adding unit tests for overriding bindings in sub grades
- Adding unit tests for compact IoC invocation
- Grammar and jsdoc fixes
@sgithens
Copy link
Author

sgithens commented Apr 2, 2020

@amb26 @the-t-in-rtf I believe this should be ready for another round of review now

@gpii-bot
Copy link

gpii-bot commented Apr 2, 2020

CI job failed: https://ci.gpii.net/job/gpii-binder-tests/12/

@the-t-in-rtf
Copy link
Collaborator

The build failed because the VM couldn't be created:

+ vagrant up --provider virtualbox
The provider 'virtualbox' that was requested to back the machine
'windows10' is reporting that it isn't usable on this system. The
reason is shown below:

Vagrant has detected that you have a version of VirtualBox installed
that is not supported by this version of Vagrant. Please install one of
the supported versions listed below to use Vagrant:

4.0, 4.1, 4.2, 4.3, 5.0, 5.1, 5.2

OK to test again.

@gpii-bot
Copy link

gpii-bot commented Apr 3, 2020

CI job failed: https://ci.gpii.net/job/gpii-binder-tests/13/

@the-t-in-rtf
Copy link
Collaborator

Vagrant timeout this go around. Ok to test again, if it fails a third time we should rope in Alfredo to assist.

@gpii-bot
Copy link

gpii-bot commented Apr 6, 2020

CI job failed: https://ci.gpii.net/job/gpii-binder-tests/14/

@the-t-in-rtf
Copy link
Collaborator

==> windows10: ok 13 Firefox 73.0 - [734 ms] - Binder Tests: /tests/static/tests-binder-commonEventBindingsOverride.html
Build was aborted
Aborted by unknown
/opt/vagrant/embedded/gems/2.2.7/gems/winrm-2.3.4/lib/winrm/http/response_handler.rb:59:in `raise_if_auth_error': WinRM::WinRMAuthorizationError (WinRM::WinRMAuthorizationError)
	from /opt/vagrant/embedded/gems/2.2.7/gems/winrm-2.3.4/lib/winrm/http/response_handler.rb:51:in `raise_if_error'

Looks like the build was killed after timing out, I suspect issues with testem. I am testing locally at the moment and will advise shortly on how to proceed.

@the-t-in-rtf
Copy link
Collaborator

OK, there are two problems:

  1. You need to merge with upstream master to pick up the fix for the Firefox hang issues described in GPII-4145.
  2. Since upstream master now uses a potentia-ii version of Infusion, you'll need to update your dependencies in the new test fixtures to use the same infusion-all rollup that the rest of the tests use. Otherwise you're missing the now-required promises API.

With those two fixes your tests pass in Vagrant locally.

@sgithens
Copy link
Author

sgithens commented Apr 7, 2020

@the-t-in-rtf Thanks for the sluething, try these updates now.

@gpii-bot
Copy link

gpii-bot commented Apr 7, 2020

CI job passed: https://ci.gpii.net/job/gpii-binder-tests/15/

@sgithens
Copy link
Author

sgithens commented Apr 7, 2020

@the-t-in-rtf Yes! It passed

@gpii-bot
Copy link

CI job failed: https://ci.gpii.net/job/gpii-binder-tests/16/

@sgithens
Copy link
Author

Looks like a timeout...

ok to test

@gpii-bot
Copy link

CI job passed: https://ci.gpii.net/job/gpii-binder-tests/17/

@sgithens
Copy link
Author

@the-t-in-rtf Ok, this is passed, and I think ready for another review now.

*/
fluid.defaults("gpii.binder.bindMarkupEvents", {
mergePolicy: {
decorators: "noexpand"
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why is this "decorators"?

Copy link
Collaborator

Choose a reason for hiding this comment

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

In other words, is there a pattern we're emulating? Just curious.

onMarkupRendered: null
},
listeners: {
onMarkupRendered: "{that}.events.onDomBind.fire({that}, {that}.container)",
Copy link
Collaborator

Choose a reason for hiding this comment

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

These should all be namespaced. I'd also suggest using the "long form" to this shorter notation. That way someone can at least opt out of part of the contract in a derived grade by changing the "funcName" to fluid.identity or the like.

if (node.length > 0) {
var name = "Decorator for DOM node with selector " + key + " for component " + fluid.dumpThat(that);
// val can be an array to support multiple event handlers
var handlerDecs = fluid.isArrayable(val) ? val : [val];
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why not just use fluid.makeArray here?

}
},
listeners: {
"onCreate.markupEventBindings": "{that}.events.onMarkupRendered.fire()"
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is the kind of thing I'd also write out, what if someone needs to do other work before firing the event? I guess they can just rewrite the whole string.

}
});

gpii.tests.binder.commonEventBindings.environment();
Copy link
Collaborator

Choose a reason for hiding this comment

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

I guess it matters less on the browser side (I think?), but for consistency with the rest of the package, this should use fluid.test.runTests instead of calling the environment directly.

}
});

gpii.tests.binder.commonEventBindingsOverride.environment();
Copy link
Collaborator

Choose a reason for hiding this comment

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

We should either consistently use fluid.test.runTests or consistently not use it.

Copy link
Member

Choose a reason for hiding this comment

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

+1 since without runTests there is no teardown

<script type="text/javascript" src="../../src/js/common-event-bindings.js"></script>
</head>
<body>
<h1 id="qunit-header">"Common Event Bindings" Component Tests</h1>
Copy link
Collaborator

Choose a reason for hiding this comment

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

Please update the page and header title to distinguish this from the other tests.

<!-- Test HTML, we have to hide this ourselves. QUnit's styles put it offscreen, which doesn't work for us. -->
<div class="viewport-common-event-bindings" style="display:none">
<form>
<h3>Common Event Bindings...</h3>
Copy link
Collaborator

Choose a reason for hiding this comment

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

I know it's mostly harmless, but for any human trying to troubleshoot the test, this should also be different than the other comment event bindings tests.

@jobara jobara changed the base branch from master to main October 22, 2020 13:58
@CLAassistant
Copy link

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants