🚀 Program
ELUSOC
💡 Feature Description
Add complete support for the Input/Output (IO) block type throughout the flowchart editor, including creation, editing, rendering, and layout integration.
🧩 Problem Statement
The project already defines an io value in the ShapeType type (alongside terminator, process, and decision), indicating that Input/Output blocks were intended to be supported.
However, this block type is currently incomplete:
- The IO block is missing from
initialDemoBlocks, so users cannot see or use it in the default flowchart.
- The block creation sidebar does not provide an option to add an IO block.
- Users cannot easily create or edit IO blocks through the existing UI.
- The standard flowchart parallelogram shape is therefore unavailable, making it impossible to build fully standards-compliant flowcharts.
As a result, users creating algorithms, system diagrams, or process documentation must incorrectly use Process blocks to represent input/output operations, reducing clarity and adherence to flowchart conventions.
🛠️ Proposed Solution
Implement complete support for the Input/Output (IO) block type across the application.
Suggested implementation
1. Add IO block to the sidebar
Update:
src/components/LeftSidebar.tsx
Add an Input/Output option alongside:
- Terminator
- Process
- Decision
Selecting it should create an io block.
2. Support IO block creation
Update the block creation logic so new blocks can be initialized as:
with the same default properties used by other block types.
3. Add IO block to demo data
Update:
src/components/CenterCanvas.tsx
(or wherever initialDemoBlocks is defined)
Include at least one example IO block, such as:
- Read Input
- Display Output
- Print Result
This allows new users to immediately understand the feature.
4. Render the standard IO shape
Render IO blocks as the conventional parallelogram used in flowcharts.
The styling should remain consistent with the project's existing design system while clearly differentiating IO blocks from Process blocks.
5. Ensure layout compatibility
Review:
Verify that layout calculations correctly support the new block type without affecting automatic positioning or edge routing.
6. Editing support
Ensure existing edit dialogs/forms support IO blocks exactly like other block types:
- Label editing
- Position updates
- Connections
- Serialization
- Import/export compatibility (if applicable)
Expected Result
Users should be able to:
- Add Input/Output blocks from the sidebar
- Edit IO block labels
- See IO blocks rendered as parallelograms
- Connect IO blocks with other flowchart elements
- Save and reload diagrams containing IO blocks
- View IO blocks in the demo flowchart
🔄 Alternatives Considered
Alternative 1: Continue using Process blocks
Users could represent input/output operations using Process blocks.
Why rejected
This does not follow standard flowchart notation and reduces diagram readability.
Alternative 2: Allow custom shapes only
Provide generic custom shapes instead of implementing IO.
Why rejected
The project already defines an io type in ShapeType, indicating that native support was planned. Completing the existing implementation is simpler, more consistent, and provides a better user experience.
📎 Additional Context
The project already contains an unused io entry within ShapeType, suggesting that this functionality was intended but never fully implemented.
Likely files involved:
src/components/LeftSidebar.tsx
src/components/CenterCanvas.tsx
src/utils/layout.ts
Estimated Difficulty: Easy
Estimated Code Size: ~100 lines
Benefits
- Completes an existing but unused feature.
- Makes the editor compliant with standard flowchart notation.
- Improves usability for algorithm visualization and educational workflows.
- Requires minimal architectural changes since the type already exists.
Probability of Acceptance: High
Confidence Score: 9/10
✔️ Pre-submission Checklist
🚀 Program
ELUSOC
💡 Feature Description
Add complete support for the Input/Output (IO) block type throughout the flowchart editor, including creation, editing, rendering, and layout integration.
🧩 Problem Statement
The project already defines an
iovalue in theShapeTypetype (alongsideterminator,process, anddecision), indicating that Input/Output blocks were intended to be supported.However, this block type is currently incomplete:
initialDemoBlocks, so users cannot see or use it in the default flowchart.As a result, users creating algorithms, system diagrams, or process documentation must incorrectly use Process blocks to represent input/output operations, reducing clarity and adherence to flowchart conventions.
🛠️ Proposed Solution
Implement complete support for the Input/Output (IO) block type across the application.
Suggested implementation
1. Add IO block to the sidebar
Update:
src/components/LeftSidebar.tsxAdd an Input/Output option alongside:
Selecting it should create an
ioblock.2. Support IO block creation
Update the block creation logic so new blocks can be initialized as:
type: "io"with the same default properties used by other block types.
3. Add IO block to demo data
Update:
(or wherever
initialDemoBlocksis defined)Include at least one example IO block, such as:
This allows new users to immediately understand the feature.
4. Render the standard IO shape
Render IO blocks as the conventional parallelogram used in flowcharts.
The styling should remain consistent with the project's existing design system while clearly differentiating IO blocks from Process blocks.
5. Ensure layout compatibility
Review:
Verify that layout calculations correctly support the new block type without affecting automatic positioning or edge routing.
6. Editing support
Ensure existing edit dialogs/forms support IO blocks exactly like other block types:
Expected Result
Users should be able to:
🔄 Alternatives Considered
Alternative 1: Continue using Process blocks
Users could represent input/output operations using Process blocks.
Why rejected
This does not follow standard flowchart notation and reduces diagram readability.
Alternative 2: Allow custom shapes only
Provide generic custom shapes instead of implementing IO.
Why rejected
The project already defines an
iotype inShapeType, indicating that native support was planned. Completing the existing implementation is simpler, more consistent, and provides a better user experience.📎 Additional Context
The project already contains an unused
ioentry withinShapeType, suggesting that this functionality was intended but never fully implemented.Likely files involved:
src/components/LeftSidebar.tsxsrc/components/CenterCanvas.tsxsrc/utils/layout.tsEstimated Difficulty: Easy
Estimated Code Size: ~100 lines
Benefits
Probability of Acceptance: High
Confidence Score: 9/10
✔️ Pre-submission Checklist