Skip to content
This repository has been archived by the owner on Jul 29, 2019. It is now read-only.

Nested groups order logic #3206

Merged
merged 12 commits into from
Aug 16, 2017
Merged

Conversation

yotamberk
Copy link
Contributor

fixes #3126 and refactor of nested groups logic

@wimrijnders wimrijnders self-requested a review July 4, 2017 06:51
@wimrijnders
Copy link
Contributor

For my understanding: the issue is that the nested groups appear in the wrong location, correct?

So, cook, clean house and shop should be placed directly under Lee.

Do I understand the issue like this?

Copy link
Contributor

@wimrijnders wimrijnders left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fix is good. The rest of the comments is me being bloody-minded.

Edit: TIL that 'bloody-minded' is not a nice word and that I got the meaning wrong. Truly sorry about that, I meant that I seriously looked at the details.

if (me.groupsData && me.groupsData.length > 0) {
var groupsData = me.groupsData;
if (me.groupsData instanceof DataView) {
groupsData = me.groupsData.getDataSet()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can groupsData be anything else than DataSet or DataView? Otherwise, there is no need for this test, DataSet has getDataSet() as well.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same remark for line 1687.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll remove it

if (groupData.nestedGroups) {
if (groupData.showNested != false) {
groupData.showNested = true;
}
Copy link
Contributor

@wimrijnders wimrijnders Jul 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This block is a tautology if showNested is always defined and boolean.

I can imagine, though, that it might not be defined and this sets a default value. In that case if (!groupData.showNested) { will do - and I think it's actually more correct in this case, since current condition implies boolean.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

groupData.nestedGroups is not required to be defined, hence the condition. This is the first place that basically defines it in case it isn't defined.

updatedNestedGroup.visible = false;
}
groupsData.update(updatedNestedGroup);
})
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hereby note that, when completely enabled, linting will yell at you about this. I propose that linting becomes compulsory when creating PR's - travis will fail on this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will be done

if (groupData.showNested != false) {
groupData.showNested = true;
}
groupData.nestedGroups.forEach(function(nestedGroupId) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Observation: This is the actual fix, correct? LGTM.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct

}
groupsData.update(updatedNestedGroup);
})
groupsData.update(groupData);
Copy link
Contributor

@wimrijnders wimrijnders Jul 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see why this call is necessary. It look superfluous to me. Why is it there?

Edit: Got it, it's for setting of showNested above. If you remove that assignment due to 'tautology', remove this as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It must be defined but I can make sure that the update is called once instead of calling update on every nestedGroup in the loop

