-
Notifications
You must be signed in to change notification settings - Fork 2
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
[Slider] Unstyled version + emotion styled #5
base: origin/next
Are you sure you want to change the base?
Conversation
mnajdova
commented
Sep 9, 2020
- I have followed (at least) the PR section of the contributing guide.
Co-authored-by: Olivier Tassinari <olivier.tassinari@gmail.com>
Co-authored-by: Umidbek Karimov <uma.karimov@gmail.com>
}), | ||
}), | ||
|
||
'& .MuiSlider-rail': { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we create a new component to reduce the specificity?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could, I left it like this, so that the overrides for both the Slider
and the SliderBase
would look the same...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tough call, I see pros and cons.
pros of the high specificity approach:
- reduce the number of styled-components. How much does it help with performance?
- when reading the CSS in the dev tool, it's easier to understand where each style is applied to where. How important is it?
- when reading the source, it's easier to copy and paste it to make customizations. How important is it?
pros of creating individual components:
- lower specificity which could mean easier customization with CSS modules and nested selectors, tailwind utility classes, global CSS. How important is it?
Move picker sources into lab (#4) Update README.md [DatePicker] Refactor pickers tests to testing-library and mocha (#5) [TimePicker] Migrate tests to testing library (#8) [DateTimePicker] Migrate tests (#9) Fix all pickers linter errors (#10) Fix all circular dependencies (#11) * Fix all circular dependencies * Enable mocha eslint rules for typescript tests [test] The last step to a green CI (#15) Migrate pickers docs (#12) Downgrade to withStyles for pickers sources (#16) Add public api exports for pickers components (#17) Consolidate component namespace and theme augmentation (#18) Describe conformance for pickers sub-components (#19) Autogenerate proptypes for typescript sources (#20) Proper build output (#21) Clear migration artifacts (#23) Eslint rule for lower-case test name convention (#24) DateRangePicker (#25) yarn deduplicate Remove GridListTile [DateTimePicker] Fix migration unit tests Fix types Fix typescript types migration issues Fix yarn lerna build (#33) Fix karma tests use window.Touch for CI karma tests Remove more outdated diff noise (#34) Replace not valid formats with valid ISO strings Try to fix CI touch tests Skip tests if Touch events are not supported Fix merge conflicts Actually type-check Fix safari tests Remove lowercase test name rule The casing is up to the test author. We're not the grammar police in tests. Fix lint Format Remove overzealous eslint-disable* Debug failing tests Better debugging Timezones are fun was isoString th efix? Let's find out what's failing and then skip it Branch for safari Skip DateRangePicker in browsers review Matt's review Co-authored-by: Matt <github@nospam.33m.co> format docs:i18n