Open paulovieira opened 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
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?
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.
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 defaultdata
, it is necessary to wrap the superviews template with<template>
:If this was a config option, the user could simply do:
2) Function prefix for the incremental dom calls
Currently superviews is calling the idom functions directly:
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