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
Creating a new custom widget is way too complex and confusing with kayak atm. Much more so than in something like React.
One way to make it simpler is to remove 'computed_styles' entirely and just have the custom widget define its base styles in an 'ElementBundle' which is the parent of all children in the rsx{} block.
This would get rid of a lot of confusion and complexity since then there would be no need to do " *computed_styles= ... " anymore and then the lack of computed_styles wouldnt make the framework freak out inside of a ContextProvider block (as PR272 describes).
Furthermore, the 'styles' could be removed entirely as well. users would just have to pass a KStyles struct inside of the 'props' for an element.
so for example, in window.rs, line 84 could simply be
mut query: Query<( &KChildren, &KWindow)>,
where KWindow contains a KStyle parameter. Computed_styles would not exist at all, those would just be defined in the outermost ElementBundle widget on line 162.
The text was updated successfully, but these errors were encountered:
Creating a new custom widget is way too complex and confusing with kayak atm. Much more so than in something like React.
One way to make it simpler is to remove 'computed_styles' entirely and just have the custom widget define its base styles in an 'ElementBundle' which is the parent of all children in the rsx{} block.
I dont understand why a widgets styles are both defined in the computed_styles AND in the outermost ElementBundle in the rsx{}. (An example of this is the WindowBundle example). https://github.com/StarArawn/kayak_ui/blob/main/src/widgets/window.rs
This would get rid of a lot of confusion and complexity since then there would be no need to do " *computed_styles= ... " anymore and then the lack of computed_styles wouldnt make the framework freak out inside of a ContextProvider block (as PR272 describes).
Furthermore, the 'styles' could be removed entirely as well. users would just have to pass a KStyles struct inside of the 'props' for an element.
so for example, in window.rs, line 84 could simply be
mut query: Query<( &KChildren, &KWindow)>,
where KWindow contains a KStyle parameter. Computed_styles would not exist at all, those would just be defined in the outermost ElementBundle widget on line 162.
The text was updated successfully, but these errors were encountered: