feat: Added support for single select in tree dropdown

[ellinge]

What does it do?

Adds support for single select in the tree dropdown. Simple select ignores any children so this is a hybrid between the two.

Also ignores clicks for simple select when labels are disabled (only checked readonly)

The middle dropdown is radioSelect and the last one a simpleSelect
https://ellinge.github.io/react-dropdown-tree-select-test/#DevelopTemp-checkeddefault

Fixes #119

Type of change

• Bug fix
• New feature

[coveralls]

Pull Request Test Coverage Report for Build 1058

• 60 of 63 (95.24%) changed or added relevant lines in 5 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.7%) to 95.591%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/index.js	10	11	90.91%
src/tree-manager/index.js	18	20	90.0%

Totals
Change from base Build 1030:	0.7%
Covered Lines:	357
Relevant Lines:	364

---

💛 - Coveralls

[ellinge]

@mrchief this one should be up for grabs. I did not change the behaviour for simpleSelect so if that is something you think we should do instead, it would require additional changes.

I also noticed on the storypage that simpleSelect is not working great with default values, which also applies to this solution. Only one default value should be possible and should be deselected when selecting something else.

[mrchief]

I did not change the behaviour for simpleSelect so if that is something you think we should do instead, it would require additional changes.

Just one question - with this change, can we manage simpleSelect without the need of an additional flag?

I also noticed on the storypage that simpleSelect is not working great with default values, which also applies to this solution. Only one default value should be possible and should be deselected when selecting something else

Great! Thanks for taking notice and fixing it!

[mrchief]

Few comments to note

[ellinge]

I did not change the behaviour for simpleSelect so if that is something you think we should do instead, it would require additional changes.

Just one question - with this change, can we manage simpleSelect without the need of an additional flag?

@mrchief Not sure what you mean with an additonal flag. Simpleselect should still behave as before. Did not want to break that so added singleSelect. If you provide both simpleSelect and singleSelect it will behave as before (no children)

I also noticed on the storypage that simpleSelect is not working great with default values, which also applies to this solution. Only one default value should be possible and should be deselected when selecting something else

Great! Thanks for taking notice and fixing it!

Unfortunately did not fix the issue since that requires some more digging. Should be a separate issue.
Fixed now, se below

[ellinge]

I bundled the selection of rendering / behaviour mode into a single prop instead like we discussed in the keyboard nav PR. We can fill the migration steps with additional breaking changes (for on action) and if bundle the text-props also.

Not sure how you want the guide formatted but perhaps you can update it to match your idea.

I added the textprops-bundle in this pr as well (without the new labels). With the onaction-changes we would cover all breaking changes needed for a release I think if we want to wait with ARIA/kryboard nav.

[mrchief]

I added the textprops-bundle in this pr as well (without the new labels). With the onaction-changes we would cover all breaking changes needed for a release I think if we want to wait with ARIA/kryboard nav.

Will it be too much to take out the bundle props out of this?

I think radioSelect, ARIA, keyboard nav are all backward compatible changes so we can merge them first and release them incrementally. onActions and bundle props then become part of the v2 release.

This release sequence lets v1 folks to not miss out on most new features. Upgrading to major versions is generally considered a bigger undertaking and makes people hesitant in upgrading which would cause them to miss out on accessibility and radio select for no good reason.

I'm open to arguments otherwise.

[ellinge]

Well since you became reluctant with the prop additions I thought it would be odd to first add them and then in the next release move them. I see all these features as major additions and the migration steps simple enough to not scare any people away. Radio select and noaction could be 2.0 and wcag 2.x.x with this paving the path to naturally add new labels. But I can revert them...

Otherwise the major thing of 2.0 would be to the bundle of props and actually getting onAction to be useful without generating your own specific id:s to base your logic upon.

The addition of typings is also the reason why we found the bugs with onAction, which would also be part of the major update. Lots of candy to remove any hesitation from users imho.

[mrchief]

These are major additions, no doubt about that. But not everything is a breaking change. Another reason for releasing them separately is backward compatibility. Id-generation logic, Radio Select, ARIA, Keyboard are all backward compatible. Releasing them as v1 will make it a frictionless upgrade for anyone. And upgrading to 2.0 is not a big hurdle but it still requires some changes.

You've done a great job at sending them as separate PRs and I'd like to take advantage of that fact. I can help with this process as well.

[codeclimate]

Code Climate has analyzed commit b1d6ef6 and detected 0 issues on this pull request.

View more on Code Climate.

[mrchief]

@ellinge Thanks for the quick update. You're the best! I'm gonna merge this unless you have any other changes to make. Let me know.

[mrchief]

Huge props for sending this!

[mrchief]

🎉 This PR is included in version 2.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