Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
126 lines (88 loc) · 4.98 KB

CONTRIBUTING.md

File metadata and controls

126 lines (88 loc) · 4.98 KB
Raw

Contributing to drawDB

Thanks for taking the time to contribute!

The following is a set of guidelines for contributing to our project. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.

Table of Contents

  1. How Can I Contribute?
  2. Style Guides
  3. Additional Notes

How Can I Contribute?

Reporting Bugs

This section guides you through submitting a bug report for our project. Following these guidelines helps maintainers and the community understand your report, reproduce the behavior, and find related reports.

  • Use a clear and descriptive title for the issue to identify the problem.
  • Describe the exact steps which reproduce the problem in as many details as possible.
  • Provide specific examples to demonstrate the steps (e.g. if you're having trouble importing a file please attach it or provide a link to it).
  • Include screenshots if applicable.
  • Explain which behavior you expected to see instead and why.

Suggesting Enhancements

This section guides you through submitting an enhancement suggestion for our project, including completely new features and minor improvements to existing functionality.

  • Use a clear and descriptive title for the issue to identify the suggestion.
  • Explain why this enhancement would be useful to most users.

Submitting Pull Requests

If you would like to implement a big feature that has not been discussed before please reach out to the maintainer on Discord at @dottle_ or send an email to drawdb@outlook.com.

Please follow these steps to have your contribution considered by the maintainers:

  1. Make sure the pull request you work on is atomic. That is, it implements a single feature or fixes a single bug.
  2. Fork the repository and create your branch from main.
  3. Write clear, descriptive commit messages.
  4. Ensure your code adheres to the project's style guides.
  5. Create a pull request.
  6. Make sure to explain what your pull request solves unless it fixes something already explained in an issue that it's linked to.
  7. Explain the solution. If you implement a more involved feature explain the design decisions.

Style Guides

Git Commit Messages

  • Use the present tense (e.g. "Add Spanish locale" not "Added Spanish locale").
  • Use the imperative mood (e.g. "Move cursor to..." not "Moves cursor to...").
  • Reference issues and pull requests liberally after the first line.

Style Guide

  • Format your code with Prettier.
  • Ensure your code passes ESLint.
  • Make sure the code base is in English, this includes comments and variable names.

Undo/Redo: pushUndo vs setUndoStack

When recording history, prefer the high-level helper pushUndo(action) from UI/components for simple append-and-clear behavior. pushUndo centralizes validation, deduplication and coalescing so the app maintains a sane undo/redo history.

However, some modules implement the low-level undo/redo engine and must manipulate the stacks directly using setUndoStack / setRedoStack. Do NOT replace those internal usages with pushUndo.

Files that intentionally use direct stack manipulation include (but are not limited to):

  • src/components/EditorCanvas/Canvas.jsx
  • src/components/EditorHeader/ControlPanel.jsx
  • src/components/EditorHeader/Modal/Modal.jsx
  • src/components/Workspace.jsx
  • src/context/UndoRedoContext.jsx

Correct usage (UI-side append+clear):

// Add a simple EDIT action and clear redo
pushUndo({
    action: Action.EDIT,
    element: ObjectType.TABLE,
    tid,
    undo,
    redo,
    message,
});

Incorrect to change internal code to this (keep low-level code as-is):

// Internal undo engine — keep setUndoStack for low-level manipulation
setUndoStack((prev) => prev.filter((_, i) => i !== prev.length - 1));
setRedoStack((prev) => [...prev, action]);

If you're unsure which to use, prefer pushUndo for component-level changes and ask during code review for anything touching the stacks directly.

Additional Notes

Issue and Pull Request Labels

This section lists the labels we use to help organize and identify issues and pull requests.

  • bug: Something isn't working.
  • enhancement: New feature or request.
  • question: Further information is requested.
  • documentation: Improvements or additions to documentation.
  • good first issue: Good for newcomers.
  • help wanted: Extra attention is needed.

Getting Help

If you have any questions, please feel free to reach out to us through the following channels:

Thank you for your contributions! ❤️