Skip to content

contribution-guidelines.md

Latest commit

 

History

History
205 lines (171 loc) · 4.83 KB

contribution-guidelines.md

File metadata and controls

205 lines (171 loc) · 4.83 KB

Contributing to JSX Framework

We love your input! We want to make contributing to the JSX Framework as easy and transparent as possible, whether it's:

  • Reporting a bug
  • Discussing the current state of the code
  • Submitting a fix
  • Proposing new features
  • Becoming a maintainer

Development Environment Setup

Directory Structure

JSX/
├── src/
│   ├── core/                  # Core JSX engine
│   │   ├── build/           # Build system
│   │   ├── runtime/         # Runtime implementation
│   │   ├── types/          # Type system
│   │   └── functions/      # Core functions
│   │
│   ├── systems/              # System implementations
│   │   ├── render/          # Rendering system
│   │   ├── state/          # State management
│   │   ├── effects/        # Effect handling
│   │   └── events/         # Event system
│   ├── test/      
│   ├── data/      
│   ├── effects/   
│   ├── forms/     
│   ├── layout/    
│   ├── lifecycle/ 
│   ├── performance/
│   ├── security/  
│   ├── state/     
│   └── validation/
├── examples/      
├── tests/         
└── docs/

Development Process

  1. Fork the repo and create your branch from main
  2. If you've added code that should be tested, add tests
  3. If you've changed APIs, update the documentation
  4. Ensure the test suite passes
  5. Make sure your code follows the style guidelines
  6. Issue that pull request!

Coding Standards

Code Style

  • Use 4 spaces for indentation
  • Use camelCase for variable and function names
  • Use PascalCase for component names
  • Add comments for complex logic
  • Keep functions small and focused
  • Follow functional programming principles

Function Architecture

// Correct: Clear inputs, outputs, and dependencies
const processData = (data, transformer) => {
    if (!data || !transformer) {
        return Either.Left('Invalid input');
    }
    return Either.Right(transformer(data));
};

// Incorrect: Side effects and unclear dependencies
const processData = (data) => {
    globalVariable = data;  // Avoid global state
    return transform();     // Avoid hidden dependencies
};

Testing Standards

// Example test
test.suite('ThemeButton', () => {
    test.it('should toggle theme', () => {
        const button = createThemeButton();
        button.click();
        test.expect(button.theme).toBe('dark');
    });
});

Pull Request Process

1. Branch Naming

Use descriptive branch names following the pattern:

  • feature/description
  • fix/description
  • docs/description
  • refactor/description

2. Commit Standards

type(scope): description

- type: feat, fix, docs, style, refactor, test, chore
- scope: core, render, event, etc.
- description: clear, concise explanation

3. Pull Request Requirements

  1. Update the README.md with details of changes to the interface
  2. Update the CHANGELOG.md with version history
  3. The PR will be merged once you have the sign-off of two other developers

4. Pull Request Template

## Description
[Detailed description of changes]

## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Documentation update
- [ ] Refactoring

## Technical Details
- [ ] Follows function architecture
- [ ] Uses framework types
- [ ] Maintains state immutability
- [ ] Includes tests
- [ ] Updates documentation

## Testing
- [ ] Unit tests
- [ ] Integration tests
- [ ] Performance tests

Issue Reporting

Bug Reports

## Bug Description
[Clear, concise description]

## Expected Behavior
[What should happen]

## Current Behavior
[What actually happens]

## Reproduction Steps
1. [Step 1]
2. [Step 2]
3. [Step 3]

## Environment
- Browser:
- Version:
- OS:

Feature Requests

## Feature Description
[Clear description of proposed feature]

## Problem Statement
[What problem does this solve]

## Proposed Solution
[How should it work]

## Alternative Solutions
[Other approaches considered]

Documentation Standards

Code Comments

/**
 * Updates application state immutably
 * @param {State} state Current state
 * @param {Function} updater State update function
 * @returns {Either<Error, State>} Updated state or error
 */
const updateState = (state, updater) => {
    // Implementation
};

Documentation Updates

  • Update README.md with interface changes
  • Update CHANGELOG.md with version history
  • Add JSDoc comments for new functions
  • Include examples for new features

Questions and Support

  • Feel free to open an issue with the tag "question"
  • Check existing issues and documentation first
  • Be clear and provide context

Version Information

  • Guidelines Version: 1.0
  • Framework Version: 1.0
  • Last Updated: 2024-12-19