Nova4 Bitbucket News Commits Laravel Package

Getting Started

This is a pre-1.0 package (v0.0.2), so treat the public API as provisional. The core idea is a "card" that renders data sourced from a repository, and the v0.0.2 release makes the card reusable: you can invoke it multiple times on the same page, each invocation bound to a different repository.

Minimal steps:

1. Install the package and publish any config/views it ships (php artisan vendor:publish --tag=...). Check the package's service provider for what is registered and what is publishable.
2. Locate the repository contract/abstract class — this is the extension point you will implement most often. Also locate the card class/component and any Blade view or view component it exposes.
3. Register your first repository (container binding, config array, or attribute — check the provider) and point the card at it.
4. Render the card once to confirm wiring, then render it a second time with a different repository to exercise the new v0.0.2 behaviour.

First use case: a dashboard where the same card layout is rendered against two data sources — e.g. an "open tickets" card backed by an internal repository and the same card backed by an external/API repository. Before v0.0.2 you effectively had to duplicate the card; now you pass a different repository per call.

Look first at: the service provider, the repository interface, and the card's constructor/signature. The signature is where the v0.0.2 change is most visible and is the best indicator of how per-instance configuration is intended to work.

Implementation Patterns

One card, many repositories. The headline pattern is invoking the card repeatedly with distinct repositories:

<x-card :repository="$internalTickets" />
<x-card :repository="$externalTickets" />

or, if the card is resolved from the container:

app(Card::class, ['repository' => $internalTickets]);
app(Card::class, ['repository' => $externalTickets]);

Confirm from the source whether the repository is passed via constructor, a fluent setter, a config key, or a Blade attribute — v0.0.x packages often support one and not the others.

Repository as a thin adapter. Keep repositories focused on fetching/normalising data for the card. Put caching, pagination, and authorisation in the repository, not the card, so each card instance inherits the behaviour of its own data source.

Per-instance configuration. When rendering multiple cards, push variation into the repository rather than the card. If the card accepts options (title, limit, filters), pass them per invocation; if it doesn't yet, wrap the card in your own Blade component that supplies defaults.

Composition over duplication. Build a small wrapper component for each card variant in your app (e.g. <x-ticket-card>) that resolves the right repository and forwards attributes. This insulates your views from the package's pre-1.0 API churn.

Integration tips. Bind repositories in a dedicated service provider rather than inline in views. If the package supports config-driven repositories, prefer config for static wiring and container bindings for anything requiring runtime dependencies (HTTP clients, current tenant, authenticated user).

Testing. Instantiate the card with a fake/in-memory repository in feature tests and assert rendered output per repository. Test the multi-invocation case explicitly — that is the behaviour v0.0.2 introduced and the most likely place for regressions.

Gotchas and Tips

• State leakage between invocations. The whole point of v0.0.2 is multiple calls with different repositories. If the card or repository holds state on a shared singleton, the second invocation can inherit data from the first. Verify repositories are resolved per instance (not shared singletons) and that any internal buffers are reset per render.
• Container binding scope. If repositories are bound as singletons, two card instances will share one repository. Bind as transient (bind, not singleton) unless the repository is genuinely stateless.
• Cache key collisions. With multiple repositories feeding the same card, a cache keyed only on card name will serve the wrong data. Include the repository identifier (and relevant filters/tenant) in cache keys.
• Pre-1.0 API instability. v0.0.x releases can change signatures without deprecation. Pin the version in composer.json and read the diff before upgrading; v0.0.2 is a feature addition, not a documented breaking change, but treat minor bumps as potentially breaking.
• Ordering and duplicate assets. Rendering the card N times may register scripts/styles/view composers N times. Check for @once guards or package-level deduplication if you see duplicated output.
• Debugging multi-instance issues. Dump the repository class actually received by each card instance (dd($card->repository::class) or equivalent). Most "wrong data" bugs are a binding or resolution problem, not a rendering problem.
• Extension points. The repository contract is your safest extension point; card internals are more likely to change. Avoid subclassing the card unless the package documents it as supported.
• Config quirks. If repositories are declared in config, remember config is cached in production — php artisan config:cache after changes, and avoid closures in config files if the package reads them at boot.
• Version bump note. Since this assessment is based solely on v0.0.2, re-check the repository contract and card signature on each subsequent release; the multi-repository behaviour is new and likely to be refined.