Question

So I’m creating reusable UI components that can be easy instantiated later, eg:

this.emailInput = new TextInput() {
    label : 'Email Address',
    validators : [validatorFunc, secondValidatorFunc],
    placeholder : '[e-mail]'
});

Would it make sense for this View to create its own Model that would store a value on keydown and handle the validation? Would it still make sense if there were no validation?

And then more complicated, with an autocomplete:

this.countryInput = new AutocompleteInput() {
    label : 'Country',
    placeholder : 'eg. United States',
    suggestions [ 
        { id : '1', value : 'USA', text : 'United States' },
        { id : 2, value : 'DE', text : 'Germany' },
        ... 
    ]
});

Would it make sense for those suggestions to be stored in a Model of their own that is created by the View as well? Should I also store the selected suggestion in that Model?

It seems like without using a Model I’ve been replicating a lot of the logic the Model gives you automatically.

I’ve also been thinking about having each suggestion be it’s own View that creates its own Model, and have the suggestionListView know about the Collection. Is that how Collection/ListViews work? The ListView knows the Collection and the ItemView knows a Model?

Answer 1

The validators part of your TextInput view are definitely more appropriate for a model. Models in Backbone self-validate, so that buys you a lot. In your keydown scenario, the model would have a persistent value field that stores the current value of the input. You don’t have to explicitly validate against any new values on keydown, you can just directly try to set the model:

If the model has a validate method, it will be validated before the
attributes are set, no changes will occur if the validation fails, and
set will return false.
— Backbone docs

So just make sure to define your validate method appropriately.

Would it still make sense if there were no validation?

This is an interesting question, since your model/view situation isn’t really typical. What I mean is, it looks like you’re creating form fields for the purpose of creating form fields. If these fields are tied to actual models in your application (i.e., things that are stored in your persistence layer), then those models should be your Backbone models. Otherwise I’m assuming that you actually want a model that means “this is an input field.” But I would say no, probably it wouldn’t make much sense if you didn’t care about validation—because in that case you’re just responding to user events and doing whatever rendering you want, careless about what the actual data is.

To your second question: I don’t think it buys you much to put the suggestions into their own model. You’re not going to be setting them individually, you’re just retrieving them based on the value of another model.

To your last point: that is certainly how collections work, but again I don’t think it would buy you much. However, just to illustrate the point, it would look something like this: suggestions would be a collection of Suggestion models; collectionView would be the view that shows the models of suggestions, which would each be a suggestionView that renders a single suggestion. Again, this would be total overkill in this situation IMO. The only reason to do it would be if you actually care about each individual suggestion, i.e., if you want to respond to events on it, or for some reason save its data. I don’t think you do, though.