@@ -1063,7 +1088,7 @@ ItemSet.prototype._onAddGroups = function(ids) {
ids.forEach(function (id) {
var groupData = me.groupsData.get(id);
var group = me.groups[id];

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pedantic overdrive: spaces in an empty line.
(I might be going over the top here, but I really do intend to review to the best of my capabilities)

@@ -1663,16 +1688,18 @@ ItemSet.prototype._onGroupClick = function (event) {
groupsData = this.groupsData.getDataSet()
}

group.showNested = !group.showNested;
var nestingGroup = groupsData.get(group.groupId)
nestingGroup.showNested = !nestingGroup.showNested;

var nestedGroups = groupsData.get(group.nestedGroups).map(function(nestedGroup) {
if (nestedGroup.visible == undefined) { nestedGroup.visible = true; }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Result of this overwritten by next line.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

true...


var nestedGroups = groupsData.get(group.nestedGroups).map(function(nestedGroup) {
if (nestedGroup.visible == undefined) { nestedGroup.visible = true; }
nestedGroup.visible = !!group.showNested;
nestedGroup.visible = !!nestingGroup.showNested;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not a direct assignment? nestingGroup.showNested is forced to boolean by line 1692.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

true. It was left when it wasn't forced to be boolean

if (groupData.showNested == false) {
updatedNestedGroup.visible = false;
}
groupsData.update(updatedNestedGroup);
Copy link
Contributor

@marcortw marcortw Jul 8, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that the senderId should either be forwarded here or no event be triggered at all (if that is possible).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@tfsarlo
Copy link

tfsarlo commented Aug 3, 2017

is there a way to use multiple levels of groups and subgroups? so far i have seen only 2 levels.

@yotamberk
Copy link
Contributor Author

@wimrijnders please review again =) I addressed the comments.
not my best PR... Good thing you've reviewed it well!

Copy link
Contributor

@marcortw marcortw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just two small proposed changes and one thing to think about. But besides that - very nice! I am eager to get this feature :-)


if (me.groupsData && me.groupsData.length > 0) {
var groupsData = me.groupsData.getDataSet();
console.log(me.groupsData instanceof DataView)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This log statement looks like a development leftover to me


group.showNested = !group.showNested;
var nestingGroup = groupsData.get(group.groupId)
nestingGroup.showNested = !nestingGroup.showNested;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When a nesting group is initialy loaded as 'open' (the implicit "showNested: true"), showNested is undefined. Negating it turns it to true which means expand, correct? This causes that an open loaded nesting group needs to be clicked twice. Adding this the line before should do the trick:

if (nestingGroup.showNested == undefined) nestingGroup.showNested = true;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah... I had that line removed because I though it had no use. I'll re-add it

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, that was due to my review comment. Fine, so it needs to be in.


if (group.showNested) {
groupsData.update(nestedGroups.concat(nestingGroup));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's a bit problematic to not have a sender here. But introducing something like a fake sender like 'nesting' wouldn't be clean either. My problem is that I catch the update event on the groups and do a lot of stuff afterwards. If there's no sender, I assume that the user modified the group, but in this case the user only cliked on the expand/collapse icon and didn't change the groups themselves. Let me illustrate this:

that.groups.on('update', function (event, properties, senderId) {
	switch (senderId) {
	case 'api':
		// do nothing / accept the changes
		break;
	case 'initialization':
		break;
	default:
		// item is supplied locally from the user/the library
		let currObj = that.groups.get(group.id);
		// --> update the changes to the API
	}
});

With your changes, I may now perform a rather complicated object comparison to see if the changes were only in the visibility of the group, but that's a bit cumbersome. Nevertheless, I have no good idea on how to approach this and I can live with it.

Copy link
Contributor Author

@yotamberk yotamberk Aug 12, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll take another look at it now.

EDIT: If you look at the other updates in the file, you'll see that none of the methods send a senderId. I don;t think it should be sent here either.

@wimrijnders
Copy link
Contributor

The travis test failing is at least partly due to #3313; it's not due to timeline. It's a unit test failing for network.

#3313 has been fixed to get rid of this testing error.

@yotamberk yotamberk merged commit 8c8f21d into almende:develop Aug 16, 2017
JobrianTrinidad pushed a commit to JobrianTrinidad/vis that referenced this pull request Aug 16, 2017
@marcortw
Copy link
Contributor

@yotamberk just a quick question: Are we supposed to push the child group id to the parent's nestedGroups array and then update the parent group? Or the child group as well? I only updated the parent group and it seems fine except for that one odd effect.

I am not sure if my code is buggy or if there's still a little bug in this PR - I experience an effect which (sometimes?) seems to cause that the last added child group is not properly nested in its parent group. It seems like an update to a child group's nestedInGroup property happens only after a subsequent update to any parent group. My updates lazily sneak in through an API. I might be totally wrong though, which is why I'd like to know how exactly an update is supposed to be executed by the library user.

@yotamberk
Copy link
Contributor Author

@marcortw Unfortunately this PR still does not resolve the problem of initially hidden nested groups so the issue you are dealing with is still open (there is an issue about it somewhere). It will need to be solved at some point. I'l currently trying to solve some other issues juggling my day job. I hope to be in holiday next week and pick up this issue aswell

primozs pushed a commit to primozs/vis that referenced this pull request Jan 3, 2019
* Fix sorting of nestedgroups when groups added after initial groups setting

* Fix nesteded groups logic when adding and removing

* Remove empty lines

* Fix comments from PR

* Remove spaces from empty line

* Fix PR review comments
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants