Though I admit it is confusing since the "Let's Get Started" section of the homepage[1] does not mention including the global css.
[0] http://blueprintjs.com/docs/ [1] http://blueprintjs.com/
141–150 of 214 posts
Though I admit it is confusing since the "Let's Get Started" section of the homepage[1] does not mention including the global css.
[0] http://blueprintjs.com/docs/ [1] http://blueprintjs.com/
This looks really nice. However, what I really want for React is a style-agnostic component library that basically extends the regular set of HTML elements, but comes with no "visual" styling (other than really basic styling like the browser's default styling for , and the like). Only styling that is necessary for the component to function should be included. Of course, optional themes would be fine. Also, non-visual…
Styling is still "unsolved" with react IMO. Inline styles feel wrong, CSS alone isn't encapsulated enough to work with components correctly, CSS modules are TOO encapsulated which makes global styles and themes a royal pain, and adding another layer ala SASS or LESS feels like more of a "patch" vs a real solution. And none of them really solve style inheritance in any way that I'd call elegant. I end up using SASS an…
I haven't run into a situation using this setup where I felt like I needed a dirty hack to make something work. It does add a layer of complexity to the build, but if you can get it working once you can just copy paste it into every new webpack config, and It feels very natural and tends to organize itself.
I am really not a fan of this new "css in your js" approach that the cool kids are using, but I guess I'm just getting old.
[1] output of the following config will be:
dist/
|_app/
|_bundle.js
|_bundle.css
|_admin/
|_bundle.js
|_bundle.css
``` const webpack = require("webpack");
const ExtractTextPlugin = require("extract-text-webpack-plugin");
const ExtractCSS = new ExtractTextPlugin("[name].css");
module.exports = {
entry: {
"./dist/app/bundle": "./app.js",
"./dist/admin/bundle": "./admin.js",
},
output: {
path: __dirname,
filename: "[name].js"
},
module: {
loaders: {
test: /\.scss$/,
loader: ExtractCSS.extract(["css", "sass?sourceMap"])
}, {
test: /\.js$/,
loader: 'babel',
exclude: /node_modules/,
include: __dirname
},
},
sassLoader: {
includePaths: "source/styles",
sourceMap: true
},
plugins: [ ExtractCSS ]
}
```Not to sound like a bummer here, but I'm not sure what kind of computer is needed to open this webpage. Simply scrolling up and down that website causes my computer to almost freeze. Firefox 49.0 user here. I would profile it, but I'm afraid of having to restart the computer as a result. Edit: It looks amazing. (Still the performance issue is reproducible easily)
And the doc has 4.2MB of minified javascript. Jesus christ. Tooks 9 seconds to load the page. All credibility gone. Why would I use components made by people who don't see performance problems?
[1] Picnic CSS: http://picnicss.com/
[2] 10K Apart: http://a-k-apart.com/
Earlier quoted context omitted.
We're aware of this: https://github.com/palantir/blueprint/issues/39 Feel free to make a PR to improve things boubiyeah, we just haven't gotten to this issue yet.
> Feel free to make a PR to improve things boubiyeah What kind of answer is this? I don't think "boubiyeah" is working for you, nor has signed up for contributing to your project. When you publish something to a public forum, even if you it is an open-source project, you open yourself to criticism(actually criticism is a great tool to help you improve your project), so my suggestion would be to be open and positive a…
[1] http://github.com/franciscop/
[2] https://github.com/umbrellajs/umbrella/issues?utf8=%E2%9C%93...
Earlier quoted context omitted.
Styling is still "unsolved" with react IMO. Inline styles feel wrong, CSS alone isn't encapsulated enough to work with components correctly, CSS modules are TOO encapsulated which makes global styles and themes a royal pain, and adding another layer ala SASS or LESS feels like more of a "patch" vs a real solution. And none of them really solve style inheritance in any way that I'd call elegant. I end up using SASS an…
I know everyone has their own favorite method, but one that I'm extremely satisfied with is using webpack > sass-loader > extract-text[1] to `include Styles from './MyComponent.scss'` in each component file, and then it all gets bundled up into a single css file per target (also great for eliminating dead CSS!). I use "layouts" at the root of my react hierarchy (under stores and routers and whatnot) and put my global…
Not to sound like a bummer here, but I'm not sure what kind of computer is needed to open this webpage. Simply scrolling up and down that website causes my computer to almost freeze. Firefox 49.0 user here. I would profile it, but I'm afraid of having to restart the computer as a result. Edit: It looks amazing. (Still the performance issue is reproducible easily)
Hi folks, I'm one of the developers of this project -- we hear your perf concerns loud and clear and are tracking the issues :) As mentioned elsewhere in this thread, this page was released a little too early while we were still playing around with animations in the header. I've gone ahead and disabled them for now, so you should see leaner CPU utilization now. Thanks for your comments.
I particularly enjoyed the piano example: http://blueprintjs.com/docs/#components.hotkeys
Earlier quoted context omitted.
I know everyone has their own favorite method, but one that I'm extremely satisfied with is using webpack > sass-loader > extract-text[1] to `include Styles from './MyComponent.scss'` in each component file, and then it all gets bundled up into a single css file per target (also great for eliminating dead CSS!). I use "layouts" at the root of my react hierarchy (under stores and routers and whatnot) and put my global…
That is what we do as well, but if you use a UI toolkit that includes it's own styles, you'll need to override them. That's where the fun hacks like .button.button.button come in to override the included styles.
.my-component {
&_component-item {
&--open {
}
}
}
and you get a nice, flat output: .my-component {}
.my-component_component-item {}
.my-component_component-item--open {}
I wish framework authors would adopt this approach as it completely eliminates specificity conflicts.TBH, I expected more from what's supposed to be a Palantir project. I mean come on, why is the site not mobile-first?