Allow methods to be nested

[JosephSilber]

I think it would make sense to allow methods to be nested under sub-objects:

new Vue({
    methods: {
        group: {
            foo() {
                // `this` should be the vm
            },
            bar() {
                // `this` should be the vm
            },
        }
    }
});

[vprimachenko]

yeah this kind of namespace-ing would be really beneficial and result in cleaner code. Example from a personal project:

At the moment all UI describing variables live in

Vue({
   data: {
      ui: {
        …
      }
   }
})

yet UI manipulator just live in methods and are prefixed ui_ which makes, imo, some ,in fact consistent, yet typo prone code e.g.

if(this.ui.foo) {
   this.ui_bar();
   this.ui.baz++;
}

[yyx990803]

I don't see the point other than style preferences. What makes it different from, say uiFoo() and uiBar()? If these methods on are invoked on the instance then they shouldn't be nested.

[JosephSilber]

They are mainly for style preference, yes. But I do have a another use case for it. It's very convenient to pass a group of methods to a child component.

In Vue 0.12, I had a validation component used to show server-side validation errors. It used a component in conjunction with a mixin. Here's a watered-down version of it:

Component:

Vue.component('validation', {
    template: `
        <div>
            <content></content>
            <span class="error"
                  v-show="isInvalid(property)"
                  v-text="getValidationError(property)"
            ></span>
        </div>
    `,
    inherit: true,
    props: [
        { name: 'property', type: String, required: true },
    ],
});

Mixin:

{
    data() {
        return { serverValidation: {} }
    },
    methods: {
        isInvalid(property) {
            if (_.hasOwn(this.serverValidation, property)) return true;
        },
        isValid(property) {
            return ! this.isInvalid(property);
        },
        getValidationError(property) {
            if (this.isValid(property)) return null;

            return this.serverValidation[property][0];
        },
        catchValidation({ data }) {
            this.serverValidation = data.validationErrors || {};
        }
    }
};

Page:

Vue.component('some-page-view-component', {
    template: `
        <validation property="name">
            <input type="text" v-model="name" v-class="error: isInvalid('name')">
        </validation>
    `,
    mixins: [validation],
    data() {
        return { name: '' };
    },
    methods: {
        save() {
            attemptToSaveStuff(...)
                .then(() => router.go('/someplace'))
                .catch(this.catchValidation.bind(this));
        }
    }
});

In short, I have a component and a mixin that work hand in hand. Since Vue 0.12 supported inherit, the component was able to utilize the validation methods directly from the parent component.

Fast forward to 1.0, and inherit is no more. I'll now have to pass all those methods down directly into the child component. Passing them all separately (for each input field) would severely clutter up the template, so I thought grouping them all in a single object and only passing that in would make more sense.

---

I might be approaching this all wrong, and I'll be happy to hear of an alternate solution. Regardless, I still think allowing methods to be grouped is a good idea. I like nesting and shorter method names 😄

[yyx990803]

I still hold the opinion that nested methods are more confusing than useful. The preferred way of connecting a child and a parent method is now doing so via v-on. If the parent and child are so tightly coupled that you are using inherit: true, then it is effectively the same as directly calling $parent.method().

[baberuth22]

Nested methods would be useful in giving mixin methods their own namespace.

[Glidias]

If you are not re-setting data objects as plain Json which will kill off their prototypes, you could create instantiated class based objects with root/nested object methods since prototypes methods/getters/setters are not proxied by Vue, but still accessible via the $data (or nested data objects) itself. Only problem is you don't get computed caching unless you manually import those nested getters into an optionally namespaced flat vue computed/methods structure in order to manually proxy into them . I have a custom haxevx compile-time macro that does this , but haxevx isn't vanilla Vue (and then again, this will not provide object-oriented dot access to re-rout through the root Vue instance anyway).

Nested accessors for Vue typically would have to exist in nested Vue components or Vuex modules rather than Object-oriented nested accessors, else set up flattened "object__propertyName" proxy access to them. However, I think using non computed nested access of object methods isn't much of a problem for this case though, as long as you don't reset yr data as plain json and you don't need caching.

[floriansimon1]

Agree with @baberuth22, and thanks for your input @Glidias: it would be cool to be able to do vm.validation.validateEmail(email), because it allows you to find quickly where a method comes from (in this case, I know I should be searching for the definition of the method inside a Validation mixin), which is more than just style preferences IMO.

[jasonlfunk]

I'd also like to advocate that this be implemented. Using objects to namespace and group functions is much more convenient than prefixing. Not only is it cleaner, but it also allows for IDEs to fold the methods as well.

As a workaround for now, this can be accomplished by using functions instead of objects:

methods: {
    validation() {
            return {
                isEmail(email) {
                },
                isBlank(str) {
                },
                isUnique(arr) {
                },
            }
        }
}

And then these can be used like validation().isEmail(addr). Not perfect, but it still gives the organizational benefits.

@yyx990803 It's been a couple years, has your opinion changed at all?

[Glidias]

If you adopt that approach, you should not put validation() under methods:, but place it under computed: and simply use validation, without the function brackets, in order to get computed caching
to avoid re-creating the object again (in fact, I tend to use computed for pseudo singletons/single-global refs/utility-classes/objects, etc. as well). That way, you get the perfect solution. The same approach is done with CSS modules as well. However, i'd assume these methods are stateless methods or stateful (but not-reactive) methods whose states data lie outside the Vue.

[jasonlfunk]

Validation was simply an example use-case which may or may not always make sense to use it as a computed property. It doesn't negate the original uses for nested methods.