React Color – Color Pickers from Sketch, Photoshop, Chrome and More(casesandberg.github.io)
casesandberg.github.io
React Color – Color Pickers from Sketch, Photoshop, Chrome and More
http://casesandberg.github.io/react-color/
91 comments
This seems to be one of the things Web Components aim to solve. I expect webapp frameworks of the future to be nothing more than wrappers around Web Components.
> All we're doing here is creating projects for those with time on their hands
I bet this guy learned a ton and has a nice widget on his resume.
> frustrating those with none
The idea is that they gained some advantage from chosing the latest and greatest framework. If that's not worth having to make a widget like this yourself, then you should've chosen old reliable instead.
I bet this guy learned a ton and has a nice widget on his resume.
> frustrating those with none
The idea is that they gained some advantage from chosing the latest and greatest framework. If that's not worth having to make a widget like this yourself, then you should've chosen old reliable instead.
[deleted]
React encourages writing core logic in a DOM agnostic way. What you're saying is not only true of different frameworks; once code touches the DOM it's poison for reusability, and you can see it even inside of the react ecosystem. The key is to abstract out a pure logical model, and then build your actual DOM-touching instances ontop of that.
> once code touches the DOM it's poison for reusability
source? In reality, it's quite the opposite. You can't easily convert a React component to another framework. The key to writing reusable code is to remove dependencies.
source? In reality, it's quite the opposite. You can't easily convert a React component to another framework. The key to writing reusable code is to remove dependencies.
React is ultimately a framework for managing DOM mutations, so it would make sense that a pure logical model that doesn't touch the DOM also doesn't have a dependency on React.
Not true. React is a framework for managing state trees and mutations. As of 0.14, react has nothing to do with the dom at all. All that logic has been moved to react-dom.
In this particular case, the HTML5 <input type=color> works great. (Not on IE yet, but there is a polyfill.)
In the long run, shadow DOM should make it easier to make framework agnostic widgets.
In the long run, shadow DOM should make it easier to make framework agnostic widgets.
Doesn't work on Safari either.
http://caniuse.com/#feat=input-color
http://caniuse.com/#feat=input-color
Doesn't support opacity, but this one does now.
Which is exactly why we need a single new framework to rule them all!
This is a curious objection to level against other people doing professional work (which you aren't obligated to consume) for free. Is your life in any way worse because React exists or this dev decided to write some very nice color pickers? If so, doesn't whatever the objection is generalize to "all human activity which doesn't directly benefit me?"
Sorry, you missed the point. My life is better overall because React solves a ton of problems other frameworks are battling with. However, we still have to rewrite this same widgets over and over - energy that may be better spent elsewhere if that were possible. These innovations are not iterative from this point of view - they re-level the field. My point was: "there has got to be a better way of dealing with these basic components"
fwiw, I thought this little project was really cool.
fwiw, I thought this little project was really cool.
I would say they're most likely not rewritten - in the sense that each new one gets to look at and improve upon the predecessors. So they're not starting from scratch and that is leading to better quality I think.
I don't agree with him at all, but probably it affects his life since now most of the innovation is moved to another framework that he doesn't use.
Not only this, but when someone graduates school and has to go to work and maintain projects written in a dozen flavor of the month frameworks; no one wins.
That's true, just like innovation in AIDS treatment affects me because I am unlikely to get AIDS. It would be so much nicer if those resources were put toward some ailment that is more likely to affect me.
Every time someone invents another genre, 1000s of hours are lost to rewriting these pop songs – 'unrequited devotion', 'overdue break-up', 'manic anthem', 'bittersweet nostalgia', etc etc. And that's before people complain about the tired tropes and outdated attitudes their predecessors have accrued over time. More wasted time as people try to get to grips with yet another style of hipness, coded-language, and personalization to fit real world expressive uses.
I'm all for innovation and advancing the state of the culture, but there has got to be a better way of dealing with these basic emotions. All we're doing here is creating projects for those with time on their hands, frustrating those with none, and keeping the Record Industry in business.
I'm all for innovation and advancing the state of the culture, but there has got to be a better way of dealing with these basic emotions. All we're doing here is creating projects for those with time on their hands, frustrating those with none, and keeping the Record Industry in business.
Web Components
Well, maybe it's true that one has to rewrite the basic components for React. But then - it is one of rare "frameworks" where the components can be really isolated from themselves and compose at the same time.
Looks awesome. Kudos.
I'm not a React specialist and I have the following question : Is it that common to write the CSS inside the JSX file?
Since I started learning React, the hardest part to swallow was that my HTML and JS now live in the same file. Now I see that this library also puts the CSS and since I'm not entirely sure if this is good or not, can someone point some Pro's and Cons and if it's common or not.
I'm not a React specialist and I have the following question : Is it that common to write the CSS inside the JSX file?
Since I started learning React, the hardest part to swallow was that my HTML and JS now live in the same file. Now I see that this library also puts the CSS and since I'm not entirely sure if this is good or not, can someone point some Pro's and Cons and if it's common or not.
Adding another good talk on the subject: https://www.youtube.com/watch?v=NoaxsCi13yQ
Many people's gut reaction is that the folks doing inline styles just don't know CSS well enough and haven't learned the techniques advanced CSS developers use to solve these problems. Regardless of how you feel about inline styles, that gut reaction is wrong – they've been there, done that, and believe this is an even better way.
Many people's gut reaction is that the folks doing inline styles just don't know CSS well enough and haven't learned the techniques advanced CSS developers use to solve these problems. Regardless of how you feel about inline styles, that gut reaction is wrong – they've been there, done that, and believe this is an even better way.
It's becoming more and more common. Check this out:
http://blog.vjeux.com/2014/javascript/react-css-in-js-nation...
http://blog.vjeux.com/2014/javascript/react-css-in-js-nation...
Having the HTML and JS in the same file makes sense, since the HTML and the DOM manipulation code (which is what you usually see in the .jsx) tend to be tightly coupled; when they are, putting them in separate files really only gives the illusion of modularization.
Having CSS in the same file will either make sense, or not, depending on how you view the html. If you feel strongly about the separation of semantics and presentation, then you will still want to keep them separate. Many people are just trying to get what is in the webpage to look like the design prototype, so their CSS would end up tightly-coupled anyway, and the previous argument to JS+HTML applies.
[edit]
Also, a lot of what is in .css right now isn't about making a paragraph look like X, a quote look like Y, etc. but rather about applying styles to specific DOM elements for various reasons. Once you're at that point, the downsides to CSS clearly outweighs the advantages.
Having CSS in the same file will either make sense, or not, depending on how you view the html. If you feel strongly about the separation of semantics and presentation, then you will still want to keep them separate. Many people are just trying to get what is in the webpage to look like the design prototype, so their CSS would end up tightly-coupled anyway, and the previous argument to JS+HTML applies.
[edit]
Also, a lot of what is in .css right now isn't about making a paragraph look like X, a quote look like Y, etc. but rather about applying styles to specific DOM elements for various reasons. Once you're at that point, the downsides to CSS clearly outweighs the advantages.
I agree with you, however the only way to really componentize (decouple) your css from the rest of the webapp is to use the shadowdom.
In Web Components writing specific CSS for a component is fine. And it wont pollute or over-rule your other css rules. Since its the shadowdom
In Web Components writing specific CSS for a component is fine. And it wont pollute or over-rule your other css rules. Since its the shadowdom
Or you could use CSS modules: https://github.com/css-modules/css-modules
It works in some cases as a pattern of keeping components very modular and only loading the styles on the page that a single component needs. And I think it works well in cases where a component is very unique and wouldn't share any styles with other components.
That said, I personally see it as an anti-pattern. Styles should be kept agnostic of application logic for the most part. Practicing proper BEM convention paired with proper organization of SASS files yields simple management of style logic. This works exceptionally well in complex applications.
There are two camps forming right now with different methodologies & use-cases in each, and it will be interesting to see which patterns are implemented & what kind of 'css in js' tools become available.
That said, I personally see it as an anti-pattern. Styles should be kept agnostic of application logic for the most part. Practicing proper BEM convention paired with proper organization of SASS files yields simple management of style logic. This works exceptionally well in complex applications.
There are two camps forming right now with different methodologies & use-cases in each, and it will be interesting to see which patterns are implemented & what kind of 'css in js' tools become available.
If you're using BEM, then in my opinion, styles in React are the logical conclusion. Using CSS means having 2 files per component, Button.js and Button.scss. If you want to share styles, then you can simply import an object. If you want to darken a color, you can import a function. And so on.
So what about caching and rendering? So I imagine that if I render 200 buttons that have inline style it would be slower if I load one stylesheet and 200 HTML tags.
And caching problem would be if I have 2 server rendered pages ( even with JSX that's possible ) and have same styles which will be downloaded twice from two js bundles.
I think separation of those is still better solution. Not to mention stylesheet commits that are far easier to follow than just modifying a js file.
And caching problem would be if I have 2 server rendered pages ( even with JSX that's possible ) and have same styles which will be downloaded twice from two js bundles.
I think separation of those is still better solution. Not to mention stylesheet commits that are far easier to follow than just modifying a js file.
You're mixing two different problems. Just because you write your CSS in JavaScript doesn't mean you have to deliver them as inline styles. [1] [2] [3]
CSS in JS is about leveraging the (relatively sane) variable/procedure declaration and control flow semantics that are already available to you in JavaScript. How you deliver them to get the best possible performance is a wholly different problem.
[1]: https://github.com/kodyl/stilr [2]: https://github.com/robertknight/ts-style [3]: https://github.com/chenglou/RCSS
CSS in JS is about leveraging the (relatively sane) variable/procedure declaration and control flow semantics that are already available to you in JavaScript. How you deliver them to get the best possible performance is a wholly different problem.
[1]: https://github.com/kodyl/stilr [2]: https://github.com/robertknight/ts-style [3]: https://github.com/chenglou/RCSS
Thanks. This solves a lot in my head. Nice references.
See Michael Chan's presentation:
https://www.youtube.com/watch?v=ERB1TJBn32c
https://www.youtube.com/watch?v=ERB1TJBn32c
Try dragging within the colorpicker rainbow sections... Its super slow, for every drag event React-engine will perform a diff on the domtree.... This is not the way to implement such components. React is nice for non-continuous dom updates. But it will be never quicker than drawing to the screen yourselve, or updating the components yourselve... Its a lot faster than diffing a tree every few milliseconds.
I've tried half a dozen libraries to solve this problem for Literally Canvas (http://literallycanvas.com). They all have one or more dealbreakers. In this case, it's superficially that the controls are too close together to be touch-friendly. But it looks really extensible and easy to change, so I'll give it a shot anyhow. Thanks!
Thanks Steve!
If you know of a color-picker design that is better spaced (mobile friendly) go ahead and open up a issue on the repo and paste it in there. I am going to be going through this week and making a couple more!
If you know of a color-picker design that is better spaced (mobile friendly) go ahead and open up a issue on the repo and paste it in there. I am going to be going through this week and making a couple more!
You'll see a pull request from me soon. I'd much rather contribute than write my own from scratch, as I had planned to do before I saw this.
Edit: to elaborate, the layouts are generally fine, you just need fatter sliders and more space between the buttons.
Edit: to elaborate, the layouts are generally fine, you just need fatter sliders and more space between the buttons.
Sweet! Yeah, let me know if you have any questions about the helper components as well, its the first time I have done something like that!
Cool but it still lags :( Wasn't ReactJS suppose to be quicker because of Virtual DOM or something?
ReactJS is quicker than you'd expect for a gigantic JavaScript-based DOM diffing engine, but somehow this got distorted into the misconception that it's faster than native. It's not.
Like with most new technologies, we're currently in the phase where we're overusing it. In the long run, this will hopefully even out into a state where React-style DOM abstraction instead becomes just one more tool to be used when appropriate.
Like with most new technologies, we're currently in the phase where we're overusing it. In the long run, this will hopefully even out into a state where React-style DOM abstraction instead becomes just one more tool to be used when appropriate.
Quicker than what? And a framework choice doesn't guarantee a certain level of responsiveness, it also comes down to the implementation.
Well, since react forces a diffing algorithm for every state changes. It is difficult to create realtime components that update every few millis to get a 60 fps framerate. I think that is what is happening here. Dragging in the color pickers causes a tree-diff algorithm to kick in on every on-mouse-move event.
One of the primary selling points of React is better performance of the virtual DOM, which apparently has no prove in benchmarks [1].
[1] https://aerotwist.com/blog/react-plus-performance-equals-wha...
[1] https://aerotwist.com/blog/react-plus-performance-equals-wha...
That article has been discredited pretty thoroughly.
Anyway, it's not a panacea. It can't do much if you're forcing a reflow every few milliseconds.
Anyway, it's not a panacea. It can't do much if you're forcing a reflow every few milliseconds.
As a complete outsider, do you have a link or two to support that so I could learn more?
It would seem to me, again completely without knowledge, that a virtual DOM seems suboptimal. Web browsers should be able to optimize for that use case a lot better.
It would seem to me, again completely without knowledge, that a virtual DOM seems suboptimal. Web browsers should be able to optimize for that use case a lot better.
Pete Hunt's talk is good. https://youtu.be/x7cQ3mrcKaY?t=1112 I'd recommend watching the entire video if you have time, but that's the gist of it. More detail:
http://stackoverflow.com/questions/21109361/why-is-reacts-co...
It is challenging to make a large app with lots of state be performant when you manually mutate the DOM, and there's no way for the browser to fix that because of the way things work.
For example, if you move an element, and then request the position of another element immediately after, the browser will be forced to recalculate layout before giving you an answer. With lots of state and lots of updates, it's very challenging to keep this in the right order.
As virtual DOM is an abstraction over the DOM, you can make a vanilla app that is much faster, but as your app grows, that quickly reverses.
http://stackoverflow.com/questions/21109361/why-is-reacts-co...
It is challenging to make a large app with lots of state be performant when you manually mutate the DOM, and there's no way for the browser to fix that because of the way things work.
For example, if you move an element, and then request the position of another element immediately after, the browser will be forced to recalculate layout before giving you an answer. With lots of state and lots of updates, it's very challenging to keep this in the right order.
As virtual DOM is an abstraction over the DOM, you can make a vanilla app that is much faster, but as your app grows, that quickly reverses.
Shadow DOM will allow browsers to optimise their rendering code to re-render encapsulated DOM subtrees independently of each other.
Virtual DOM makes sense when (A) you have a huge tree and (B) you show only a small portion of that tree to the user at any given time.
For example a long scrollable list or a multi-line text editor would be better implemented with virtual DOM, but using it everywhere is an overkill.
Virtual DOM makes sense when (A) you have a huge tree and (B) you show only a small portion of that tree to the user at any given time.
For example a long scrollable list or a multi-line text editor would be better implemented with virtual DOM, but using it everywhere is an overkill.
The more correct selling point is that you should be able to get "good enough" performance (usually meaning consistent 60fps) with properly optimized React code.
Where did you notice a lot of lag (what device and where on the site)? I thought the performance was very good within a single widget, but there's obviously some debubble going on when updating the linked components
Try dragging your mouse (while holding the mouse button) in the "Saturation" component (its the square with rainbow colors). Every mousemove event causing the react action-render-treediffalgo-dom-mutations loop to kick in. Which is too slow to keep up with the mousemove events.
At least on my 1.82 GHZ Core duo
At least on my 1.82 GHZ Core duo
Gotcha, I got it to sputter a bit when wildly flying back and forth, but it seemed smooth under "normal" circumstances. I'm on an i7 though so, decently different hardware test ;-)
I'm running this on an 8-core Intel chip with 16GB of RAM and 4GB of Video memory and it was lagging, like _stepping_ really during all dragging. I confirmed it on 1-year-old Macbook too.
Did that lead to downvoting? I'm just curious how questions about expanding on test conditions aren't considered valuable, especially when they could clarify when to use / not to use this component...
Did what lead to downvoting? I'm not sure what you're asking. I think your parent comment might be downvoted because the wink at the end comes off as condescending.
Pretty, although I found a few issues:
The Sketch colour picker in the second sample in More Examples has no alpha, yet displays an editable field for it. Furthermore, while a text box for the colour component has focus, dragging of the label below it changes the colour, but not the value in the text box. And I think for all "dialog-like" colour pickers the text box labels should actually be labels for the text box, that is, when clicked, they should put focus on the text box.
The Sketch colour picker in the second sample in More Examples has no alpha, yet displays an editable field for it. Furthermore, while a text box for the colour component has focus, dragging of the label below it changes the colour, but not the value in the text box. And I think for all "dialog-like" colour pickers the text box labels should actually be labels for the text box, that is, when clicked, they should put focus on the text box.
Very nice work. Sincerely, thank you for the writeup! I'm still trying to gauge whether React is good for me or not, and this is very readable :)
I noticed that it is trivial to break the whole thing in a way that would probably put off average users. (See Bug Report at bottom.)
I would like to read ideas here that weigh the merits of Web Components and other compartmentalized (web) programming techniques and their ability to still have the ability to fail globally, especially if they promote an environment that gives the (perhaps false) notion that 'What I do in this will not be a problem for you'. Is this a function of React(and similar), the programmer, or other? Is it even a thing at all?
Bug Report: Changing an integer value to "g" in the R field of "Sketch" breaks ALL widgets with the only apparent way of fixing is clicking a swatch or entering a valid hex where available. Clicking Up or Down arrows in 'Chrome' does not fix. Clicking in color areas of 'Chrome', 'Sketch', or 'Photoshop' does not fix. Inputting Valid RGB values into any field does not fix but reverts to NAN.
I noticed that it is trivial to break the whole thing in a way that would probably put off average users. (See Bug Report at bottom.)
I would like to read ideas here that weigh the merits of Web Components and other compartmentalized (web) programming techniques and their ability to still have the ability to fail globally, especially if they promote an environment that gives the (perhaps false) notion that 'What I do in this will not be a problem for you'. Is this a function of React(and similar), the programmer, or other? Is it even a thing at all?
Bug Report: Changing an integer value to "g" in the R field of "Sketch" breaks ALL widgets with the only apparent way of fixing is clicking a swatch or entering a valid hex where available. Clicking Up or Down arrows in 'Chrome' does not fix. Clicking in color areas of 'Chrome', 'Sketch', or 'Photoshop' does not fix. Inputting Valid RGB values into any field does not fix but reverts to NAN.
Thank you so much for the bug report! There are so many edge cases, I cant believe I didnt even catch this one -- being so basic. I have created a github issue for it and hope to fix this tonight!
https://github.com/casesandberg/react-color/issues/11
https://github.com/casesandberg/react-color/issues/11
This was fixed in 1.0.5, thanks :D
It's missing my personal favorite the triangle or sometimes called color wheel.
Any particular rendition of it you like? I can put one together today!
I'd love to see a GTK-style version, i.e. a hue wheel with a S/L triangle like this: http://i.imgur.com/yscI9Iy.png
It's on the list for me to build!
https://github.com/casesandberg/react-color/issues/6
https://github.com/casesandberg/react-color/issues/6
This looks awesome; the color pickers I've seen for react so far are either really minimally complete or too rigid. Nice to have a solid one to reference/use if I need it. Thanks for your work on this!
This is really cool! Sorry if this is kind of a dumb question but I know nothing about web development: can I use this without running node on the server? I'd like to use this for a WebGL distance field renderer I'm working on but host things on my Github page and thus can only do client side stuff. Getting a server is a possibility but for just one tiny project it doesn't seem worth it.
Yes, you can absolutely run React components without the use of a server. You can edit an html file locally and put a react component in there. That's usually the first thing most React tutorials have you do.
If you're using a backend server you're just rendering the react stuff to html and sending it to the client.
If you're using a backend server you're just rendering the react stuff to html and sending it to the client.
Great! I'll go check out some React tutorials.
I think you are searching for something like dat.GUI [1], most WebGL-demos are using it.
[1] http://workshop.chromeexperiments.com/examples/gui/#1--Basic...
[1] http://workshop.chromeexperiments.com/examples/gui/#1--Basic...
Yeah, you totally can! It's all front-end with React and Webpack. You can use Webpack in development and just have it build the static html and js files for gh-pages. Thats how the documentation site is built :)
The documentation is awesome, I noticed it is pretty similar to React-CSS's documentation. Is that the original source of this documentation style or is there some library I can use for my own personal project?
Thanks! I built it originally for `reactcss` but have used it on 3 projects now. I am going to be releasing it at the end of next month with a nice writeup!
Really cool, look forward to it!
Wow! I feel like this is one of the first packaged widgets I've ever come across (could be very very wrong). Great example of how React and web components will make the future of the web more awesome.
There's some good widget collections out there:
* http://material-ui.com/#/components/appbar
* http://react-bootstrap.github.io/components.html
Appreciate the links, thanks!
could be very very wrong
You are.
You are.
Fair enough. Should do more research before I spout such broad statements on HN.
In fairness, you did say '[that] I've ever come across'. Your comment is not incorrect.
Looks really great. Why the React dependency though? Would be more flexible, faster, and avoid dependency hell if it was vanilla JS.
"dependency hell" is a bit of an exaggeration. It has one dependency.
Dependency hell is from when multiple components depend on the same framework, but work with different versions. Since React is pre 1.0, you can expect the API to change a bit. If you build an app with multiple React components, you'd better hope all of them are well maintained, or you'll break some scripts when upgrading React (which you'll need to do for other scripts' bug fixes)
In fairness. The vast majority of the code in this library is describing the UI, and event handlers, which is exactly what React is used for. It's not like there's a ton of non-React code in here that could be abstracted out into a separate library.
Because React's cool for the next five minutes, and now we need to re-implement everything in React.
Really slick but would be great if there was a browser compatibility listed somewhere.
does this work with react 0.14?
I'm all for innovation and advancing the state of the art, but there has got to be a better way of dealing with these basic components. All we're doing here is creating projects for those with time on their hands, frustrating those with none, and keeping StackOverflow in business.