Support Laravel Package

Getting Started

netflex/support is a read-only subtree split of the Support component inside netflex/framework. That single fact drives everything about how you should adopt it:

1. Check what you already have. If your project requires netflex/framework, this package is already pulled in transitively — don't add it to composer.json directly, or you'll end up with two divergent version constraints fighting each other. Run composer why netflex/support before doing anything.
2. Install standalone only if you're deliberately cherry-picking the component. That is the only legitimate reason to composer require netflex/support on its own — e.g. you want ReactiveObject, the Accessors/Serializable traits, or the string/array helpers in a non-Netflex Laravel app, and you accept the coupling risk.
3. Read src/ first, not the README. There is effectively no consumer-facing documentation for a subtree split. The composer.json autoload block tells you the namespace (Netflex\Support\), and the directory listing is the real API surface.
4. First use case to try: the attribute/accessor plumbing. Subclass a ReactiveObject-style base, define your attributes, and confirm that toArray() / jsonSerialize() round-trips the way you expect. That single exercise validates the traits, the accessor magic, and the serialization contract at once.

Pin an exact version ("netflex/support": "1.2.*" style) rather than ^1.0. A subtree split has no independent release cadence — its tags are cut to mirror the monorepo, and a caret range can silently jump you across a framework-wide refactor.

Implementation Patterns

Extend the reactive base class for API-backed models. The core of this component is modelling records that live remotely and need to track dirty state and push changes back. Wrap your transport client in a repository, hydrate a subclass of the reactive base, mutate attributes through the accessor layer, and only persist on an explicit save()/commit call. Keep the transport out of the model — the base class should never know about HTTP.

Use the accessor traits instead of hand-written getters. The Accessors pattern gives you getFooAttribute/setFooAttribute-style interception without duplicating Laravel's own HasAttributes. The value is consistency: every model in the app mutates the same way, so serialization, dirty tracking, and array conversion all stay in sync. When you add a mutator, add the corresponding entry to the attribute definition so toArray() includes it.

Treat the component as the base layer, not the domain layer. Typical layering that works well:

app/Models/            -> your domain models (extend Netflex\Support bases)
app/Repositories/      -> transport + caching, returns hydrated models
app/Http/Resources/    -> shape the output; don't let support classes leak into JSON contracts

The support package should appear in use statements in app/Models and almost nowhere else. If you find Netflex\Support\* imports in controllers, you've skipped a layer.

Registries for driver-style extension. If the component exposes a registry/trait for registering named handlers, use it for your own plug-ins rather than switch statements. Register from a service provider's boot(), not register() — registration frequently depends on config being loaded.

Testing pattern. Because these are framework-agnostic-ish helpers, you can unit-test most of them without booting Laravel. For the reactive/accessor layer, test three things every time: (a) attribute set → getAttribute returns the mutated value, (b) isDirty()/change detection, (c) toArray() shape after mutation. Those are the three places regressions hide.

Composer wiring for a cherry-pick. If you're pulling this into a non-Netflex app, require it explicitly and add an extra.laravel.dont-discover guard if a service provider auto-registers something you don't want. Also lock a matching version of netflex/framework in conflict so Composer refuses an accidental dual install.

Gotchas and Tips

• Never open a PR here. It's a subtree split; commits pushed to this repo are overwritten by the split process. All changes go to netflex-sdk/framework and get synced down. File your issue there or it will be closed/missed.
• Version skew is the #1 failure mode. Support classes are designed against specific framework classes. Mixing netflex/support v1.0 with netflex/framework v1.3 produces "method not found" errors at runtime, not install time. Keep them in lockstep and always resolve the version from the framework's composer.lock, never independently.
• Helper function collisions. Packages of this vintage often ship global helper functions (str_*, array_* style) that can collide with Laravel's Str/Arr or with other packages. If you get a "cannot redeclare function" fatal, grep vendor/netflex/support/src for function at the top level and check your other dependencies.
• Autoload confusion after install. If classes aren't found after composer require, it's almost always a stale autoloader: composer dump-autoload -o first, then check that the package isn't listed under replace or provide in your root composer.json.
• Magic accessors defeat static analysis. IDE autocompletion will not see getFooAttribute-generated properties. Either add @property docblocks on your subclasses or generate them with a tool — otherwise every refactor is a typo lottery.
• Dirty tracking and nested values. If an accessor returns an object or array, mutating it in place usually does not mark the parent dirty, because the comparison is on the stored value. Always reassign through the setter ($model->foo = $model->foo->with(...)) rather than mutating the nested instance.
• Boot order surprises. Anything registered via a bootable trait fires during boot(), after all providers' register(). If your registration depends on config, ensure the config is published and that you're not reading it at constructor time.
• Debugging extension points. The fastest way to understand a trait is use Netflex\Support\... in a scratch class and dd(class_uses($instance)) — trait stacks in support packages are deep and order matters when two traits define the same method.
• Zero-ecosystem reality. With 0 stars and 0 dependents listed, there is no Stack Overflow corpus to search. Budget time for reading source, and keep a local note of every base-class behaviour you rely on — you are the documentation.
• Prefer composition for the transport. Don't subclass into HTTP concerns. The support layer is deliberately thin; adding a client there makes upgrades across the subtree split far more painful, and you lose the ability to test models without mocking a network.