Enhancing canvas coding mode with declarative outline

ChatGPT Feature requests
,
1

The current title doesn’t fully capture the depth of this idea, and I can’t think of any existing application that offers what is being proposed.

At present, when using GPT-4o with canvas in coding mode, you interact with a single canvas displaying code and a separate prompt window for conversational changes. While this setup works, many changes would be far more effective with the addition of a second canvas dedicated to a declarative outline of the code.

In essence, writing code often begins with a simple, declarative prompt. As the code evolves, the prompt grows richer, effectively acting as a progressively detailed outline. This new way would introduce a declarative outline in a second canvas that could then serve as a living blueprint for both developing and maintaining the code.

The workflow could be as follows: users modify the declarative outline, and ChatGPT updates the corresponding code in the other canvas. If errors arise, they are reported back to ChatGPT in the conversation, which adjusts both the code and the outline accordingly.

By the end of the process, not only would you have functional code, but also a clear declarative outline that doubles as documentation. This outline could even be used as a self-contained prompt to recreate the code, streamlining the development process while providing a built-in reference for future use.

A potential future enhancement could work with modular code, for example, an object-oriented design with classes. This would allow each component to be maintained in its own canvas, effectively overcoming the size limitations of a single canvas. These limitations often necessitate abandoning the use of canvas entirely for larger projects.

Additionally, since much code is hierarchical in nature, ChatGPT can often infer code concepts accurately when certain parts are replaced with descriptive comments, such as:

class XYZ(A, B, C):
    # Implementation goes here

This approach enables the handling of more complex code structures while maintaining clarity and modularity.

While I mostly program, this pattern of placing an outline between the prompting and created result can be used for more than just coding.

  • Writing a book
  • Creating a picture with DALL*E
  • Composing a song (haven’t done this yet)

For a recent small prototype code used this prompt to create the outline

Create a detailed declarative outline that can be used as a prompt to recreate the code and also serve as user documentation.

This created the following which when used as prompt for GPT-4o created a working page very similar to the original but with some differences and errors but fairly close considering the level of detail.

Outline

Declarative Outline for Code Creation and Documentation

Overview

This application demonstrates an event-driven architecture where a Model validates all inputs and handles state changes, while multiple Views interact with the Model through a central Message Bus. Each View displays errors and updates dynamically based on feedback from the Model. This design is suitable for scenarios requiring decoupled components with centralized validation.

Components

1. Model

The Model serves as the single source of truth. It:

  • Holds three key pieces of data:
    • primaryValue: A number that represents the main value of the system.
    • min: The minimum allowable value for primaryValue.
    • max: The maximum allowable value for primaryValue.
  • Performs all data validation:
    • Ensures primaryValue is within the range [min, max].
    • Validates that min is less than max.
  • Emits events for success and failure through the Message Bus:
    • primaryValueChanged: Broadcast when primaryValue is successfully updated.
    • rangeUpdated: Broadcast when min and max are successfully updated.
    • error: Broadcast when validation fails (indicating the source of the error and a descriptive message).

2. Message Bus

The Message Bus is implemented using the EventTarget API to:

  • Facilitate communication between the Model and Views.
  • Allow any component to dispatch and listen for events.

3. Views

Each View is a self-contained UI component responsible for displaying data, receiving user input, and reacting to events from the Model.

a. View A: Up/Down Control

  • Displays:
    • A title: "Up/Down Control"
    • Two buttons: "+" and "-" for incrementing and decrementing primaryValue.
    • The current value of primaryValue as text.
    • An error message area.
  • Behavior:
    • Dispatches requestPrimaryValueChange when buttons are clicked.
    • Updates its value display on primaryValueChanged.
    • Displays error messages on error (if the source is primaryValue).

b. View B: Keyboard Input

  • Displays:
    • A title: "Keyboard Input"
    • A text input field for entering primaryValue.
    • An error message area.
  • Behavior:
    • Dispatches requestPrimaryValueChange with the entered value.
    • Updates its input value on primaryValueChanged.
    • Displays error messages on error (if the source is primaryValue).

c. View C: Horizontal Slider

  • Displays:
    • A title: "Horizontal Slider"
    • A slider input (<input type="range">) for modifying primaryValue.
    • The current value of primaryValue as text.
  • Behavior:
    • Dispatches requestPrimaryValueChange with the slider’s value.
    • Updates its slider position and value display on primaryValueChanged.

d. Limit View

  • Displays:
    • A title: "Set Range"
    • Two input fields for min and max.
    • A button labeled "Set" for submitting the range.
    • The current range [min, max] as text.
    • An error message area.
  • Behavior:
    • Dispatches requestRangeChange with the new min and max.
    • Updates the displayed range on rangeUpdated.
    • Displays error messages on error (if the source is range).

Events

Dispatched by Views

  1. requestPrimaryValueChange:

    • Payload:
      • value: The new primaryValue or the amount to increment/decrement.
      • operation (optional): "increment" for relative changes, otherwise absolute.
    • Purpose: Request the Model to validate and update primaryValue.

  2. requestRangeChange:

    • Payload:
      • min: The new minimum value.
      • max: The new maximum value.
    • Purpose: Request the Model to validate and update the range.

Dispatched by the Model

  1. primaryValueChanged:

    • Payload:
      • value: The successfully updated primaryValue.
    • Purpose: Notify Views to update their displays.

  2. rangeUpdated:

    • Payload:
      • min: The updated minimum value.
      • max: The updated maximum value.
    • Purpose: Notify Views to update the displayed range.

  3. error:

    • Payload:
      • source: The source of the error ("primaryValue" or "range").
      • message: A descriptive error message.
    • Purpose: Notify Views to display appropriate error messages.

UI Behavior and Error Handling

  • Validation Delegation:

    • Views pass all input to the Model without validation.
    • The Model validates the input and sends success or error feedback.

  • Dynamic Updates:

    • On success:
      • All Views update their displays based on primaryValueChanged or rangeUpdated.
    • On failure:
      • The View that initiated the change displays the error message from the error event.

Usage Example

Setting a Range

  1. User enters min = 10 and max = 5 in the Limit View.
  2. Limit View dispatches requestRangeChange with { min: 10, max: 5 }.
  3. The Model validates and emits an error with:
    • source: "range"
    • message: "Invalid range. Min must be less than Max."
  4. Limit View displays the error message.

Updating Primary Value

  1. User clicks + in View A.
  2. View A dispatches requestPrimaryValueChange with { value: 1, operation: "increment" }.
  3. The Model adds 1 to the current primaryValue (if valid) and emits:
    • primaryValueChanged with the new value.
  4. All Views update their displays to reflect the new value.

Extensibility

  • Adding New Views:

    • Create a new View component that listens for primaryValueChanged, rangeUpdated, and error.
    • Dispatch events as needed (e.g., requestPrimaryValueChange or requestRangeChange).

  • Extending Validation:

    • Modify the Model to include additional validation rules.
    • Use the error event to notify Views of new validation errors.

This declarative outline can serve as both a prompt for recreating the code and user documentation for understanding how the system works. Let me know if you’d like further refinements or additions!