Skip to content
New issue

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

By clicking “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? Sign in to your account

Issue/composer v2 #5985

Open
wants to merge 161 commits into
base: master
Choose a base branch
from
Open

Issue/composer v2 #5985

wants to merge 161 commits into from

Conversation

matborowczyk
Copy link
Collaborator

@matborowczyk matborowczyk commented Oct 15, 2024

Description

Pull request that merge all changes made to the instance composer to move away from old design and functionalities and make composer to follow form-like behaviour

Task that are still required for full redesign:

#5870 #5986 #5987 #5988 #5989 #5990 #5991

Screen.Recording.2024-10-16.at.12.39.47.mov

closes #5868

Self Check:

Strike through any lines that are not applicable (~~line~~) then check the box

  • Attached issue to pull request
  • Changelog entry
  • Code is clear and sufficiently documented
  • Sufficient test cases (reproduces the bug/tests the requested feature)
  • Correct, in line with design
  • End user documentation is included or an issue is created for end-user documentation (add ref to issue here: )

Copy link
Collaborator

@LukasStordeur LukasStordeur left a comment

Choose a reason for hiding this comment

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

I re-reviewed the first part of the PR.

changelogs/unreleased/5868-composer-v2.yml Outdated Show resolved Hide resolved
changelogs/unreleased/5868-composer-v2.yml Outdated Show resolved Hide resolved
changelogs/unreleased/5868-composer-v2.yml Outdated Show resolved Hide resolved
changelogs/unreleased/5868-composer-v2.yml Outdated Show resolved Hide resolved
serviceModel.inter_service_relations?.map((relation) => relation.name) ||
[];

const nestedRelations = serviceModel.embedded_entities?.flatMap((entity) =>
Copy link
Collaborator

Choose a reason for hiding this comment

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

For relations, you are adding the safe returning of an empty array, but not here. Typescript might still infer the result of the flatmap as undefined.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Here I should remove "?" because according to interface embedded entities in service model cant be undefined, I checked on test env it seems to align


/**
* Handles the event triggered when there are loose embedded entities on the canvas.
* The loose embedded entities are the entities that are not connected to the main entity. If there are any, they will be highlighted and deploy button will be disabled.
Copy link
Collaborator

Choose a reason for hiding this comment

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

What with the Inter-service relations? Is the deploy disabled too when a loose Inter-service relation is dragged on the canvas?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

no, I'll create ticket for that

};

setServiceOrderItems((prev) => {
// related instances aren't added to the serviceOrderItems map, this condition is here to prevent situation where we try to remove the related instance from the canvas and it ends up here with status to delete it from the inventory
Copy link
Collaborator

Choose a reason for hiding this comment

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

here too, be more explicit. what are the related instances?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I think it's quite explicit, especially that relation in app is I think exclusively related(no pun intended) to inter-service relation

Copy link
Collaborator

@LukasStordeur LukasStordeur Oct 18, 2024

Choose a reason for hiding this comment

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

Well, that's the thing, sometimes related is used for embedded or inter-service-relations. We have an explicit term, so we should use it to avoid any possible confusion. If we had no term for them, sure, but we have the right terms. There's no reason to re-invent them :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Is it used though? I never came across that use but, maybe I missed something, I'll change it :)

};

/**
* Handles updating the stencil state for the embedded entities.
Copy link
Collaborator

Choose a reason for hiding this comment

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

The name of the method isn't mentionning the embedded entities, maybe make the method name more explicit.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I removed the embedded entities part ,as stencil state holds only those, so it's redundant here, added more into description of the state in the context docstrings

Copy link
Collaborator

Choose a reason for hiding this comment

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

Did you push the changes? I don't see them.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

There all should be there

src/UI/Components/Diagram/Context/EventWrapper.tsx Outdated Show resolved Hide resolved
stencil.max !== undefined &&
stencil.current >= stencil.max;

// If the current count of the instances created from given stencil is more than or equal to the max count, disable the stencil of given embedded entity
Copy link
Collaborator

Choose a reason for hiding this comment

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

update based on feedback above.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

In case of what I wrote above, there is nothing to update, right?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Is it then worth adding a comment that is simply written differently than the previous one, but actually would mean the same?

Copy link
Collaborator

@LukasStordeur LukasStordeur left a comment

Choose a reason for hiding this comment

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

I haven't gone through some of the tests yet, but I'll do that Tuesday


/**
* create the stencil sidebar only left sidebar ref, the scroller, related inventories by inter-service relations, main service and service models are defined
Copy link
Collaborator

Choose a reason for hiding this comment

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

the comment make it feel like left sidebar is something else than the stencil sidebar, while they are in fact the same :)

</ZoomWrapper>
<StencilContainer
className="stencil-sidebar"
data-testid="left_sidebar"
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'd like it to be consistently called the same, either you opt for stencil-sidebar, or left-sidebar :)

/>
);
}
if (instanceWithRelationsQuery.isError) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

hmm, I see now what you meant in our call about this...
Perhaps this isn't the best solution either.
Maybe having the message/retry/ariaLabel in a React.state would make more sense, a bit like we do for the toaster in general? And have a useEffect on any of the errors which would update the state-variables. Just an idea for improvements, can eventually be a ticket to have a better look at how we do error handling in general for queries. When there are a few queries present on the same page, it sometimes becomes very repetitive.

stencil.max !== undefined &&
stencil.current >= stencil.max;

// If the current count of the instances created from given stencil is more than or equal to the max count, disable the stencil of given embedded entity
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is it then worth adding a comment that is simply written differently than the previous one, but actually would mean the same?

@@ -173,84 +160,210 @@ export function showLinkTools(
linkView.addTools(tools);
}

/**
* Function that creates, appends and returns created Entity, differs from appendInstance by the fact that is used from the scope of Instance Composer and uses different set of data
Copy link
Collaborator

Choose a reason for hiding this comment

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

Comment isn't exactly clear which one uses the scope of the instance composer. And does it use a different set of data, or different sets of date (isn't exactly the same)

const PADDING_S = GRID_SIZE;

/**
* Class initializing the Service Instance Stencil Tab.
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think the name should be more clearer, and it would be nice to specify what exactly this tab contains. In the designs it's called the New tab, maybe something with the new-keyword would make it clearer.

And since you're using classes, perhaps using inheritance in this very case could be interesting. I'm not that familiar with class based patterns. But I see some similarities between the two tabs

/**
* Class representing a stencil sidebar.
*/
export class StencilSidebar {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think it might be nice to have each class in a separate file and under a folder

}

/**
* IconButton class
Copy link
Collaborator

Choose a reason for hiding this comment

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

Naming this a class while it's a const can be confusing.

/**
* ZoomHandlerService class
*
* This class is responsible for managing the navigation of the canvas.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Paning would be a better word than navigation :) Navigation implies routing, or boats, or GPS

"fullscreen",
) as IconButton;

if (document.fullscreenElement) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

This if else could be improved like the snippet I gave you where you needed to toggle the classes.

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

Successfully merging this pull request may close these issues.

[Instance Composer] Create Details/Form sidebar
2 participants