@umituz/react-native-settings 4.20.58 → 4.20.60

package/ARCHITECTURE.md

@@ -0,0 +1,246 @@
+# Architecture Overview
+
+Comprehensive architecture documentation for the `@umituz/react-native-settings` package following Domain-Driven Design (DDD) principles.
+
+## Purpose
+
+This document defines the architectural principles, structural organization, and design patterns governing the `@umituz/react-native-settings` package. It serves as the authoritative reference for understanding the system's layered architecture, domain organization, and interaction patterns between components.
+
+## File Paths
+
+**Base Directory**: `/Users/umituz/Desktop/github/umituz/apps/artificial_intelligence/npm-packages/react-native-settings/`
+
+**Key Structure**:
+- `/src/domains/` - Domain-specific modules
+- `/src/application/` - Application layer interfaces
+- `/src/infrastructure/` - Infrastructure implementations
+- `/src/presentation/` - UI components and screens
+
+## Architecture Layers
+
+```
+┌─────────────────────────────────────────┐
+│      Presentation Layer                 │
+│  (UI Components, Screens, Hooks)        │
+└─────────────────────────────────────────┘
+                  ↓
+┌─────────────────────────────────────────┐
+│       Application Layer                 │
+│   (Business Logic, Interfaces)          │
+└─────────────────────────────────────────┘
+                  ↓
+┌─────────────────────────────────────────┐
+│      Infrastructure Layer               │
+│  (Data Persistence, Services)           │
+└─────────────────────────────────────────┘
+                  ↓
+┌─────────────────────────────────────────┐
+│         Domain Layer                    │
+│   (Business Entities, Rules)            │
+└─────────────────────────────────────────┘
+```
+
+### Layer Responsibilities
+
+**Presentation Layer**: UI rendering and user interaction handling
+**Application Layer**: Business logic orchestration and interface definitions
+**Infrastructure Layer**: Data persistence and external service implementations
+**Domain Layer**: Business entities, rules, and domain-specific logic
+
+## Directory Structure
+
+```
+src/
+├── domains/                    # Business domains
+│   ├── about/
+│   ├── appearance/
+│   ├── legal/
+│   ├── disclaimer/
+│   ├── feedback/
+│   ├── faqs/
+│   ├── rating/
+│   ├── video-tutorials/
+│   ├── cloud-sync/
+│   └── dev/
+├── application/                # Application layer
+│   └── ports/                  # Layer interfaces
+├── infrastructure/             # Infrastructure layer
+│   ├── repositories/           # Data repositories
+│   └── services/               # Business services
+└── presentation/              # Presentation layer
+    ├── components/             # Shared components
+    ├── screens/                # Screens
+    ├── hooks/                  # Presentation hooks
+    └── navigation/             # Navigation
+```
+
+## Domain Organization
+
+Each domain follows a consistent self-contained structure:
+
+```
+domain/
+├── domain/            # Business entities
+├── application/       # Domain-specific application logic
+├── infrastructure/    # Domain-specific infrastructure
+├── presentation/      # Domain-specific UI
+├── types/            # Domain types
+└── utils/            # Domain utilities
+```
+
+### Domain Examples
+
+**About Domain**: Application information, version details, developer contact
+**Appearance Domain**: Theme settings, language preferences, display options
+**Legal Domain**: Terms of service, privacy policy, legal notices
+**Disclaimer Domain**: Usage disclaimers, liability statements
+**Feedback Domain**: User feedback collection, issue reporting
+**FAQs Domain**: Frequently asked questions and answers
+**Rating Domain**: App store ratings, review prompts
+**Video Tutorials Domain**: Tutorial videos, help content
+**Cloud Sync Domain**: Data synchronization, backup/restore
+**Dev Domain**: Development tools, debugging features
+
+## Data Flow Patterns
+
+### Reading Settings
+
+```
+User → UI Component → Hook → Query → Service → Repository → Storage
+```
+
+### Updating Settings
+
+```
+User → UI → Mutation Hook → Service → Repository → Storage
+```
+
+## Design Patterns
+
+### Repository Pattern
+Separates data access logic from business logic through interface-based abstractions
+
+### Dependency Injection
+Inject dependencies through constructors for testability and flexibility
+
+### Factory Pattern
+Create objects with factory functions for consistent object creation
+
+### Observer Pattern
+React hooks and TanStack Query use observer pattern for reactive state management
+
+## Strategy
+
+1. **Domain-Driven Organization**: Structure the codebase around business domains rather than technical layers, ensuring each domain is self-contained with its own entities, logic, and presentation
+
+2. **Layered Architecture**: Maintain clear separation between presentation, application, infrastructure, and domain layers with unidirectional dependencies flowing from outer to inner layers
+
+3. **Interface-Based Design**: Define clear interfaces between layers and components to enable loose coupling, testability, and independent evolution of components
+
+4. **Dependency Inversion**: Depend on abstractions rather than concrete implementations, allowing for easy substitution of implementations (e.g., different storage backends)
+
+5. **Single Responsibility Principle**: Each component, service, and module should have one reason to change, ensuring focused, maintainable code
+
+## Restrictions
+
+### ❌ DO NOT
+
+- Skip architectural layers when communicating between components (e.g., Presentation must not directly access Storage)
+- Create circular dependencies between layers or domains
+- Mix concerns within a single layer (e.g., business logic in presentation components)
+- Access external services directly from domain or presentation layers
+- Duplicate business logic across multiple domains or components
+
+### ❌ NEVER
+
+- Allow presentation components to directly access infrastructure implementations
+- Create dependencies from inner layers (domain/infrastructure) to outer layers (presentation)
+- Implement business rules in UI components or hooks
+- Share mutable state between different domains without proper encapsulation
+- Bypass repository interfaces when accessing data
+
+### ❌ AVOID
+
+- Creating tightly coupled dependencies between different domains
+- Implementing complex business logic in presentation layer hooks
+- Using global state or singletons for sharing data between layers
+- Making infrastructure details (e.g., storage implementation) visible to other layers
+- Creating overly complex abstractions that don't serve a clear purpose
+
+## Rules
+
+### ✅ ALWAYS
+
+- Use interfaces to define contracts between layers and components
+- Follow dependency injection patterns for passing dependencies
+- Implement proper error handling at each layer with consistent error types
+- Maintain type safety with TypeScript throughout the architecture
+- Write tests that verify behavior at each architectural layer
+
+### ✅ MUST
+
+- Ensure all data access goes through repository interfaces
+- Keep domain entities and business rules independent of infrastructure
+- Implement proper separation of concerns in all components
+- Use async/await for all asynchronous operations
+- Handle edge cases and errors gracefully at each layer
+
+### ✅ SHOULD
+
+- Prefer composition over inheritance when sharing behavior
+- Keep interfaces focused and cohesive (small, related sets of methods)
+- Use factory functions for creating complex objects with dependencies
+- Implement proper logging at each layer for debugging and monitoring
+- Maintain consistency in naming conventions across all layers
+
+## AI Agent Guidelines
+
+### Architecture Modifications
+
+When modifying the architecture:
+
+1. **Layer Adherence**: Always respect the layered architecture and maintain unidirectional dependencies from outer to inner layers
+2. **Domain Boundaries**: Keep domains self-contained and minimize inter-domain dependencies
+3. **Interface Stability**: When changing interfaces, maintain backward compatibility or provide migration paths
+4. **Incremental Changes**: Make architectural changes incrementally, ensuring tests pass at each step
+
+### Adding New Features
+
+When adding new features:
+
+1. **Domain Identification**: Determine which domain the feature belongs to, or create a new domain if appropriate
+2. **Layer Placement**: Place each piece of functionality in the appropriate layer following the architecture patterns
+3. **Interface Design**: Design clear interfaces before implementing functionality
+4. **Dependency Management**: Use dependency injection to pass dependencies and enable testing
+
+### Refactoring Guidelines
+
+When refactoring existing code:
+
+1. **Maintain Contracts**: Keep existing interfaces stable; internal refactoring should not break external contracts
+2. **Test Coverage**: Ensure comprehensive test coverage before and after refactoring
+3. **Gradual Migration**: Refactor incrementally, maintaining functionality at each step
+4. **Documentation Updates**: Update architecture documentation to reflect significant structural changes
+
+### Code Review Checklist
+
+Review should verify:
+
+- Layer separation is maintained
+- Dependencies flow in correct direction (outer → inner)
+- Interfaces are well-defined and cohesive
+- Domain logic is properly encapsulated
+- Error handling is consistent across layers
+- Tests cover all architectural layers
+- No circular dependencies exist
+- Type safety is maintained throughout
+
+## Related Documentation
+
+- **TESTING.md**: Comprehensive testing strategies for each architectural layer
+- **Domain READMEs**: Individual domain-specific documentation
+- **Component Documentation**: UI component usage and patterns
+
+## License
+
+MIT

