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

[Slider] Unstyled version + emotion styled #5

Open
wants to merge 37 commits into
base: origin/next
Choose a base branch
from

Conversation

mnajdova
Copy link
Owner

@mnajdova mnajdova commented Sep 9, 2020

}),
}),

'& .MuiSlider-rail': {

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?

Copy link
Owner Author

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...

Copy link

@oliviertassinari oliviertassinari Sep 9, 2020

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?

packages/material-ui/src/Slider/Slider.js Outdated Show resolved Hide resolved
packages/material-ui/src/Slider/Slider.js Outdated Show resolved Hide resolved
mnajdova pushed a commit that referenced this pull request Nov 10, 2020
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants