The current implementation of SplitScroll struct would introduce a breaking change whenever anything is added to it since it's exposing all of its internal fields as public.
This scenario can happen potentially many times as for example we would need to expose more configurations for the underline ScrollView.
I have two suggestions to solve this:
- Make all fields of
SplitScroll pub(crate) or private and make them accessible via builder pattern (Similar to Table).
- Keep the code as it's but add the flag
#[non_exhaustive] to the struct to avoid breaking changes on adding new fields. However, this will solve the breaking change with pattern matching but won't solve when users are constructing it.
I would be glad to provide a PR with one of those fixes once we have a decision about which approach is more suitable for you
The current implementation of
SplitScrollstruct would introduce a breaking change whenever anything is added to it since it's exposing all of its internal fields as public.This scenario can happen potentially many times as for example we would need to expose more configurations for the underline
ScrollView.I have two suggestions to solve this:
SplitScrollpub(crate)or private and make them accessible via builder pattern (Similar toTable).#[non_exhaustive]to the struct to avoid breaking changes on adding new fields. However, this will solve the breaking change with pattern matching but won't solve when users are constructing it.I would be glad to provide a PR with one of those fixes once we have a decision about which approach is more suitable for you