create-provider-context

Creates reusable React providers and manages their scope for feature-level implementations.

4.1k|1.3k|Updated Nov 11, 2016

Search Tags:#context #frontend #react #monorepo #state-management #provider #erxes

Ready to run

npx skills add https://github.com/erxes/erxes --skill create-provider-context

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: create-provider-context
Source: https://github.com/erxes/erxes/tree/main/.agents/skills/create-provider-context
Command: npx skills add https://github.com/erxes/erxes --skill create-provider-context

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill eliminates the pain of manually creating React providers and contexts by enforcing erxes' architectural patterns, preventing common pitfalls like overusing contexts for single components.

Core Features & Use Cases

Pattern Enforcement: Validates provider naming conventions (PascalCase for providers, *ProviderEffect for side-effect components)
Scope Management: Ensures providers are created at appropriate levels (feature, module, plugin, global)
Best Practices: Automates hook exports, error handling for missing contexts, and composition rules
Use Case: When building a new "Tag" feature requiring shared state across multiple components without prop drilling, this skill scaffolds a TagProvider with proper scoping and error boundaries.

Quick Start

Use the create-provider-context skill to add a new provider for the 'Tag' feature in the 'my-plugin' UI module with 'feature' scope.

Frequently Asked Questions about create-provider-context

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I create scoped React providers in a monorepo environment?▼

Creating scoped React providers in a monorepo involves structuring contexts at appropriate levels like feature, module, or plugin. This enforces naming conventions, automates hook exports, and ensures proper state management boundaries to prevent architectural pitfalls.

When should I use React context for shared state instead of prop drilling?▼

React context is appropriate for shared state when multiple components across a feature tree need access to the same data without prop drilling. It should be scoped correctly, as overusing context for single components leads to unnecessary re-renders and architectural fragmentation.

What's the best way to manage shared state across component trees in an erxes application?▼

Managing shared state in erxes applications requires following established architectural patterns for provider creation. This includes using PascalCase for providers, defining ProviderEffect components for side effects, and scoping contexts at feature, module, plugin, or global levels.

How do I scaffold a new feature provider with proper error boundaries in React?▼

Scaffolding a feature provider requires defining the context scope and implementing error handling for missing contexts. This skill automates hook exports and validates naming conventions to ensure the provider integrates cleanly with existing code organization.

Does this provider creation approach work within a monorepo frontend architecture?▼

Yes, the provider creation approach is specifically designed for monorepo frontend environments. It applies to frontend development tasks requiring shared state across component trees, integration boundaries, or global data loading within applications like erxes.

Why does overusing React context for single components cause architectural issues?▼

Overusing React context for single components causes architectural issues by creating unnecessary integration boundaries and state management overhead. Proper scoping ensures providers are only created at appropriate levels, maintaining clean code organization and preventing performance degradation.