-
-
Notifications
You must be signed in to change notification settings - Fork 57
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
Fix for #142 #143
Fix for #142 #143
Conversation
@shadyvd thank you for fixing this! Could you add a test that asserts the behavior? By adding the failing test, applying your fix should ensure it passes and make it safe for us to further improve the logic in the future. |
@@ -7,7 +7,7 @@ function capitalize(key) { | |||
|
|||
let defaults = {}; | |||
['separator', 'prepend', 'replace'].forEach(function (key) { | |||
if (config.pageTitle && config.pageTitle[key]) { | |||
if (config.pageTitle && (config.pageTitle[key] !== null) && (config.pageTitle[key] !== undefined)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NOTE: Adding safety checks is a great idea. I wonder if we can make this logic clearer using a more functional programming style:
let defaults = {};
let {pageTitle = {}} = config;
['separator', 'prepend', 'replace']
.filter(key => {
return key in pageTitle && pageTitle[key];
})
.forEach(function (key) {
defaults[`default${capitalize(key)}`] = pageTitle[key];
});
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if a functional programming style makes it clearer, actually. How about if we go to ember utils, and use isPresent, instead?
Do you think
if(config.pageTitle && isPresent(config.pageTitle[key]))...
is clearer?
@shadyvd can you add tests that assert the conditionals introduced here? Thanks 🚀 |
Given that the config is an import, how would you even write a test to use varying configs? Shouldn't this code be done in the init of the service? Anyone that would want to extend this service would completely lose the config default code. You could also use either of the following If needed I can put together a PR taking this approach if you would like? |
@cah-briangantzler sounds good to me. |
My apologies for dropping the ball on this. I'll try and get the tests done using the approach suggested by @cah-briangantzler in the next two or three days. |
Seems I must have missed the sounds good and never did a PR either. Sorry. Currently time is a little short. |
Resolved in #168 |
Explicit check for not-null and not-undefined when setting the default values from the configuration.
The current code will not set defaultPrepend / defaultReplace to "false" because the check will fail. The Pr fixes #142