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

[2589] Improve the label component API to facilitate its customization #2590

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

frouene
Copy link
Contributor

@frouene frouene commented Nov 17, 2023

Pull request template

General purpose

What is the main goal of this pull request?

  • Bug fixes
  • New features
  • Documentation
  • Cleanup
  • Tests
  • Build / releng

Project management

  • Has the pull request been added to the relevant project and milestone? (Only if you know that your work is part of a specific iteration such as the current one)
  • Have the priority: and pr: labels been added to the pull request? (In case of doubt, start with the labels priority: low and pr: to review later)
  • Have the relevant issues been added to the pull request?
  • Have the relevant labels been added to the issues? (area:, difficulty:, type:)
  • Have the relevant issues been added to the same project and milestone as the pull request?
  • Has the CHANGELOG.adoc been updated to reference the relevant issues?
  • Have the relevant API breaks been described in the CHANGELOG.adoc? (Including changes in the GraphQL API)
  • In case of a change with a visual impact, are there any screenshots in the CHANGELOG.adoc? For example in doc/screenshots/2022.5.0-my-new-feature.png

Architectural decision records (ADR)

  • Does the title of the commit contributing the ADR start with [doc]?
  • Are the ADRs mentioned in the relevant section of the CHANGELOG.adoc?

Dependencies

  • Are the new / upgraded dependencies mentioned in the relevant section of the CHANGELOG.adoc?
  • Are the new dependencies justified in the CHANGELOG.adoc?

Frontend

This section is not relevant if your contribution does not come with changes to the frontend.

General purpose

  • Is the code properly tested? (Plain old JavaScript tests for business code and tests based on React Testing Library for the components)

Typing

We need to improve the typing of our code, as such, we require every contribution to come with proper TypeScript typing for both changes contributing new files and those modifying existing files.
Please ensure that the following statements are true for each file created or modified (this may require you to improve code outside of your contribution).

  • Variables have a proper type
  • Functions’ arguments have a proper type
  • Functions’ return type are specified
  • Hooks are properly typed:
    • useMutation<DATA_TYPE, VARIABLE_TYPE>(…)
    • useQuery<DATA_TYPE, VARIABLE_TYPE>(…)
    • useSubscription<DATA_TYPE, VARIABLE_TYPE>(…)
    • useMachine<CONTEXT_TYPE, EVENTS_TYPE>(…)
    • useState<STATE_TYPE>(…)
  • All components have a proper typing for their props
  • No useless optional chaining with ?. (if the GraphQL API specifies that a field cannot be null, do not treat it has potentially null for example)
  • Nullable values have a proper type (for example let diagram: Diagram | null = null;)

Backend

This section is not relevant if your contribution does not come with changes to the backend.

General purpose

  • Are all the event handlers tested?
  • Are the event processor tested?
  • Is the business code (services) tested?
  • Are diagram layout changes tested?

Architecture

  • Are data structure classes properly separated from behavioral classes?
  • Are all the relevant fields final?
  • Is any data structure mutable? If so, please write a comment indicating why
  • Are behavioral classes either stateless or side effect free?

Review

How to test this PR?

Please describe here the various use cases to test this pull request

  • Has the Kiwi TCMS test suite been updated with tests for this contribution?

@frouene frouene linked an issue Nov 17, 2023 that may be closed by this pull request
@frouene frouene force-pushed the fro/fix/label_api branch 3 times, most recently from 29d1f42 to 23a83d6 Compare November 20, 2023 09:40
@frouene frouene changed the title [doc] Contribute an ADR to improve the label component API [2589] Improve the label component API to facilitate its customization Nov 20, 2023
@frouene frouene added this to the 2023.12.0 milestone Nov 20, 2023
Bug: #2589
Signed-off-by: Florian ROUËNÉ <florian.rouene@obeosoft.com>
Comment on lines +66 to +71
<Label diagramElementId={id} label={data.label}>
<div style={labelStyle(data.faded, !!data.label.iconURL)}>
<LabelIcon />
<LabelText />
</div>
</Label>
Copy link
Member

Choose a reason for hiding this comment

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

Why are you changing the behavior of the label here. We were using the exact same Label component as in other nodes like ImageNode, no need to change that as part of this PR.

Comment on lines +24 to +25
minWidth: ({ iconWidth }) => `${iconWidth}px`,
minHeight: ({ iconHeight }) => `${iconHeight}px`,
Copy link
Member

Choose a reason for hiding this comment

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

This has nothing to do with this PR

@@ -82,6 +82,7 @@ export interface Label {
text: string;
iconURL: string[];
style: React.CSSProperties;
borderStyle?: React.CSSProperties;
Copy link
Member

Choose a reason for hiding this comment

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

The properties of the border can be defined in style why do you need a new property for that?

)}
{label && (
<Label diagramElementId={id} transform={`translate(${labelX}px,${labelY}px)`} label={label} faded={false} />
<div style={{ transform: `translate(${labelX}px,${labelY}px)` }}>
<DiagramLabel diagramElementId={id} label={label} faded={false} />
Copy link
Member

Choose a reason for hiding this comment

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

This label should probably be faded when it's relevant just like the other labels

display: 'flex',
flexDirection: 'row',
alignItems: 'center',
justifyContent: borderStyle?.justifyContent ?? 'flex-start',
Copy link
Member

Choose a reason for hiding this comment

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

If someone needs the label at the start of some div, they can just move the whole DiagramLabel component. This option is not necessary.

export const DiagramLabel = ({ diagramElementId, label, faded }: DiagramLabelProps) => {
return (
<Label diagramElementId={diagramElementId} label={label}>
<div style={labelStyle(faded, !!label.iconURL, label.borderStyle)}>
Copy link
Member

Choose a reason for hiding this comment

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

I don't think we need to consider the style of the label object, that's not relevant in the props of our component. If someone needs a border, they can add it the div containing DiagramLabel. Because tomorrow, someone else will come and ask for the customization of the CSS of the borderTop, or borderLeft or anything else. Just like transform was an issue related specifically to MultiLabelEdge, we have no need for a border or flex-start here.

};

if (label.id === currentlyEditedLabelId) {
return <DiagramDirectEditInput editingKey={editingKey} onClose={handleClose} labelId={label.id} transform={''} />;
Copy link
Member

Choose a reason for hiding this comment

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

Is that transform still needed?

import React from 'react';
import { Label } from '../DiagramRenderer.types';

export const LabelContext = React.createContext<Label | undefined>(undefined);
Copy link
Member

Choose a reason for hiding this comment

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

Just put an empty Label here and remove the undefined it will simplify tons of code below that should never be used if the label is not there. In case you need to explicitly handle the lack of value, prefer null next time to help distinguish values which do not exist.

@sbegaudeau sbegaudeau modified the milestones: 2023.12.0, 2024.1.0 Nov 23, 2023
@sbegaudeau sbegaudeau removed this from the 2024.1.0 milestone Dec 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add customization possibilities for node labels
2 participants