rogden / tailwind-config-viewer

A local UI tool for visualizing your Tailwind CSS configuration file.
2.01k stars 111 forks source link

Font sizes in weird order #32

Closed gekkedev closed 3 years ago

gekkedev commented 3 years ago

You'd expect font sizes to be ordered by size (either ascending or descending); but they appear unordered. Still trying to figure out why, maybe the default ones appear before custom ones?

gekkedev commented 3 years ago

Can be fixed here by implementing sorting here: https://github.com/rogden/tailwind-config-viewer/blob/master/src/components/Canvas/Sections/FontSizes.vue

BTW: https://github.com/rogden/tailwind-config-viewer/blob/55b4d9946d1d6a7388fc66f1f22d36a4979be556/src/components/Canvas/Sections/FontSizes.vue#L37 If I'm not mistaken this should be a computed property, as that's a better way to obtain values. Methods serve a different purpose.

rogden commented 3 years ago

@gekkedev Thanks for the report. Can you post the font size section of your tailwind config file? Sorting should do the trick regardless.

gekkedev commented 3 years ago
fontSize: {
    "2xs": ".6875rem",
    xs: ".75rem",
    tiny: ".8125rem"
}

I managed to sort it down the problematic values: Almost anything below zero positions itself incorrectly. In the config viewer, xs is correctly ordered but after my tallest defined font size, I get 2xs and tiny: image The reason why text-xs is correctly positioned although it has the same value is because it was a TW-native font size I accidentally redefined :grin:. So as long as a font size is both custom and below zero, it gets appended instead of ordered. The notation doesn't seem to matter, as I prefixed the dot-values with zeroes and it still positioned them at the end. I might create a PR if I see a handy way to fix this sorting issue, but can't today.

gekkedev commented 3 years ago

https://github.com/rogden/tailwind-config-viewer/blob/4609fb4ceae8d1e38ee7e63e3ec0a6eddcfbd4e7/src/utils/index.js#L5 (found no related MR where to review this) couldn't this be done via !rem.includes("rem") for the sake of readability? And possibly renaming the remVar. Or is this too new (ECMA-wise)?