Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[REF] Pull out anonymous javascript function to make it testable #15378

Merged
merged 1 commit into from
Oct 5, 2019

Conversation

demeritcowboy
Copy link
Contributor

Overview

I want to write a test for this function but can't because it's anonymous and it's part of an ajax event handler but that doesn't work with the jasmine/karma tests.

Technical Details

There's a tradeoff with making any private function public, but I don't think this was written originally with hiding variables/functions in mind, just that the "standard" way to write event handlers is with anonymous functions. It just makes them hard to test if they do stuff that would be nice to unit test on their own.

@civibot
Copy link

civibot bot commented Oct 3, 2019

(Standard links)

@civibot civibot bot added the master label Oct 3, 2019
@colemanw
Copy link
Member

colemanw commented Oct 4, 2019

I'm happy with this change but I think it could be further improved by separating the business-logic-y part of the function from the ajax-y part of the function. What about leaving it as an anonymous function and keeping the stuff like var newType = _.values(data.relationshipType)[0]; and scope.digest() inside that anonymous function but break out the business logic into a separate function that takes newType as a param.

@demeritcowboy demeritcowboy force-pushed the deanonymize-on-the-fly branch from ccc6bd7 to cdd01a3 Compare October 4, 2019 14:51
@demeritcowboy demeritcowboy changed the title [NFC] Pull out anonymous javascript function to make it testable [REF] Pull out anonymous javascript function to make it testable Oct 4, 2019
@demeritcowboy
Copy link
Contributor Author

That makes sense.
I'm not an angular expert but I think that separation from the $scope.$digest would then require one slight change. By making this separation, the caller of the new function can no longer make assumptions about what the called function is doing. So either I should keep the $scope.$digest in the new function where it knows what it just did, or the caller needs to call $scope.$apply to make sure it catches everything the called function might do, which might include changes outside the current scope - it doesn't currently but if decoupled then it can't assume that. I've gone with the latter.

@colemanw
Copy link
Member

colemanw commented Oct 5, 2019

Yea that's even better.

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

Successfully merging this pull request may close these issues.

2 participants