`index.html` or `base.html` for fallback component template

[joshuadavidthomas]

While thinking through #29, another thought occurred to me about the 'fallback' template for a component.

Right now, it's index.html. I chose this initially because I was in a React component headspace trying to translate that to Django templates. Over in the land of Sauron, you (or at least I) generally have an index.{js,ts} file in a component's folder that exports the public, usable interface for a component.

However, the common convention for Django templates would actaully lean towards base.html being the ultimate fallback for a template directory. And since we aren't actually 'exporting' behavior, I wonder if using the ecosystem's convention would be a better fit for a Django component library?

Also, a side-thought - is this behavior even needed? I would vote tentatively yes, as I like the idea of having a fallback template for a component in it's directory, but I'm struggling at the moment to come up with a specific use-case. Clearly I had one in mind when I wrote this logic in, but I didn't write anything down. There should be an example use-case to go along with this behavior -- and if one can't be conjured up from the dark recesses of my mind, then maybe this should be removed?

[joshuadavidthomas]

Okay, it's slowly coming back to me -- maybe it wasn't a specific use-case, but more an organizational thing.

To me, if I have an accordion component with multiple small, related components (e.g. the main accordion, heading, content, etc.) -- I would want to put them in their own directory. So templates/bird/accordion/. Then the sub-components name would be a file within that directory, so:

• accordion/heading.html
• accordion/content.html

Except what to do about the main accordion component? These are all options currently:

• accordion/accordion.html
• accordion/index.html
• accordion.html

The last option is what you would do in django-cotton, separating the main component template from the parts that make it up, and is one thing that doesn't sit well with me with that library. (Note: not a criticism, just a personal preference!)

But, then if you put it sub-directory you end up with accordion/accordion.html, which leads to inconsistencies when using the component. For the subcomponents, the API looks like:

{% bird accordion.heading %}

And that corresponds to the actual structure of the component directory, with the divider switching from / to .. But, accordion/accordion.html would be used like this:

{% bird accordion %}

Here, the component name doesn't actually map to the structure and the inconsistency bothers me in some small way.

So then, my initial thought was using the behavior mentioned in the issue up top, with the index.html 'fallback' template (though it's not really a fallback is it?). In addition to the React example, there's also the standard web server behavior, where a index.html file in a directory can be visited without the filename in the URL (https://github.com/ instead of https://github.com/index.html, for example).

[joshuadavidthomas]

Maybe all that is needed is some specific documentation, perhaps a dedicated section, about template resolution and this design decision.