-
-
Notifications
You must be signed in to change notification settings - Fork 218
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for inertia deferred props #939
base: main
Are you sure you want to change the base?
Add support for inertia deferred props #939
Conversation
class InertiaDeferred extends ConditionalLazy | ||
{ | ||
public function __construct( | ||
mixed $value, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is mixed
instead of DeferProps', since the
$valueparameter in the
AutoInertiaDeferred::build` method is mixed and needs to be passed to this function
@rubenvanassche I'm also not sure if this should really be part of the package. The problem I had was that I wanted to achieve the following:
By doing this, I can use the generated type as the type of the props of the react component:
This allows me to catch possible type mismatches between the data returned from the controller and the props expected by the component. If I change the name of the After a lot of playing around (including this PR), I just achieved this, more specifically generating a TS type where
Not sure if there are any other use cases for supporting deferred props in this package. Best, |
Hello 👋
I've drafted up an initial version of support for inertia v2 deferred props.
Usage looks like this:
I'm not really happy with the implementation, since the concept of deferred props is technically not related to lazy properties, but the implementation is basically copied 1:1. On the other hand, this kind of makes sense, since the effects of lazy and deferred properties are very similar.
My other approach would've been to basically copy the structure of the
abstract Lazy
,AutoLazy
&InertiaLazy
classes, but this would've required a bunch more changes.However, I still don't really like how I've done it here, but I don't think this can be done a lot better without larger refactoring. Maybe a bigger refactoring even makes sense, since merging props should also be implemented.
I'm definitely open for any suggestions!
Best,
Matthias