Skip to content

set defaults #181#183

Merged
hueniverse merged 2 commits intohapijs:masterfrom
stephen-bartell:181
Mar 10, 2014
Merged

set defaults #181#183
hueniverse merged 2 commits intohapijs:masterfrom
stephen-bartell:181

Conversation

@stephen-bartell
Copy link
Contributor

possible solution for setting defaults

@stephen-bartell
Copy link
Contributor Author

this PR fails with the schema:

var schema = { one: Joi.number().default(1).options({ modify: true }) };

in the finish fn, the parent gets overridden to undefined:

    var finish = function () {

        // Apply mutators as long as there are no errors

        for (var m = 0, ml = self._mutators.length; m < ml && !errors.length; ++m) {
            var err = self._mutators[m](value, state, options);
            if (err) {
                errors.push(err);
            }
        }

        if (!errors.length &&
            state.parent &&
            options.modify) {

            state.parent[state.key] = value; // <---- here's where the override happens.
        }

        // Return null or errors

        return errors.length ? errors : null;
    };

it might make more sense to not do this in a mutator, but instead do it like convert, by modifying the value. modifying value would also give it the chance to pass through the validation functions to catch the case where someone tries to set a default that violates the joi type:

var schema = { one: Joi.number().default('imastring!') };

@nvcexploder you mentioned doing this in .optional. Where it could be used like:

var schema = { one: Joi.number().optional({ default: 1 })

have you decided on which format to use? i like the idea of doing it in .optional more than in .default.

i'm pretty new to this codebase, trying to catch up fast, so any feedback on if what i'm doing makes any sense would be appreciated.

@nvcexploder
Copy link
Contributor

I like the value in .default also, it implicitly shows that it's not
available in 'required'

On Tue, Feb 25, 2014 at 4:16 PM, stephen-bartell
notifications@github.comwrote:

this PR fails with the schema:

var schema = { one: Joi.number().default(1).options({ modify: true }) };

in the finish fn, the parent gets overridden to undefined:

var finish = function () {

    // Apply mutators as long as there are no errors

    for (var m = 0, ml = self._mutators.length; m < ml && !errors.length; ++m) {
        var err = self._mutators[m](value, state, options);
        if (err) {
            errors.push(err);
        }
    }

    if (!errors.length &&
        state.parent &&
        options.modify) {

        state.parent[state.key] = value; // <---- here's where the override happens.
    }

    // Return null or errors

    return errors.length ? errors : null;
};

it might make more sense to not do this in a mutator, but instead do it
like convert, by modifying the value. modifying value would also give it
the chance to pass through the validation functions to catch the case where
someone tries to set a default that violates the joi type:

var schema = { one: Joi.number().default('imastring!') };

@nvcexploder https://github.com/nvcexploder you mentioned doing this in
.optional. Where it could be used like:

var schema = { one: Joi.number().optional({ default: 1 })

have you decided on which format to use? i like the idea of doing it in
.optional more than in .default.

i'm pretty new to this codebase, trying to catch up fast, so any feedback
on if what i'm doing makes any sense would be appreciated.


Reply to this email directly or view it on GitHubhttps://github.com//pull/183#issuecomment-36076114
.

@leore
Copy link

leore commented Mar 4, 2014

+1 for .default when is this going to be available in hapi

hueniverse pushed a commit that referenced this pull request Mar 10, 2014
@hueniverse hueniverse merged commit 81d5b88 into hapijs:master Mar 10, 2014
@hueniverse hueniverse added this to the 2.8.0 milestone Mar 10, 2014
@hueniverse hueniverse self-assigned this Mar 10, 2014
@lock
Copy link

lock bot commented Jan 9, 2020

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.

@lock lock bot locked as resolved and limited conversation to collaborators Jan 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

feature New functionality or improvement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants