Allow customization of icons

[jakezatecky]

Currently, the iconset is tied to Font Awesome. Ideally, we would also allow the customization of these icons. Could possibly set this as a property to the tree itself or allow the specification via :before CSS property.

[imkevinjones]

What about adding an "icon" property to the supporting JSON object to provide an image? This would be very useful.

[jakezatecky]

@kevinpwns If I interpret you correctly, you are suggesting being able to specify icons on individual node levels? I suppose we could support this, but it might be a different feature track on its own. The question is do we allow ALL icon types to be replaced. i.e. the chevrons, folder, file, etc, or just the file/folder icon?

Currently thinking about allowing the developer to pass in nodes OR classes for the various icons. Might have an icons property with the various types as such:

{
    leaf: <i className="fa fa-file-o" />,
    parentClose <i className="fa fa-folder-o">,
    parentOpen: <i className="fa fa-folder-open-o">,
    collapseClose: <i className="fa fa-chevron-down" />,
    collapseOpen: <i className="fa fa-chevron-right" />,
    check: <i className="fa fa-check-square-o" />,
    uncheck: <i className="fa fa-square-o" />,
    partialCheck: <i className="fa fa-check-square-o rct-half-checked" />,
}

I am thinking if I go along that route, I might remove hard references to Font Awesome in the HTML and just extract it all into the CSS, such that a user need only alter the style without having to supply potentially verbose properties, but he or she could still specify HTML-level icons.

[imkevinjones]

Yeah mate, that's exactly what I was thinking. I've got a modified version of react-checkbox-tree that has both node-level defined icons and pessimistic/optimistic toggling. It's provided incredible flexibility. Fantastic work on this library, BTW. Best React checkbox library available.

[Gillingham]

For at least checked/uncheck is there a reason to use font-awesome there at all instead of a normal checkbox with indeterminate state for the partialCheck?

[jakezatecky]

@Gillingham The indeterminate state in normal checkboxes cannot be set through HTML. They are set through JavaScript invocations after the element has already been rendered in the browser. Updating an element after it has been rendered is not a very React-y approach.

There's been talk about adding it as a property to <input> elements, but I personally think it should be omitted until the HTML specification supports it.

Even if you could specify indeterminate through HTML, native browser checkboxes visually vary wildly from browser and operating system, and this library wants a consistent look and feel across all browsers. Since we are already using Font Awesome for other icons, it made sense just to make use of what was already available there.

[Gillingham]

Little late to suggest this, but perhaps an alternative to the implementation of 09c4e7d would be the ability to simply specify the class names, or class name prefix via props instead of having to potentially duplicate CSS entries? That seems like a cleaner solution then restricting everything to fixed class names which any user has to implement when they may have existing classes that apply very well to things used by this framework

[jakezatecky]

@Gillingham A primary reason things were shifted to CSS was to decouple the dependency on Font Awesome from the markup, and to not require that user add boilerplate properties to the component itself when it could be achieved in achieved in CSS. If you have existing classes, you can always use the @extends syntax or equivalent in your CSS preprocessor and override the library's classes.

Markup-level specification can be added to this component, but I am curious as to which icons you would find useful to alter. I can add support for all icons similar to my earlier comment, but I do not know if anyone finds value in changing ALL of them.

If we add support for the above, the CSS option would still exist as the preferred alternative, so we would have full backward compatibility. The newer specification would potentially more exotic icon configuration, but the developer would have to be aware that significant deviations might make the icons mis-align.