Skip to content

Conversation

AmauryLiet
Copy link

@AmauryLiet AmauryLiet commented Jul 16, 2025

Current typing incorrectly enforces passing styling props as:

<Calendar
    theme={{
      stylesheet: {
        calendar: {
          header: {
            dayTextAtIndex0: { color: 'fuchsia', fontSize: 42 },
          }
        }
      }
    }}
/>

although this leads to ignored styling. Correct usage is:

<Calendar
    theme={{
      'stylesheet.calendar.header': {
        dayTextAtIndex0: { color: 'fuchsia', fontSize: 42 },
      }
    }}
/>

@SWARVY
Copy link

SWARVY commented Aug 25, 2025

@AmauryLiet

Thank you so much for uploading this PR!

I'd like to share a suggestion regarding styling consistency that I've noticed while working with the library. Currently, there are two different approaches for styling calendar components in the original source code:

  1. Other Custom style properties: Can be modified using stylesheet.~... approach
export default function getStyle(theme: Theme = {}) {
    ...other things...,
    ...(theme['stylesheet.calendar.main'] || {})
  });
}
  1. ExpandableCalendar properties: Must use the currently defined types for styling to be applied
export default function styleConstructor(theme: Theme = {}) {
  const appStyle = {...defaultStyle, ...theme};

  return StyleSheet.create({
    ...other things...,
    ...(theme?.stylesheet?.expandable?.main || {})
  });
}

As a developer using this library, I've found this inconsistency to be a bit confusing when trying to understand which styling approach to use. It would be really helpful if we could have a more consistent styling pattern across all calendar components.

Suggestion: Would it be possible to consider standardizing the styling approach (either all stylesheet.~... or all current types) and applying it uniformly? This would make the library much easier to use and maintain for the community.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants