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.

@stale
Copy link

stale bot commented Dec 11, 2025

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Dec 11, 2025
@AmauryLiet
Copy link
Author

@Inbal-Tish any input on this one? or a recommendation for another reviewer?

@stale stale bot removed the stale label Jan 13, 2026
@AmauryLiet
Copy link
Author

@SWARVY it would totally make sense to uniformize the styling, you could submit another PR in that sense. However keep in mind that this would be a breaking change and will need an appropriate version bump

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