Show HN: I Made JavaScript Color Conversion Library for LCH/Lab/XYZ/RGB/Hex/HSL
github.com
github.com
Do you have any plans to add interpolation functionality to ac-colors?
I’d expect such a library to be way smaller (I dunno, but less than 10KB/4KB), and preferably support tree-shaking so that I can just pick out the hcl() function, for example, if that’s all I want.
At the end of the source there's a section where you can comment out lines which should remove sections of the code when compressing it.
Also no mention of what kind of RGB it is. From the xyzToRgb function it seems to be[1] sRGB but that should be mentioned, and also consistent throughout the library (in case it isn't).
[1]: http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix....
I think it would be better to have a function in the library that does this. Then it can be extended to allow for more clever things than a simple min/max clamp.
Color is a great example of how "low-order" approximations are very useful, and how quickly it can get very hard once you want to go a bit beyond that.
They've got pretty extensive and awesome documentation. I discovered it a couple of months ago.
https://twitter.com/colour_science/status/125826870601631744...
Curious what your library does differently aside from API design. `color-convert` has been around for years and has supported all of these algorithms plus more - and it does a BFS search to convert between models that do not have an explicitly written conversion algorithm.
I'm not one to say "don't do this", but I'm generally pretty against re-inventing the wheel if there's something to be improved upon.
Comments!
My advice would be to add comments to the code. Comments shouldn't repeat the code, but e.g. describe what it's doing, or provide links to where the formulas come from and what they mean. It's also helpful to document overall code structure (where do I go to find something?).
Formatting!
And to run it through code quality tools. A lot of minor styling issues. It could use more new lines (esp. between functions).
These sorts of things might seem minor, but they matter if you're applying for a job. A lot of people will give a cursory glance at your code repos to see if everything looks reasonable or if there's anything insane. These sorts of surface features make a disproportionate difference.
Plus, they really do help. A lot of your users might not know what LAB colors are, or how exactly HSV is computed.
"The source code is in `index.js`. In order to build the minified version, run `[command]`. [description of what `index.js.min` is, and how it compares to `dist/ac-colors-min.js`] [Maybe short description of other travis commands used during development]"
Basically, imagine you're running into this repo having never looked at it before. What do you want to know?
From there, you can go one level deeper, and document `index.js`. It's not rocket science, but it is helpful. For example, I have no idea what `256colors.js` is, or how it's used for testing. That should be either a comment at the top of the file, or in the README (depending on how important the file is).
When you go into `index.js`, it's nice to have an overview of what's what in the file, and how it's structured. I like when docs are build from files, actually (so instead of all of this in `README.md`, you have that in comments in code, and build to something like `README.md`). I also like having clearly documented inputs and outputs.
I also really recommend blank lines between functions. This is especially true if you have blank lines within functions. lchabString, lchab, and the first part of rgbtoHsl fuse into one big code paragraph right now.
I wouldn't necessarily take what I say as how you ought to do it -- that's a question of style, and how I solve these problems. Take it more as a problem statement and example solution.
That stuff is tricky.