package/CHANGELOG.md

@@ -0,0 +1,67 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [4.20.58] - 2025-01-08
+
+### Added
+- Complete documentation migration to new format
+- AI Agent Guidelines for all components
+- Strategy-based documentation without code examples
+- File path references in all documentation
+- CONTRIBUTING.md guide
+- LICENSE file
+
+### Changed
+- All README files now use Purpose/Strategy/Restrictions/Rules format
+- ARCHITECTURE.md updated to new documentation style
+- TESTING.md updated to new documentation style
+- Removed all code examples from documentation
+- Added AI-friendly guidelines throughout
+
+### Fixed
+- Documentation consistency across all files
+- Missing file path references
+- Incomplete AI guidelines
+
+## [4.20.57] - Previous Releases
+
+### Features
+- Settings screen with modular sections
+- Theme management (light, dark, auto)
+- Language selection
+- Notification preferences
+- About screen with app info
+- Legal documents (privacy, terms)
+- Disclaimer system
+- Feedback collection
+- FAQ management
+- Rating prompts
+- Video tutorials
+- Cloud sync support
+- Development utilities
+
+### Architecture
+- Domain-Driven Design (DDD)
+- Four-layer architecture
+- Repository pattern
+- Service layer
+- TanStack Query integration
+- Type-safe implementation
+
+## Documentation Format
+
+From version 4.20.58 onwards, all documentation follows:
+- No code examples
+- Strategy-based approach
+- File path references
+- Clear restrictions (❌ DO NOT, ❌ NEVER, ❌ AVOID)
+- Mandatory rules (✅ ALWAYS, ✅ MUST, ✅ SHOULD)
+- AI Agent Guidelines
+
+## License
+
+MIT License - see LICENSE file for details

package/CODE_OF_CONDUCT.md

@@ -0,0 +1,75 @@
+# Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, religion, or sexual identity
+and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our Standards
+
+### Positive Behavior
+
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
+
+### Unacceptable Behavior
+
+- The use of sexualized language or imagery
+- Trolling, insulting or derogatory comments
+- Personal or political attacks
+- Public or private harassment
+- Publishing others' private information
+- Other unethical or unprofessional conduct
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, or to ban temporarily or permanently any
+contributor for other behaviors that they deem inappropriate, threatening,
+offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies within all project spaces, and it also applies when
+an individual is officially representing the project or its community in public
+spaces. Examples of representing a project or community include using an official
+project e-mail address, posting via an official social media account, or acting
+as an appointed representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the project team at umit@umituz.com. All complaints will be reviewed
+and investigated and will result in a response that is deemed necessary and
+appropriate to the circumstances. The project team is obligated to maintain
+confidentiality with regard to the reporter of an incident.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.0, available at
+https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+https://www.contributor-covenant.org/faq

package/CONTRIBUTING.md

@@ -0,0 +1,107 @@
+# Contributing to @umituz/react-native-settings
+
+Thank you for your interest in contributing to this package! This document provides guidelines for contributing.
+
+## Purpose
+
+This document guides contributors on how to effectively participate in the development of `@umituz/react-native-settings`, ensuring code quality, consistency, and maintainability.
+
+## How to Contribute
+
+### Reporting Issues
+
+Before creating issues:
+- Check existing issues for duplicates
+- Use clear, descriptive titles
+- Provide reproduction steps
+- Include environment details (React Native version, platform, etc.)
+- Add screenshots for UI issues
+
+### Submitting Pull Requests
+
+1. Fork the repository
+2. Create a feature branch (`git checkout -b feature/amazing-feature`)
+3. Make your changes following our guidelines
+4. Write tests for new functionality
+5. Ensure all tests pass
+6. Commit your changes (`git commit -m 'Add amazing feature'`)
+7. Push to the branch (`git push origin feature/amazing-feature`)
+8. Open a Pull Request
+
+## Development Workflow
+
+### Getting Started
+
+1. Clone the repository
+2. Install dependencies: `npm install`
+3. Run type checking: `npm run typecheck`
+4. Run linting: `npm run lint`
+
+### Code Style
+
+Follow the existing code style:
+- Use TypeScript strict mode
+- Follow naming conventions
+- Add JSDoc comments for public APIs
+- Use meaningful variable names
+- Keep functions focused and small
+
+### Testing
+
+- Write unit tests for new features
+- Maintain test coverage above 80%
+- Test error conditions
+- Include accessibility tests
+- Update documentation for changes
+
+## Project Structure
+
+```
+src/
+├── domains/              # Feature domains
+├── presentation/         # UI layer
+├── application/          # Interfaces
+└── infrastructure/       # Data layer
+```
+
+Follow Domain-Driven Design principles when adding features.
+
+## Documentation
+
+All documentation must follow the new format:
+- No code examples
+- Use file paths instead
+- Include Purpose, File Paths, Strategy sections
+- Add Restrictions with ❌ markers
+- Add Rules with ✅ markers
+- Include AI Agent Guidelines
+
+See `DOCUMENTATION_TEMPLATE.md` for the template.
+
+## Commit Messages
+
+Use clear, descriptive commit messages:
+- `feat:` - New features
+- `fix:` - Bug fixes
+- `docs:` - Documentation changes
+- `refactor:` - Code refactoring
+- `test:` - Adding/updating tests
+- `chore:` - Maintenance tasks
+
+Example: `feat(appearance): add custom color palette support`
+
+## Code Review Process
+
+1. All PRs require review
+2. Address review feedback
+3. Ensure CI checks pass
+4. Update documentation as needed
+5. Squash commits if necessary
+
+## Questions?
+
+Feel free to open an issue for questions or discussions.
+
+## License
+
+By contributing, you agree that your contributions will be licensed under the MIT License.