Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add a global config #11

Open
paulovieira opened this issue Apr 19, 2016 · 3 comments
Open

add a global config #11

paulovieira opened this issue Apr 19, 2016 · 3 comments

Comments

@paulovieira
Copy link

paulovieira commented Apr 19, 2016

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>
  1. 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
Copy link
Owner

davidjamesstone commented Apr 19, 2016

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
Copy link
Author

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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants