By the end of this tutorial, you’ll know how to rename the data parameter Lodash injects into _.template() expressions—making templates clearer and avoiding naming conflicts.
01
Default obj
See why Lodash uses obj.property in template tags by default.
02
Rename to data
Set templateSettings.variable for more readable template source.
03
Per-template override
Pass { variable: 'viewModel' } without changing global settings.
Keep template data separate from Lodash helpers in imports.
06
Compile timing
Set the name before _.template() runs—already-compiled functions stay unchanged.
Fundamentals
What Is _.templateSettings.variable?
_.templateSettings.variable is a string that names the data object parameter available inside compiled template expressions. When you write <%= obj.name %>, the obj part comes from this setting—Lodash default is literally the identifier obj.
💡
Beginner tip
Changing variable does not change what you pass when rendering. You still call render({ name: 'John' }). Only the name you use inside the template string changes—from obj.name to data.name.
Teams rename the variable when obj feels cryptic, when designers expect data or viewModel, or when template helpers from imports make short names like obj easy to confuse with other symbols.
Foundation
📝 Syntax
Assign a valid JavaScript identifier string to the global settings object (or pass it per compile):
Lodash compiles the template into a function that receives your object and exposes it as data inside tag expressions. The render call stays a normal plain object.
Example 2 — Default obj (no change needed)
If you never set variable, Lodash expects obj.property in template source.
javascript
// _.templateSettings.variable === "obj" by default
const tpl = _.template("Hello, <%= obj.name %>!");
console.log(tpl({ name: "Ada" }));
// -> "Hello, Ada!"
// Writing data.name here would fail unless you set variable = "data"
The options object merges with global templateSettings for that single compile. Other templates compiled elsewhere still use the global variable value.
Example 5 — Same variable in logic and output tags
evaluate blocks must use the same identifier as interpolate tags.
data holds your payload; _ holds helpers. That split makes templates easier to scan during code review.
Compare
📋 variable vs related settings
Setting
Type
Purpose
Example
variable
String
Name the data parameter in expressions
"data"
interpolate
RegExp
Match value-insertion tags
/<%=([\s\S]+?)%>/g
escape
RegExp
Match escape-output tags
/<%-([\s\S]+?)%>/g
evaluate
RegExp
Match logic blocks
/<%([\s\S]+?)%>/g
imports
Object
Inject helpers into template scope
{ _: _ }
🧠 How variable Works
1
Read identifier from settings
_.template() loads variable from global settings or the per-call options object (default obj).
Config
2
Embed name in compiled code
Expressions inside delimiter tags are wrapped in a function that receives your data under the chosen parameter name.
Compile
3
You write matching template source
Template strings must reference data.title (or whatever name you picked) in every tag expression.
Author
=
📝
Render with a plain object
Call render({ title: 'Hi' })—Lodash binds it to your variable name and evaluates each tag.
Important
📝 Notes
variable is a string identifier, not a RegExp like interpolate.
Default name is obj—template source and setting must agree.
Changes apply at compile time; re-run _.template() after renaming.
All tag types (interpolate, escape, evaluate) share the same variable name.
Pick a valid JavaScript identifier—no spaces or reserved words.
Renaming does not change the shape of the object you pass to the render function.
Wrap Up
Conclusion
_.templateSettings.variable lets you choose the name of the data object inside Lodash template expressions. Stick with default obj for minimal setup, or switch to data, viewModel, or another clear identifier when readability and team conventions matter.
Set it globally at bootstrap, override per compile when one file needs a different name, and keep it aligned with your interpolate and evaluate tags. That completes the core _.templateSettings configuration story.
Choose descriptive names like data, viewModel, or ctx
Set variable once at application startup before compiling shared templates
Document the chosen name in your template style guide
Use per-template overrides when only one module needs a different name
Keep the same name across interpolate and evaluate tags in one template
❌ Don’t
Mix obj.name and data.name in the same template after renaming
Use variable = "_"—that collides with typical Lodash imports
Expect already-compiled render functions to pick up a renamed global setting
Assume changing variable changes the render call signature
Use invalid identifiers (spaces, hyphens, reserved words)
Summary
Key Takeaways
Knowledge Unlocked
Five things to remember about variable
Use these points when naming the data parameter in Lodash templates.
5
Core concepts
📝01
String
Identifier name, not RegExp.
Basics
📦02
Default obj
Built-in unless overridden.
Default
💬03
data / viewModel
Common renames.
Pattern
⚙️04
Compile time
Set before _.template().
Timing
🔄05
Override
Per-call options.
Scope
❓ Frequently Asked Questions
It sets the name of the data object parameter available inside compiled template expressions. The default is obj, so tags typically reference obj.name. Change it to data and write data.name instead.
No. variable is a string—the identifier Lodash injects into the compiled render function. interpolate, escape, and evaluate are RegExp patterns for delimiter tags.
obj. Unless you override templateSettings.variable or pass variable in the _.template() options, expressions should use obj.propertyName.
When obj feels unclear, when your team prefers data or viewModel, or when obj clashes with another symbol in template scope (for example imports that expose _).
No. You still call render({ name: 'Ada' }). Only the identifier inside template source changes—from obj.name to data.name.
Yes. Pass { variable: 'data' } as the second argument to _.template(). That compile uses your name without mutating global templateSettings.
Did you know?
Lodash defaults to obj because early template compilation used a with statement to expose properties. Even when you pass a plain object today, the compiled function still expects you to prefix fields with whatever name variable holds—usually obj or your custom rename.