davidjamesstone / superviews.js

Template engine targeting incremental-dom
http://davidjamesstone.github.io/superviews.js/playground/
246 stars 15 forks source link

add a global config #11

Open paulovieira opened 8 years ago

paulovieira commented 8 years ago

It makes sense to be able to set some global options. Two concrete examples that I encountered:

1) arguments for the compiled idom render function

If the user prefers to use ctx as argument (for instance) instead of the default data, it is necessary to wrap the superviews template with <template>:

<template args="ctx">
    <div>
        hello {ctx.name}!
    </div>
</template>

If this was a config option, the user could simply do:

    <div>
        hello {ctx.name}!
    </div>

2) Function prefix for the incremental dom calls

Currently superviews is calling the idom functions directly:

elementOpen("div");
elementClose("div");

If the user is including incremental dom via a browser script, it is easier to reference the functions from the "IncrementalDOM" object that is exposed globally

IncrementalDOM === window.IncrementalDOM; // true
IncrementalDOM.elementOpen("div");
IncrementalDOM.elementClose("div");
davidjamesstone commented 8 years ago

Hi Paul

Your first point is already available, although a global config could be a better way of doing it.

The superviews function takes 3 arguments. The template string is the first option. The second and third control the function name and arguments. This provides an alternative to using a template element.

These 2 options are available using the cli too.

I like the idea of the 2nd point, I use the superviewify browserify transform so I don't really get affected but I see how it could be useful nd I'll look into it.

Cheers

Dave

paulovieira commented 8 years ago

The superviews function takes 3 arguments. The template string is the first option. The second and third control the function name and arguments.

Yes, I had noticed the signature. However I see that more like a way to override some general configuration. That is, at the beginning the user would be able to set the default argument string and wouldn't have to care about it anymore. Then, if for some particular template there's a need for other arguments, it could be done directly in the call to superviews

I use the superviewify browserify transform so I don't really get affected

I'm curious: so how does the compiled idom template finds the incremental dom function? How do you inject elementOpen et al into the template's scope?

davidjamesstone commented 8 years ago

I'm curious: so how does the compiled idom template finds the incremental dom function? How do you inject elementOpen et al into the template's scope?

It gets injected by the transform.

Browserify then bundles is like this

Have a look here to see some examples.

At the beginning the user would be able to set the default argument string and wouldn't have to care about it anymore.

This would be nice

Then, if for some particular template there's a need for other arguments.

More often than not, I find this is the case.

Again see this project, it's how I have been using superviewify and structuring code using browserify. I'm still working out some things about where controller, models and such like live but it's working ok so far.