As per Rust rules it's not possible to implement a forigin trait on a forigin type, a common pattern to circumvent this is to introduce "newtypes" as we had previously on Uuid.
This however has some issues, namely that some standard crates has had important implementations provided for those types making usage of those libraries clunky together with leptos-struct-table this pr could make atleast some of those cases avoidable.
This pr:
Introduces an owned trait CellValue (i'm open to sugestions on the name) that has imlementations similar to those of IntoView (for those that turn into text) (the macro is stolen right from the leptos codebase)
Removes Uuid newtype and excessive dependance on v4, v6, serde and js, feature flags of Uuid
Implements CellValue for uuid::Uuid behind the uuid feature flag
Updates examples to work with the above breaking changes (naming the dependency on uuid and using that type (and calling new_v4() instead of default()
and we can, in this crate provide some nice default rendering for the types of well known crates (behind feature flags) as done here with the Uuid type (the actual one from the uuid crate). I think it would be nice to implement CellValue for some types from time along with other well known and well used crates in the ecosystem in upcomming pr-s
I have a feeling we could ditch a lot of the special handling built into the derive macro for chrono but not 100% sure about that yet.
I made a previous pr #26 that I agree is subpar. This aproach feels much better, atleast to me but I think it achives the same benefit in the end, that this library can be used together with sqlx::FromRow even in more complex cases
As per Rust rules it's not possible to implement a forigin trait on a forigin type, a common pattern to circumvent this is to introduce "newtypes" as we had previously on
Uuid
. This however has some issues, namely that some standard crates has had important implementations provided for those types making usage of those libraries clunky together withleptos-struct-table
this pr could make atleast some of those cases avoidable.This pr:
CellValue
(i'm open to sugestions on the name) that has imlementations similar to those of IntoView (for those that turn into text) (the macro is stolen right from the leptos codebase)v4
,v6
,serde
andjs
, feature flags of UuidCellValue
foruuid::Uuid
behind the uuid feature flagnew_v4()
instead ofdefault()
and we can, in this crate provide some nice default rendering for the types of well known crates (behind feature flags) as done here with the
Uuid
type (the actual one from theuuid
crate). I think it would be nice to implementCellValue
for some types fromtime
along with other well known and well used crates in the ecosystem in upcomming pr-sI have a feeling we could ditch a lot of the special handling built into the derive macro for
chrono
but not 100% sure about that yet.I made a previous pr #26 that I agree is subpar. This aproach feels much better, atleast to me but I think it achives the same benefit in the end, that this library can be used together with
sqlx::FromRow
even in more complex casesAny feedback welcome