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

feat: edit data in nested table (PT-188211532) #40

Merged
merged 3 commits into from
Sep 13, 2024

Conversation

emcelroy
Copy link
Contributor

@emcelroy emcelroy marked this pull request as ready for review September 12, 2024 20:36
Copy link

@tealefristoe tealefristoe left a comment

Choose a reason for hiding this comment

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

This looks good, but I do think it would be worth updating some types before merging.

I know you didn't add the anys that I pointed out, but this would be a good opportunity to fix them. I mentioned that you could just do something like type Case = any, but I bet something like this would work:

interface Case {
  id: number
  values: Values
}

I also think it would be better to use Cases instead of CaseValuesWithId.

I'm approving because I don't think this should hold up the PR if there's any urgency, but I do think it would be worth spending an hour or two to make these changes.


export const EditableTableCell = (props: IProps) => {
const { attrTitle, caseId, children, handleUpdateCollections, selectedDataSetName } = props;
const displayValue = String(children);

Choose a reason for hiding this comment

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

Would it make sense to make this a displayValue: string prop, rather than casting a special ReactNode?

import { DraggableTableContainer, DraggagleTableHeader } from "./draggable-table-tags";
import { getAttrPrecisions, getAttrTypes, getAttrVisibility } from "../utils/utils";

import css from "./tables.scss";

interface IFlatProps extends ITableProps {
items: Array<any>
cases: Array<any>

Choose a reason for hiding this comment

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

It would be great to start removing any types. Even if you just define type Case = any in types.ts, this would at least allow future engineers to see where cases appear in the codebase. But maybe you can do better than that?

@@ -18,21 +18,22 @@ interface IProps {
selectedDataSet: any;
dataSets: IDataSet[];
collections: ICollections;
items: any[];
cases: any[];

Choose a reason for hiding this comment

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

Another any here.

Comment on lines +118 to +119
return Object.keys(aCase).map((key, index) => {
if (key === "id") return null;

Choose a reason for hiding this comment

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

I get the feeling that it would be simpler if you passed a Case object in, instead of a Values object with a special id value. Then you could just map through aCase.values.

@emcelroy
Copy link
Contributor Author

@tealefristoe Thanks 👍 I started improving the typing a bit. I'm pretty sure your other suggestions make sense, but I want to consult with @lublagg when she's back next week before implementing them. Since we're going to continue working in the same parts of the code, I'm going to merge this and we'll possibly make the other changes in the next PR.

@emcelroy emcelroy merged commit 2e11cab into main Sep 13, 2024
5 checks passed
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.

2 participants