5 ms·
ReactCSS – Bringing Classes to Inline Styles
- yummybear 11y agoMaybe this would make more sense for Native?
- travjones 11y agoThis is pretty cool. For now, I'm going to stick to regular CSS files, but when that becomes unmanageable it will be nice to have styles combined with react components. Some would argue that this is edging near "inline styles" and "one should never inline CSS." But this package definitely has practical value. Talk about "rethinking best practices?!" Nice work!
- Sakes 11y agoThis is a very elegant and magical solution. My problem is with the react community's position on maintaining css in JS rather than in css files. I'd much prefer to see the problems that the JS managed css solves handled during the build phase of the life cycle.
- clessg 11y agoWhat is your practical issue with it? I know it feels wrong at first, and by default performance may not be as good, but it makes sense to colocate the trio: one component into one file. If you already use a methodology like BEM or SUIT, this is just a natural extension of that.
- jeremiep 11y agoThing is, your one component might share styles with half the other components. Then having a proper separation of code and style with class names to bind the two becomes your only sane option at scale.
- clessg 11y agoimport theme from 'styles/theme';
- DougBTX 11y agoComponents sharing styles is the same as functions sharing constants, so there isn't a fundamental difference here. One benefit of sharing constants is that you can use, eg, TypeScript to compile-time check that all of the constants are defined, making it much easier to remove unused styles.
- Bockit 11y agoI prefer to colocate into 1 folder. index.jsx, index[.css,.styl,.scss, etc.] Just like my JS requires different JS files, my CSS imports various files too. The preprocessor turns that into 1 css file (or n, if you want).
- clessg 11y agoRight, so it's more based on "what feels right"? (I don't mean that in a bad way - sorry - am genuinely curious.) Note that you can import files in JS too. If you want to turn it into n files, then there's webpack's code splitting, which makes even more sense here.
- Bockit 11y agoMore that I don't have to force everything into a single file. I think it's more flexible that way. Let's say one day I work static files into my build process I could chuck them into the same folder where they're relevant to the component.
- Sakes 11y agoThe problem is you break the cascading part of CSS. So if you include someone else's react components, you have to do any modifications to the styling either in some config file they provide you, or by extending the component and modifying it there. I know one of the larger motivations for managing styles directly in the react components was to solve a desire to have namespaces in CSS. Maybe there are other benefits that I am unaware of which would support handling styling directly in the react component. But if you only partially implement your app / site in React, you have further complicated an already dense set of develop/styling abstractions. You will now have to think of your styling in terms of pre-instantiated app & post-instantiated app. If you fully implement your app in React, you will most likely want to do away with traditional css all together with the exception of some base css libraries. CSS without cascades seems like a strange place to be.
- clessg 11y agoYeah, if you go the inline styles route, the "cascading" and "sheets" part disappear (to some extent, anyway - you still need some global styles). This isn't a bad thing, though. Good CSS architectures usually avoid the cascade as much as possible. Imagine you have an Avatar inside a Header: class Header extends React.Component { render() { return ( <div className="Header"> <Logo /> <Avatar /> </div> ); } } You want the Avatar to be floated to the right, so you do: .Header .Avatar { float: right; } Unfortunately, this breaks encapsulation. It's basically monkey-patching and makes your components less portable. It causes a lot of problems in larger apps that aren't apparent until down the line. So you could use BEM: <div className="Header"> <Logo /> <Avatar className="Header__Avatar" /> </div> This prevents many of the problems with global selectors, specificity, and encapsulation, but it gets repetitive and is a little ugly once things get more complicated. It's still pretty bug-prone. Another way to do it is: const styles = { base: { // ... }, avatar: { float: 'right' } }; <div style={styles.base}> <Logo /> <Avatar style={styles.avatar} /> </div> Which is how Radium and React Style do it. In this case, it might be <Avatar is="avatar" /> but it's the same idea. Specificity, modularity, namespacing, indeterminism, etc., are almost all fixed. Plus you now have the ability to dynamically compute values, import constants and functions, get values statically from CSS, and apply modifiers like `Header--loggedOut` by doing {this.props.isLoggedOut && styles.loggedOut}.
- cardeo 11y agowhat happened to a clear division between js and css? In my experience many developers want nothing to do with css, they want a designer who can code to handle that
- clessg 11y agoIf your experience is that designers do all the CSS and no JS, then feel free to continue using that approach. Some of us either have good designers who adhere to Atomic Design and know some JS, and some of us have to translate mock-ups into HTML/CSS.
- betenoire 11y agoI have been doing web apps and websites for a long time, and when I first saw this, it looked so wrong but felt so right. Inline styles were impossible to maintain. Even if these (reactCSS) are rendered inline, it's easy to maintain, easy to follow, easy to change. Javascript used to refer to making things move around and handling click/hover events (javascript was the DOM language). Now it's the entire application. what am I trying to say...? it seems wrong, but try it out and see if your concerns don't just go away.
- iMark 11y agoIn many cases that division doesn't exist. Part of the beauty of React, as far as I'm concerned, is that it allows us to think about things on the page in terms of components, rather than as separate blocks of html, and javascript. It does make sense to bring css into the mix as well, as css can have functional effects. If you have a React component, for example, which explicitly toggles whether items are displayed or not, it makes sense to tie the toggling of the css display property directly into the component, rather than factoring it out into a separate stylesheet and creating an additional dependency. Note that I'm not suggesting that all styling should be done this way - I think that would be disastrous - but that there is merit in composing the html, css and javascript together.
- betenoire 11y agoExactly. It's still a separation of concerns, just a different set of concerns. Organizing my code by feature/component is so much easier on my brain than organizing it by file extension. You can mess this up, of course. We are really good at making things more complex than they ought to be, especially while the ideas are fresh in our head. We just need to keep that in mind to :)
- danr4 11y ago<Icon is="Icon" /> <span is="span" /> <CodeSmell is="Stinky" /> Besides, you kinda lose all the advantages of using javascript to style, which is complex computations and co.
- clessg 11y ago<div is="dialog"> <h1 is="title"> { this.props.title } </h1> <div is="actions"> <Button is="Cancel" label="Cancel" /> <Button is="Accept" label="Accept" /> </div> </div> Seems more expressive to me than <div className="dialog">. I understand the point though; the example provided on the homepage is very contrived. Few people are going to do something like <span is="span">. (Well, I could be wrong.)
- mateuszf 11y ago> Besides, you kinda lose all the advantages of using javascript to style, which is complex computations and co. No, you dont' loose it. You can still script the "is" attribute, also you can escape to regular className in case of advanced cases. So this is a 80-20 solution.
- dauoalagio 11y agoRegardless as to what this project is trying to achieve, I appreciate that the site is using all inline styles and is surely using this project to have made it easier!
- kolodny 11y agoI've never seen any builder that outputs js to that[1]. Does anyone know what he's using? [1][ https://raw.githubusercontent.com/casesandberg/reactcss/gh-pages/common.js https://raw.githubusercontent.com/casesandberg/reactcss/gh-p... ]
- colinramsay 11y agowebpack
- sabarasaba 11y agothat's webpack http://webpack.github.io/ http://webpack.github.io/
- ylg 11y agoThe way CSS in React should be is not to be.
- clessg 11y agoElaborate?
- ylg 11y agoSure: CSS is better managed and maintained and more easily understood by future maintainers outside of React and JavaScript, i.e., more cheaply and with less risk. And there are plenty of sugars for making it even better, e.g., SCSS, LESS.
- Semiapies 11y agoCSS in JS is not an inherently bad idea, but I haven't seen a good implementation, much less one as good as a CSS preprocessor. CSS done in React abandons all that's powerful about CSS in order to do glorified inline styles. Look at the example. Imagine that being one of dozens or hundreds of components in an app. Then imagine trying to re-style the app from a flat-looking interface to whatever's trendy next. I'd much rather do that with a LESS file than muck through however many JS files that would take with this.
- clessg 11y agoI suppose I look at things differently, because I use the BEM/SUIT methodology. There is already a logical one-to-one mapping between most BEM components and React components, so the effort required to change everything would be roughly the same. The point of using inline styles isn't to be hip: it fixes most problems caused by specificity wars, global selectors, monkey patching, code bloat, dead code, and indeterminism. I agree that there is yet to be an implementation that is perfect, but there are some very smart minds working on this problem at the moment.
- NathanCH 11y agoMy issue is that the problems you listed are solvable if you write good CSS. I mean, specificity wars... isn't that one of the first things we learn to avoid when writing stylesheets?
- autobot 11y agoThoughts on https://github.com/pluralsight/react-styleable https://github.com/pluralsight/react-styleable ? A higher-order React Component that: - Makes defining and using css styles in React Components consistent. - Makes your styles portable with your reusable components. - Makes overriding styles easy and predictable. Uses CSS modules.
- rcgs 11y agoHey, you put CSS in my JavaScript! Surely this could be done in a smarter way, using one of the many CSS preprocessors to replace the variable mapping done by `classes()`? After all, the `render()` template just needs to reference variables!
- brunolazzaro 11y agoI think you might want to try https://github.com/css-modules/css-modules https://github.com/css-modules/css-modules
- likeclockwork 11y agoI've been indirectly using React via Reagent in Clojurescript and I've been enjoying expressing logic in Clojure syntax, with dom structure in Hiccup's syntax. I've been wishing for a nice way to incorporate CSS into that as well. I'm starting to feel like using 3 different languages.. HTML/JS/CSS to achieve a single effect is a bit unwieldy, though I've done it for years. I haven't yet seen story in JS or Clojure for bringing CSS into the actual programming yet that I'm ready to adopt.. but this is interesting.
- jaequery 11y agoI believe in the future, js may replace css, perhaps even html. Javascript is the future.
- ihsw 11y agobarfs violently In all seriousness, I could see a future where the browser is just another user environment. Desktop OS (Linuxes, Mac OSX, Windows), mobile OS (Android, iOS, Windows), and the browser (Firefox, Google Chrome, Safari, IE/Edge). We compile things against it (there's a standard library/API/ABI), it has a screen that users interact with. At the risk of sounding more irrationally exuberant than the parent, the browser is an OS in itself. Yes I realize that "OS" and "browser" are actual terms that have narrowly defined definitions, however the sentiment is the same. It's just another client for our code/binaries to run on and in actuality what's running our code is irrelevant. I'm intentionally avoiding calling it a platform, though.
- hhsnopek 11y agoCan someone explain or lead me to a reason that this is a good idea? I understand that React is solving a problem, but I don't see how inlining your css like so contributes or improves the solution that React brings.
- clessg 11y agoSee the seminal presentation on the subject. https://speakerdeck.com/vjeux/react-css-in-js https://speakerdeck.com/vjeux/react-css-in-js
- andreasklinger 11y agocss tends to be used with global name spacing this becomes very quickly hard to manage the core idea is to do what react did in js (global namespace => components) but for css that being said i believe stuff like https://github.com/css-modules/css-modules https://github.com/css-modules/css-modules will be a more correct solution (you can also use scss to precompile eg)
- guiporto 11y agoI understand the idea but I still think the BEM methodology is better than this approach.
- RussianCow 11y agoI disagree. Using something like ReactCSS, all the code related to a component is in the same file. I don't have to switch between HTML, JS, and CSS files just to edit some small part of my app.
- snookca 11y agoI'm not sure that trying to keep everything in one file is necessarily a great argument. Optimizing for not having to open files doesn't seem like the best thing to optimize for. Even many of the react+inline styles examples include putting variables and other patterns into external files. Language (i18n) strings could be another external dependency. Data model, controllers, and routing are other good examples. (Rarely (if ever) have I seen an MVC framework that doesn't separate things into separate files.)
- luisrudge 11y agohere's a great video about inlining css with react. Colin Megill - Inline Styles are About to Kill CSS https://www.youtube.com/watch?v=NoaxsCi13yQ https://www.youtube.com/watch?v=NoaxsCi13yQ
- AriaMinaei 11y agoWebpack's css-loader is made pretty much for the same goals, but it has some differences. https://github.com/webpack/css-loader https://github.com/webpack/css-loader One difference between the two is that css-loader allows you to use normal css files with classes and selectors, while ReactCSS inlines all properties. For example, with css-loader, you can use much of your old toolchain for css. You can use sass, less, or newer tools like postcss, but you still get the benefit of local styles. Here is a nice articles that touches on css-loader and postcss: https://medium.com/@olegafx/frontend-welcome-to-the-future-91ff064884b6 https://medium.com/@olegafx/frontend-welcome-to-the-future-9...
- deleted 11y ago[deleted]
- Lazare 11y agoFirst, this isn't really anything to do with webpack or css-loader; it's an idea which just happens to be supported by, among other things, css-loader. (Also has a browserify plugin.) Second, I find this idea to be conceptually very interesting, especially compared to the inline styles people are playing with. It works with the existing CSS tooling, knowledge, frameworks, browser optimisations, etc we already have. There's no real workarounds, edge cases, weird hacks, whatever. It's normal CSS, but scoped to your component, which makes reusing components across a project or between projects MUCH easier. It's not a magic bullet; you have to be smart still about organising your CSS. But it's really quite clever. I'm using it on a decently large project right now; too soon to tell how it'll work out but it's been good so far.
- dinosaurs 11y agoHow does this compare to something like Radium? I have been looking for a clean way to work with styling in React and was planning to use Radium, then I noticed this.
- williamstein 11y agoI'm also very interested in the answer to this. (http://projects.formidablelabs.com/radium/ http://projects.formidablelabs.com/radium/)
- vlunkr 11y agoMaybe we should start calling this something besides inline styles, because of the huge negative connotation it carries. It's more like component-ized styles or something. This is a pretty interesting concept though. I've noticed that in really large and interactive web apps sass becomes super unwieldy, and many styles just aren't re-usable.
- davidkpiano 11y agoLook at the source. It's quite literally inline styles.
- olefoo 11y agoI think what vlunkr is trying to say is that perhaps we shouldn't be as contemptuous of inline style information as the design community has been over the past 10 years.
- baby 11y agoisn't it more like multilines style?
- vlunkr 11y agoSure that's the final result, but like mmatants said, it's the opposite of how inline styles were used back in the day. They were static then, and repetitive, the idea here is to programmatically create inline styles for web pages that have become increasingly dynamic and complex.
- mmatants 11y agoGenerated styles? And great point - these new inline/generated styles are the opposite of what they meant 10 years ago (copy-pasta hacks). Now they are even more powerful than regular CSS, instead.
- Lazare 11y agoEasier, maybe. But they're actually less powerful; inline styles support a strict subset of what regular CSS supports. (eg, no support for pseudo elements, as others have mentioned)
- nathan_f77 11y agoI'm not a big fan, to be honest. I've read a few posts about the idea, but I'm just not convinced. I'm very happy with SASS, especially with frameworks like Foundation, Bootstrap, and Skeleton. If you follow the advice and best practices outlined by those framework authors, then I don't think CSS needs such a huge paradigm shift. And then there's PostCSS, which I haven't really explored yet, but seems really promising.
- dwwoelfel 11y agoFor anyone experimenting with inline styles, there are a couple of things you'll still need a stylesheet for. Inline styles can't modify psuedo-elements or psuedo-styles. You'll need to define styles for :before, :focus, :active, etc. in a stylesheet. These selectors are really important if you want to make appealing forms, e.g. http://blog.circleci.com/adaptive-placeholders/ http://blog.circleci.com/adaptive-placeholders/ Vendor prefixes are difficult to do with inline styles. If you're using a map to represent your styles, you can't define multiple values for the same key. For example, if you wanted to use flexbox, you'd need "display: flex" and "display: -webkit-flex". Solving that with inline styles is going to get messy. It's much easier to use less's auto-prefixer plugin to do that for you. You need a stylesheet to define keyframe animations. There's probably more I've missed, but those were the problems I ran into when I experimented with inline styles. In the end, the vender prefixes problem made me move all of my styles to a stylesheet. The good news is that the problem could probably be solved by applying a runtime equivalent of less's auto-prefixer.
- danr4 11y agoGood point. This is why I think there is a place for a hybrid of javascript styles which are processed by build tools to generate style sheets. https://github.com/teal-lang https://github.com/teal-lang is an interesting approach
- snookca 11y agoWhile you can't modify pseudo elements or pseudo classes, you can replicate them using actual elements and conditional logic. I've seen React examples that do just that.
- Raphmedia 11y agoImpressive, but to me, as a front-end developper that has been breathing CSS for the best part of my adult life, this solve an issue that shouldn't be an issue. Yes, you can end up with unmanageable CSS. Yes, it is very easy to end up with a website that is hell to maintain if you have no idea what you are doing. The real solution is to hire someone who is an expert at managing CSS in enormous websites. You don't see people saying "Oh? OOP programming? That's too hard! Write all your code with this insert unconventional project instead!". That being said, this project is impressive, and I love that people are working toward making CSS better.
- clessg 11y agoOf course, anybody is able to manage a problem, but our jobs as engineers should be to fix the problem. And indeed, there is a lot that is problematic about CSS, just as there is a lot that is problematic about writing concurrent code in old versions of Java. You can deal with it if you're careful and don't let anybody touch the code, but you've solved nothing and as an engineer, that should make you feel bad.
- tracker1 11y agoI'm not sure that this really solves the problem better than keeping your less files next to your jsx files for component specific styles and relying on css classes, hierarchy or properties as it stands. I've gone down the path of doing similar things to this, and in the end I find it's more complex than simply using less (or scss)... While I appreciate the effort actually inheriting styles in/out of react components, based on parent/child relationships is a lot harder to manage when dealing with your react components directly imho.
- grandalf 11y agoThough the styling of the website looks similar, this is not a facebook project. I think the main reasons to want a component to do some styling are: - so the consumer doesn't have to include separate CSS elsewhere to get default appearance - and so that stuff that is an implementation detail can be relatively hidden (as with the shadow dom) and can expose what it makes sense to expose. So the ideal styling approach lets a component properly render itself, yet also lets it be customizable with regular CSS.
- supercoder 11y agoDo inline CSS styles impact performance ?
- etjossem 11y agoI really can't imagine a circumstance in which this would be a good idea (as opposed to refactoring your CSS such that it's well namespaced).