-
-
Notifications
You must be signed in to change notification settings - Fork 270
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
[LiveComponent] Exposing public objects via emit() #1744
Comments
Hey! It looks like if we want to implement this feature we have to resolve #1587 first. I think this can be a great idea. The thing is @smnandre in the issue I linked, mentioned some security by exposing too much data... I think we can implement this can of feature with a big red flag on the doc. What do you think? |
What i like in the idea of @Guikingone is that using an dedicated attribute is an active choice, that cannot hide some unwanted / hidden behaviour |
@WebMamba I think a notice in the documentation is not enough, most of the time, a developer will see that it can trigger an event with an object, will do it and will come crying like a baby because "critical data" has leaked (sorry to say things like that but that's the case most of the time 馃槄). That's why having an attribute is a better idea IMHO, we can easily trigger an exception / warning if the attribute is not used in the object sent via Again, if you have a better idea, I'm open to discuss about it 馃檪 |
Hi 馃憢馃徎
Small suggestion to improve the current usage of
ComponentToolsTrait::emit()
, for now, the method defines the following signature:The main issue here IMHO is the usage of
$data
, AFAIK, we can only pass arrays of scalars, this prevent us from using objects when communicating between components using only the PHP approach (without emitting from the JS code), I'm not sure how it can be improved (after discussing with @smnandre, maybe we can use a new attribute#[ExposedStimulusObject]
for example, this attribute would allow us to say that this object is serialized/deserialized when emitting the event and that if it contains sensitive data, we're fully responsible for any leak) but I think it could be a good idea as we sometimes want to emit events that contains objects (think of notifications, ValueObject's, DTO's, etc).Any thoughts? 馃檪
PS: This approach would not allow to emit event with objects from the frontend (as we need to obtain and keep the FQCN of the object to serialize/deserialize) but this kind of use case if strongly tied to the PHP usage of the
emit
method.The text was updated successfully, but these errors were encountered: