# Scaffolding / Generator
###### tags: `specs` `scaffold` `design doc`

## Phase 2:

### UX

#### CLI

nix-shell https://holochain.love --run "hc scaffold gui"

npm init @holochain # Brings up the UI, scaffolds app with the latest holochain version (hdi crates version??) and sets up nix and cachix
npm init @holochain my_project --ui vue # Scaffolds a full app already with vue

either:

cd my_project
nix-shell
hc scaffold web-app forum --ui vue
hc scaffold app forum
hc scaffold dna forum-wall
hc scaffold zome posts
hc scaffold call post \
  message:String
hc scaffold entry tweet \
  tweet_body:Vec[u8]
  tweet_links:Vec[links]

or

cd my_project
npx @holochain-scaffolding/gui # Brings up the UI
hn-scaffolding # alias?

#### CI
Q: How do we confirm that code scaffolded by the scaffolded code works with the current version of the conductor?
A: Scaffold also scaffold tests that are run in CI. Once the version in default.nix is auto-bumped, then CI will catch any mismatches.

### Next steps

All these steps need to keep in mind that we are not going to be just "creating" apps anymore but editing them instead.

1. Rewrite the generators for scaffolding in rust.
2. Embed the generators in `holochain_cli` by creating a `hc_scaffold` binary that will produce the UX of `hc scaffold zome posts`.
3. Include the `hc_generate` binary in holonix.
4. Refactor the UI to use the same generators.
5. `hc_generate` should take the last version from `hn-versions` and set it in default.nix.

## Phase 1:

**Target:** Enable web developers (who are not Rust experts) to bootstrap themselves into having the basic elements of a hApp to bring across the finish line.

