Discussion: iro.js 4.0+

[jaames]

This thread is for discussion about future additions and changes to iro.js, starting with the next major version (4.0.0) and beyond.

So far, the feedback I've received has been overwhelmingly positive (thank you!!), but I've also noticed a need for the library to evolve into something more featureful and customisable.

When I started working on this project I tried to keep it as minimal as possible, one thing that's still really important to me is finding the right balance between having a low-friction, easy to comprehend API, and having enough features for it to be useful in different situations. Hence why I'd like to take some time to consider new additions and how they can be accommodated.

I've compiled an overview of the various features and changes I'd like to see:

• Overall goals:

  • Transparency support (see Request for a second horizontal slider for alpha transparency #22)
  • Lay down groundwork for plugins and custom UI elements (like the swatch requested in Request: A few options for configurable design tweaks #19)
  • New slider types for hue / saturation / transparency
  • Alternate layout directions, e.g left-to-right (see Request: A few options for configurable design tweaks #19)
  • Add support for custom handles (also see Request: A few options for configurable design tweaks #19)
  • New "group" component for composing layouts
  • Continue to improve documentation

• ColorPicker API changes:

  • New methods: mount, unmount, reset
  • Alias marker param with handle
  • Possibly remove the anticlockwise param and make it true by default
  • New layout param, which can be used for more advanced layout and custom UI elements:

  layout: [
    {
      component: iro.components.slider,
      type: "hue",
      height: 32,
      ...
    },
    {
      component: myCustomComponent
      custom component options...
    }
  ]

• Code improvements:

  • Tests! I really need to wrap my head around javascript testing frameworks and find a suitable way of testing that both the UI and API work correctly
  • Stop stressing quite so much about the size of the minified output, obviously keeping the library relatively minimal should still be an overall goal, but it shouldn't come at the cost of code quality
  • Rename marker ->handle, opts -> params internally
  • Consider debouncing color update events
  • Simplify internal SVG lib, add support for use
  • Add helpful warnings and checks to the dev build to catch common errors, but strip them out of the production build to keep it small

• Side projects:

  • Official iro.js component for React, Vue and possibly Angular
  • Optional integration with Chroma.js
  • Experiment with using Svelte and/or web components
  • Investigate using CSS variables instead of a full dynamic stylesheet writer

I should also note that development is going to be slow down for a bit, right now I'm trying to focus on other projects so I have a few extra portfolio pieces -- I'd like to get an internship soon :P

[adrianjost]

I already wrote an wrapper for iro.js for Vue. If you wan't I can share my single File Component with you.

[jaames]

Sure thing @adrianjost! I was actually hoping to use Vue to render the SVG ui as well, but I'll take a look :>

[adrianjost]

My current implementation can be found here: https://github.com/adrianjost/SmartLight-Firebase/blob/master/src/components/iro.vue
But it's only emitting the color change event with an hex value at the moment. I'm sure this could be improved anytime later. But my usecase didn't require that so far so it's not implemented for now.

[josephNg95]

Thank for your iro.js. This is awesome.
But it seems you are not interested in .iro_maker, for example, I want to take the position I must use document.getElementsByClassName('.iro_maker') and then handle it, take a position through transform attribute.
Anyway I just want to say thank you for this! 😄

[jaames]

@thuyettiensinh I'm not sure I understand, you want to get the .iro__marker positions? Can you provide an example case where that would be useful?

(Also, thank you very much for the kind words!)

[josephNg95]

let g = document.getElementsByClassName('iro__marker');

g[0].attributes.transform.nodeValue and g[0].transform.animVal[0].matrix

I can get transition value with this, but i think it's quite complicated

[jaames]

Figured I should give an update on the 4.0 progressL

Right now solving complex layouts is proving to be a major roadblock. With SVG everything has to be given explicit positions, there's nothing like css flexbox or grids. The way iro does layout is already messy (like, really messy), and it would get even worse if certain requests are implemented, such as alternate layout directions (#19), the option to remove the slider completely (#33, #10, #13), responsive layouts (#32), or extra elements(#22, #17)

I'll work something out, just might take a while. :P

[jaames]

Small update: I just pushed version 3.5.0, which rewrites API classes in the cleaner es6 class syntax, and moves the build process over to bili.

I hope this might encourage others to consider contributing to iro's development so that v4 can happen. :)

[mhadaily]

I have also written an Angular Module which is now being used internally in our project but I can make it public if it's interesting.

[jaames]

@mhadaily Sure! I personally haven't used Angular before so I think it might be helpful. :)

[jaames]

Another update: I'm thinking about overhauling the UI code and rewriting it with Preact! This is mainly because I keep hitting roadblocks with the internal SVG lib, and I think it needs to go.

There's some things to consider:

Pros:

• Much cleaner code, each UI element would just be a JSX component
• Anyone with React experience can contribute to UI code
• Would be much easier to implement v4 targets, and many more features in the future
• Can use standard Preact / React tools for testing
• Easier to port the UI to other frameworks

Cons:

• Larger bundle size (my estimate is about 20KB minified, or 7KB minified + gzipped). This doesn't bother me too much, although I would like to keep this library relatively lightweight -- we're currently at 13KB minified
• Performance cost... there's a lotta dom nodes. The hue wheel alone uses 360 svg arc elements, whenever the color changes each of these would be diffed in the vdom resulting in input lag. I'm pretty sure this could be optimised in some way, like by wrapping the hue arcs in a component where shouldComponentUpdate always returns false or something?

That said, I would love to hear some thoughts on this from devs with more production experience. :)

[mhadaily]

I personally suggest keeping your library purely in Javascript.

1- as you said it's lightweight
2- it always remains relevant to every frontend as it's pure javascript
3- optimization is up to you no the framework
4- you can approach more developers with different tastes, such as Angular, Vue and etc...
5- what you simply do in your library, really doesn't need another library/framework to handle dom manipulation so, I guess rewriting in a different framework for what you have already achieved it seems like a overwork.
6- you may say 20KB Gzip doesn't bother you but I guess this is really important, even 1KB is 1KB in the big project, so if you can instead make your code even lighter like from 13KB to 10KB or less. that would even better, so writing it in a different thing which makes it even larger I guess it's not a good choice.
7- I don't think writing in React/Preact with JSX leads to cleaner code! clean code can be achieved regardless of that. Although JSX may seem cleaner to you and React developer, I know many developers that they think JSX is not an optimal solution. so, I guess purely javascript can satisfy everyone not just group of developers.
8- Why you think anyone with React developer can contribute only? why not using something that everyone can contribute, I believe a react developer is also a Javascript develop so they can also contribute whether it's React or not!

Of course, it's up to you to make a decision, I just suggest what I think 😄

[jaames]

Thanks for the feedback @mhadaily! I think there may be a couple of misconceptions though, sorry if I wasn't clear enough ':)

it always remains relevant to every frontend as it's pure javascript

It will still be compiled to pure JS, just with preact's core bundled in -- everything on the surface will be exactly the same!

what you simply do in your library, really doesn't need another library/framework to handle dom manipulation so, I guess rewriting in a different framework for what you have already achieved it seems like a overwork

The current internal dom library really isn't suitable for a lot of things. For example, I'd like to be able to resize the color wheel after the initial render, but this requires the whole UI to be fully recalculated and redrawn in order to work properly. Simply passing new sizes to each UI component for them to rerender themselves would be far less complicated than manually changing different attributes with the current lib. :)

You may say 20KB Gzip doesn't bother you but I guess this is really important, even 1KB is 1KB in the big project, so if you can instead make your code even lighter like from 13KB to 10KB or less

It's only 7KB if gzip is used! I agree that this is maybe a bit much for a "lightweight" color picker widget. I'd love for iro.js to stay minimal, but I think a lot of people like the library for how it looks, not the small filesize, and they expect to be able to customise it more. If it becomes too heavy we could always branch off a "lite" version of the library that just has the basic features.

I don't think writing in React/Preact with JSX leads to cleaner code! clean code can be achieved regardless of that. Although JSX may seem cleaner to you and React developer, I know many developers that they think JSX is not an optimal solution.

I'm not a 100% fan of JSX, but I'm certain it will be cleaner than what's being used currently.

---

When I get the time I'll publish a preact branch to demonstrate, I think it will be better to show rather than tell. :)

[mhadaily]

Sounds Great, I think I misunderstood you then, looking forward to checking your new branch out. Happy to help and contribute as well.

thanks.

[d2kssc]

@mhadaily Do you mind to share your Angular Module for iro.js? I like to try it in my Ionic app.
Thank you!

[jaames]

Hi, sorry that it's been so long! Driving lessons/job searching/etc have taken up a lot of my time recently.

The Preact rewrite I was talking about earlier is mostly feature-complete now.I'm pretty happy with this direction, the UI code in particular is a lot clearer, plus it's now already possible to add third-party UI components and customise these components individually. You can see the code here: https://github.com/jaames/iro.js/tree/v4/src

There will be some small breaking changes to the API, mostly related to how the components fit themselves into the width/height dimensions provided when creating a new color picker. However these changes mean that it will be trivial to add commonly requested features such as the transparency slider or the option to have no sliders at all.

Let me know what you think!

[jaames]

Another update since the last couple of days have been really productive!

iro.js 4.0 is super close to being production-ready, and a bunch of commonly-requested features are already implemented, or very close:

• Color pickers now have a resize() method to change their size at any given time.
• Using your own custom SVG handles is now possible.
• A new Plugin API which allows you to extend iro.js to suit your requirements. This includes a variety of hooks that plugin authors can use to tap into color picker events.
• Custom UI components are close!! Soon, plugins will also be able to register their own SVG or HTML/CSS components that can be added into the color picker -- these components will use a React-like API, but with all the complicated mouse/touch event stuff automatically handled by the iro.js core.
• The Dynamic CSS feature is going to become its own plugin, in order to reduce the size of the main library and also add some extra functionality to this feature. Expect support for CSS variables and other neat things.
• Some of the color helper methods like mix(), lighten(), etc are also going to become a seperate plugin for the same reason. This plugin will also add support for more exotic color formats like CMYK and HCL.
• Estimated final bundle size is only 7kb minified + gzipped.

Next I need to rewrite the readme to make it easier to find information, and then I'm going to tackle updating documentation.

If anyone is willing to help test the new version please let me know! I'm also looking for ideas for more examples/demos of what can be done with the library. :>

[jaames]

I finally made the last few changes and released v4! Thank you everyone who contributed your opinions!