Summary
On a record detail page, a Field.address value renders as a stringified JSON object instead of a formatted address. The create/edit dialog renders the same field correctly as Street / City / State / ZIP / Country inputs, so this is specific to the detail page's read renderer.
Decisive evidence — same record, same field group
| field | type | detail page (read) |
|---|
billing_address | Field.address | ❌ {"street":"中策路 1 号","city":"杭州",…} |
office_location | Field.location | ✅ 📍 30.2741, 120.1551 |
Both fields sit in the same contact_info group on the same account record. The detail-page read renderer therefore has a location formatter and lacks an address one, so address falls through to stringifying the object.
This matches the shipped console bundle: the input registry carries both address: and location:; the display registry the detail page uses does not carry address.
The detail page's inline edit mode shows the JSON too.
Reproduce
- Declare an
address field on any object and give a record a value for it. - Open that record's detail page.
- The value renders as raw JSON. Open the create/edit dialog for the same record — it renders correctly.
Scope
Type-level, not object-specific. Confirmed by writing a value to a second object's address field through the API and seeing the same rendering (reverted afterwards).
Why we have no app-side workaround
- Changing the field to
text destroys the structured value and breaks the flat billing_country projection our territory sharing rules match on — and loses the sub-field inputs that currently work. - A mirrored "display" field puts two addresses on the page that can drift apart.
- Authoring detail-page sections changes the value's source, not the renderer that formats it.
So we have recorded it as a known gap rather than papering over it.
Environment
@objectstack/* protocol ^17.0.0-rc.1, console served from @objectstack/console, driver-sql on SQLite, browser locale zh-CN.
Filed from a downstream app (hotcrm-heimao), tracked there as issue #54.
Summary
On a record detail page, a
Field.addressvalue renders as a stringified JSON object instead of a formatted address. The create/edit dialog renders the same field correctly as Street / City / State / ZIP / Country inputs, so this is specific to the detail page's read renderer.Decisive evidence — same record, same field group
billing_addressField.address{"street":"中策路 1 号","city":"杭州",…}office_locationField.location📍 30.2741, 120.1551Both fields sit in the same
contact_infogroup on the same account record. The detail-page read renderer therefore has alocationformatter and lacks anaddressone, soaddressfalls through to stringifying the object.This matches the shipped console bundle: the input registry carries both
address:andlocation:; the display registry the detail page uses does not carryaddress.The detail page's inline edit mode shows the JSON too.
Reproduce
addressfield on any object and give a record a value for it.Scope
Type-level, not object-specific. Confirmed by writing a value to a second object's
addressfield through the API and seeing the same rendering (reverted afterwards).Why we have no app-side workaround
textdestroys the structured value and breaks the flatbilling_countryprojection our territory sharing rules match on — and loses the sub-field inputs that currently work.So we have recorded it as a known gap rather than papering over it.
Environment
@objectstack/*protocol^17.0.0-rc.1, console served from@objectstack/console, driver-sql on SQLite, browser localezh-CN.Filed from a downstream app (
hotcrm-heimao), tracked there as issue #54.