> For the complete documentation index, see [llms.txt](https://docs.decentraland.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decentraland.org/creator/scenes-sdk7/programming-patterns/mutable-data.md).

# Mutable Data

Learn how to handle ead-only and mutable data from components

When referencing data from a [component](/creator/scenes-sdk7/architecture/entities-components.md), you can either fetch the mutable or the read-only (immutable) version.

You should always deal with the read-only versions of data when possible. This practice can bring a very significant improvement in the performance of your scene, when compared to always dealing with mutable versions of that same data.

The `.get()` function in a component returns a read-only (immutable) version of the component. You can only read its values, but can't change any of the properties on it.

The `.getMutable()` function returns a version of the component that allows you to change its values. Use mutable versions only when you plan to make changes to a component, otherwise, always use `get()`.

```ts
// fetch a read-only (immutable) version
const immutableTransform = Transform.get(myEntity)

// the following does NOT work:
// immutableTransform.position.y = 2

const mutableTransform = Transform.getMutable(myEntity)

// the following line DOES change the entity's position
mutableTransform.position.y = 2
```

A good practice is to iterate over read-only components to check values, and then only fetch the mutable version of an individual component when a change is required.

```ts
// hard-coded maximum height
const MAX_HEIGHT = 10

// Define the system
function HeightLimitSystem(dt: number) {
	// iterate over all entities that have a Transform component
	for (const [entity] of engine.getEntitiesWith(Transform)) {
		// get read-only values
		const currentHeight = Transform.get(entity).position.y

		// compare values
		if (currentHeight > MAX_HEIGHT) {
			// fetch mutable version to make a change
			const mutableTransform = Transform.getMutable(entity)

			// change transform
			mutableTransform.position.y = MAX_HEIGHT
		}
	}
}

// Add system to engine
engine.addSystem(HeightLimitSystem)
```

In the example above, a system checks the read-only values of an entity's `Transform` component. On every tick it checks to see if the position's *y* is higher than a hard-coded maximum height. If the height on the transform happens to be above this limit, then and only then we fetch the mutable version of the Transform. This may seem like extra work for the scene, but in a scene where we're checking values on every tick of the game loop, and only making changes occasionally, it results in huge performance gains.

This practice follows the principles of [data oriented programming](/creator/scenes-sdk7/architecture/data-oriented-programming.md). It's also gradually being adopted as an industry standard practice in the gaming, because of how much of an improvement it makes.

{% hint style="warning" %}
**📔 Note**: In older versions of the SDK (6.x or older), components were always treated as mutable. That pattern may be a bit more straight forward to learn, but was a lot less efficient to run.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.decentraland.org/creator/scenes-sdk7/programming-patterns/mutable-data.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.