feat(microsoft-fast-build): map data-* attributes to nested dataset state

[janechu]

Pull Request

📖 Description

When a custom element receives data-* HTML attributes, the SSR renderer now groups them under a nested "dataset" key in the child state, following the MDN HTMLElement.dataset naming convention.

How it works

attribute::data_attr_to_dataset_key converts a data-* attribute name to the full dot-notation state path:

data-date-of-birth  →  "dataset.dateOfBirth"
data-name           →  "dataset.name"

The caller in render_custom_element splits on ." to insert into the nested state map, so shadow templates can use {{dataset.X}}` via ordinary dot-notation:

<test-el data-date-of-birth="{{dob}}"></test-el>

<div data-date-of-birth="{{dataset.dateOfBirth}}"></div>

<div data-date-of-birth="1990-01-01" data-fe-c-0-1></div>

Attribute → State Mapping

Attribute	Child state
data-date-of-birth="1990-01-01"	{"dataset": {"dateOfBirth": "1990-01-01"}}
data-date-of-birth="{{dob}}"	{"dataset": {"dateOfBirth": <value of dob>}}
label="Hi"	{"label": "Hi"} (non-data-* unchanged)

Change surface

• attribute.rs: data_attr_to_dataset_key returns the full path "dataset.dateOfBirth"; private kebab_to_camel helper
• directive.rs: child state builder splits the dot-notation path on . and inserts into a nested "dataset" map
• context.rs: no change — dot-notation already handles nested access

📑 Test Plan

8 integration tests in crates/microsoft-fast-build/tests/dataset_attributes.rs:

• {{dataset.name}} content binding reads state["dataset"]["name"]
• Multi-word camelCase (dataset.dateOfBirth)
• Static data-* attribute on custom element → {{dataset.X}} resolves in shadow
• data-* value from parent binding (data-date-of-birth="{{dob}}")
• Multiple data-* attrs all grouped under dataset
• Non-data-* attrs remain as top-level state keys
• <f-when value="{{dataset.active}}"> truthy and falsy

All 109 existing Rust tests continue to pass.

✅ Checklist

General

• I have included a change request file using $ npm run change
• I have added tests for my changes.
• I have tested my changes.
• I have updated the project documentation to reflect my changes.
• I have read the CONTRIBUTING documentation and followed the standards for this project.

[Copilot]

Pull request overview

This PR updates the @microsoft/fast-build SSR renderer so data-* attributes on custom elements are grouped into a nested dataset object in the child state, enabling natural {{dataset.fooBar}} bindings that match HTMLElement.dataset conventions.

Changes:

• Add attribute::data_attr_to_dataset_key (and kebab_to_camel) to convert data-* names to dataset.* dot-paths.
• Update render_custom_element to route data-* attributes into a nested dataset state object.
• Add integration tests and documentation describing the new mapping behavior.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
crates/microsoft-fast-build/src/attribute.rs	Introduces data-* → dataset.* conversion helper.
crates/microsoft-fast-build/src/directive.rs	Builds nested dataset child state when rendering custom elements.
crates/microsoft-fast-build/src/context.rs	Documents nested dot-notation access (incl. dataset.*).
crates/microsoft-fast-build/tests/dataset_attributes.rs	Adds integration tests validating dataset bindings and custom element propagation.
crates/microsoft-fast-build/README.md	Documents dataset attribute/state mapping and usage.
crates/microsoft-fast-build/DESIGN.md	Updates design notes for data-* routing into dataset.
change/@microsoft-fast-build-a7be27dd-c99a-4485-8ba1-5b3490b7f55e.json	Adds release change entry for this feature.

[Copilot]

If an element has a non-data-* attribute named dataset (or the state map already contains a dataset key) and it's not a JSON object, subsequent data-* attributes will be silently dropped because the if let JsonValue::Object(...) branch won’t run. Consider handling this conflict deterministically (e.g., overwrite dataset with an object, or preserve the existing value under another key and still insert the data-* entries).

Suggested change

	.or_insert_with(|| JsonValue::Object(std::collections::HashMap::new()));
	.or_insert_with(|| JsonValue::Object(std::collections::HashMap::new()));
	if !matches!(group_val, JsonValue::Object(_)) {
	*group_val = JsonValue::Object(std::collections::HashMap::new());
	}

[Copilot]

data_attr_to_dataset_key returns Some("dataset.") for the attribute name "data-", which then produces an empty property name when inserted into the child state. It would be safer to return None (or otherwise reject) when the suffix after data- is empty to avoid creating state.dataset[""] entries.

Suggested change

	/// Returns `None` for names that do not start with `data-`.
	///
	/// Examples: `"data-date-of-birth"` → `"dataset.dateOfBirth"`, `"data-name"` → `"dataset.name"`
	pub fn data_attr_to_dataset_key(name: &str) -> Option<String> {
	name.strip_prefix("data-").map(|rest| format!("dataset.{}", kebab_to_camel(rest)))
	/// Returns `None` for names that do not start with `data-` or have an empty suffix.
	///
	/// Examples: `"data-date-of-birth"` → `"dataset.dateOfBirth"`, `"data-name"` → `"dataset.name"`
	pub fn data_attr_to_dataset_key(name: &str) -> Option<String> {
	name.strip_prefix("data-")
	.filter(|rest| !rest.is_empty())
	.map(|rest| format!("dataset.{}", kebab_to_camel(rest)))

[Copilot]

The change file description looks inverted relative to the PR behavior: it says “convert dataset.X attribute names to data-X”, but the PR maps data-* attributes into nested dataset.* state for SSR. Update the comment string so release notes accurately describe the actual change.