Skip to content

Conversation

@hydralien
Copy link
Collaborator

@hydralien hydralien commented Oct 28, 2025

Description

Adjusting the code to use data-aue-component property instead of data-aue-model and/or data-aue-filter and da-aue-behaviour.

The page configuration PR is at aemsites/da-block-collection#21

Related Issue

#99

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • I have signed the Adobe Open Source CLA.
  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

@hydralien hydralien changed the title Issue/99 Update instrumentation Issue/99 Update UE instrumentation to use data-aue-component Oct 29, 2025
@hydralien hydralien marked this pull request as ready for review October 29, 2025 13:03
'data-aue-label': 'Page',
'data-aue-type': 'component',
'data-aue-model': 'page-metadata',
'data-aue-component': 'page-metadata',
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here I'm not sure if we should call it page instead of page-metadata. Also, will this be within the component-definition? Can we create a page-metadata component?
If not, it would make sense to keep this one with data-aue-model

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We used the page-metadata model for page wide properties. So far page-metadata was not in the component definition, only in models definition.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then let's keep it page-metadata. As it is neither supposed to be added/removed/moved/copied, I would keep it as it was with data-aue-model

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reverted to data-aue-model

'data-aue-type': 'container',
'data-aue-label': 'Main Content',
'data-aue-filter': 'main',
'data-aue-component': 'main',
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above main is unique and usually you can not add a new main component.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct, projects can not do anything on main we only need it for the filter as main has n sections. Should we keep the filter here?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say so, no data-aue-component, just the filter as it was

Copy link
Collaborator Author

@hydralien hydralien Oct 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reverted to filter

*/
function addBlockFieldAttributes(ueConfig, block) {
const blockName = block.properties['data-aue-model'];
const blockName = block.properties['data-aue-component'];
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we keep reading data-aue-model as fallback for projects which have not adjusted the instrumentation files. With the assumption the model name == component name? @maximilianvoss WDYT?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How many customers would we potentially break?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

3 live sites I'm aware of (but we have good contact to ACS) and x number of commerce team demos.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added fallback

'data-aue-label': 'Page',
'data-aue-type': 'component',
'data-aue-model': 'page-metadata',
'data-aue-component': 'page-metadata',
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We used the page-metadata model for page wide properties. So far page-metadata was not in the component definition, only in models definition.

'data-aue-type': 'container',
'data-aue-label': 'Main Content',
'data-aue-filter': 'main',
'data-aue-component': 'main',
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct, projects can not do anything on main we only need it for the filter as main has n sections. Should we keep the filter here?

@mhaack mhaack changed the title Issue/99 Update UE instrumentation to use data-aue-component WIP: Issue/99 Update UE instrumentation to use data-aue-component Oct 29, 2025
@mhaack
Copy link
Collaborator

mhaack commented Oct 29, 2025

I marked the PR as WIP. As this will be breaking and while we can deploy this to STAGE we should not get this on the main branch as it will break projects. Lets collect all breaking changes in a "v1" branch.

@hydralien
Copy link
Collaborator Author

@mhaack by

Lets collect all breaking changes in a "v1" branch

do you mean this branch shoul dbe renamed, or we just consider this branch a "v1"?

@mhaack
Copy link
Collaborator

mhaack commented Oct 30, 2025

do you mean this branch shoul dbe renamed, or we just consider this branch a "v1"?

No lets leave it, just don't merge to main. We have no automatic stage deployment for the worker. I was thinking we add a stage branch which we merge into and use that for stage deployments. Too be discussed.

wrangler.toml Outdated

[env.dev]
vars = { ENVIRONMENT = "dev", UE_HOST = "localhost:4712", UE_SERVICE = "https://localhost:8000", DA_ADMIN = "https://admin.da.live" }
vars = { ENVIRONMENT = "dev", UE_HOST = "localhost:4712", UE_SERVICE = "https://localhost.corp.adobe.com:8000", DA_ADMIN = "https://admin.da.live" }
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will require that you are on VPN the whole time. Didn't it work with localhost?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry I meant to move it to another PR for the configuration template, I'll remove it from here. That doesn't require VPN, it's ought to be registered at /etc/hosts to work but the benefit is we have a certificate for that. But that's another story.

@hydralien hydralien changed the base branch from main to stage November 11, 2025 09:07
@hydralien hydralien merged commit b25941b into adobe:stage Nov 11, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants