React Color – Color Pickers from Sketch, Photoshop, Chrome and More

http://casesandberg.github.io/react-color/

by casesandberg • 11 years ago

274 90 11 years ago

casesandberg.github.io

thedaemon2• 11 years ago

It's missing my personal favorite the triangle or sometimes called color wheel.

casesandberg8• 11 years ago

Any particular rendition of it you like? I can put one together today!

matrix• 11 years ago

I suggest the using the one on color.adobe.com (formerly Kuler) as a starting point.

thedaemon2• 11 years ago

GTK Color Wheel actually. It's the one with a triangle in the middle. User dbbolton suggested it and it looks like it's on your list.

Twinklebear2• 11 years ago

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.

casesandberg8• 11 years ago

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 :)

ClayM• 11 years ago

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.

Twinklebear2• 11 years ago

Great! I'll go check out some React tutorials.

TN1ck• 11 years ago

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...

mshenfield3• 11 years ago

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.

vezzy-fnord• 11 years ago

could be very very wrong

You are.

mshenfield3• 11 years ago

Fair enough. Should do more research before I spout such broad statements on HN.

awinder4• 11 years ago

There's some good widget collections out there:

  * http://material-ui.com/#/components/appbar
  * http://react-bootstrap.github.io/components.html

And for more single-use components, theres http://react-components.com/

mshenfield3• 11 years ago

Appreciate the links, thanks!

sktrdie• 11 years ago

Cool but it still lags :( Wasn't ReactJS suppose to be quicker because of Virtual DOM or something?

watty• 11 years ago

Quicker than what? And a framework choice doesn't guarantee a certain level of responsiveness, it also comes down to the implementation.

jarek-foksa2• 11 years ago

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...

TeeWEE5• 11 years ago

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.

Udo• 11 years ago

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.

awinder4• 11 years ago

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

TeeWEE5• 11 years ago

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

dbbolton• 11 years ago

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

casesandberg8• 11 years ago

It's on the list for me to build!

https://github.com/casesandberg/react-color/issues/6

JDDunn94• 11 years ago

Looks really great. Why the React dependency though? Would be more flexible, faster, and avoid dependency hell if it was vanilla JS.

tajano• 11 years ago

Because React's cool for the next five minutes, and now we need to re-implement everything in React.

ultrafez• 11 years ago

"dependency hell" is a bit of an exaggeration. It has one dependency.

JDDunn94• 11 years ago

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)

andrewingram• 11 years ago

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.

ygra• 11 years ago

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.

drinchev3• 11 years ago

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.

clessg5• 11 years ago

See Michael Chan's presentation:

https://www.youtube.com/watch?v=ERB1TJBn32c

graffitici• 11 years ago

It's becoming more and more common. Check this out:

http://blog.vjeux.com/2014/javascript/react-css-in-js-nation...

jaen• 11 years ago

http://keithjgrant.com/posts/against-css-in-js.html

kylecesmat• 11 years ago

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.

clessg5• 11 years ago

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.

exogen• 11 years ago

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.

aidenn0• 11 years ago

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.

TeeWEE5• 11 years ago

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

ts3302• 11 years ago

Every time someone invents another framework, 1000s of hours are lost to rewriting these widgets - colour pickers, date pickers, drop-downs, combo-boxes etc etc. And that's before people complain about lack of flexibility and all the missing features their predecessors have accrued over time. More wasted time as people try to get to grips with yet another style of configuration, operation and tweaking to fit real world use cases.

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.

jewel• 11 years ago

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.

look_lookatme• 11 years ago

Doesn't support opacity, but this one does now.

jawngee• 11 years ago

Doesn't work on Safari either.

http://caniuse.com/#feat=input-color

tinco• 11 years ago

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.

spankalee• 11 years ago

Web Components

patio11• 11 years ago

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?"

obilgic• 11 years ago

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.

ts3302• 11 years ago

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.

HeyImAlex2• 11 years ago

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.

JDDunn94• 11 years ago

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.

dominotw• 11 years ago

http://webcomponents.org/

symlinkk• 11 years ago

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.

tonyblundell• 11 years ago

Which is exactly why we need a single new framework to rule them all!

mateuszf• 11 years ago

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.

gojomo• 11 years ago

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.

smaili• 11 years ago

Really slick but would be great if there was a browser compatibility listed somewhere.

markthethomas• 11 years ago

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!

ademup• 11 years ago

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.

casesandberg8• 11 years ago

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

casesandberg8• 11 years ago

This was fixed in 1.0.5, thanks :D

webosb• 11 years ago

does this work with react 0.14?

stevejohnson2• 11 years ago

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!

casesandberg8• 11 years ago

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!

stevejohnson2• 11 years ago

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.

TeeWEE5• 11 years ago

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.

TeeWEE5• 11 years ago

https://github.com/casesandberg/react-color/issues/13

KiaFathi2• 11 years ago

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?

casesandberg8• 11 years ago

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!

KiaFathi2• 11 years ago

Really cool, look forward to it!

React Color – Color Pickers from Sketch, Photoshop, Chrome and More

Related Stories