Skip to content
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

Consider removing 'computed styles' entirely from custom widgets #273

Open
ethereumdegen opened this issue Jul 6, 2023 · 0 comments
Open
Labels
enhancement New feature or request

Comments

@ethereumdegen
Copy link

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.

@StarArawn StarArawn added the enhancement New feature or request label Jul 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants