Skip to content

Instantly share code, notes, and snippets.

@xeioex
Created February 13, 2026 21:43
Show Gist options
  • Select an option

  • Save xeioex/db54d541189371bccdeb5492aa587d72 to your computer and use it in GitHub Desktop.

Select an option

Save xeioex/db54d541189371bccdeb5492aa587d72 to your computer and use it in GitHub Desktop.

js_set Inline Syntax: Comparison of Approaches

1. $var Shorthand vs No Shorthand

$var shorthand No shorthand
Syntax '$uri.toUpperCase()' 'r.uri.toUpperCase()'
Expands to r.variables.uri.toUpperCase() used as-is
nginx-idiomatic Yes — familiar $var references No — pure JS, foreign to nginx users
Access scope r.variables.* only Full request object (r.uri, r.headersIn, r.args, etc.)
Ambiguity $uri means r.variables.uri, not r.uri None — what you write is what runs
Conflicts Clashes with JS ${...} template syntax No conflicts
Learning curve Looks simple but hides the r.variables.* mapping Requires knowing the JS r API
Portability to files Breaks when moved to js_import$uri is not valid JS Works identically in inline and js_import files
Pros Familiar to nginx users, shorter for common variable lookups No ambiguity, full API access, what you write is what executes, seamless migration from inline to file
Cons Only reaches r.variables.*; $ ambiguity with JS syntax; textual substitution may surprise users; inline expressions tend to grow — when moved to a js_import file the shorthand stops working, forcing a rewrite More verbose for simple variable access (r.variables.uri vs $uri)

2. Expression Syntax (current) vs Template Literals

Expression Template Literal
Syntax js_set $v 'expr'; js_set $v '`...${expr}...`';
Wrapper return (expr) return (`...`)
String building '$uri + "_" + $host' '`${r.uri}_${r.host}`'
Readability Operators and concatenation visible Natural interpolation, reads like a string
nginx.conf parse Works Works (backticks are literal in '...')
$var shorthand Compatible Conflicts — $ is claimed by ${...}
Arbitrary JS Single expression Arbitrary expressions inside ${...}
Inline code concern Moderate — clearly an expression Higher — template strings can hide complex logic in ${...} blocks
New syntax to learn None — standard JS expression Backtick-inside-single-quote nesting
Pros No new syntax layer, $var shorthand works, clear boundary (one expression), nginx users don't need to learn template literal semantics Natural string interpolation, cleaner when building strings with embedded values
Cons String concatenation with + is verbose, quoting gets awkward for strings within expressions (r.headersIn["Foo"] || "none") Incompatible with $var shorthand, backtick-inside-single-quote nesting is unusual, blurs the line between config and inline code, marginal benefit over expression syntax
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment