If using subviews hash, do we need registerSubview or renderSubview?

[Zearin]

The subviews documentation is pretty thin compared to most of Ampersand. I’m interesting in using the subviews hash to write my subviews declaratively, but I’m having trouble getting it to work.

• In particular, do subviews in the subviews hash get auto-registered?
• In render(), do I call this.renderSubview?
• How would I do something like subview.collection.on('add', function() {…})? (In other words, if I want to attach the listener inside the parent view’s initialize, how do I refer to the subview I want from the hash?)

[wraithgar]

Yes, the views in the subviews has get auto-registered, so you do not need to later call renderSubview. renderSubview is for manually rendering another subview later, after initialization.

[wraithgar]

As far as the last question, I think they get named according to their key in the subviews hash. I'd have to test this, and you may be in a better position to verify this if you have code you're using right now.

[Zearin]

Alright, so if I understand correctly: I don’t need registerSubview, or renderSubview if I’m using the subviews: … hash. Is that right?

• What about referring to subviews in the has from the parent view?
• I recently just tried switching some of my code from a manual renderSubview() and renderSubview() to use the subviews hash instead. But…it’s not rendering. :-( How do I figure out what’s wrong?

[Zearin]

(Oops—just noticed your second reply. I’ll see what I can do, but FYI I’m not super confident in my abilities here.)

[Zearin]

(I know people have strong opinions about CoffeeScript. If you happen to hate it, please stay your judgement upon me for now. Thanks!)

Okay. So here’s a snippet of my code:

SemestersFormView = View.extend({
    autoRender: true
    template:   TEMPLATES.SemestersFormView
    events:
        'click [data-hook=add]': -> @collection.add new Semester()

    subviews:
        unassigned:
            hook:    'unassigned-courses-container'
            prepareView: (el) ->
                return new COURSEVIEWS.CoursesListView(
                    collection:         @_updateCourses(),
                    parent:             @,
                    dragDropController: @dragDropController,
                    viewOptions:
                        filter: (c) -> c.taken is false
                )
    # ... rest of the class definition
})

Then, I can refer to the subview using @unassigned (or this.unassigned). However:

• I see this as posing a high risk for name collisions. It’s not hard for me to imagine a project where a programmer would want the a subview’s name to match another name, because they are related. If I were to do this in the above code, for example, I would declare this.unassigned to be a collection, and use this.subviews.unassigned as the subview for that collection. Currently, this is impossible, because all the keys under subviews are just copied in.
• I did not see the subview above automatically render. In my code, I had to add @renderSubview(@unassigned, @queryByHook 'unassigned-courses-container') inside of render() for the subview to appear. Is this a bug? Or am I doing something wrong?

[wraithgar]

Yes the name collision problem is there, perhaps a discussion issue is in order since that exists for a lot of other things, including reserved words.

[Zearin]

@wraithgar Glad to hear it. I look forward to the discussion!

[bernharduw]

To avoid naming collisions, I am using ...View as a suffix for subviews as a convention. So it is unassignedView, which is then accessible as view.unassignedView.collection.whatever.

[Zearin]

To avoid naming collisions, I am using ...View as a suffix for subviews as a convention. So it is unassignedView, which is then accessible as view.unassignedView.collection.whatever.

Yeah, that could work. But I would still prefer to access all subviews through an attribute, if it is possible to do this in a future release.

In the meantime, if naming conventions are the official route that AmpersandJS is going on this issue, then it should probably be documented in the View conventions.

[bernharduw]

#96 is related - throwing an error is a gold improvement.