Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 2 additions & 3 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
<div align="center">
<div align="center">

![banner](https://i.imgur.com/pNIYDWO.png)

Expand Down Expand Up @@ -37,9 +37,8 @@ Shout out to our contributors! We appreciate your continous efforts. Here's what

-Save-button-The saveStore and reloadStore were updated to improve canvas state capture, now saving complete node information (including positions and properties) for more accurate reconstruction. However, reloadStore still needs work to properly render nodes and rebuild the graph after a reload, requiring focus on better graph store integration in future development.



- **Refactoring**:

- We have recreated the Svelvet canvas by removing the default nodes.
- We added an "Add Node" button that allows for the creation of nodes with default anchors.
- Edges can now be created and connected to nodes.
Expand Down
117 changes: 53 additions & 64 deletions Version11 README_1.md/Graphstore.README.md
Original file line number Diff line number Diff line change
@@ -1,38 +1,39 @@
## Project Documentation: Svelvet Graph Component Issues & Iteration Progress

## Problem Statement

The current implementation of the Svelvet Graph component is encountering issues related to state management, event handling, and certain prop behaviors. Specifically, the following problems have been observed:

- Graph Initialization Issues:
-The graph variable is not always correctly initialized or updated after mounting.
-Local storage retrieval sometimes results in an inconsistent graph state.

-The graph variable is not always correctly initialized or updated after mounting.
-Local storage retrieval sometimes results in an inconsistent graph state.

- Drawer Prop Behavior:
-The drawer prop is not reliably affecting the Graph component’s behavior.
-The console logs confirm that the drawer value is passed but does not always trigger the expected UI updates.

-The drawer prop is not reliably affecting the Graph component’s behavior.
-The console logs confirm that the drawer value is passed but does not always trigger the expected UI updates.

- Edge Management Problems:
-The disconnect function does not always properly remove edges between nodes.
-Edges are not consistently detected or updated in edgeStore.
-The disconnect function does not always properly remove edges between nodes.
-Edges are not consistently detected or updated in edgeStore.

- Zoom and Translation Handling:
-Two-way binding for Zoom is inconsistent, making it difficult to maintain the expected behavior.
-The initial translation of the graph sometimes does not apply correctly.
-Two-way binding for Zoom is inconsistent, making it difficult to maintain the expected behavior.
-The initial translation of the graph sometimes does not apply correctly.

- Event Dispatching Issues:
-onEdgeChange does not always correctly trigger events when edges are updated.
-Some events do not propagate as expected, leading to missing state updates.
-onEdgeChange does not always correctly trigger events when edges are updated.
-Some events do not propagate as expected, leading to missing state updates.

# Documentation for Add Node Button

# Overview

The Add Node button in the Svelvet Graph Editor allows users to dynamically add new nodes to the graph. When clicked, it increments the total number of nodes and places them in a randomized position within the graph editor.

- Functionality
-The button is located inside a Node component.
-It increments the totalNodes variable.
-The new nodes are created using a Svelte {#each} loop, placing them at randomly generated positions.
-The button is located inside a Node component.
-It increments the totalNodes variable.
-The new nodes are created using a Svelte {#each} loop, placing them at randomly generated positions.

```Code Snippet
<Node bgColor="red" inputs={4} position={{ x: 600, y: 200 }} draggable>
Expand All @@ -41,86 +42,74 @@ The Add Node button in the Svelvet Graph Editor allows users to dynamically add
```

- Behavior
-When clicked, totalNodes increase by 1.
-The {#each} loop detects the change and renders a new Node at a randomized position.
-The new node is draggable and maintains the default properties.

-When clicked, totalNodes increase by 1.
-The {#each} loop detects the change and renders a new Node at a randomized position.
-The new node is draggable and maintains the default properties.

- Usage
This feature is useful for users who want to expand their graph by dynamically adding new elements without manually configuring each node.

This feature is useful for users who want to expand their graph by dynamically adding new elements without manually configuring each node.

# Suspected Causes

- State Management & Context Issues:
-The graph variable is set using setContext, but it may not be updating across components as expected.
graphStore.add(graph, graphKey); might not be correctly persisting the graph state.
-The graph variable is set using setContext, but it may not be updating across components as expected.
graphStore.add(graph, graphKey); might not be correctly persisting the graph state.

- Component Lifecycle Problems:
-onMount() logic depends on local storage but does not properly handle cases where stored data is incomplete or invalid.
-Some values such as zoom are reactive ($:) but may not be syncing properly with the graph.
-onMount() logic depends on local storage but does not properly handle cases where stored data is incomplete or invalid.
-Some values such as zoom are reactive ($:) but may not be syncing properly with the graph.

- Event Handling & Dispatching Bugs:
-The disconnect function’s reliance on match() may fail when edge keys are not stored correctly.
-Edge events are not correctly linked to graph updates, possibly due to missing subscriptions.
-The disconnect function’s reliance on match() may fail when edge keys are not stored correctly.
-Edge events are not correctly linked to graph updates, possibly due to missing subscriptions.

- Drawer Prop Inconsistency:
-The drawer prop might not be reactive in all components where it is needed.
-There may be a missing bind: directive or event listener that causes UI updates to lag.

-The drawer prop might not be reactive in all components where it is needed.
-There may be a missing bind: directive or event listener that causes UI updates to lag.

# Steps Taken So Far
- Debugging Graph Initialization:
-Added console logs in onMount() to check local storage retrieval.
-Verified that graphStore.add(graph, graph.id); is correctly adding graphs.
-Tested different cases where stateObject exists or does not exist.

- Debugging Graph Initialization:
-Added console logs in onMount() to check local storage retrieval.
-Verified that graphStore.add(graph, graph.id); is correctly adding graphs.
-Tested different cases where stateObject exists or does not exist.

- Testing Drawer Prop Behavior:
-Added a reactive statement ($: console.log("Svelvet drawer prop:", drawer);) to track updates.
-Verified that drawer is correctly passed as a prop to <Graph /> but does not always trigger updates.

-Added a reactive statement ($: console.log("Svelvet drawer prop:", drawer);) to track updates.
-Verified that drawer is correctly passed as a prop to <Graph /> but does not always trigger updates.

- Edge Management Fix Attempts:
-Checked edgeStore updates with console.log(edgeStore);.
-Modified disconnect() to ensure it correctly retrieves sourceAnchor and targetAnchor before deleting.
-Observed cases where match() failed and edge keys were not found.

-Checked edgeStore updates with console.log(edgeStore);.
-Modified disconnect() to ensure it correctly retrieves sourceAnchor and targetAnchor before deleting.
-Observed cases where match() failed and edge keys were not found.

- Zoom & Translation Adjustments:
-Added $: reactive statements to monitor zoom changes.
-Tested explicit calls to update graph.transforms.scale.set(zoom);.

-Added $: reactive statements to monitor zoom changes.
-Tested explicit calls to update graph.transforms.scale.set(zoom);.

- Event Dispatching Debugging:
-Verified that onEdgeChange receives updates.
-Checked if dispatch(type, {...}) correctly sends expected event payloads.
-Found inconsistencies in when events were triggered.


-Verified that onEdgeChange receives updates.
-Checked if dispatch(type, {...}) correctly sends expected event payloads.
-Found inconsistencies in when events were triggered.

# Future Work & Recommendations

- Refactor State Management:
-Ensure graphStore correctly reflects the current graph state.
-Consider adding an explicit updateGraph() function to handle changes.
-Ensure graphStore correctly reflects the current graph state.
-Consider adding an explicit updateGraph() function to handle changes.

- Fix Drawer Prop Issues:
-Investigate whether the drawer needs a Svelte store for reactivity.
-Ensure it is correctly passed to all necessary child components.

-Investigate whether the drawer needs a Svelte store for reactivity.
-Ensure it is correctly passed to all necessary child components.

- Improve Edge Handling Logic:
-Debug disconnect() to confirm that edges are reliably removed.
-Add test cases where edges are added, removed, and re-added.

-Debug disconnect() to confirm that edges are reliably removed.
-Add test cases where edges are added, removed, and re-added.

- Enhance Event Dispatching:
-Ensure onEdgeChange fires consistently.
-Investigate using graph.edges.subscribe() to track changes.

-Ensure onEdgeChange fires consistently.
-Investigate using graph.edges.subscribe() to track changes.

- Improve Zoom & Translation Behavior:
-Verify that zoom level updates propagate through all necessary components.
-Implement explicit setters for zoom and translation where necessary.


-Verify that zoom level updates propagate through all necessary components.
-Implement explicit setters for zoom and translation where necessary.
40 changes: 23 additions & 17 deletions Version11 README_1.md/Snapgrid and Padlock.md
Original file line number Diff line number Diff line change
@@ -1,59 +1,65 @@
# Snap-Grid Feature Overview

# Introduction

The Snap-Grid functionality is a game-changer for node placement, providing users with enhanced flexibility and precision when positioning elements on a canvas. This feature bridges the gap between total freedom and organized structure, allowing users to drag nodes freely or snap them into perfect alignment with a simple keyboard click.

# Purpose

The Snap-Grid functionality was created to address the need for both creative freedom and precise control in node placement. Whether designing layouts, organizing elements, or working with complex arrangements, users now have the ability to:

- Move nodes freely: Drag nodes anywhere on the canvas without restriction.
- Snap nodes into place: Achieve perfectly aligned layouts instantly with a keyboard click.
This feature allows users to toggle between these two modes seamlessly, enhancing both the design experience and the organization of the layout.
This feature allows users to toggle between these two modes seamlessly, enhancing both the design experience and the organization of the layout.

# How it Works

The Snap-Grid feature integrates smoothly with the node manipulation system. Here's how it operates:

- Free Movement Mode:
Users can click and drag nodes anywhere on the canvas without constraints. This is ideal for precise placements and creative adjustments.
Users can click and drag nodes anywhere on the canvas without constraints. This is ideal for precise placements and creative adjustments.

- Snap-to-Grid Mode:
Activate Snap-Grid: Press the arrow-key to snap nodes into a place..
This allows for rapid toggling between free movement and snapping, empowering users to design with full control.

Activate Snap-Grid: Press the arrow-key to snap nodes into a place..
This allows for rapid toggling between free movement and snapping, empowering users to design with full control.

# Conclusion
The Snap-Grid functionality is designed to make node placement easier, faster, and more efficient. By providing the option to toggle between free movement and snap-to-grid modes, users can achieve a balance of creativity and control, making it a valuable addition to any project that requires node manipulation.

The Snap-Grid functionality is designed to make node placement easier, faster, and more efficient. By providing the option to toggle between free movement and snap-to-grid modes, users can achieve a balance of creativity and control, making it a valuable addition to any project that requires node manipulation.

# Revamped Padlock Feature

# Introduction

In Svelvet 11, we’ve redefined the Padlock feature to align more intuitively with its intended behavior, ensuring a smoother and more logical experience when managing nodes. Previously, a locked padlock would still allow nodes to be moved, which created confusion regarding its functionality. With this update, we’ve ensured that the padlock operates as expected—locked nodes stay in place, and unlocked nodes are free to move.

# Purpose

The primary goal of this revamped Padlock feature is to provide a more intuitive and predictable experience when managing nodes on the canvas. By making the padlock behavior more logical, users can now focus on their work without worrying about unintended movements or misinterpretations of the locking feature.

The core changes are:
-Locked nodes remain stationary: Once a node is locked, it can no longer be moved, ensuring it remains in its designated position.
-Unlocked nodes can be moved freely: When a node is unlocked, users can move it around as needed, providing complete flexibility.

# How it Works

The updated Padlock feature works by enforcing the following behaviors:

- Locking a Node:
When a node is locked (indicated by the locked padlock icon), it will remain stationary on the canvas.
The user cannot accidentally move the node in any way. This ensures that the locked node’s position remains fixed, ideal for anchoring elements in a design.
When a node is locked (indicated by the locked padlock icon), it will remain stationary on the canvas.
The user cannot accidentally move the node in any way. This ensures that the locked node’s position remains fixed, ideal for anchoring elements in a design.

- Unlocking a Node:
When a node is unlocked (indicated by the unlocked padlock icon), the user can freely move it across the canvas.
This gives users the flexibility to reposition elements whenever needed, allowing for dynamic design adjustments.

When a node is unlocked (indicated by the unlocked padlock icon), the user can freely move it across the canvas.
This gives users the flexibility to reposition elements whenever needed, allowing for dynamic design adjustments.

- Visual Feedback:
Locked State: The padlock icon will be displayed as a closed lock, clearly indicating that the node is immovable.
Unlocked State: The padlock icon will display as an open lock, signaling that the node is free to be moved.

Locked State: The padlock icon will be displayed as a closed lock, clearly indicating that the node is immovable.
Unlocked State: The padlock icon will display as an open lock, signaling that the node is free to be moved.

- Toggle Mechanism:
Users can toggle the padlock status of a node with a simple click of the padlock icon. This provides quick and easy access to locking or unlocking nodes as part of their workflow.

Users can toggle the padlock status of a node with a simple click of the padlock icon. This provides quick and easy access to locking or unlocking nodes as part of their workflow.

# Conclusion
The revamped Padlock feature in Svelvet 11 provides a more logical and intuitive way to control node movement. By ensuring that locked nodes cannot be moved and unlocked nodes can, we’ve simplified the user experience and reinforced the expected behavior of the padlock. This update is a valuable improvement for users who need a more efficient and predictable way to manage their layouts and node positions.

The revamped Padlock feature in Svelvet 11 provides a more logical and intuitive way to control node movement. By ensuring that locked nodes cannot be moved and unlocked nodes can, we’ve simplified the user experience and reinforced the expected behavior of the padlock. This update is a valuable improvement for users who need a more efficient and predictable way to manage their layouts and node positions.
8 changes: 5 additions & 3 deletions Version11 README_1.md/Version 11.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,5 @@
# Welcome to Version 11 ReadMe.

# Version 11 was released in February 2025.

Our Team wanted to leave next iterators with some information that we hope can help guide you throughtout working on Svelvet's Codebase. We Thank You for your Contribution.
Expand All @@ -14,16 +15,17 @@ You are now able to create nodes and edges(refer to Graphstore readme in this fo
Uniquely, we later found that in the routes folder, there are a variety of routes there that you can visit in the browser at those specific endpoints, you will be able to see various Svelvet Features. This is something we recently found and wanted to share.

Additionally, we visited previous Versions of Svelvet. We looked at the commit histories from Svelvet(730+ commits) and found teh ones closely related to each version. I have attached the Commit SSHs for your reference. We ran:

- For Version 9
" git checkout 7ba45fdb4bfd349b4f536f61156ff66c76542f8a"
" git checkout 7ba45fdb4bfd349b4f536f61156ff66c76542f8a"

- For Version 8
"git checkout 377c65b519777d73b06cf8ccd0f6f527818dc906"
"git checkout 377c65b519777d73b06cf8ccd0f6f527818dc906"

Overall, working with Svelvet was definitely an education journey.
Diving into an unknown Codebase can seem intimidating at first but Remember "Progress is Progress no matter how small". I wouldn't consider anything a failure.

Feel free to navigate the remaining files in this Version 11 ReadMe folder to better learn about my team's contributions.

Goodluck and Best Wishes.
Team Svelvet 11 @February 2025.
Team Svelvet 11 @February 2025.
2 changes: 2 additions & 0 deletions Version11 README_1.md/saveStore and reloadStore.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,13 @@
# Persistent cavas state.

The saveStore.ts and reloadStore.ts modules work together to manage the state of the canvas. saveStore.ts converts the current state into a JSON string and stores it, while reloadStore.ts retrieves that information, parses it, and rebuilds the canvas from the JSON object. This allows for maintaining state persistence and restoring previously saved diagrams.

The saveStore.ts functionality began to be developed in version 10, where the foundations for capturing nodes via a button were laid, and in version 11.0, we took advantage of this advancement and improved the implementation, ensuring that the Save button not only saves nodes, but also stores all their complete properties, allowing for accurate reconstruction of the canvas.

In addition, we worked intensively on the implementation of the reloadStore function, which aims to restore the graph from the stored data. However, we faced several issues that prevented the graph from being correctly rebuilt and will be integrated into the graphStore. For the team continuing this functionality in the next release, we recommend focusing on the way nodes are retrieved and initialized in the store, specifically the createGraph() function as this could be the main points of failure.

# Changelog on “Save Button” (UPDATED)

In this release, we updated the saveStore and reloadStore codebase to improve canvas state capture. Node positions are now correctly saved once they are dragged onto the canvas, ensuring their location is preserved in storage.
Initially, the functionality only allowed for capturing the existence of nodes, but did not store additional properties. With this improvement, we are able to save complete information for each node, facilitating a more accurate reconstruction.
Despite these advances, reloadStore still requires work to ensure that nodes are correctly rendered after a reload. Currently, the graph is not effectively rebuilt, which represents a key area for future iterations. We recommend that the next development team focus their efforts on properly integrating the graph store when reloading data.
Loading