**Basic elements =**
1. New DNA with: Element defs, CRUD functions, support for anchors, and get_link functions for retrieving collections.
2. Basic CRUD tests
3. Basic UI components for calling CRUD (using [jsonforms](https://www.npmjs.com/package/@jsonforms/vue))

#### Workflow

Run locally via `npm init @holochain` to have direct file access via express server. We can later add the ability to import/export zip file.

Take dev through the process of structuring an app by defining:
- DNAs (new or select from devhub)
- Select from existing "library" of DNAs
- Create custom DNA
- Zomes (new or select some mixins)
- Select from existing "library" of zome
- Create custom zome
- Entries (rust struct builder with ui edit/display widget hints from jsonsch)
- Devs create sample data as JSON which is used to create EntryDef and jsonform UI for creating & editing entries.
- Links / Get_links --> List collection functions
- (GUI?) Link editor that allows dev to create links as arrows from one entry def to another with tag as 'words' along the arrow. (Note: This may take multiple iterations to get UX right.) Links are created during CRUD. If they want to make other custom links at another time, they'll have to code that manually at the moment.

File Structure: Separate generated code from custom edited code for easy reimport and updating via the scaffolding.

### DevHub
- `zome_library` zome that you can pull zomes from -> these needs to be coded by Guillem
- You can pull zomes or DNAs from the DevHub to scaffold your happ.

#### Menu Features:
- Create new app (clear junk in progress and start over)
- (Note download / upload become unnecessary with the file system API for the browser)
- Switch Language
- Connect to DevHub
- About hApp Generator

#### Templates / Components for DNAs or apps
- Roles: https://hackmd.io/wkrHreFGTWKiggtNNN8IAQ
- Progenitor:
- Profiles:

##### Sample JsonSchema approach for EntryDef

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "properties": {
    "agent_pub_key": {
      "type": "string"
    },
    "handle": {
      "type": "string"
    },
    "reputation": {
      "type": "number",
      "widget": "rating"
    }
  },
  "required": [
    "agent_pub_key",
    "handle",
    "reputation"
  ]
}

## Later Phases
- Blockly code editing/generation
- UI widget registry
- UI drag and drop layout pallette?
- JsonSchema builder?

# Meeting Notes

## 2022-10-14

Attendees
* Guillem
* Stefan

### Notes

- scaffolding
- GM has been rewriting in rust
- cannot scaffold zome code yet
- can scaffold structure
- issues
- hc depends on hc-bundle and hc-sandbox
- GM's going to look at [cargo's pattern](https://github.com/rust-lang/cargo/blob/master/src/bin/cargo/main.rs#L224-L247) and try to apply it to hc
- entrypoints
- the npm entrypoint proves to be difficult because there issue with compiling some things to wasm
- holochain_types crate. the following subdirs
- app/app_manifest
- dna/dna_manifest
- web/webapp_manifest
- scaffolding x holonix integration
- applies only to linux and macos
- holonix will include the rust based derivation
- aligning versions for the hc-scaffold crate and holonix
- hc-scaffold release process is gated on an holonix integration test
- holonix that includes hc-scaffold exposes binaries that hc-scaffold indicates support for

## 2022-11-22

- `nix run https://holochain.love#hc -- scaffold web-app` sets up a default.nix that points to the holonix repository
- That derivation that lives on holonix depends on:
- The derivations from the holochain main repository
- The derivation from the scaffolding repository
- The derivation from the launcher repository

The default.nix looks like this:

let
  holonixPath = (import ./nix/sources.nix).holonix; # points to the current state of the Holochain repository
  holonix = import (holonixPath) {
    holochainVersionId = "v0_0_173"; # specifies the Holochain version
  };
  nixpkgs = holonix.pkgs;
in nixpkgs.mkShell {
  inputsFrom = [ holonix.main ];
  packages = with nixpkgs; [
    niv
    # any additional packages needed for this project, e. g. Nodejs
  ];
}

---

The default.nix in holochain-client-js looks like this:

let
  holonixPath = (import ./nix/sources.nix).holonix; # points to the current state of the Holochain repository
  holonix = import (holonixPath) {
    holochainVersionId = "v0_0_173"; # specifies the Holochain version
    include = {
      holochainBinaries = true;
      node = false;
      happs = false;
      scaffolding = false;
      niv = false;
    };
  };
  nixpkgs = holonix.pkgs;
in nixpkgs.mkShell {
  inputsFrom = [ holonix.main ];
  packages = with nixpkgs; [
    niv
    # any additional packages needed for this project, e. g. Nodejs
  ];
}

---

Release flow:

1. Weekly release in holochain repository
2. A scheduled CI in the holochain-nixpgs repository checks that there is a new version and spawns a PR
- The PR will trigger a build
- If the build succeeds, it's pushed to cachix
- The PR is merged
3. If there is a breaking change in the conductor api, there is a new version in npm
4. The scaffolding tool points to that new holochain version and client version, and releases a new version
5. Holonix gets updated to point to the new scaffolding version

---

How to check whether a new version of holochain is compatible with the existing scaffolding CLI:

1. Call `hc-scaffold versions` to check whether the new version of holochain is semantically compatible with the version requirement specified in the scaffolding cargo manifest.
NOTE TO HC DEVS: be careful to adhere to SemVer between the holochain, hdk, and hdi crates.
2. If the versions are compatible, run the tests.

sequenceDiagram

CI->>holochain-nixpkgs-util: update-holochain-tags
holochain-nixpkgs-util->>holochain-nixpkgs-util: get tags from holochain repository
holochain-nixpkgs-util->>holochain-nixpkgs-util: filter by holochain- prefix
holochain-nixpkgs-util->>holochain-nixpkgs-util: if tag is not in the `update_config.toml` file, add it there
holochain-nixpkgs-util->>holochain-nixpkgs-util: if some config file has changed, commit it
loop for each new config file entry
  holochain-nixpkgs-util->>hnixpkgs-update-single: changed config file
  hnixpkgs-update-single->>hnixpkgs-update-single: read config toml file
  hnixpkgs-update-single->>update-holochain-versions: invoke with update_config.toml args
  update-holochain-versions->>update-holochain-versions: generate nix derivation for holochain version
  
end