eta icon indicating copy to clipboard operation
eta copied to clipboard

ability to use variables directly without 'it'

Open dirslashls opened this issue 4 years ago • 11 comments

Is your feature request related to a problem? Please describe. I have a fixed set of variables that my users will use in creating their templates. Say, x and y. So, instead of having them to write the template using it.x and it.y, I am wondering if there is a way to directly use x and y as it would be natural to the end users.

Describe the solution you'd like Perhaps at the time of compiling a template a list of variables can be provided and those will be made available directly as arguments to the compiled function rather than via the it object. At the time of rendering, these will be unpacked and applied to the function perhaps including the existing it which passes all the data as is. So the template function might compile to

function(it,x,y) { ... } instead of function(it) { ... }

Describe alternatives you've considered At the moment, I am constrained to using it.x and it.y.

Additional context Using this template engine in a low code environment requires it to be as easy as possible for end users.

dirslashls avatar Mar 31 '21 22:03 dirslashls

@dirslashls This is possible by specifying useWith to true in the config which will bring everything into the global scope with with() {}

shadowtime2000 avatar Apr 05 '21 22:04 shadowtime2000

Thanks @shadowtime2000 . In my case the 'it' object is actually a proxy. That and the fact that with is a bad idea to start with makes me reluctant to use it.

dirslashls avatar Apr 06 '21 02:04 dirslashls

@dirslashls So what you are talking about would be powerful static analysis to detect which variables come out of nowhere and could be considered props on it. This is really out of scope of the project and wouldn't be that great because JS parsers written in JS aren't very fast then we would have to do also pretty slow static analysis and then we have to consider the bloat from building a parser ourselves and if we didn't build a parser ourselves it would violate our like rule of trying to stay dependency and bloat free. We could do an option where u have to give the variables that are added but that messes up the whole point because you want it to be dynamic. Lmk what you think

shadowtime2000 avatar Apr 06 '21 06:04 shadowtime2000

@shadowtime2000 , absolutely not suggesting to parse and identify all the unbound variables. That's why I mentioned "Perhaps at the time of compiling a template a list of variables can be provided" when I filed this issue. Templates are good for providing low code solutions where the set of variable names end user can use are fixed and so explicitly passing them at the compilation time is all that is needed.

dirslashls avatar Apr 06 '21 06:04 dirslashls

@dirslashls Sorry! I think I didn't notice it. Yeah we could do that. If you want you could open a PR for it or I will do it myself later.

shadowtime2000 avatar Apr 07 '21 00:04 shadowtime2000

Thanks @shadowtime2000 for your time and will look forward to a fix.

dirslashls avatar Apr 07 '21 22:04 dirslashls

Okay so I am working on this now (very late i know sorry), but it seems this would uh be a bit more difficult to implement and work with the current system because functions compile to have two more parameters after the it parameter and then there is a likelihood of conflicts which would probably mess templates up. @dirslashls thoughts?

shadowtime2000 avatar Jul 12 '21 06:07 shadowtime2000

@shadowtime2000 , thanks for starting to look at this.

Here is a proposal.

  1. At the time of compilation, the config should include a 'vars' parameter.
Eta.compile(template,{ ..., vars: ['x','y'] })

The list of vars provided should not be from reserved variables as listed at https://eta.js.org/docs/syntax/caveats

  1. This should compile from the current approach of
function(it,...) {
}

to either

function(it,...) {
   (function({ x, y} = it) {
   })()
}

or

function(it,...,{x,y}) {
}

and the rendering function will bind 'it' to the last parameter as well.

dirslashls avatar Jul 12 '21 07:07 dirslashls

Hey guys, found eta a few days ago. Was about mid-way switching to it before realizing you must use it to reference passed-in variables. I'm coming from ejs which has no such requirement and didn't personally want to add it. to all my templates everywhere I was previously referencing a variable. If I could reference variables directly, as dirslashls pointed out, I'd switch to eta as I'd no longer have a reason not to. Either way, cheers.

AlanMorel avatar Aug 06 '21 01:08 AlanMorel

Hey guys, found eta a few days ago. Was about mid-way switching to it before realizing you must use it to reference passed-in variables. I'm coming from ejs which has no such requirement and didn't personally want to add it. to all my templates everywhere I was previously referencing a variable. If I could reference variables directly, as dirslashls pointed out, I'd switch to eta as I'd no longer have a reason not to. Either way, cheers.

@AlanMorel you can do that with useWith https://github.com/eta-dev/eta/issues/101#issuecomment-813694698

LeanKhan avatar Jan 28 '22 17:01 LeanKhan

Hey guys, found eta a few days ago. Was about mid-way switching to it before realizing you must use it to reference passed-in variables. I'm coming from ejs which has no such requirement and didn't personally want to add it. to all my templates everywhere I was previously referencing a variable. If I could reference variables directly, as dirslashls pointed out, I'd switch to eta as I'd no longer have a reason not to. Either way, cheers.

@AlanMorel you can do that with useWith #101 (comment)

You are correct! I must have taken the on-going thread as a sign that this was a feature being debated, not already available. Thank you!

AlanMorel avatar Jan 28 '22 17:01 AlanMorel

This is now possible using the functionHeader configuration option, or by using plugins :)

bgub avatar Jun 13 '23 20:06 bgub