feat: ✨ refine/refactor sd-input/sample-datepicker

karlbaumhauer commented 10 months ago

User Story

As a consumer/stakeholder of the Solid Design System, I would like to utilize a clear and understandable design concept for the calendar so that designing and coding is effective.

Please note 

Datepicker is no longer a dedicated webcomponent but a sd-input sample offered in Figma as a helper component and in Storybook as a theme developers can add to sd-input and customize as desired.

Component name and version number:

sd-input/sample-datepicker V.1.0.0 (Replaces sd-datepicker V.0.0.1)

Figma Branch

Components detailed requirements

[x] Rework/optimize date styes.  Add range
[x] Add read-only boolean
[x] Change autolayout in flayout items to “wrap” for easier access.
[x] Add default slot content.
[x] Add slots for label, help-text, error-text.  Delete success message
[x] Add field-top slot for e.g. month selection.
[x] Delete preferred values for icons.

DoR

[x] Item has business value
[x] Item has been estimated by the team
[x] Item is clear and well-defined
[ ] Item dependencies have been identified

DoD

[x] Brand approval (if neccessary)
[x] Figma documentation file incl. hand-off has been created/updated (if applicable)
[x] Tokens have been applied/updated (if applicable)
[ ] Crosslinks are created/updated
[x] Implementation works successfully on figma branch
[ ] Published in Figma and communicated in release notes
[ ] Issues for dependencies have been created (if neccessary)

coraliefeil commented 10 months ago

Refine ... look at flatpicker ... sync with dev next week

coraliefeil commented 9 months ago

Datepicker Concept

Pls review @EllaELSA -> only the new stylings for date and range ... the other stuff is not refactored yet

mariohamann commented 9 months ago

Is this a design ticket? Can we mark this with a figma label?

mariohamann commented 9 months ago

@abudd1094 Could you please review the design component? I think you're most into what's possible and what not. It would be nice if you could align some props (if possible) to have flatpickr names stuff. But we shouldn't overforce that here, as we won't provide a component in the end.

karlbaumhauer commented 9 months ago

Is this a design ticket? Can we mark this with a figma label?

@mariohamann from my perspective, this is the design ticket to define the component, which will be build in #273

coraliefeil commented 9 months ago

I think it is too early to review ... presenting design draft to brand on Thursday.

coraliefeil commented 9 months ago

Hi @abudd1094 , could you help me review this, pls? https://www.figma.com/file/9hJu09NkrkaPJKIe6eC5uk/sd-datepicker?type=design&node-id=401-2293&mode=design Thank you

abudd1094 commented 8 months ago

We are mixing up our concepts and language around the Datepicker. It is referred to in the tickets and comments as a “component”. I am seeing words like “slot” and “props”. There is no component, there are no slots, there are no props. This feels like a continuation of the research discussion

What do we provide?

From the previous discussions, we have said we will provide:

A CSS file that represents a Flatpickr theme (not officially endorsed, see below)
ONE of the following:
- Example implementation of a date picker component that uses Flatpickr including the various recommended configuration object properties for use cases like single date selection and date range selection (ok idea)
- A custom plugin that can be plugged into the configuration and takes care of all desired behavior (probably a bad idea)

What was learned in the research phase?

Flatpickr does NOT encourage development of custom themes. They have an extremely basic page on themes which simply shows the ones they have developed and says “To use a theme of your choice, simply load its corresponding CSS file”. The level of their documentation makes me question using it at all. No where do they explain the classes used or provide any further context on developing your own theme. My research was made by painstakingly copying one of their pre-made themes and inspecting in the dev tools where the classes are used. They are not easy to read, don’t follow a clear set of best practices, and are subject to change at any time with updates. Therefore, developing a custom theme is a risk and should be carefully considered if updating Flatpickr in the future. Version locking may be necessary to protect our customization and since developers will be installing and using Flatpickr without us, we have to very carefully communicate which version we used. Inspecting change logs if there are problems will be painful.
Plugins are likewise not given much context. There is NO information on developing your own plugins and 2 of the 5 existing ones (including the coveted rangePlugin) are in a beta phase.
Providing a custom plugin is almost certainly not a good idea. I hacked together the template in my POC branch and it will take someone else a lot of time and effort to figure out what Flatpickr is doing internally and finish hacking the desired behaviors. Even if that works, it could break at any time without version locking.

My thoughts:

I don't like hacking an external library with vague documentation, it does not feel reliable and will be a lot of work to figure out for developers. In the end, that work may not pay off.
We cannot opt for a bare bones approach of providing a single CSS file to deliver all of the desired features and designs. We need in addition, examples of recommended configurations and likely several demonstration implementations. If those are expected in Story form, won't we need to install Flatpickr in our repo? Doesn't that defeat the whole purpose of not implementing a component ourselves that increases the bundle size?
We should remove the words “component”, “slot”, and “prop” from our tickets and designs. This is simply a style.
The Figma file is way too full and I don't understand what to review there. I answered the comments under "Discussion" and "REFACTOR" @coraliefeil .
We should forget about customizing a plugin, I barely trust customizing a theme. It will be more work than it is worth and unreliable over time depending on how Flatpickr develops.
The design for the date range with two date pickers is not feasible. We should simply use the dateRange plugin as provided by Flatpickr.

Conclusion

It feels to me like we are reaching for a simple solution and overcomplicating it. Flatpickr simply does not seem to promote extensive customization and certainly does not have the supporting documentation to make that process easy. It will be a hack job and the considerations outlined above should be carefully thought over before finalizing any designs.

I would do one of the following:

use the basics of what Flatpickr has to offer and compromise heavily on design
cautiously provide a custom theme with very clear documented examples & a recommended set of config objects in addition to a disclaimer and discussion of version locking
adapt the old UI datepicker
adapt the React datepicker from Airbnb that has all of the coveted design features we keep discussing

mariohamann commented 8 months ago

@abudd1094 This ticket here focuses design, and they need some kind props etc. Still thanks for your updated thoughts on Flatpickr...

coraliefeil commented 8 months ago

Handing this one over to you for review. Thanks a lot.

mariohamann commented 8 months ago

I would second @abudd1094 what he said in the Figma file: Remove everything what indicates, that we have a web component for that. It feels more like a "helper component" so that people can build their thing easier. So we shouldn't call it sd-datepicker, maybe it's even more a template or pattern with a helper-component? Or we show it as a sample of the input-component? And there we provide the theme in Storybook as well? In that case, you wuld be pretty free how to name the stuff – but as said, remove things like <slot> etc. and make very clear, that thit is NOT a component.

Does this help you enough, @coraliefeil ?

coraliefeil commented 7 months ago

"Datepicker is no longer a dedicated webcomponent but a sd-input sample offered in Figma as a helper component and in Storybook as a theme developers can add to sd-input and customize as desired."

coraliefeil commented 7 months ago

@mariohamann Please check briefly whether this is sufficient to start coding.

coraliefeil commented 7 months ago

Thanks!

mariohamann commented 7 months ago

I believe we decided to start working on it in development, so I would propose to close this ticket and leave the current state as is. Fine for you @coraliefeil?

coraliefeil commented 7 months ago

Great. Then I would label it with waiting for dev and publish when code is ready.

coraliefeil commented 5 months ago

Handing this one to you @van-nguyen-ht so you can publish when code is ready.

solid-design-system / solid