[HN Gopher] Chakra UI - Simple, Modular and Accessible UI Compon...
___________________________________________________________________
Chakra UI - Simple, Modular and Accessible UI Components for Your
React Apps
Author : jhabdas
Score : 53 points
Date : 2020-06-13 19:05 UTC (3 hours ago)
(HTM) web link (chakra-ui.com)
(TXT) w3m dump (chakra-ui.com)
| tony wrote:
| Use it on a few websites (https://www.hskflashcards.com,
| https://parataxic.org). Like it.
|
| - TypeScript
|
| - WAI ARIA / a11y for accessibility
|
| - Passthrough styling props via Styled System: https://styled-
| system.com/
|
| - Passthrough responsive conditional props: https://chakra-
| ui.com/responsive-styles
|
| - Light / Dark: https://chakra-ui.com/color-mode (but it doesn't
| work on Gatsby: https://github.com/chakra-ui/chakra-
| ui/issues/305)
|
| - I eschew some of the helper components like <Flex>. You are
| fine just using plain old Box as the shorthand props in Flex
| component don't add much. You can just pass display="flex" into a
| Box.
|
| - Passing hover/active styling requires using PseudoBox (or a
| component deriving from it), so <Box> - or anything built on top
| of it - can't have hover colors directly. This means
| configuration for some components require additional wrappers
|
| - Active! https://github.com/chakra-ui/chakra-ui
|
| - Author is very courteous (if my limited interaction with him on
| the tracker is any indicator!) If you use Chakra and like it, you
| can support the creator via https://www.patreon.com/segunadebayo
| chris_engel wrote:
| The initial example immediately drove me away. Attributes for
| font size, -weight and the like? There was a reason we stopped
| using inline styles...
| xmorse wrote:
| And what is the reason?
|
| So you can have a global css file difficult to maintain and
| update?
|
| So you can give a stupid class name to every single tag you use
| in your markup?
|
| So that every time you include third party css there is the
| risk of confilicts?
| holoduke wrote:
| nah. what about theming? you cannot do that with inline
| styles. I think external CSS files for layout is always
| better than inline. it's very hard to debug and fix UI
| issues. nowadays you fix stuff on the fly with your browser
| inspector. you copy the result and paste it in your CSS file.
| cannot be simpler than that
| player2121 wrote:
| > nah. what about theming? you cannot do that with inline
| styles.
|
| Nobody is utilizing inline styles in that example. It
| _looks_ like inline styles but it not. It generates css
| class name behind the hood which you can override in
| multiple ways. Starting from the ThemeProvider or just like
| this:
|
| const Footer = styled.div` ${PrimaryButton} { color: red; }
| `
|
| I strongly suggest to look at https://styled-system.com/ to
| better understand the mechanics.
| saagarjha wrote:
| > And what is the reason?
|
| So you can use CSS the way it was designed?
|
| > So you can have a global css file difficult to maintain and
| update?
|
| You know you can have multiple CSS files, right? Plus the
| code is all in one place and you can refactor it.
|
| > So you can give a stupid class name to every single tag you
| use in your markup?
|
| No, you give it a _good_ class name. If something is a
| button, you call it a button rather "grey-rectangle
| width-500 clickable"
|
| > So that every time you include third party css there is the
| risk of confilicts?
|
| That's why you name your classes so this doesn't happen?
| player2121 wrote:
| > So you can use CSS the way it was designed?
|
| css was designed to style HTML documents. It was never
| designed to build rich and scallable apps thus we have all
| these libraries which fixes a lot of underlining problems.
| mmm_grayons wrote:
| Using something the way it was designed isn't an inherent
| virtue nor a reason to do so. Nothing is designed
| perfectly.
|
| > "grey-rectangle width-500 clickable"
|
| Oof, this is starting to feel like working with a Microsoft
| product.
| jacobr wrote:
| I am sure there are plenty of cases where this approach
| works just fine.
|
| I assure you that those of us who work on projects where
| this would _not_ work are not simply bad at naming things
| and that's the only reason we picked component based
| styles.
| Vinnl wrote:
| Note that you're not directly setting the size and the like.
| Instead, you're selecting items from a scale that should
| compose well together. They could advertise this better; I've
| read a post in the past that explained it well, but
| unfortunately I couldn't find it any more. https://styled-
| system.com might be a good place to start if you want to
| investigate why there might be more to it than you might assume
| at first.
|
| _Edit:_ I think this was the one:
| https://jxnblk.com/blog/mathematical-web-typography/
| ggregoire wrote:
| > There was a reason we stopped using inline styles...
|
| A few things happened between the 2000's and today tho.
| Practices evolve along with tools and technologies.
|
| We started styling our React components with CSS years ago at
| my job and we have been keeping doing so until today. While it
| works (if everybody on your team agrees to follow the same
| methodology and conventions, which is hard to enforce), it
| provides 0 benefits for us. We just went this way because it
| has always been the way to go while developing web stuff with
| Java, PHP, Django and friends. Separating the style from the
| structure while composing presentational components (Text, Box,
| etc) in a page doesn't actually make much sense and CSS
| maintenance, classes naming and conflicts prevention is a real
| burden. I've been following the "CSS-in-JS" solutions (which
| have been developed to solve these exact issues) during the
| last years and it seems like they could help us focusing on
| what actually matters.
| saagarjha wrote:
| Yeah, it's the new "utility CSS" thing that is basically just
| inline style with a bit less boilerplate. It's quick to get
| started with, hence its popularity, but it's not really great
| after that.
| ericwood wrote:
| I'm not a huge fan of atomic CSS, but part of the idea behind
| it is it solves the "ever-inflating CSS bundle" as well as
| the "where do I put this CSS" problems, both of which are
| issues on large projects.
| dubcanada wrote:
| There is also https://vue.chakra-ui.com/ a Vue version.
| xmorse wrote:
| I use this library for basically all my projects now, i have
| tried many component libraries but this is the one I am most
| productive with
|
| The idea of using atomic css properties is similar to the
| tailwind philosophy but there is no need to purge the css and you
| get typescript completion and validation
| RNCTX wrote:
| The people who publish this also have a drag and drop interface
| for assembling low level components into higher level bundles of
| components, too.
|
| Seems to be an all-around well designed system to me, I like it!
| [deleted]
| JMTQp8lwXL wrote:
| What is the threshold for UI component libraries describing
| themselves as "accessible"> Is it running through automated
| tools, such axe, is it an audit by an independent third-party
| group, or is it manual testing by actual users who regularly use
| screen reader tools?
| player2121 wrote:
| I am a big fan of styled-system and glad that more frameworks are
| utilizing it. This is something that helps a lot when building
| desktop-alike apps for the web.
| jxi wrote:
| I gave this a shot recently and thought it was cool at first, but
| like many projects in this space, it isn't really built on solid
| foundations. This thing is basically taking a bunch of ideas from
| TailwindCSS (which is awesome), wrapping it in ReactJS and
| providing a few components on top of that.
|
| This was actually what I was looking for, but turns out this
| library is really buggy. For example, dark mode doesn't work well
| with GatsbyJS: https://github.com/chakra-ui/chakra-ui/issues/305.
| I just went back to using TailwindCSS directly.
| player2121 wrote:
| question to the author, why did you switch from styled-components
| to emotion?
___________________________________________________________________
(page generated 2020-06-13 23:00 UTC)