Connecting View Generation to Interaction in an Enterprise Environment
In Part 1, we covered how the execution environment is separated.
Now the generated UI runs within a controlled and safe boundary.
However, this alone is not enough to consider it a real product feature.
After reviewing the result, users continue their workflow based on that output.
They need to modify text, adjust data queries, and refine the layout as a natural next step.
In other words, the generated UI should not remain a static output. It needs to become an interface that leads to the next action.
The control model changes inside an iframe
In a typical frontend setup, the DOM is accessed directly and state is shared.
But in a cross-origin iframe, this approach does not work.
Instead of working around this constraint, CommerceOS redesigned the structure around it.
Rather than relying on direct access, the system exchanges state and intent through messages.
What matters in this structure is defining which messages are allowed to flow.
Handling postMessage
postMessage is the most basic cross-origin communication mechanism provided by the browser.
The problem is that it is open by default.
Any window can send messages, and there is no enforced structure.
Instead of using this layer as-is, CommerceOS constrains it with clear rules.
The system only accepts messages from specific origins. It matches requests and responses using unique identifiers. It also validates all incoming data against predefined schemas.
With these constraints in place, postMessage operates as a restricted interface.
The key idea behind this design is simple.
Only allow explicitly permitted messages to flow
Separating requests and responses stabilizes the system
One of the critical design decisions was to clearly separate requests and responses.
The iframe sends a request when needed, and the host returns a response tied to that request.
Without this structure, several issues can occur.
- The same request may be processed multiple times
- Responses to earlier requests may arrive late
- Unintended messages may be processed
To prevent this, every request includes a unique identifier, and the system only processes responses that match that request.
This structure may look simple, but it plays a key role in maintaining stability in an asynchronous environment.
Separating authentication clarifies control boundaries
API calls from inside the iframe require authentication. However, cookie-based authentication does not behave consistently in iframe environments.
CommerceOS keeps authentication out of the iframe.
The iframe requests a token when needed, and the host provides it based on the current session. This keeps authentication centralized while the iframe only uses what it needs.
This approach makes an important architectural decision clear.
The system controls authentication, not the browser
Determining whether the UI is actually ready
An iframe provides a load event, but this mostly indicates that the HTML has loaded. It does not guarantee that the application itself is ready.
In addition, sandbox environments may terminate after a certain period, so the system needs to continuously verify its state even after the initial load.
To address this, CommerceOS uses a heartbeat pattern.
The iframe sends periodic signals, and the host determines the current state based on those signals.
This structure handles two conditions at once.
- The moment when the application is actually ready
- The moment when the execution environment has stopped
A single mechanism handles both without requiring complex state management.
Edit Mode is about interpretation, not access
At first glance, allowing users to click and edit elements inside the iframe may seem straightforward.
However, in a cross-origin environment, direct access to those elements is not possible.
CommerceOS solves this by changing the approach.
During code generation, the system embeds metadata into elements that can be edited.
This metadata includes:
- Which elements are editable
- Which file each element maps to
- Which data queries are associated with it
The iframe detects user interactions, collects this information, and sends it to the host. The host then builds the editing interface based on that data.
The key point is that the system does not directly control the DOM.
Instead, it exchanges information that can be interpreted at a semantic level.
Real editing requires access to the underlying code
An editing interface alone is not enough.
For changes to take effect, the system needs access to the underlying code.
However, the host cannot directly access files inside the iframe.
To solve this, CommerceOS uses the same request and response pattern.
The host requests a file, and the iframe reads and returns its contents. Throughout this process, the execution boundary remains intact. The code stays inside the sandbox, and the host only receives what it needs.
This structure follows a simple but important principle.
Exchange only what is necessary while keeping the boundary intact
Handling retries and timing issues
In real-world environments, requests are not always processed immediately.
If the application inside the iframe has not fully initialized, a request may be sent but no response may be returned.
To handle this, retry logic is built into the request flow.
If no response is received within a certain time, the system retries the request. If the maximum number of retries is reached, it treats the request as a failure.
This approach is simple, but it keeps the system stable when initialization timing and network delays overlap.
Conclusion
Separating the execution environment is only the first step.
To turn it into a real product feature, the system must support interaction on top of it.
CommerceOS achieves this with a message-driven architecture.
- Messages follow a constrained interface
- The system continuously monitors state
- Interactions stay within controlled boundaries
With this structure, View Generation becomes more than a preview. It becomes an interface where users can make changes and iterate in real time.
in solving your problems with Enhans!
We'll contact you shortly!