Javascript Context Laravel Package

Product Decisions This Supports

• Decoupling Frontend/Backend Logic: Enables clean separation of PHP backend logic and JavaScript frontend state by providing a structured way to pass data (e.g., user preferences, API endpoints, or dynamic configurations) without tightly coupling templates or APIs.
• Progressive Enhancement: Supports feature flags, A/B testing, or locale-specific UI adjustments by dynamically injecting data into JavaScript contexts (e.g., set("feature-flags", ["new-dashboard": true])).
• Build vs. Buy: Justifies buying this lightweight package over custom solutions (e.g., manual data-* attributes or global JS objects) when:
  • Teams need domain-specific contexts (e.g., app vs. backend data separation).
  • Security is a priority (HTML escaping prevents XSS in injected data).
  • Maintainability is critical (providers centralize data injection logic).
• Roadmap Priorities:
  • Phase 1: Replace hardcoded JS globals with structured context data (e.g., API base URLs, auth tokens).
  • Phase 2: Implement feature flags via providers (e.g., FeatureFlagProvider).
  • Phase 3: Extend to microservices (e.g., pass data from Laravel to a Vue/React SPA via Symfony’s HTTP client).

When to Consider This Package

Adopt if:

• Your stack uses Laravel 8+ with Twig/Symfony components and you need a simple, secure way to pass PHP data to JS.
• You require domain-specific data isolation (e.g., frontend vs. admin contexts).
• Your team prioritizes maintainability over minimalism (providers reduce boilerplate for repeated data).
• You’re already using Symfony 5+ and want to leverage its DI container for consistency.

Look elsewhere if:

• You’re not using Twig (package is Twig-centric; alternatives like Blade or JSON::encode() may suffice).
• Your project is JavaScript-heavy (e.g., Next.js, SvelteKit) with minimal PHP backend logic—consider API-driven data fetching instead.
• You need real-time updates (this is for static page loads; use Laravel Echo/Pusher for dynamic data).
• Your team prefers minimal dependencies (this adds ~10KB; alternatives like window.__INITIAL_STATE__ are lighter but less structured).
• You’re on Laravel <7.0 and unwilling to update (Symfony 5 support is irrelevant unless you’re using Symfony components directly).

How to Pitch It (Stakeholders)

For Executives: "This package lets us safely and cleanly share backend data (like user settings or feature flags) with JavaScript without exposing our API or bloating our frontend code. It’s like a ‘data bridge’ between PHP and JS—secure, maintainable, and scalable. For example, we could dynamically enable/disable features for users without redeploying the frontend. It’s a small investment now that pays off in faster iterations and reduced technical debt as we add more JS-driven features."

For Engineers: *"Pros:

• Structured data injection: Replace window.appConfig = {...} with typed, escaped data via JavaScriptContext.
• Domain separation: Use providers to scope data (e.g., app vs. admin contexts) without template clutter.
• Security: Automatically escapes <, >, and & to prevent XSS in injected data.
• Symfony/Laravel alignment: Works seamlessly with Laravel 8+ (Symfony 5+) and future-proofs integrations.

Cons:

• Twig-only: Not ideal if you’re using Blade or no templating.
• Minimal community: Low stars/recent activity, but the code is simple and well-documented.

Recommendation: Adopt for new projects or greenfield features where data sharing between PHP/JS is needed. For existing projects, evaluate the effort to migrate from manual globals to this pattern. Low risk, high reward for maintainability."*