[Enhancement] Declarative way to instantiate views

[grabcode]

Ever wanted a shortcut to instantiate your views directly via writing a sort of custom HTML tag into your template ? Well I gave it a shot and I'd love to get your thought. I can pretty easily create a PR though I believe it would deserve a bit of review (and test coverage).

Marionette.Viewtag

Please throw whatever comes in your mind. Would you think it is a convenient alternative way in some instances ? Would you be concerned by some compatibility issues ? Would you say there might be some performance concerns ? [...]

[JSteunou]

It looks cool for those who need this.

Now, just my 2 cents, I'm a guy who dislike declarative à là angular stuff inside HTML. I Better like readable, tweakable, maintainable code inside view.

[capricube]

:+1: really cool. this might be useful. Especially when providing UI components to other developers .

[grabcode]

@capricube @JSteunou, thanks for your comments.

@JSteunou I must say in the defence of a declarative approach that it is supposedly more readable. Of course, bringing this alternative way would leave more flexibility to the framework's users, but at the end nothing prevents you to adopt a guideline in your project that would exclusively use one way or another.

I merely intend to address a pattern I may have used many times into my Marionette project since I try to split my templates into granular components I reuse pretty much always the same time and a behaviour wouldn't exactly bring much visibility to my code.

At the end of day, I strongly think it is matter of taste as you've suggested.

[jeffijoe]

@grabcode this looks pretty sweet, actually been wanting something like this for awhile. It seems like you're locked into _.template though? I'm all about that Jade, so can't use it I suppose?

@JSteunou Regarding the whole "declarative or not" things, here's my 2 cents; when it comes to reusable components, like <address-selector>, <markdown-editor>, declarative just feels right for me. But stuff like ContentView, SidebarView, ToolbarView make sense as plain subviews, because you're probably only using that in 1 place.

[grabcode]

@jeffijoe I'm confident that should work with your current projects involving Jade for templating. Your Jade files eventually get converted into html by your asset pipelines.

To summarise, I think your templates go from JADE to HTML to JAVASCRIPT. I might be wrong in the unlikely case where your _.template has been enhanced to interpret raw Jade file (that would be weird!).

Guideline

And I completely embrace your declarative or not guideline, though I really wanted to give the developer access to the full Marionette view options.

I believe Backbone/Marionette provides little opinion, hence the coder is given full power/responsibility. After all, even within the strongly opinionated Angular you can end up with a messy codebase if you don't follow internal (project/company scoped) guidelines.

Note

Fyi, technically, this extension works in 2 steps:

• first it interprets component (tags with "cp-"), and plugs a javascript function in charge of bridging the declarative piece of informations to Marionette
• secondly, the bridging function get executed whenever your template is executed, and creates then the corresponding Marionette.XXXView passing through the right parameters.

[jmcgdz]

I've recently been using polymer web components with marionette, it actually works great together.

You can pass data in via attributes, an 'id' or a full model (the JSON) or you can interact with the element directly, like using the ui hash.

[grabcode]

@jmcgdz that's a superbe idea to melt this 2 together. I came across some blog posts explaining how to marry this 2 together.

Now there's some cons. Polymer turned 1 (v1, not year 1) just few weeks ago. And Polymer has a cost in term of weight, and learning curve. Of course the benefits in term of functionalities might outweigh the steep learning curve, but in my company it would be yet another rather thick layer to pass through prior contributing.

And ultimately the 2 solutions could live side by side (or not?). I won't recommend that though!

[jeffijoe]

@grabcode my Jade is being preprocessed and all I am left with are compiled JS functions when the page loads.

[ianmstew]

@marionettejs/marionette-core Thoughts on promoting this to MarionetteLabs?

[samccone]

reminds me of https://github.com/samccone/marionette-behaviors#autoregion :goat:

[samccone]

:+1: on moving into labs

[ianmstew]

@grabcode We're interested is moving this to official community-supported/experimental status as a MarionetteLabs repo. Are you interested in transferring ownership to MarionetteLabs? You will be repo admin.

[grabcode]

@ianmstew yes I am. Thanks. Could you send the instructions?

[ianmstew]

Sure thing, sorry for the delay. Your repo -> Settings -> Transfer ownership -> New owner: MarionetteLabs -> Team: viewtag. I have already invited you to the viewtag team. Once your repo is in, I will supply admin access to viewtag to the viewtag team. Welcome to MarionetteLabs!

Just a heads up, I just transferred a potentially related project over to MarionetteLabs as well, handlebars-idom. I can see an intersection of the two when it comes to parsing out Components in a couple ways:

1. It would be nice if handlebars-idom could be used alongside Components, but I'm not sure how yet.
2. You could possibly use a DOM parser->AST approach for finding Components similarly to how handlebars-idom is starting with the DOM-aware HTMLBars AST.