Skip to content

Unstable Sorting in EditorProvider#getToolboxGroups() Function #46

New issue

Have a question about this project? No Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “No Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? No Sign in to your account

Closed
mythsman opened this issue Oct 15, 2024 · 7 comments
Closed

Unstable Sorting in EditorProvider#getToolboxGroups() Function #46

mythsman opened this issue Oct 15, 2024 · 7 comments

Comments

@mythsman
Copy link

Although the sorting of EditorProvider#getToolboxGroups itself is stable, when adding steps using DefinitionModelBuilder#steps, the originally ordered steps get regrouped based on model.type . After that, using Object.values(this.definitionModel.steps) does not guarantee the order.

@b4rtaz
Copy link
Contributor

b4rtaz commented Oct 21, 2024

Hello @mythsman,

I'm not sure if I understand correctly. The getToolboxGroups method returns groups and steps in alphabetical order. For that, the localeCompare method is used.

	public getToolboxGroups(): ToolboxGroup[] {
		const stepModels = Object.values(this.definitionModel.steps);
		...
		categories.forEach((category: string | undefined) => {
			...
			groupSteps.sort((a, b) => a.name.localeCompare(b.name));
			groups.push({
				name,
				steps: groupSteps
			});
		});
		groups.sort((a, b) => a.name.localeCompare(b.name));
		return groups;
	}

Do you want to keep the order from the model builder?

@mythsman
Copy link
Author

@b4rtaz Oh, you know exactly what I want. I have confused 'the order from the model builder' with 'alphabetical order using localCompare' .

There's an issue when using localCompare because the displayed order may differ on machines with different language settings, which made me think it was due to unstable sorting.

So, I think maintaining the order as provided by the model builder might be a better choice.

@mythsman
Copy link
Author

And , i am currently facing a scenario related to node definition upgrade. I have designed a node that works perfectly fine. However, as the business grows, the definition of this node needs to be changed. Directly modifying the node definition is not an option since the old workflow definition wouldn't render correctly in the new workflow.

My current solution is to define a new node based on the original one and hide the old one in the getToolboxGroups. This would allow the new workflows to only use the new node while the old workflows can still read from the old node as usual.

Therefore, I believe adding a hidden property or similar in the Step or DefinitionModel, and then filtering it in the getToolboxGroups could be a better choice.

Of course, a custom getToolboxGroups could resolve all these issues as well.

@b4rtaz
Copy link
Contributor

b4rtaz commented Oct 23, 2024

@mythsman please check the 0.14.3 version. I added both features. If you want to keep the default order from the builder, you should use a sorter that does nothing (an empty function).

@mythsman
Copy link
Author

Thanks for your great work!

@mythsman
Copy link
Author

image

Oh ,you forgot to export it in index.d.ts 😅

@b4rtaz b4rtaz mentioned this issue Oct 27, 2024
@b4rtaz
Copy link
Contributor

b4rtaz commented Oct 27, 2024

@mythsman fixed in 0.14.4. Thanks!

No Sign up for free to join this conversation on GitHub. Already have an account? No Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants