Dynamic Content Generation in JSON UI

Because Bedrock's JSON UI lacks a procedural scripting layer inside the resource pack, you cannot write a traditional loop to create elements. Instead, you declare a template control and instruct a parent container to stamp out copies of that template at runtime. The engine exposes two distinct structures for this: grids and factories.

Grids are designed for two-dimensional or one-dimensional arrangements of uniform items, such as inventory slots, scoreboard rows, or recipe book pages. Factories are more flexible; they are commonly attached to stack panels to instantiate heterogeneous or sequential elements, like incoming chat messages or the buttons inside an Action Form. In both systems, the C++ engine dictates the total count of items via a named collection, and each spawned child inherits a collection index so its bindings know which slice of data to read.

A factory is declared as an object inside a container element, typically a stack_panel so that generated children automatically stack vertically or horizontally without overlapping. Inside the factory block, you must provide a name that matches an internal engine factory identifier, and a control_id (or a map of control_ids) that tells the factory which JSON element to instantiate.

When the game triggers the factory—for example, when a script calls ActionFormData.show() and the server_form screen opens—the container clears or appends instances of your template. If the factory is backed by a collection, you also set collection_name on the parent container so each spawned child can bind to collection-specific properties like button text or icons.

{
  "namespace": "server_form",
  "dynamic_button_template": {
    "type": "panel",
    "size": ["100%", 32],
    "controls": [
      {
        "button@common_buttons.light_text_button": {
          "size": ["100% - 4px", "100% - 4px"],
          "$pressed_button_name": "button.form_button_click",
          "$button_text": "#form_button_text",
          "$button_text_binding_type": "collection",
          "$button_text_grid_collection_name": "form_buttons",
          "bindings": [
            {
              "binding_type": "collection_details",
              "binding_collection_name": "form_buttons"
            }
          ]
        }
      }
    ]
  },
  "button_list_panel": {
    "type": "stack_panel",
    "orientation": "vertical",
    "size": ["100%", "100%c"],
    "collection_name": "form_buttons",
    "factory": {
      "name": "buttons",
      "control_id": "server_form.dynamic_button_template"
    }
  }
}

When your layout requires a strict row-and-column structure or needs to bind directly to an inventory array, you use a control of type grid. Instead of a factory block, a grid uses grid_item_template to specify the child element and collection_name to specify the data source. If the number of items is variable, you replace the static grid_dimensions array with either grid_dimension_binding or grid_rescaling_type.

Every element cloned by a grid or a collection-backed factory needs to know which index it represents. In your child template's bindings array, you set binding_type to collection and binding_collection_name to match the parent's collection_name. If a child control is a complex template (like a standard button from common_buttons), you also include a binding of type collection_details so the button's press event sends the correct index back to the game engine.

{
  "namespace": "hud",
  "status_effect_slot": {
    "type": "panel",
    "size": [24, 24],
    "controls": [
      {
        "icon": {
          "type": "image",
          "size": [18, 18],
          "bindings": [
            {
              "binding_name": "#mob_effect_texture",
              "binding_name_override": "#texture",
              "binding_type": "collection",
              "binding_collection_name": "mob_effects_collection"
            }
          ]
        }
      }
    ]
  },
  "effect_grid": {
    "type": "grid",
    "size": [120, "default"],
    "grid_item_template": "hud.status_effect_slot",
    "grid_rescaling_type": "horizontal",
    "collection_name": "mob_effects_collection",
    "bindings": [
      {
        "binding_name": "#mob_effects_grid_size",
        "binding_type": "global"
      }
    ]
  }
}

A frequent point of confusion for add-on creators is trying to invent a custom collection_name in JSON UI and populate it from a script. The UI engine does not allow arbitrary collections to be created from JSON alone; the C++ screen context must own the collection. To drive dynamic UI from a behaviour pack, you piggyback on existing engine collections and update them via the @minecraft/server or @minecraft/server-ui modules.

The two cleanest pathways are Server Forms and the Scoreboard. When you build an ActionFormData in script and append buttons inside a loop, the client's server_form screen populates the form_buttons collection with one entry per button. Alternatively, for persistent on-screen HUD elements without cursor lock, you can pass variable strings through player.onScreenDisplay.setTitle() and parse them on the HUD screen using factory controls bound to the title text, or read entries from the scoreboard_players_collection.

import { world } from "@minecraft/server";
import { ActionFormData } from "@minecraft/server-ui";

export function showOnlinePlayersMenu(viewer) {
  const form = new ActionFormData();
  form.title("Active Players");

  const players = world.getAllPlayers();
  for (const target of players) {
    form.button(target.name, "textures/ui/Friend2");
  }

  form.show(viewer).then((response) => {
    if (response.canceled) return;
    const selectedPlayer = players[response.selection];
    if (selectedPlayer) {
      viewer.sendMessage(`You selected: ${selectedPlayer.name}`);
    }
  });
}

Applies to Minecraft Bedrock 1.16.100 and newer (including current 1.20 and 1.21 releases). JSON UI factories and grids are stable core features and require no experimental toggles. Using @minecraft/server-ui to populate form collections is also stable.

Read out of the game itself, so the ids match the version you are building for.