Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor ui5-calendar's onAfterRendering logic #10867

Open
1 task done
vladitasev opened this issue Feb 14, 2025 · 1 comment
Open
1 task done

Refactor ui5-calendar's onAfterRendering logic #10867

vladitasev opened this issue Feb 14, 2025 · 1 comment
Assignees
Labels

Comments

@vladitasev
Copy link
Contributor

Feature Request Description

Currently, there is a mix of responsibilities in ui5-calendar regarding the knowledge of picker specifics and rendering the header buttons. This is manifested in onAfterRendering where the calendar needs to access the pickers in order to correctly render the header buttons.

Proposed Solution

Refactoring suggestion (but other options are welcome):

  • The "calendar header" part is no longer part of the calendar itself - each picker will render its own header (as the individual pickers have the knowledge how to render these buttons, not the calendar)
  • However, reuse the ".tsx" template for the header across all pickers (just the logic will be different)
  • When a button is pressed, the picker will fire an event to the calendar and the calendar will switch pickers, which in turn will render their own headers etc.

Proposed Alternatives

No response

Organization

No response

Additional Context

No response

Priority

Low

Privacy Policy

  • I’m not disclosing any internal or sensitive information.
@dobrinyonkov dobrinyonkov self-assigned this Feb 14, 2025
@dobrinyonkov
Copy link
Contributor

Hello @SAP/ui5-webcomponents-topic-b,

could you please check this refactoring suggestion?

Kind Regards,
Dobrin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: New Issues
Development

No branches or pull requests

4 participants