Object Property Shorthand and Computed Property Names in JavaScript

Object literals are everywhere in JavaScript. We use them for configuration, API payloads, component state, lookup tables, and the anonymous bits of data that glue the rest of an application together.

That is exactly why ES6 improving object literal syntax mattered so much.

Neither object property shorthand nor computed property names are flashy features. They are the sort of language changes that seem almost too small to care about until you realise how often they remove noise from ordinary code.

They also tend to show up together, because both features make object creation more expressive without adding much ceremony.

Property Shorthand Removes Duplication

Before ES6, if a variable and an object property needed the same name, we had to repeat ourselves:

const name = 'Ellie';const role = 'Developer';const user = {  name: name,  role: role,};

That is not difficult to read, but it is repetitive.

With property shorthand, this becomes:

const name = 'Ellie';const role = 'Developer';const user = {  name,  role,};

JavaScript reads that as "create properties called name and role, using the values of the variables with the same names".

It is a small change, but in real code it makes object construction much cleaner.

This Matters Because Object Literals Often Grow Quickly

Configuration objects are a good example.

const retries = 3;const timeout = 5000;const endpoint = '/api/products';const requestOptions = {  retries,  timeout,  endpoint,};

When an object has five or ten properties, repeating each key and value pair the long way adds a surprising amount of visual clutter.

Shorthand helps the important information stand out:

• which variables are included
• which values are being passed around
• where the object shape changes

Property Shorthand Only Works When the Names Match

This is the first limitation worth remembering.

If the property name and variable name are different, you still need the normal form:

const retries = 3;const requestOptions = {  maxRetries: retries,};

That is still perfectly fine. Shorthand is an option, not a rule you have to force everywhere.

Trying to bend names unnaturally just to use shorthand usually makes the code worse rather than better.

Method Shorthand Arrived Alongside It

ES6 also made method definitions inside object literals slightly cleaner:

const cart = {  items: [] as string[],  addItem(item: string): void {    this.items.push(item);  },};

That is equivalent to writing:

const cart = {  items: [] as string[],  addItem: function addItem(item: string): void {    this.items.push(item);  },};

Again, the gain is not magical new behaviour. The gain is that the object reads more like a coherent unit and less like a pile of boilerplate.

Computed Property Names Solve a Different Problem

Property shorthand is about less repetition.

Computed property names are about dynamic keys.

Before ES6, creating an object with a property name derived from a variable was awkward. We often had to create the object first and then assign into it:

const fieldName = 'email';const errors: Record<string, string> = {};errors[fieldName] = 'Please enter a valid email address';

With ES6 computed property names, we can do it directly in the object literal:

const fieldName = 'email';const errors = {  [fieldName]: 'Please enter a valid email address',};

The square brackets tell JavaScript to evaluate the expression and use the resulting value as the property name.

This Becomes Very Useful with Derived Keys

The expression inside the brackets does not need to be a bare variable.

It can be something derived:

const locale = 'en';const messages = {  [`title_${locale}`]: 'Welcome back',  [`button_${locale}`]: 'Continue',};

That kind of pattern shows up in real front‑end work more often than people expect:

• form validation maps
• analytics event payloads
• translation dictionaries
• feature‑flag objects
• CSS class or token lookup tables

Computed Properties Can Make Intent Clearer

Suppose we are building a small filter payload for an API:

const filterName = 'category';const filterValue = 'books';const payload = {  page: 1,  [filterName]: filterValue,};

That is easier to understand than creating the object and mutating it afterwards. The final shape is visible in one place.

It also tends to reduce the risk of forgetting a later assignment line when the logic gets refactored.

Watch Out for Silent Overwrites

Computed keys are still ordinary object properties in the end. That means collisions behave exactly as you would expect in a normal object literal: later properties win.

const key = 'status';const result = {  status: 'draft',  [key]: 'published',};

Here, result.status ends up as 'published'.

That is not an ES6 gotcha so much as a reminder that dynamic property names can overwrite static ones if the expressions resolve to the same key.

The Feature is Expressive, but Not Always the Best Choice

There is a temptation to overdo computed keys once you realise you can put expressions inside object literals.

For example:

const result = {  [user.isAdmin && user.isActive ? 'privileged' : 'standard']: true,};

Yes, this works. No, it is not especially kind to the next person reading the file.

Computed property names are most effective when the expression is simple and the resulting key is meaningful.

If the expression becomes dense, it is usually cleaner to pull it out first:

const accessLevel = user.isAdmin && user.isActive ? 'privileged' : 'standard';const result = {  [accessLevel]: true,};

Property Shorthand and Computed Properties Work Well Together

This is where object literals start to feel genuinely pleasant to build:

const locale = 'en';const version = 2;const theme = 'light';const settings = {  version,  theme,  [`label_${locale}`]: 'Save',};

The fixed keys stay concise through shorthand, and the dynamic key sits alongside them naturally.

That combination is one of the reasons ES6 object literals feel much less noisy than older JavaScript.

These Features Improve Readability When Used with Restraint

Neither feature changes the fundamental nature of objects in JavaScript. They do not replace good naming, and they do not make messy logic automatically elegant.

What they do is remove unnecessary ceremony from code we write constantly.

That matters. Language improvements do not have to be dramatic to be useful. Some of the best ones simply make ordinary code easier to read at a glance.

If you remember the core distinction, you will avoid most confusion:

• property shorthand is for when variable names and property names match
• computed property names are for when the key must be worked out dynamically

Once those two ideas click, object literals in modern JavaScript become noticeably cleaner.