
How the heck do I set up a scratch org using sfdx? Well, you're in the right place.

Firstly, you will need to have SFDX ([Salesforce CLI](https://developer.salesforce.com/tools/sfdxcli)) installed and VS Code. You will also need your own Salesforce DevHub instance setup (need a hand with setting up your dev hub? check out this [trailhead unit](https://trailhead.salesforce.com/en/content/learn/modules/sfdx_app_dev/sfdx_app_dev_setup_dx).

## Create a Salesforce DX Project

The second step is to create a (SF)DX project.

```shell
sf project generate -n YOUR_PROJECT_NAME
```
<small>Replaces the deprecated `sfdx force:project:create` command.</small>

## Auth your DevHub

Next, we need to connect your DevHub with your new project

```shell
sf org login web -d -r https://login.salesforce.com -a ALIAS_FOR_YOUR_DEV_HUB 
```
<small>Replaces the deprecated `sfdx force:auth:web:login` command.</small>

- `-d` sets this as the default Dev Hub.
- `-r` sets the login URL for the org.
- `-a` sets this alias for the org.

> If you have already auth'd, set your default username using `sf config set defaultdevhubusername=lukesfakeemail@force.com`

## Login To Sandboxes

In addition to DebHubs, we can also connect to standard salesforce Sandboxes. This can be handy when it comes to pulling components into your scratch org

```shell
sf org login web -r https://test.salesforce.com -a ALIAS_FOR_YOUR_SANDBOX
```
<small>Replaces the deprecated `sfdx force:auth:web:login` command.</small>

> Remember, don't use the `-d` flag. If you do, the CLI thinks the org is your Dev Hub, and then you'll see an error when you try to create a scratch org.

If ~~`force:auth:web:login`~~ `sf org login web` isnt working, use ~~`sfdx force:auth:device:login`~~ `sf org login device` instead.

## Rename (add) Alias

```shell
sf alias set NEW_ALIAS_FOR_YOUR_SANDBOX=current@sandbox.user.com
sf alias set OLD_ALIAS_FOR_YOUR_SANDBOX=
```
<small>Replaces the deprecated `sfdx force:alias:set` command.</small>

## Logout of Sandboxes

logout/remove the sandbox from the `sfdx force:org:list`

```shell
sf org logout -o ALIAS_FOR_YOUR_SANDBOX
```
<small>Replaces the deprecated `sfdx force:auth:logout` command.</small>

## Create your scratch org

Now for the fun part, creating your scratch org.

> if you want to set the scratch org name, or adjust other config options, edit the `./config/project-scratch-def.json` file before progressing

```shell
sf org create scratch -v ALIAS_OF_YOUR_DEBHUB -f config/project-scratch-def.json -a ALIAS_FOR_SCRATCH_ORG -y 30 -w 10
```
<small>Replaces the deprecated `sfdx force:org:create` command.</small>

- `-v` optional param to choose your DevHub (not needed if you have a default DevHub set)
- `-s` sets this as the default sratch org
- `-f` sets the location for the config file (to build the org)
- `-a` sets the alias for the scratch org
- `-y` sets the expiry to 30 days
- `-w` sets the wait time to 10mins
- `-e` edition to use (developer, enterprise, group, professional, partner-developer, partner-enterprise, partner-group, partner-professional)


### View Scratch Org Config/Details

```shell
sf org display -o SCRATCH_ORG_ALIAS
```
<small>Replaces the deprecated `sfdx force:org:display` command.</small>

### Generate Password Scratch Org

```shell
sf force user password generate -u SCRATCH_ORG_ALIAS
```
<small>Replaces the deprecated `sfdx force:user:password:generate` command.</small>

### Delete Scratch Org

```shell
sf org delete scratch -o SCRATCH_ORG_ALIAS
```
<small>Replaces the deprecated `sfdx force:org:delete` command.</small>

### Assign Permission Set

Before you can start pushing code, we have to set up some permission sets to allow us.

```shell
sf org assign permset -n NAME_OF_PERMISSION_SET
```
<small>Replaces the deprecated `sfdx force:user:permset:assign` command.</small>

> most likely named `SalesConsoleUser` on default scratch orgs

### Deploy code back to DevHub

Deploy all of type

```shell
sf deploy metadata -m ApexPage, ApexClasses, LightningComponentBundle -o ALIAS_FOR_YOUR_DEV_HUB
```
<small>Replaces the deprecated `sfdx force:source:deploy` command.</small>

Deploy specific component by path

```shell
sf deploy metadata -p force-app/main/default/lwc/SINGLE_COMPONENT_NAME -o ALIAS_FOR_YOUR_DEV_HUB
```
<small>Replaces the deprecated `sfdx force:source:deploy` command.</small>


## Deploy code to a Sandbox

> NOTE: These are the same deploy commands as above but with the extra `project` keyword in the command.

Deploy all of type

```shell
sf project deploy metadata -m ApexPage, ApexClasses, LightningComponentBundle -o ALIAS_FOR_YOUR_DEV_HUB
```
<small>Replaces the deprecated `sfdx force:source:deploy` command.</small>

Deploy specific component by path

```shell
sf project deploy metadata -p force-app/main/default/lwc/SINGLE_COMPONENT_NAME -o ALIAS_FOR_YOUR_DEV_HUB
```
<small>Replaces the deprecated `sfdx force:source:deploy` command.</small>


## Retrieve / Fetch / Pull Data

Retrieve all ApexClasses, ApexPages and LWC's

```shell
sf project retrieve metadata -m ApexClass, ApexPage, LightningComponentBundle -o ALIAS_FOR_YOUR_DEV_HUB
```
<small>Replaces the deprecated `sfdx force:source:retrieve` command.</small>

[Metadata Ref](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_types_list.htm)


## Create Data

Specify the Object type and the fields 'n values

```shell
sf data create record -s Account -v "Name='Marriott Marquis' BillingStreet='780 Mission St' BillingCity='San Francisco' BillingState='CA' BillingPostalCode='94103' Phone='(415) 896-1600' Website='www.marriott.com'" -o SCRATCH_ORG_ALIAS
```
<small>Replaces the deprecated `sfdx force:data:record:create` command.</small>

#### Export Data

Using SQL to JSON data

```shell
sf data export tree -q "SELECT Name, BillingStreet, BillingCity, BillingState, BillingPostalCode, Phone, Website FROM Account WHERE BillingStreet != NULL AND BillingCity != NULL and BillingState != NULL" -d ./data -o SCRATCH_ORG_ALIAS
```
<small>Replaces the deprecated `sfdx force:data:tree:export` command.</small>

#### Import Data

```shell
sf data import tree -f data/Account.json
```
<small>Replaces the deprecated `sfdx force:data:tree:import` command.</small>

## Create an Apex Class

```shell
sf apex generate class -n YourClassName -d force-app/main/default/classes
```
<small>Replaces the deprecated `sfdx force:apex:class:create` command.</small>

## `config/project-scratch-def.json`

Disable Lightning Experience caching

```json
"settings": {
  "orgPreferenceSettings": {
    "s1EncryptedStoragePref2": false
  }
}
```

> Disabling secure and persistent browser caching has a significant negative performance impact on Lightning Experience. Always enable the setting in production orgs.

## Useful Links

- [Salesforce Metadata Ref](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_types_list.htm)
- [Salesforce CLI (`sf`/`sfdx`)](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_top.htm)

How the heck do I set up a scratch org using sfdx? Well, you're in the right place

SFDX: How to setup a Scratch Org


Lightning Web Runtime, or LWR for short was released back in [Spring 21 (v51.0)](https://help.salesforce.com/s/articleView?id=release-notes.rn_experiences_developers_lwr.htm&release=230&type=5). Even before the release of LWR, most developers dreamed of being able to build custom nested components. We could see that OOTB (Out Of The Box) components could use them (see Tabs component).

Salesforce recently released the ability to build custom LWCs with child `<slot/>`'s, to allow nesting of components. Nested LWCs allow you to compose multiple components together into a single component. The child components maintain their own life cycle and can communicate with each other through events, making it easy to create flexible and dynamic apps.

W> Before continuing, Aura based Communities are (sadly) not supported. So if you're currently using them it might be time to make the switch to LWR.

## Code Example

Enough talk, lets jump into the code and see the magic happen.

### HTML

We'll start by creating the HTML template to hold our `<slot/>`'s.

```html
<template>
  <template if:false={isAura}>
    <div class="container">
      <div>
        <slot name="region1"></slot>
      </div>
      <div>
        <slot name="region2"></slot>
      </div>
      <div>
        <slot name="region3"></slot>
      </div>
    </div>
  </template>
</template>
```

### JavaScript

Now lets have a look at the JavaScript. The important part (or magic) here is the `@slot` definitions in the comment directly above the LWC export. Without these definitions, the dynamic components will not work.

The `isAura` check also ensures this component shows a warning in the experience builder when it is being used from within an Aura based community.

```javascript
import { LightningElement } from 'lwc'

/**
 * @slot region1
 * @slot region2
 * @slot region3
 */
export default class NestedLWCs extends LightningElement {
  get isAura() {
    return window['$A'] !== undefined && window['$A'] !== null
  }
}
```

### Metadata XML

Make sure your `.xml` file is setup to be available in the experience builder. The key values are setting `isExposed` to `true` and including both `lightningCommunity__Page` and `lightningCommunity__Default` as `targets`.

```xml
<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata">
  <apiVersion>57.0</apiVersion>
  <isExposed>true</isExposed>
  <masterLabel>Nested LWCs</masterLabel>
  <description>Nested LWC magic</description>
  <targets>
    <target>lightningCommunity__Page</target>
    <target>lightningCommunity__Default</target>
  </targets>
</LightningComponentBundle>
```

## Experience Builder

Now lets open up the Experience Builder and see our custom LWC in action.

![Experience Builder: Draging our custom LWC onto the page](/lwc-nested-components/nested-lwc-1.gif)

We can also nest components within other nested components. I am not aware of any limitation here. I was able to place up to 10 levels deep without any issues, noting theses are very barebones test LWCs. More complex LWCs may start affecting performance.

![Experience Builder: Draging our custom LWC onto the page](/lwc-nested-components/nested-lwc-2.gif)

## Wrapping Up

In summary, nested LWCs provide a powerful and flexible way for developers to create custom components that can be composed of multiple other components, making it easier to build dynamic and reusable apps on the Experience Cloud platform.


A quick look into how to build LWCs with slots to allow for nesting of LWCs

Lightning Web Components: Custom Nested Components


Mixins (or Abstract subclasses) are templates for classes that allow us to write generic functionality to be reused. Given the nature of classes, it is not possible to have more than one superclass. Mixins allow us to pass the base class as a property and unlock nested inheritance.

## JavaScript Mixin Usage

Before we dive into an LWC example, lets look at how we can use mixins in a plain javascript environment.

Firstly, we must create a mixin function that our classes can use. This should be a piece of generic functionality that multiple classes can utalise.

```javascript
// A simple Mixin method
// adds the `windowSize()` method to classes that implement this mixin
export const WindowSizeMixin = (BaseClass) =>
  class extends BaseClass {
    get windowSize() {
      return {
        width: window.innerWidth,
        height: window.innerHeight,
      }
    }
  }
```

```javascript
import { WindowSizeMixin } from './windowSizeMixin'

// Implementing the `WindowSizeMixin` gives us access to the
// `this.windowSize` getter
class Header extends WindowSizeMixin(BaseClass) {
  getWindowSize() {
    return this.windowSize
  }
}
```

In the above example, calling the `getWindowSize()` function on our Header class will return the object defined in the `WindowSizeMixin`.

## LWC Mixin Usage

Now we have a basic understanding of how mixins work in JavaScript, lets look at how the concept applies to LWC. Using mixins in LWC is almost identical with one difference, your `BaseClass` should be `LightningElement` (or another class that has extended `LightningElement`).

We'll assume the same above mixin source code that we used above (`WindowSizeMixin`) but instead our implementation will be a LWC component.

```javascript
// don't forget to import LightningElement, we need to extend it as our base class
import { LightningElement } from 'lwc'

// assume our mixin has been created as a separate LWC to be used by multiple components
import { WindowSizeMixin } from 'c/windowSizeMixin'

// LWC expects a default export of our `LightingElement` extended component
export default class Header extends WindowSizeMixin(LightningElement) {
  getWindowSize() {
    // available via the WindowSizeMixin
    return this.windowSize
  }
}
```

## Stacking Mixins

The beauty of mixins is that you can use more than one. This can be useful for creating smaller snippet mixins for similar functionality that is used across multiple LWCs.

Lets have a quick look at an example. We will create another mixin method.

```javascript
export const DateMixin = (BaseClass) =>
  class extends BaseClass {
    // a function that returns the current date as an object
    getDate() {
      const date = new Date()
      return {
        day: date.getDate(),
        month: date.getMonth() + 1,
        year: date.getFullYear(),
      }
    }
  }
```

Lets update our LWC example from above to include the new `DateMixin`.

```javascript
// don't forget to import LightningElement, we need to extend it as our base class
import { LightningElement } from 'lwc'

// assume our mixins have been created as a separate LWC to be used by multiple components
import { WindowSizeMixin } from 'c/windowSizeMixin'
import { DateMixin } from 'c/dateMixin'

// LWC expects a default export of our component
// we can stack mixins here
export default class Header extends DateMixin(
  WindowSizeMixin(LightningElement)
) {
  getWindowSize() {
    // available via the WindowSizeMixin
    return this.windowSize
  }
  getCurrentDate() {
    // available via the DateMixin
    return this.getDate()
  }
}
```

## Using `@wire` in a Custom Mixin

[`@wire`](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.data_wire_service_about) is a service that streams immutable data to the component. This is heavily used in on platform development and a must when it comes to building dynamic components.

Lets have a look at a simple example mixin that uses the standard [`getRecord`](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/reference_wire_adapters_record) wire method.

```javascript
import { wire } from 'lwc'
import { getRecord } from 'lightning/uiRecordApi'

export const AccountWireMixin = (BaseClass) =>
  class extends BaseClass {
    // explicitly not setting recordId so that the consuming
    // component can choose how it wishes to implement it (e.g @api, get/set)
    // recordId

    // this can be dynamically changed by the implementing class if needed
    // this array acts as a default field list
    fieldRef = ['Account.Id', 'Account.Name', 'Account.Phone']

    @wire(getRecord, {
      recordId: '$recordId',
      fields: '$fieldRef',
    })
    wiredGetRecord(response) {
      // you can choose to either set the data to a variable for you component to consume
      // or fire off a function that your consuming component can override.
      // for this example, we will call a method
      this.handleWiredAccount(response)
    }

    /**
     * This method should be overriden by the consuming component
     */
    handleWiredAccount = (response) => {
      const { error, data } = response

      if (error) {
        // TODO: handle errors
      } else if (data) {
        // TODO: handle success
      }
    }
  }
```

We can update our above example and stack the `AccountWireMixin` on top.

```javascript
// don't forget to import LightningElement, we need to extend it as our base class
import { LightningElement } from 'lwc'

// assume our mixins have been created as a separate LWC to be used by multiple components
import { WindowSizeMixin } from 'c/windowSizeMixin'
import { DateMixin } from 'c/dateMixin'
import { AccountWireMixin } from 'c/accountWireMixin'

// LWC expects a default export of our component
// we can stack mixins here
export default class Header extends AccountWireMixin(
  DateMixin(WindowSizeMixin(LightningElement))
) {
  // ... existing code

  // override the shell method defined in the AccountWireMixin
  handleWiredAccount = (response) => {
    const { error, data } = response

    if (error) {
      // TODO: handle errors
      console.error('Oh no, something went wrong ', error)
    } else if (data) {
      // TODO: handle success
      console.log('We have account data, yay ', data)
    }
  }
}
```

## Wrapping up

In conclusion, mixins are an incredibly useful tool in LWC development. They allow us to write generic, reusable functionality that can be shared between multiple components. By stacking multiple mixins, we are able to compose complex components from smaller, focused mixins. Mixins help keep our code DRY (Don't Repeat Yourself) and maintainable.


A short guide on how to implement your own custom mixins in LWC

Lightning Web Components: Custom Mixins


![Salesforce Trekken: Banner](/salesforce-trekken-cms-migration-tool/banner.png)

The Salesforce CMS data migration experience is lacking. There is no bulk export, and there is no sorting/filtering of content and you are sent an email link instead of being able to directly download the zip file.

Salesforce Trekken aims to rethink the Salesforce CMS migration experience. Using modern web technologies and thoughtful a user experience, migrating Salesforce CMS data has never been easier.

## How does it work?

Salesforce Trekken allows users to authenticate using one of two methods:

- The [sfdx cli](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli.htm)
- Access Token (and Instance URL)

The [Salesforce REST API](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/intro_rest.htm) is used to fetch CMS Channels and the CMS Content after a specific channel has been selected.

## Features

- Multiple Authentication Methods (`sfdx cli` or ACCESS_TOKEN)
- Channel Selection: Choose the right CMS Channel to export data from
- Feature Rich Export Table
- Bundled Zip file export, ready to be imported into your target org.

## Walkthrough

#### Select Your Authentication Method

![Salesforce Trekken: Select Authetnication Method Screenshot](/salesforce-trekken-cms-migration-tool/authentication.png)

#### Select An Org

![Salesforce Trekken: Select An Org Screenshot](/salesforce-trekken-cms-migration-tool/select-an-org.png)

#### Select A CMS Channel

![Salesforce Trekken: Select A CMS Channel Screenshot](/salesforce-trekken-cms-migration-tool/select-channel.png)

#### Search/Filter/Sort and Select Content

![Salesforce Trekken: Select CMS Content Screenshot](/salesforce-trekken-cms-migration-tool/select-cms-content.png)

#### Select An Output Folder

and whether to include images as part of the export.

![Salesforce Trekken: Select An Output Folder Screenshot](/salesforce-trekken-cms-migration-tool/select-output-folder.png)

#### Success

Either open the source folder or start over.

![Salesforce Trekken: Successful Export Screenshot](/salesforce-trekken-cms-migration-tool/success.png)

Your content is now ready to import into your target org.

W> If you are working with `cms_image`, make sure you import your images zip file first

## Closing

Now you've seen the powers of Salesforce Trekken and its improved user experience compared to the standard salesforce experience.

Want to find out more and/or download, checkout the [Salesforce Trekken site](https://trekken.lukesecomb.digital/)


Exporing the new Salesforce CMS Migration Tool built with Tauri, React, TailwindCSS & Vite

salesforce

Articles

SFDX: How to setup a Scratch Org

Lightning Web Components: Custom Nested Components

Lightning Web Components: Custom Mixins

Salesforce Trekken: Salesforce CMS Migration Tool