-
Notifications
You must be signed in to change notification settings - Fork 1
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
base: master
Are you sure you want to change the base?
Issue/composer v2 #5985
Conversation
…73-persisting-coordinates
Co-authored-by: Lukas <[email protected]>
Co-authored-by: Lukas <[email protected]>
Co-authored-by: Lukas <[email protected]>
…73-persisting-coordinates
…a/web-console into issue/5273-persisting-coordinates
…73-persisting-coordinates
…73-persisting-coordinates
…stanceWithRelations.ts Co-authored-by: Lukas <[email protected]>
Co-authored-by: Lukas <[email protected]>
Co-authored-by: Lukas <[email protected]>
Co-authored-by: Lukas <[email protected]>
Co-authored-by: Lukas <[email protected]>
…to issue/composer-v2
There was a problem hiding this 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.
serviceModel.inter_service_relations?.map((relation) => relation.name) || | ||
[]; | ||
|
||
const nestedRelations = serviceModel.embedded_entities?.flatMap((entity) => |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
Co-authored-by: Lukas <[email protected]>
Co-authored-by: Lukas <[email protected]>
Co-authored-by: Lukas <[email protected]>
Co-authored-by: Lukas <[email protected]>
Co-authored-by: Lukas <[email protected]>
Co-authored-by: Lukas <[email protected]>
Co-authored-by: Lukas <[email protected]>
…stanceWithRelations.ts Co-authored-by: Lukas <[email protected]>
Co-authored-by: Lukas <[email protected]>
…to issue/composer-v2
There was a problem hiding this 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 |
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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.
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