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.
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.