// Imagine an org with components from three different sources running together:
// - Your own custom component
// - A component from an internal team in another department
// - A component bundled inside an installed AppExchange package

// Without strong isolation, any one of these could potentially:
// - read or modify another component's private data
// - intercept events meant for a different component
// - break the entire page if it misbehaves

// LWS exists specifically to prevent all of this, automatically, for every component

// This is NOT a real, working pattern in LWC, specifically because of LWS isolation:
// componentA somehow directly reaching into componentB's internal class fields
// or calling componentB's private methods without going through @api or events

// This is precisely why Modules 5 through 7 exist: @api properties, custom events,
// Pub-Sub, and Lightning Message Service are the ONLY sanctioned communication paths,
// and LWS is the underlying security mechanism that makes any other path impossible

// Code that tries to reach FAR beyond the component's own template,
// such as directly manipulating document.body from deep inside a component,
// or relying on global variables shared loosely across the entire page,
// is the category of pattern most likely to behave unexpectedly under LWS.

// Code that stays within the component's own shadowRoot (recall Module 13's
// shadowRoot.querySelector pattern) and uses standard, modern JavaScript
// generally works exactly as expected, with no special LWS considerations needed.

<template>
  <iframe src="https://trusted-partner-site.com/widget"
          title="Partner Widget"></iframe>
</template>
// This domain MUST first be added as a CSP Trusted Site in Salesforce Setup,
// or the browser will simply refuse to load the iframe content at all

// Sending a message INTO the iframe from your component
const iframeEl = this.template.querySelector('iframe');
iframeEl.contentWindow.postMessage({ action: 'refresh' }, 'https://trusted-partner-site.com');

// Listening for messages FROM the iframe
connectedCallback() {
  window.addEventListener('message', this.handleIframeMessage);
}
disconnectedCallback() {
  window.removeEventListener('message', this.handleIframeMessage);  // Module 2's cleanup lesson, again
}

# Authenticate to an org (opens a browser login flow)
sf org login web --alias myDevOrg

# Deploy your local project's metadata TO the org
sf project deploy start --target-org myDevOrg

# Retrieve metadata FROM the org, back down to your local project
sf project retrieve start --target-org myDevOrg

# See which orgs you are currently authenticated to
sf org list

# Push: CLI automatically detects local changes and deploys ONLY those changes
sf project deploy start

# Pull: CLI automatically detects org changes and retrieves ONLY those changes
sf project retrieve start

# Compare this to a non-source-tracked org (like most sandboxes), where you
# typically must specify exact file paths or use a full deploy every time

# 1. Authenticate to your target org (only needed once per org)
sf org login web --alias myDevOrg

# 2. Write and locally test your component (Module 13's Jest tests)
npm run test:unit

# 3. Commit your code to version control (recall this is exactly what platforms
#    like Copado, covered in a separate guide on this site, manage and orchestrate
#    at a larger, more governed scale across many developers and environments)
git add .
git commit -m "Add order status update component with full test coverage"

# 4. Deploy to the org
sf project deploy start --target-org myDevOrg

# 5. Verify in the org itself, then repeat this cycle for the next change