Nested View.ui

[Leestex]

Add an ability to create and use nested "ui" storage.

Defining:

ui: {
    buttons: {
        submit: '.container input[type=submit]',
        reset: '.aligned button.reset'
    },
    fields: {
        title: 'input.title'
    }
}

Usage:

events: {
    'click @ui.buttons.submit': 'submitForm',
    'click @ui.buttons.reset': 'resetForm',
    'focus @ui.fields.title' : 'loadData'
}

[samccone]

Not sure how I feel about encouraging deeply nested objects in the UI hash. On one side I enjoy how declarative this is, and how it adds structure to the ui hash. However on the flipside If you need so many UI elements it might be a sign that your view is too large and has too many concerns.

On the fence not sure yet, but thanks for the interesting idea @Leestex

[paulovieira]

I agree. I think it would be one those nice-to-have features that I wouldn't recommend using. Marionette objects should encourage simplicity.

Anyway, this feature would essentially be a namespace for the ui entries. Then maybe it is possible to accomplish/emulate it with flat objects, using a dot in the key? Something like:

ui: {
    'buttons.submit' : '.container input[type=submit]',
    'buttons.reset' : '.aligned button.reset',
    'fields.title' : 'input.title'
}

Would this still work?

[jamesplease]

Interesting idea @Leestex! I'm with @samccone in that my views are usually so small that this seems like unnecessary organization. With that said I don't build complex forms or anything, which is where I can envision the ui hash growing quite large.

@paulovieira, your approach is also really neat! I like how succinct it is, yet at the same time it adds more string-magic to the library, which is a negative, I think. I'm not sure which of the two approaches I like better at the moment.

Also, on whether or not I think we should add it...I'm also with @samccone and not quite sure :)

[jamiebuilds]

@paulovieira that would lead to:

this.ui['buttons.submit'].on('click', ...);

[jamesplease]

@thejameskyle I think his idea is to do string-magic on it, like we do with modules.

'buttons.submit' would be ~~magically~~~* parsed into this.ui.buttons.submit

[jamiebuilds]

Oh I thought it was a suggestion for what you can do right now

[jamesplease]

ohhh you know what, I think I misinterpreted him. I think you're right.

[samccone]

Angular has this in $scope.$eval :)

[Leestex]

@paulovieira your example will not work, as regexp used to parse those values doesn't include a dot.

[Leestex]

I made some changes here https://github.com/Leestex/backbone.marionette/pull/1/files But it breaks unit tests. It works for me on 1.8.6

[Anachron]

I've made some thoughts about this.

• The UI declaration seems more organized
• It will add extra 'magic', which the user needs to understand
• It shouldn't be a breaking change
• I can see problems in bigger projects when dealing with unknown modules that this seems harder to get into
• It's still working with old syntax
• With time, users could actually get used to this and improve it

For now I don't think it's good enough. I suggest putting it on the V2 waiting list and encourage users to take part in the discussion.

[jamesplease]

I think this would be introduced in v3 at the earliest. v2 is already quite large, and I'm afraid if we keep putting things into v2 it will never be released :)

[jamiebuilds]

Thought about this a little more, and I think that we should pass on this.

The only use case I can see is a really long form, in which case a single view for it would get unnecessarily complicated and one should probably abstract the complicated functionality in other ways.

For example:

• I want to serialize my really long form => abstract it into a form serializer like Backbone.Syphon
• I want to add dynamic sections to my form => break the dynamic sections into separate views, and add some kind of controller
• I want to add data binding to my form => abstract it into a data-binding lib/plugin like stickit or modelbinder

Other cases: https://github.com/powmedia/backbone-forms

I think in terms of most UIs, if its getting so complex you need a nested ui hash, you're probably doing too much in one view that you should be breaking into multiple.

[samccone]

Closing for now, open to further discussion.

[gabrielbull]

:+1: For allowing nested ui elements.

If you need so many UI elements it might be a sign that your view is too large and has too many concerns.

In some cases the view has to have some complexity to it and this helps organize it.

[gabrielbull]

Here's a commit with the change: https://github.com/gabrielbull/backbone.marionette/commit/d356936b3e568af4997fd045c6657920e7cab30d

[jamiebuilds]

@gabrielbull Do you have a use case outside of the stuff I listed previously?

• I want to serialize my really long form => abstract it into a form serializer like Backbone.Syphon
• I want to add dynamic sections to my form => break the dynamic sections into separate views, and add some kind of controller
• I want to add data binding to my form => abstract it into a data-binding lib/plugin like stickit or modelbinder

[gabrielbull]

Besides better organisation, no, sorry, I don't have a better example.

[jamiebuilds]

@gabrielbull I don't think we should add complexity to the ui hash to support overloading it when there are better existing solutions. @marionettejs/marionette-core thoughts?

[samccone]

I am still -1 for my initially stated reasons

[Anachron]

Me too.