The api's to build each of the components should be public

[jaysonmaw]

Context Structs are not all pub, making replacing just one piece of a sub-component much more difficult when needing customizations not supported out of the box.

I'm arguing that any context struct used by a component should be public, and at very least any fields used by any component should also be public as well. The issue this solves is the following:

If you want to replace the logic in just one element while keeping everything else the same, you are currently unable to do that in many cases.

As an example, lets say I want to relace the SingleCalendarDay component to change something about the way it is rendered or calculated.

The following contexts are used, at a minimum:

• BaseCalendarContext pub with private fields
  • SingleCalendarDay uses the private fields today, disabled, focused_date as an example
• CalendarViewContext private
• CalendarContext pub with private fields

The original component can then access information needed to build its view, but if an end user wants to replace just this one inner component they end up needing to replace everything so they can provide contexts that they actually have access to, in order to just get back to that base functionality. In the end if you need to slightly modify just one sub-component you end up needing an entire fork essentially of at least that component in order to replace it.

Ideally, how I think it should work is I should be able to copy the entirety of the SingleCalendarDay component into my project, pull in all the required imports, and that should then just work. At that point I can then make any changes necessary. This currently does not work due to these private structs/fields.

The reason this then spreads to having to replace all the components is because if I make my own version of the context in my create, that is not the context actually being provided by the parent components still under this repo.

I would argue with the way the dx components add ___ command adds the components to your crate with shims pointing to this repo, it is trying to set you up so that it is easy to replace just one subcomponent, but due to the contexts issue, in practice this is not actually possible without replacing everything.

Obvious downsides:

• All of these context structs become part of the public interface for this crate, meaning breaking changes for these structs are public breaking changes.

Alternate Solutions:

• Make context structs pub, but add getter and/or setter functions for fields where necessary to allow for future internal changes
• User forks/venders the entire repo when needing to make small changes to subcomponents
• User copies all subcomponents and contexts into your crate for that one component, to re-build up the original functionality, just to make the small change.

[ealmloff]

I don't want to expose fields directly, but the apis to build each of the components should be public. I would rather expose more getters and setters alongside a series of hooks. The react aria library handles this pretty well. They have hook versions of all of there components: https://react-aria.adobe.com/Calendar/useCalendar.html

[jaysonmaw]

Yeah exposing all the fields directly is definitely the nuclear option so that makes sense.

They have hook versions of all of there components

I would be curious if you can point to anything using that pattern with dioxus. I attempted to write what I thought a use_calendar_state hook might look like just to give myself an idea but had trouble mapping that 1 to 1 with the dioxus paradigm, and wasn't sure if it was making sense. I also don't have any experience with react so I may have just been misunderstanding the examples.

My (original) best guess it that would look something like this:

pub struct CalendarState{
    props: CalendarProps,
    base_ctx: BaseCalendarContext,
    view_ctx: CalendarViewContext,
    //...
}

impl CalendarState {
    pub fn offset_view_date(&self) -> Date {}
    pub fn set_offset_view_date(&self, date: Date) {}
    pub fn view_date(&self) -> ReadSignal<Date>{}
    pub fn date(&self) -> Date{}
    //...
}

pub fn use_calendar_state(props: CalendarProps) -> CalendarState{
    CalendarState{
        props,
        base_ctx: use_context(),
        view_ctx: use_context(),
        //...
    }
}

With the intention that you should be able to create any subcomponent using this state. Unclear to me if this would need separate state hooks for each of the subcomponents or if there would be one main state hook. Also unclear if you actually need to be passing the props to this, that was just carried over from the react examples.

I will say I'm pretty sure at least the way I've written it here it not correct, because I'm thinking in reality you actually want use_calendar_state to be a use_contex_provider, not a use_context, and maybe the additional hooks (use_calandar_day as an example) would then be use_context. As otherwise you could not actually replace the highest parent component ie Calendar.

I may end up coming back to this with fresh eyes and see if I can put something together that is more than just pseudocode.

I also renamed this issue to using your better description of the issue.

[ealmloff]

Yes, in general I think the root hook being a context provider and then child hooks as context consumers makes sense. There could be a distinction between the state/behavior level and the rendering level (both of which are important for primitives). At the state level, you need to be able to read which calendar item is currently focused. At the rendering level, you need to be able to get a list of aria-* props to spread onto the element that represents a cell in the calendar grid.

We implement something like this for focus control today. The parent provides a focus provider to all children. That focus provider is a context with methods to control the current focused child. Then children can either read if they are focused manually or use the use_focus_control hook to get a onmounted event which handles focusing for them

[jaysonmaw]

Alright, I had some time to look at this some more.

I have this commit here that is creating state (use_calendar_day_state) and attribute (use_calendar_day_attributes) hooks for just the CalendarDay component, allowing recreating and modifying that component by any outside user, while with using the attribute hook making it very simple to do so. The state hook should also be giving access to anything the user might need if they want to overwrite any of the behavior provided by the base attributes (overwriting the onclick, etc. ).

I then also moved the private components SingleCalendarDay and RangeCalendarDay in this repo to also use the new hook as to not duplicate that logic (I didn't yet remove the SingleCalendarDay and RangeCalendarDay, upstreaming that logic into CalendarDay itself, but that could be done now as they are equivalent).

An example then of creating my own CalendarDay component in an outside crate then looks like this:

#[component]
pub fn CalendarDay(props: CalendarDayProps) -> Element {
    let mut state = use_calendar_day_state(props.clone());
    let day = state.date().day();
    let base = use_calendar_day_attributes(props);
    //dummy value, would pull from somewhere in real application
    let event_count = if day % 4 == 0 { 4 } else { 0 };

    let overwrite = attributes!(
        button{
            onclick: move |_|{
                // Select the next day for some reason
                state.set_selected_date(state.date().next_day());
            },
            ..base,
        }
    );

    rsx! {
        button {
            ..overwrite,
            div{
                color: if event_count == 0 {"grey"},
                {day.to_string()}
            }
        }
    }
}

If you think I'm on the right track with this, I can continue with the rest of the components in Calendar to start.
Perhaps we could also turn this issue into a tracking issue with each component listed so that they can be marked off as they are completed.

Obviously this is a much better solution than mine of just making things pub as it not doesn't require you to duplicate all the logic even for parts you do not want to change.

Sidenote: I built it out this way with the assumption that overwriting spread attributes was trivial, however overwriting attributes that have been spread in the rsx! macro does not seem to work (?), it just always uses the value from the spread, and then you can overwrite them in the attributes! macro, but I did find it strange that it allowed any ordering (i.e. spread first or last) however it would always overwrite anything in the spread. Other languages (TS, JS, etc) will change behavior based on order with the later items always taking precedence.