You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thank you so much for developing such an excellent library.
I wonder if there's any rationale behind having only one custom event type. If a component re-renders on every custom event, this may become a performance bottleneck (every component has to try handling it, and when they encounter it, they would have to check all potential sources of change to handle the change).
If it had a way to discern events it is interested in from those it isn't, perhaps it would have been helpful.
Looking at the implementation of Event there's already a union containing event information, which is pretty large and can accommodate quite a bit of data.
What if Event::Type had a Custom variant and the union contained, say, at least an integer tag, but maybe also a pointer to metadata (or, in a wild dream, Event would be parameterized and all components would have to be parameterized over the custom event type, and no need for an integer tag; it's a big breaking change, of course)?
_Edited: for experiment's sake, I started adding custom event type parameterization, and it went well until I saw g_active_screen. This part would need some rethinking 🤔 _
Edited 2: I've opened #677 to show-case the lightweight tagging approach described above (sans the pointer to keep things light for this discussion)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi,
Thank you so much for developing such an excellent library.
I wonder if there's any rationale behind having only one custom event type. If a component re-renders on every custom event, this may become a performance bottleneck (every component has to try handling it, and when they encounter it, they would have to check all potential sources of change to handle the change).
If it had a way to discern events it is interested in from those it isn't, perhaps it would have been helpful.
Looking at the implementation of
Event
there's already a union containing event information, which is pretty large and can accommodate quite a bit of data.What if
Event::Type
had aCustom
variant and the union contained, say, at least an integer tag, but maybe also a pointer to metadata (or, in a wild dream,Event
would be parameterized and all components would have to be parameterized over the custom event type, and no need for an integer tag; it's a big breaking change, of course)?_Edited: for experiment's sake, I started adding custom event type parameterization, and it went well until I saw
g_active_screen
. This part would need some rethinking 🤔 _Edited 2: I've opened #677 to show-case the lightweight tagging approach described above (sans the pointer to keep things light for this discussion)
Beta Was this translation helpful? Give feedback.
All reactions