Fft Laravel Package

Getting Started

This is a patch-level release (1.0.1) with no API changes, so there is nothing new to learn before installing — but there is a clear signal about where the package's hot path lives: the polar/angular geometry layer that converts each data point into sin/cos coordinates. That class is the first thing to open when you start working with the package.

Minimal path in:

1. composer require the package and let Laravel's package discovery register the service provider.
2. Publish the config (php artisan vendor:publish) and read it before writing any rendering code — dataset defaults, angular span, and precision usually live there rather than in method arguments.
3. Render one dataset with a handful of points and dump() the computed coordinates before touching the view layer. Confirming the angle → x/y mapping early saves hours of "why is my chart rotated" debugging later.

First real use case: a single series built from a query (e.g. Model::query()->pluck('value')) rendered once, inside a controller or a small view component. Get that working end-to-end before adding a second series.

Implementation Patterns

Build datasets from queries, not from the view. Map Eloquent results into plain arrays/collections in a dedicated method or action class. The package only cares about ordered numeric sequences; keeping the mapping explicit makes it trivial to test and to swap data sources.

Multi-series is where 1.0.1 pays off. The release memoizes sin/cos calls that repeat between datasets of the same length, yielding ~20% on iteration. That gain is realised when you render several series sharing the same point count — dashboards, comparison charts, small multiples. It does roughly nothing for a single large series, so if you are optimising one heavy chart, look at reducing point counts instead.

Pre-compute, then cache. For expensive pages, resolve the geometry in a queued job or a cached service method and store the computed series (or final SVG/JSON) with a cache key derived from the underlying data's updated_at. The package's internal trig cache is per-render and will not survive the request.

Keep series lengths aligned on purpose. If your UI supports toggling series, normalise them to a common length (pad or trim) before handing them over. This both makes the rendered output comparable and takes maximum advantage of the shared-angle caching.

Integration: in Livewire/Inertia, pass already-computed series arrays rather than models, so re-renders don't re-query. In Blade, wrap the render call in a component so caching and formatting stay in one place.

Gotchas and Tips

• Upgrade is safe but re-baseline snapshot tests. No public API changed, yet any test asserting exact coordinate output should use a float delta (assertEqualsWithDelta) — memoised values can differ in the last bits.
• The cache is scoped to a render pass and keyed to point position. Datasets of different lengths, or series rendered with a per-series angular span/offset override, will not share entries. Don't assume the 20% applies universally.
• Custom angle providers bypass the win. If you supply your own angle calculation or pre-computed labels via an extension point, the package may recompute rather than reuse — profile before assuming the optimisation covers your setup.
• Debugging rotation/alignment issues: dump the angle array and the resulting coordinates separately. A wrong sin/cos order and a wrong angular offset look identical in the final output but differ at that intermediate step.
• Config quirks: precision/rounding in config affects the cached values too. Changing precision mid-project silently invalidates any coordinate fixtures you checked in.
• Memory: holding many large same-length datasets in one request now costs less CPU but the same memory. Chunk rendering if series counts grow past a few dozen.
• Extension point worth knowing: the renderer is the natural seam for custom output formats (SVG vs JSON vs inline styles). Subclass or bind your own implementation in the container rather than modifying vendor files.