Closed kirillsemyonkin closed 10 months ago
As was mentioned to me over Discord, this PR combines #[styled_component_impl]
and #[styled_component]
into #[styled]
. Possibly, just rename #[styled_component_impl]
then, but still beware of that #[component]
Yew PR breaking #[styled_component]
.
Following is also possible: use stylist::yew::styled_component_impl as styled;
, I'm just pointing out some of the benefits of properly supporting this.
Thank you for the proposal.
The reason why I brought up that #[autoprops]
cannot be used to enforce #[function_component]
is because that I feel #[autoprops] #[styled_component]
is a more natural way to use stylist with #[autoprops]
.
Subjecting users to use 3 attributes for a component definition and all of them required to be arranged in a specific order is simply not a good user experience.
I would like to reserve the name styled
for a macro that can mimic styled-component(JavaScript library)-like styled
usage. So I am not in favour of renaming styled_component_impl
to styled
.
However, I am fine with a different name for styled_component_impl
if anyone is able to come up with a better name.
In addition, changing #[function_component]
to #[component]
is not a breaking change. #[function_component]
will continue to work for the next Yew release. Making #[styled_component]
to use #[component]
internally is not a breaking change as well.
I am not a fan of the current autoprops syntax in general and is fine with stylist not making any accommodations to it if it simply works as-is.
Discussion is not required
Since you said this, I am going to make this as the final decision and will not discuss this any further.
and all of them required to be arranged in a specific order
Gotta point out, only the #[component]
would need to be last
styled-component(JavaScript library)
I've only heard negative opinions on that JS library, meanwhile stylist is at least as good as tailwind, about which I heard only positive opinions and it is getting very popular
However, I am fine with a different name for
styled_component_impl
if anyone is able to come up with a better name.
I can only think of #[with_style]
currently
In addition, changing
#[function_component]
to#[component]
is not a breaking change.#[function_component]
will continue to work for the next Yew release. Making#[styled_component]
to use#[component]
internally is not a breaking change as well.
Only if Yew officially has pub use component as function_component;
in that PR. By it requiring changes I meant that if Yew will only rename and not keep old one, you will have a broken styled_component
Since you said this, I am going to make this as the final decision and will not discuss this any further.
Thats not what I meant, I meant that if discussion happens, it happens, if not, PRs would suffice, but OK lol
I will stand by my opinion, and keep using use stylist::yew::styled_component_impl as styled;
(if I myself ever will need it, I personally only use use_style!
).
Change
#[styled_component]
to no longer be a#[function_component]
wrapper, and to become a simple function body modifier#[styled]
instead.Breaking changes; low or medium priority. Discussion is not required, PRs can be done either by stylist devs, me, or someone else in the community.
Description
As yew-autoprops 0.4 released, we have been greeted with the following syntax:
Autoprops only touches props and the function body (to add some implicit clones in front). Assuming
#[styled_component]
also only slightly modifies the component body, it appears to be changeable to use the same model (becoming#[styled]
) with still being able to be compatible with autoprops in either of those two configurations:Benefits
#[styled]
to have an easy way to write down some custom options for it (if that will ever be needed).#[autoprops]
- this one is fully up to stylist to decide, its just a bonus lol#[function_component]
in its code.Drawbacks
] #[function
for the users.#[function_component]
ensured that the result will make a yew-compatible code. If stylist uses hooks in the generated body, it will have no proper way to check whether user used#[function_component]
, which may lead to a non-user-friendly error.Alternative
Leave only autoprops supporting this. Following syntax should already work now: